Omni-wheel balancing robot

[i-fixed-it-44]

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?

Wow I didn't see this post till now,but I think this is a good idea and will definitely work the acceleration sensor will work fine and use the gyro too,also make the sensors facing up.

[stryker001]

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.

[stryker001]

OMG, that post was long. Sorry...

[muntoo]

OMG, that post was long. Sorry...

Don't worry, the longer your post, and the more sciencey-words in it, the more smartest you are!

[hassenplug]

Some days, I love the topic of balancing, using an acceleration sensor. However, please forgive me if I grow tired of the discussion, before you give up on trying to make it work for more than about 3 seconds.

The "secret" is to use the Accelerometer as a tilt sensor, not an acceleration sensor.

Other cool things to do: Use an ultrasonic sensor to measure sound level, and using a light sensor to measure color.

Oh, and the best part of all this? We discovered it accidentally. So there.

I hope I didn't insult everyone by saying what I just did. I am aware that the popular opinion is that this can't be done, but if everyone went with "popular opinion", there would never be, IMHO, any groundbreaking discoveries.

Please keep in mind that this discovery may NOT have been ground-breaking. It would be a shame for you to look foolish, if it turned out this awesome discovery in fact didn't work as you expected.

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.

That's an excellent place to start. Next you may want to look into static vs dynamic systems. (falling vs leaning)

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 also want to consider the center-of-mass of the robot, and where the sensor is, in relation to that point.

That is the key to an accelerometer-based segway: it is imperative that your accelerometer be as close to the axle as possible.

Really? What happens to the reading on the sensor, when the wheels (axle) actually move? How about this example: If the robot starts to fall to the left (looking at muntoo's picture), the wheels would drive to the left, correct?

Wouldn't that create an acceleration reading, telling the robot it's falling to the right? At that point, the robot would stop driving left, and drive right. It would seem this left/right acceleration could easily overwhelm the smaller tilt values being returned by the sensor.

In any case, it sounds like you've about got it figured out. If you need some additional reading, try this page:
http://www.teamhassenplug.org/NXT/NXTSensors.html

Good luck.
Steve

[stryker001]

Please keep in mind that this discovery may NOT have been ground-breaking. It would be a shame for you to look foolish, if it turned out this awesome discovery in fact didn't work as you expected.

I am well aware of that, but I posted in excitement. (Kinda like when you vent your rage, but happiness instead.) We have, in fact, ran into a few problems that cause it to be less stable than other bots, but it does stand up and stay up for awhile. Which just psyches me out because I've never really programmed anything before and this was my first try (and the guy who was helping me had never used the sensor before ever, so it was like his first time as well).

Next you may want to look into static vs dynamic systems. (falling vs leaning)

My brother is taking that class in college right now and it seems pretty intense (compared to the High School stuff I'm currently doing). So, while I hope to go to college and end up taking that course, It might not be for awhile. But it's a good thing to think about, thanks for mentioning it.

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 also want to consider the center-of-mass of the robot, and where the sensor is, in relation to that point.

Very true. I forgot to mention that and realized that the next day.

That is the key to an accelerometer-based segway: it is imperative that your accelerometer be as close to the axle as possible.

Really? What happens to the reading on the sensor, when the wheels (axle) actually move? How about this example: If the robot starts to fall to the left (looking at muntoo's picture), the wheels would drive to the left, correct? Wouldn't that create an acceleration reading, telling the robot it's falling to the right? At that point, the robot would stop driving left, and drive right. It would seem this left/right acceleration could easily overwhelm the smaller tilt values being returned by the sensor.

Again, thanks for pointing that out. I really should have explained better.
Five guys at the church I go to (Ch. Bo., Ch. Bo.'s Dad, An. Ma., Ja. Gr., and Jo. Gr. (me)) have teamed up to make a RoboCup Jr. team. We gather at Ch. Bo.'s house every other Sunday, because we go to Youth Group those Sundays, and so we can all ride with each other. (Makes it easy on the parents to coordinate days.)
So last time we got together, we were dividing up tasks for RoboCup Jr. (building certain parts of the bot, as well as programing certain parts). An. Ma. and myself were working on a system to detect a hill, because we wanted to up the motor speed when we reached the hill. We discussed several ideas and ended up deciding to use an accelerometer as a tilt sensor, but by the time we finally came to that conclusion it was time to go to Youth Group. So An. Ma. and I got his laptop, one NXT Brick, one Motor, one wheel, and one Accelerometer, as well as a few liftarms and pins. We brought these to Youth Group and started learning to use the NXC commands for reading the accelerometer.
What we started out doing was just feeding the Accelerometer's value into the motors, so that whe you leaned the system back (as if it were on a hill) it sped up. Then we started playing around and attached the sensor to the motor, blah blah blah, we ended up with a one-wheeled segway. Because of the few pieces we had, we really couldn't attach the accelerometer any lower than the lowest attach point on the motor. So, we just figured the lower the accelerometer, the better.
Your point is a good one, though: if it's too low, it won't work very well. I guess there must be a "sweet spot". You know how as the bottom of the bot moves left, the top moves to the right? I'm thinking (but haven't tested it yet, so I'm probably totally wrong) that the spot in the middle that just rotates would be the "sweet spot". What do you think? You've certainly been doing this longer than I have, but I think that would greatly stabilize the robot.

P.S. Each Sweet spot would be different, based upon the height/COG of your robot, if I'm thinking correctly.

[hassenplug]

I guess there must be a "sweet spot". You know how as the bottom of the bot moves left, the top moves to the right? I'm thinking (but haven't tested it yet, so I'm probably totally wrong) that the spot in the middle that just rotates would be the "sweet spot". What do you think? You've certainly been doing this longer than I have, but I think that would greatly stabilize the robot. P.S. Each Sweet spot would be different, based upon the height/COG of your robot, if I'm thinking correctly.

There IS a term for this sweet-spot. I can give you a clue:

Steve

[stryker001]

There IS a term for this sweet-spot. I can give you a clue:

Thanks. I wasn't really sure, but I guess I just needed to really think about it. That's cool.

So then, if you did have your accelerometer sensor there, you could make a pretty decent balancing bot, right?

[hassenplug]

So then, if you did have your accelerometer sensor there, you could make a pretty decent balancing bot, right?

I can't answer that.

Steve

[stryker001]

So then, if you did have your accelerometer sensor there, you could make a pretty decent balancing bot, right?

I can't answer that.

Steve

Oh. Sorry!