An example. Suppose the the accelerometer measures the acceleration from rear to front. When the robot is straight up and standing still the acceleration is 0.
.....
I'm no expert like Stryker
, but wouldn't the acceleration be 9.8m/s because of gravity?
I'm no expert either, I've been coding less than a week now. However, I
did just finish a few High School Physics chapters involving gravity and the acceleration due to gravity.
To answer you, though, the acceleration would be 0, 0, or (the equivalent of) -9.8
m/
sec2. The accelerometer is capable of reading up to 2 G's, with a max reading of (I think) about 400, so one G (-9.8
m/
sec2) would read about 200.
The reason you have these three different values (0, 0, ~200) is because you could read the X, the Y, or the Z.
If your accelerometer is facing forward, your X is forward/backward, your Y is left/right, and your Z is up/down. (I don't have one and haven't tested recently, but I'm pretty sure that's how they are.)
when the robot is falling face down the acceleration is also 0 (when it is in free fall (in vacuum)). So there is no way to distinguish between the two.
No, it won't be exactly 0. The sensor would need to be falling, not just pivoting on the wheel.
Well, the first person is certainly on to something. If your accelerometer is pointing down and you read X, then it reads +1G. If it is held level and you move it forwards with an acceleration of -9.8
m/
sec2, you will (I think) get -1G. So, if your accelerometer is falling straight down, and it hasn't reached its terminal velocity yet, and we're ignoring resistance due to air, and your accelerometer is pointing straight down, you will read a grand total of: 0G. But, the second person is on to something as well: the sensor is not falling with no resistance, nor is it even falling in a straight line, and most important, it's not falling
and still remaining level. Rather, it is rotating as it is falling, at a very precise rate.
Now, we could (probably) calculate what angle the accelerometer is by including a bunch of things in a calculation, things like the acceleration due to gravity, the radius at which the accelerometer is placed, the weight of the bot, air resistance (negligible), friction of the tires, relation of [the distance from the ground to the axle] and [the distance from the axle to the accelerometer, aka the radius], and possibly some other things (wind, slope, moon's location, etc.)
You could argue that if you had all this information you could calculate what precise angle your robot is at, and the best way to fix it.
Or, you could just feed the accelerometer's X value into the motor.
You see, the person who posted the graphic makes a key point: when the accelerometer is level, the X value is 0. Zilch, nada, nuthin, call it what you want. You might be getting random sensor noise, but a decent averaging filter can limit that. So if your accelerometer's radius (measured away from the axle) is huge, and your bot starts to fall forward, the accelerometer will read a whole lot of acceleration. But if your radius is very small, there will be very little acceleration--at least in the X-dimension. Why? Well, let's ignore units for the sake of simplicity. Imagine you have a radius of 10. Not too big, not too small. Now attach an accelerometer onto one end and the other end onto a motor. Also, ignore the values created by gravity. Now spin the motor at, say, 50. Try reading the accelerometer. Now make your radius 1000 and run the motor at the same speed: your accelerometer's value increases drastically. Now shrink your radius to 1: your accelerometer reads next-to-nothing.
That is the key to an accelerometer-based segway: it is
imperative that your accelerometer be
as close to the axle as possible.
So does your segway actually balance for more than a few seconds yet? A good one will stay in balance until the batteries start to run down (the one I built would balance for about 20 minutes or so). How do you differentiate between the acceleration readings you get due to the tilt of the robot and those due to the robot moving backwards and forwards?
Currently, with some poor code that lags horribly, the segway we've made uses two (synced) motors, one NXT Brick, one accelerometer sensor from HiTechnic, 6 AA batteries, some parts. and some cables. Does it balance? Absolutely. Is it perfect? Absolutely not. Is it something we accidentally made, and we haven't even finished and tested version 2.0? You bet.
So while it may not be perfect, we've proved it can be done and we're making it better. And we're using standard parts, standard NXC code (created by a few newbs), and a little imagination.
It's also almost done (as far as I know). We are diligently working on RoboCup stuff right now, though, so it might not be done as soon as we hope.
I feel badly that I have stolen this topic from aswin0. He originally posted,
This weekend I finished my first omniwheel robot using the rotacaster wheels. It is a remotely controlled robot, details can be found on my blog. Now I'm looking for a more difficult task. I'm thinking of a kind of omniwheeled self balancing bot. Basically I want to place my robot on top of a football. It should be able to maintain it's position without falling of. If I manage that the next step would be to make it move around. I could use gyro sensors to maintain balance, but then I would need two of them and I only got one. I do have an accelerometer that measures over three axes. Can this be used in a self balancing robot?
Yes, aswin0, you can use your three-axis accelerometer for such a task. I've been naughty an spending time on things other than RoboCup, one of them being some code for
your bot. I'm still a newbie so it's going slow, and I have no idea how you control a kildough platform such as the one you're using. If you would PM or Email me, we could work on the code.
