Update 31/01/14
Chassis arrived
Put together
Mounted servos.
Looking good.
Just need to work out the best way to get power to the servos. Also need to determine the best configuration for the arduino and (future) pandaboard.
Starting to get a little excited. I think this could actually have some chance of working.
Nice work!
We built a similar project. However, we installed an Android device onto a RC car and used an IOIO board instead to control it autonomously. Here is the preliminary result:
http://youtu.be/vkvkfcqEUkk
thanks
There’s still a bit of work to go…
The latest news is I was able to order the pandaboard from digikey. The bad news is its huge and I’m going to have to rethink a few design aspects…
no problems
What would you like to know?
There’s three main components:
1) opencv library to perform the image processing and object detection using hough circles on masked video frames
2) serial comms to send the commands to the arduino using libserial
3) ardunio reads the command string and moves the servos and runs the motors accordingly.
Soon I will add obstacle detection and avoidance which will involve feedback from the arduino. At the moment the arduino is not doing a great deal.
1 reply
Re: Since i am firly new to open
For us, having the servos move smoothly was a challenge since we can only get 16fps using OpenCV at a minimum resolution of 176x144. At that refresh rate it was not possible to track the object using the camera thread so we decided to use the microcontroller thread instead to call the PID every 10ms. That means that the COG is calculated every 60ms at the end of each frame so there will be 6 PID cycles for each frame to update the servos; which also means less blur on the image. Here is the result:
1 reply
Impressive
I would be happy with 15fps, at the moment I get about 3 - 5 with considerable lag on my setup which is a celeron 900 running Ubuntu 12.04 desktop.
The way I compensate for the lag so far is instead of attempting to track in realtime, when the object is noticed, it will tell the servos to move straight to that position where it last saw it and make that the centre of the screen. This is done by calculating an offset angle relative to the camera angle of view, I roughly calculated mine to be about +/- 11 and 8 degrees for horizontal and vertical. If it has moved away by the time it gets there, then hopefully it is still within the frame, if not, it goes looking.
The result is fairly jerky, but it matches what I see happening on the camera.
I’m hoping that the headless odroid running hardfloat ubuntu server will achieve better fps which should improve it a fair bit. (I compiled the kernel last week, odroid should arrive this week I hope.)
The other thing I could do is set up two threads. One simply tracks the object and populates the result which is read by a second thread that calculates the servo positions.
It wouldn’t be much faster, but it may free up some cycles to be used for the opencv side of things.
1 reply
Why dont you create dynamic
Why dont you create dynamic threads which your second thread will read through each thread with the highest priority (latest value) while your first thread reads the second thread?
1 reply
Not sure I follow, but thanks
At the moment I have 2 worker threads, but they are not dynamic. I have overloaded virtual functions for each thread. It gets around the problems of using classes quite nicely.
I have two classes, one performs the serial functions and the other the image processing. Each have members that need to be accessible from the threads. Static functions won’t cut it in this situation apparently, so I have to use function pointers in my threads.
It is fairly basic threading, a loop with an exit condition. I have worked with threads before in c#.net (I’m a software developer irl), but posix threading is something I learned in 2-3 days.
I’ll take a look at dynamic threads and see whether they can help.
1 reply