balancing robot question

Whelzorn

I am trying to decide if it's worth building a balancing robot. I have read the nuts and volts articles, looked it up, and done some research. The construction looks fairly simple, but what really gets me is the math and theory behind the accelerometer/gyro.
From what I understand, you need a two axis accelerometer, and a single axis gyro minimum. I understand that the gyro is used to determine the angle, and the accelerometer provides a reference based on the deviation from 1g (y axis) and 0g (x axis), to compensate for gyroscope drift. I am just having a hard time with the fact that a gyro is needed at all.
Suppose you were to take a dual axis accelerometer like the ADXL202/203. Holding it so that the y axis points vertically and the x axis points horizontally, you would get -1g and 0g respectively.
Now what if you were to align the accelerometer so that it matched the picture (attached)? both the x and the y axis would have the same value (.707 something) if the robot was perfectly balanced. if the robot began to fall in one direction (left, for the reference of the picture) then the left value would be greater and the right value would be lesser. The robot would simply need to drive left and try to get both the values to match. As long as the values were within .001 (maybe even less) of each other, the robot should remain balanced.
So why isn't this method used? it would certainly make the construction ~$100 cheaper.
I'm sure there is something that prevents this from working, but It would be great to know why if anyone can offer some insight.
Thanks!

Bruce Bates

Whelzorn -

Balancing robots are out of my own area of expertise, but the first question that comes to my mind is: What happens if the wheels are not rotating at the same speed? Won't the 'bot wander all over the place? Perhaps that's part of the reason for the gyro?

Regards,


Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

Whelzorn

hmmm... I'm not quite sure I understand, the robot's wheels should be allowed to move at different speeds so that it can turn, and the gyro measures the same axis the robot needs to balance itself in (measures the robots angle, which should be 90 degrees vertical unless it needs to be balanced).

Tronic (Greece)

It won't work with just the accelerometer. I tried the method you suggested but it didn't worked at all. Have you ever tried to balance an accelerometer on your hand?·If you let it fall on either side, its output will be 0g or near 0g! A gyroscope is required to properly calculate the rate of fall on either side.

About the wheels now... Since each wheel needs its own balancing value you can use an offset value that can be variable to be able to control the steering of the balancing bot.

What I learned trying to code these sensors to my 2wheels BS2 balancing bot is that faster hardware is needed nor to mention fast motors for each wheel.

Rgrds, Thanos


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Greekbotics: Greek Robotics Forum

(Translate it using Babelfish)
·

JohnBF

I believe the key problem with an accelerometer by itself is that the tilt information is obscured much of the time by the robot's movement trying to balance itself. For example, the response to a forward tilt is indistinguishable from the response to a forward acceleration as the wheels move to get under the center of gravity. Gyros are not sensitive to this noise, but they have no absolute sense of up and down and drift over time. So the idea of the accelerometer/gyro combination is to use the gyros to guide behavior·and take·accelerometer readings when the robot is stable to periodically recalibrate the gyros.

There are much simpler ways to build balancing robots, if you are willing to accept that they will only work on a level surface. There are many examples of·balancing robots using IR sensors, e.g., to sense distance or angle from the floor. I built a balancing robot that uses the Parallax Ping))) to do this. It works fine on a level surface but will fall over if it encounters a hill.

Might be better to start with something simpler than the fairly sophisticaed approach in the Nuts&Volts article.

/John

AIman

A balancing robot from the completed projects. Stands on 2 wheels.

http://forums.parallax.com/showthread.php?p=570699

Whelzorn

aah, alright I see what the issue is now. Well, it was worth a shot.
I'm not too into making it only work on level surfaces, so I think I'll avoid the range finder method. I'm surprised though that there isn't a sensor with the sole purpose of finding the angle between it and the force of gravity (j vector).
Anyway, until this gets a bit less complex (or I get better at physics) I'm going to hold off on this project.
Thanks for your input!

slashsplat

OK. I understand this can be done with IR. BUT I want it to work on ANY surface, even if not level...

I have the MEMSIC and am trying to get this to work with that sensing the incline. I have the board mounted on some erector set stuff and the problem appears to be that the servos are not quick enough. The code is working fine to sense the tilt, but the servos do not appear to move quickly enough to correct it. The device is about 10" tall and purposely top heavy.

I am thinking of larger diameter wheels...









▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */
"There's no place like 127.0.0.1"

Post Edited (slashsplat) : 1/1/2007 10:17:06 PM GMT

Steve Joblin

Slashsplat - why did you make your design to be purposely top heavy and that much more unstable?· Isn't the idea to keep the COM as low as possible?

JohnBF

Hi Slapshot,

How much does your robot weigh? The balancing robot I posted on the Completed Projects forum this morning weighs 1.2 lbs. I originally had it at 1.6 lbs and couldn't quite get it to balance. I reduced the weight to 1.2 lbs and it works really well now. The two other things that helped a lot are 3" foam wheels (Du-Bro wheels from Tower Hobbies) and NiCd batteries, which visibly improved the performance of the servos by providing stronger surges when they start up or change direction (pretty much all they do in this application).

I tried really hard to get the Memsic accelerometer to work but couldn't. It's beautifully accurate at rest, but once the motors start trying to balance the robot they indicate more about what the motors are doing than tilt. Did you find any way around this? Are you using any filtering algorithms in your program. If you do get it to work that will be great, and I'll keep trying too.

/John

slashsplat

I wanted it to be WORST case with weight up top. If I can get that to work, I have no limit on the payload. The weight is about 0.6#. The servos are so slow that they just seem totally unable to correct quickly enough. I will juice up the power, but I don't think that will do it. The NiCds make sense. I am trying to use the MEMSIC and I am seeing reasonable results from the display to indicate that it seems to be stable in detection. I am not filtering, but am running the servos proportional to the angle, so it would compensate smoothly near center. Even with that disabled, the servos are just not quick enough... Or maybe my program is horribly worng in driving them... I have tried sending multiple corrections per read of the MEMSIC, or just one, disabled the display and debug... I will get back on it. I am using the BoE Bot wheels at 2.5" and am sure that a larger wheel would provide faster correction. That is next.

Then a REAL motor.

UPDATE: I put a fresh 9V on it and the servos livened up. I will readjust the center of gravity and play some more. Thanks for the idea.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
slashsplat
/* Ira Chandler */
"There's no place like 127.0.0.1"

Post Edited (slashsplat) : 1/9/2007 3:33:37 AM GMT

Franklin

Weight on top is a good thing. It adds inertia to the top that has to be overcome. try balancing a wooden ploe as opposed to a broom or hammer. the weight on top tends to accelerate slower and it is easier to get under it with your balance point.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

Gadgetman

JohnBF said...

I tried really hard to get the Memsic accelerometer to work but couldn't. It's beautifully accurate at rest, but once the motors start trying to balance the robot they indicate more about what the motors are doing than tilt. Did you find any way around this? Are you using any filtering algorithms in your program. If you do get it to work that will be great, and I'll keep trying too.

You may want to move the Memsic to the top of the robot.
(you need to measure the accelleration of the end, not the middle of the robot)



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

JohnBF

I tried the Memsic all over the robot but did not get clean results anyplace - the Memsic's strength, that it's so sensitive, is a also a weakness in this jerky application. I thought I might get better results not on the top, but at the vertical center of gravity, which is close to the center of rotation. As I look at the robot while balancing from the side, it appears that there's a point that's not moving - the robot is moving one way below and the opposite way above, but quite still right at that center of rotation. But then I learned something from the Memsic. As you get further up from the axle, there is also an increasing vertical component to the movement. As the robot starts to fall, any point above the axle moves down. When the wheels turn to get under the center of gravity it pushes back up. The Memsic reports on all this quite actively.

I don't see any way around a software filter that teases what we want to know from the noise over time, along with a gyro for quicker, if not absolute readings.

/John

zboot

If you look at the full blown kinematic equations to stabilize an inverted pendulum, you need to know both the current tilt angle and the rate at which that angle is changing.

Tilt angle can be easily determined from acceleration. Tilt rate can be found by differencing acceleration. The problem with using accelerometers at the only sensor for getting these readings is the relatively slow update rate of the accelerometer. For about $50 a piece, a gyro will have 3x the update rate of an accelerometer.

Gyros give you tilt rate, however, these values are subject to drift over time. So, typically, you use a gyro (because you get results faster and thus can run your control algorithms more times per second) and use the slower accelerometer to correct the drift in the gyro.

However, I'm confident I can make a balancing robot using ONLY an accelerometer. In the summer of 2005, I made one that uses IR distance measuring sensors to detect tilt (relative to a flat surface). These sensors have an update rate of about 25 times per second. The MEMSIC accelerometer I'm getting is reported to have an update rate of about 33 times per second (though the datasheet suggests an upper limit of 45). If I had an additional $50 to spend on this project, I could buy a gyro which has an update rate of 100 readings per second.

Based on my prior experience with the relatively slow IR sensors, I'm pretty confident in using an accelerometer.

Someone mentioned earlier making the robot top heavy. Other wondered why, asking wouldn't it be better to have the center of mass closer to the ground. The issue is the rotational inertia of the robot. With the COM close to the ground (ie close if not on the drive wheel axle), the robot has little rotational inertia. This means it barely resists the tendency to fall and requires less torque to recover from a fall. Unfortunately, this means it falls MUCH faster and your motors need incredibly fast response times and need to be able to generate high speeds in very short times. Also your sensors need to be fast enough to respond. Given that most sensors are not fast enough. . and motors are probably slower, it is better to have the COM higher.

Having a high COM gives a large rotational inertia. The more the robot resists changes in rotational motion (about the axle), the less work you have to do to keep it balanced. The problem is that once the robot tilts beyond a certain point, the higher inertia will probably require more torque than motors can provide.

Another reason why the higher COM works better is that it plays right into the use of PID or other control algorithms which ALL assume linearized motion of the robot. As long as the tilt angle stays small, we can apply small angle approximations (which are linear) and not have to worry about nonlinear sines and cosines.

************************
A little more info about my current robot. I'm building it to enter into the trinity college firefighitng competition. The competition doesn't need a balancing robot, however, I wanted to see if I could improve upon my previous design and use lower cost parts for the motive portion of the robot. I'm currently using the Tamiya Double motor gearbox. The reason I'm building this one with an accelerometer is because IR sensors require the robot be on a flat surface to maintain balance. On an incline, they will fail. One solution could be to use a combination of IR sensors and a tilt sensor. However, most tilt sensors are too slow or don't provide enough resolution. The best cheap tilt sensor is an accelerometer and they have faster update rates than the IR. . .so I didn't see any point in using both to keep balanced.