Angle measurement for balancing robot.

[HenrikOlsson]

Hi,
(Long winded story...)
I'm working on a two wheel inverted pendulum balancing robot. (photo attached). The basic idea is to sense the angle of the robot relative to gravity and drive the wheels so that they are right under the robots center of gravity.

To do this I need to meassure the tilt-angle of the robot and for this I have an ADXL203 dual axis accelerometer (only one axis in use). Now this would work perfect if it wasn't for the fact the accelerometer measures, eeh...well acceleration.

As soon as the robot accelerates to compensate as it starts to fall over the reading from the accelerometer is no longer only proportional to the robots tilt-angle.

In comes the gyro....an ADXRS150 in my case. This is a rate gyro, ie it
outputs a voltage proportional to how fast it's turning. If this voltage is integrated over time it's proportional to the difference in tilt-angle compared to the angle at power-on. In a perfect world, that is. The problem here, as you probably know, is that the gyro's bias is drifting pretty fast so the 'angle' value isn't accurate for very long.

Now, in researching other inverted pendulum robots, (like the nBot, bBot, gyroBot, etc) they all seem to 'merge' the readings from the acceleromter and the gyro via either a complementary filter or a Kalman filter. I have found code (GNU) from a heli auto pilot project for a Kalman filter
but the math is a bit daunting and it's written in C (whatever that is... :-)... just kidding).

Anyway, have anybody of you done anything like this with PBP and/or is willing to have a look at/work with me on porting the Kalman code to PBP (if possible). Or do you have any other ideas on how to acomplish this.
(Except for buing a FAS-G inclinometer for $795, that is)

Sorry for the long post, just wanted to show that I've done my homework ;-)
I do have a short video of it actually balancing (briefly) but I can't seem to upload it here.

TIA
/Henrik Olsson.

[SteveB]

I don't know if it helps, but I seem to remember someone using "range finding" as a technique. They used two sonar modules to measure the distance from the top of the robot to the the floor, then did some less arduious math to compute the angle. I can't remember if this was a "concept" or it was actually implemented successfully.

Cool project, BTW. Good Luck,
SteveB

[vacpress]

Nuts N' Volts magazine has recently run 2 articles about this exact topic. They used picc i think, but the concepts are close.. Their robot used hobby servos, sumobot wheels, salvo RTOS, and some fairly simple looking code. If you cannot find it, i can tell you issue #s when i am at home..

basically their bot used just a 2-axis gyro, if i recall, and an AVR.. not a pic.. no PICC.. Hmm.. At any rate, you can checkout their code, it probably avoids Floating point math, which will help you.

There is another method out there that peopel seem to actually have some success using; which is to use 2 IR range sensors pointed at the ground... Seems much slower than a gyro\accelerometer.. but, what do i know..

hope that helps at least a little.
-R

[sayzer]

I suggest that you use a third wheel.

You will not need to write complex coding and save a lot of coding space and parts.

[HenrikOlsson]

Hi,
I've seen the IR-approach, there's a really cool working system here: www.balbot.com The thing is I'm not sure of the idea since the surface has to be flat - or atleast that's what I think. You can't run up or down a slope for example since the difference between the front and back sensor will be different. The same drawbacks would apply to the ultrasonic transducer approach. Besides, I already got the gyro and accelerometer.... ;-)

I seem to recall someone mentioning the NV article a while back. I may even have seen it and if I have I think they used the same kalman filter code I'm refering to but I may very well be wrong on that point.

I've been working on this on and off for the last 7-8 months, so I'm not gonna give up and put in that third wheel just yet but thanks anyway sayzer ;-)

Thanks guys! Please keep the ideas comming!

/Henrik Olsson.

[Darrel Taylor]

Hi Henrik,

Don't know if this will help or not, but one of our members, Tom Igoe, has a routine that's supposedly "based" on a kalman filter.

http://www.tigoe.net/pcomp/code/arch...o/000710.shtml

Versions in C and picbasic.

Don't know enough about it to know if it's what you're looking for.

HTH,

[RodSTAR]

I suggest that you use a third wheel.

You will not need to write complex coding and save a lot of coding space and parts.

LOL that's innovative !!

[RodSTAR]

Well,
interesting project, in fact i did that some years ago with stepper motors, hardware talking, you must combine both sensors accelerometer and gyro, aswell as obvious other sensors for not to mess with walls and other more complex obstacles. I applied kalman in C, in those times, I'll try to give myself a time to work in a PICBasic version to share it and adapt it to some new personal proyects I have in mind. Added also a digital compass to test gyro's Z response. Calibration and software compensation is the goal for this. Neural implementation for this, is the way to be taken.

Regards
Rodrigo,
RodSTAR