Self Balancing Robot using Computer Vision

armcontrol systemembeddedimageprocessingpid controller

I'm planning to implement a Self Balancing Robot which is usually implemented using a gyroscope sensor which gives feedback to the micro-controller to adjust the position with wheels. I'm looking into an option of controlling using Computer Vision (OpenCV).
Firstly, looking at a similar project PID algorithm implementation using computer vision
i'm convinced that it is not quiet easy to implement without the right tools and good concept.

I have an Arduino Uno board which i will be using for controlling the DC motors. I still have to decide on the Embedded System board which i should be using (Mostly ARM Processor based, like Raspberry Pi, Beagleboard etc), the selection of processor depends upon the speed of the application. A webcam mostly, but i'm looking into other cameras as well.
CMUcam

Control algorithm used will be PID implemented in the Processor. The bound box is what i intend to use to observe the change in motion and then use error correction via a Ethernet port or wireless depending upon the speed needed.

Please do comment about the drawbacks and flaws of the design.

OS of the processor : Linux distro (Ubuntu or Debian), initially i thought about RTOS(Real Time OS), but i guess it is too complex.

Need your valuable feedback.

Best Answer

I have worked with self balancing robots in my bachelor and master thesis. Ad hoc I see these problems, that will very likely get in your way.

  1. Self balancing robots are instable by definition. You have to collect data from your sensors (the camera) fast enough, to react to changes in the attitude of the robot. So the question is: can you process the information from the camera fast enough to stabilize the system (dead-time)?

  2. Gyros will give you the angular acceleration along the axis. But with your camera you have something that correspond to the angle. To clarify this, you can not get the angular velocity or even angular acceleration with just one picture. You have to do some processing based on multiple pictures. That means you need more time => greater dead-time. Also this processing will probably introduce noise, which will complicate the controller design.