Angle measurement for balancing robot.

[HenrikOlsson]

Ioannis,
I don't think Joe can stand from a horisontal position on it's own. If I ever get mine to work it will hopefully be something like this one:

http://www-robotics.cs.umass.edu/Res...uBot/uBot.html

In one of the videos they show how it recovers from its "resting" position. Very cool and stable two wheeler.

The math seems to range from rather complicated to extremly complicated. Since my mathskills are rather (very, in this case) limited I'm aming for complicated at the most. I'm confident it CAN be done with PBP i just have to understand HOW it works.

I have quadrature encoders mounted on the wheels and I'm thinking I can calculate the robots acceleration by comparing current speed with previous speed and subtract that from the acceleromter reading ending up with 'pure' tilt. My concern now is that the resolution of the encoders are to low. But hopefully I'll be able to understand this Kalman thing any year now..... ;-/

Atleast it's a fun project :-)

/Henrik Olsson.

[ronf]

I don't know if anyone has investigated this one
http://www.circuit-ed.com/accel.htm
Might be worth a try for the angle part and not toooo much $.

[vacpress]

soo..from reading the nuts n volts article, i think the PBP is fast enough. After all, PBP gets compled into ASM, even bloated ASM will run pretty well at 40mhz with only a few tasks, right? this is the advantage of picbasic over parallax..

the nuts n volts december 2006 article pretty much spells it out.. in c though.. they use a RTOS as well.. real time operating system.. this is a type of OS with direct control of hardware. windows is not RTOS, linux is, for example..

the october 2006 article, which i cannot find covers the math, probably in pretty easy to understand terms.. i suggest you look for that... otherwise why not teach yourself the mathematics you need? how hard can it be? brak it into bits... find the main equation and do your best to understand it, then look at some code... the code will look much different...

ive never tried this type of project, but there are a ton of resources.. i watched a video of some really stable 2-wheelers.. off roading, over curbs, etc... also a relaly cute one that could follow children wearing red and had very compelling movement characteristics due to the PID correction being a bit coarse... it dipped and swayed with the child...





anyways... they list these resources:

www.geology.csmu.edu/~dpa-www/robo/nbot

http://autopilot.sourceforge.net/gallery.html

barello.net/Robots/gyrobot/index.htm

jormundgand.net/projects/crunch/

sparfkun.com

--------------------

[HenrikOlsson]

Ronf,
Thank you for that link, good price on that one! But it is a acceleromter so it won't work (on it's own) for sensing tilt in a dynamic enviroment. I have the sensor hardware covered, accelerometer and gyro, it's how to combine the two readings into one stable tilt angle that is the problem/exercise.

Vacpress,
Thank you! The Kalman code that I posted IS from the NV article. They in turn probably got it from the AutoPilot project on Sourcforge, it's written by Trammell Hudson at Rotomotion. They supposedly used to make low cost IMU's but seems to have moved on to bigger high dollar things.

It was indeed the nBot that got me started on this. I have since looked at everything I could find on the net.

What you say about learning the math is what I'm trying to do here ;-) If someone already had ported it PBP it would be easier (relative term) to understand it than from the C code from Rotomotion.

It seems that some get away by just integrating the rate gyro signal but that doesn't work to good with my sensor, which is the ADXRS150 that I got from www.sparkfun.com

I took the same route as the nBot creator and started by balancing a pole on top of a stable (non tilting) platform. So I have the PID code for driving the motors once I have stable tilt angle feeding the PID regulator.

This is a complex project, motivation and time comes and goes but i WILL make it work, someday.... ;-)

Thanks guys!
/Henrik Olsson.

[Luciano]

Hi Henrik,

Why not work first on a simplified version of
the self-balancing robot?

==========================================
Version 1: (For flat surfaces only / indoor).

Use a Sharp infrared sensors to measure the distance to
the floor and uses that information to deduce tilt angle.
==========================================

==========================================
Version 2: (For flat and inclined surfaces).

Encoders + rate gyro
==========================================

Try the second version of the self-balancing robot only when
version one works as expected. I am sure that you will
able to re-use part of the code and experience developed
during the realization of the first version.

Best regards,

Luciano

[HenrikOlsson]

Luciano,
Absolutely!! 2 Sharp GP2D120 ordered from ARRobotics, hopefully they'll be here within a week or so. If (when) I get that to work it will boost my motivation even further.

Thanks!
/Henrik Olsson.

[uffi]

Hi Henrik,

I am also working on a balancing robot. My platform is an ATMEGA16 with L293D motor controller ICs and I am using a two-axis accelerometer board built with Freescale MMA2260DR2 for x-axis and MMA1260DR2 for z-axis with a bandwidth of 50Hz, which should be fast enough for a pure accelerometer solution. The robot's mechanical structure is built with Fischertechnik components. I also use a rate gyro CRS03-02 by silicon sensors (bandwidth 10 Hz, which could be a little too slow).
I also asked myself whether it could be possible to use only the accelerometer alone or the rate gyro alone. To solve the problem of the acceleration of the robot influencing the measurement values of the two-axis accelerometer I would like to suggest the following to you:

First of all I would recommend to use both readings of the two-axis accelerometer. The accelerometer should be placed in the height of the motors. If you use the x-axis in direction of the robots acceleration and the z-axis in the direction to the sky or ground (starting initially without tilt), both the tilt and the acceleration can be calculated from the data using trigonometric relations and solving a squared equation. I used the drawing in the paper of Joe Le Pendulum for reference, see attached file Tilt_Angle.doc or their paper on the web, Figure 5.

Then the forward (or backward) acceleration a of the robot can be calculated to:

a= +- SqareRoot( Square(x) + Square(z) - 1)
+ for the case a>0
- for the case a<0

and

tilt=arcsin((x-z*SquareRoot(Square(x)+Square(z)-1))/(Square(x)+Square(z)))
# for the case a>0

tilt=arcsin((x+z*SquareRoot(Square(x)+Square(z)-1))/(Square(x)+Square(z)))
# for the case a<0

tilt=arcsin(x)
# for the case a=0

All values are normalized to the earth's acceleration g (g=1).

The remaining unknown figure is the sign or direction of the acceleration a to get the correct result for the tilt. This could be derived from the motor control comparing the motor power during the last two control steps before this measurement.

For the motor control it is then essential to use in addition to the tilt also the tilt change rate (for a PD regulation) by comparing the last two tilt values (differentiating), because if you only use the tilt itself, the reaction of the motors will be too slow.

If you only want to use the rate gyro alone (as was done for Joe Le Pendulum), then you need a way to compensate for the gyro's drift. A simple way of doing this could be to work with a running average for the offset. Make a reference measurement of the offset as a starting point and keep the robot in an upright position for a short time after releasing the reset button. Then update the offset with a weighted value of the rate measurement, such as:

offset_new= offset*(999/1000)+ rate/1000

for every new measurement of the rate. The weighting should be adapted to the timing period of your measurement updates. By this the drift of the gyro could be compensated. I am working on this tuning at the moment. Assuming a measurement timing period of 10ms (100Hz), the above equation would correspond to a low pass filter with 100Hz/1000=0,1 Hz filtering the dc component of the measurement signal to be used for the offset.

All this I am writing here is still in an experimental state and are thoughts I developed during my research over the last weeks. I hope you can make use of these ideas. If so, please let me know. My own robot is not yet perfectly balancing, I am tuning the PD regulation constants and the offset filtering at the moment based on the pure gyro rate approach. Next step I will do then is use the pure accelerometer approach.

Kind regards, uffi.