Omni-wheel balancing robot

[doc222]

Yes this is very cool. Puts a whole new spin on NXT football. These new wheels look very nice too. Or perhaps a new kind of summo on a ball, first to fall is out .


Doc

[stryker001]

I'm looking for a more difficult task. I'm thinking of a kind of omniwheeled self balancing bot. I do have an accelerometer that measures over three axes. Can this be used in a self balancing robot?

Indeed it can. Don't let anyone tell you it can't be done. It is totally easy, and I think everyone who's done any balancing 'bot programming before should find it easy to work with. (The only thing is, the "ID" part of "PID" can be difficult, but it's not as necessary to make a 'bot that simply balances.)

[gloomyandy]

Really. I've not seen any balancing bot that only uses an accelerometer. Do you have a link or anything else to one that works? There was a very long discussion on nxtasy about this and no one ever produced a robot that could stay balanced for more than a few seconds...

[mightor]

Andy, obviously they didn't try hard enough, sheesh! I can't wait for Stryker to show us how it's done

- Xander

[mattallen37]

IIRC, it was determined that in theory, it COULD be done, but you won't be able to do it. That is, a segway type robot. However, I have made balancing robots with only an accel sensor (as far as the sensors used). It obviously wasn't a segway type robot, but none the less, it was a balancing robot (even a counterweight system could be considered a "balancing robot").

[hassenplug]

...It is totally easy, and I think everyone who's done any balancing 'bot programming before should find it easy to work with.

A couple years ago, I was talking with Dean Kamen and mentioned using an acceleration sensor to balance my Legway. He just shook his head, knowing how the story would end.

It took me a few hours to understand what physics rules apply. For some people, it takes more.

Steve

[aswin0]

I grasp that it does not work because of this:

Acceleration and gravity are opposite vectors that can cancel each other out.

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. But 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.

Anyway. I decided to use a three axis gyro, but that is another thread.

[stryker001]

With complete respect for all fellow members of this forum, I can only say this:

People: I am disappoint.

And by people I mean aswin0, hassenplug, etc.

(I would like to warn you ahead of time: this is a huge post.)

aswin0, you summed up the problem pretty well: "Acceleration and gravity are opposite vectors that can cancel each other out."

While your statement is (pretty much) 100% true (and because your statement is true) we don't make accelerometer-based segways like that. It's useless, the thing just falls over and does nothing. Why? Because that is not how you make a segway with an accelerometer. The "secret" is to use the Accelerometer as a tilt sensor, not an acceleration sensor.

Conventional sensor placement (as far as NXT stuff goes) on balancing bots seems to always be up/down. Point the Light Sensor down, point the Gyro up. But the Accelerometer is neither a Gyro nor a Light Sensor: it's an Accelerometer. We point it straight forward, centered over the axle.

To answer mightor: this is how the it works, in psuedocode.
task main(){
while(){
read accelerometer's x value
use x as motor speed (forward)
}
}

(Technically, you can do it all in just 8 lines of code, but I'm not very good at coding, and that's all I remember right now. More on that later.)

If your bot is falling the wrong direction, you can do one of three things: multiply x by -1, drive the motors backward, or just turn the accelerometer around.

The reason it works is simple. It's still a work in progress, but when it's finished I'll make a topic about it. (And yes, it is almost finished. I suspect it will be complete by the end of next week, but that's ignoring the ID part of PID. we're just some beginners coding here, so just P is fine for now.)

To prove to yourself that this works, don't make the Segway with the above code; rather, use the same code BUT do this: Attach a motor and accelerometer to the NXT (via cables) and run the code. Point the accelerometer forward, and nothing will happen. Lean it forward a little, and the motor starts running. Lean it forward more, the motor runs more. Same with reverse.

Then, attach the accelerometer directly to the orange part of the motor: if you kept the accelerometer level, nothing will happen. If you lean the whole assembly forward, the motor will run backwards slightly until it reaches level again, simply because of the program. (If it runs backwards, follow one of the three steps mentioned above.)

Then, finally, attach a wheel to the orange part of the motor, and attach the accelerometer the the cable end of the motor. You now have a segway.

Why? Well, you just created a PID algorithm minus the ID. Because you are feeding the accelerometer directly into the motor's speed, you get a P loop. Granted, certain things don't work very well: you have to take an average of the accelerometer to keep it from jittering around, and you need to multiply x by approximately .75 (it seems to peak the speed to soon otherwise). Other than that, though, it's a segway. Using only an Accelerometer. Yep, I did just do that.

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. A friend and I actually happened upon this while teaching ourselves how to use the accelerometer as a tilt sensor: we needed to determine when we were on an incline, so we could increase the motor speed. The friend who was coding was like, "Let's just multiply [the motor's speed value] by [the accelerometer's x value + 1] and point the accelerometer backwards. That way, it will speed up when tilted back." So he made some basic code, about ten lines as I recall, and we tested it. we just held the robot up in the air and then simulated the slope by leaning it back a little. It worked! So then I was like, "Hey, if we attach the cable end of one motor to the business end of another, and attach the accelerometer to the other available business end..." It looked somewhat like this:
___ ___ _________
/ \_______ / \____| Accel |
| Motor 1 / \ | Motor 2 | ____|
\________\OO/OOOOO\________|O_O_O|

Imagine if we then fed the Accelerometer's x value into the second motor, and had the first motor spinning at a constant rate: motor 2 would go round and round, but the tip of motor two would be going round and round the opposite direction, because of the Accelerometer. It would have been like a ferris wheel, with the Accelerometer being a self-righting seat. (In reality we lacked motor 1 and had to improvise by spinning it by hand, but the results are the same either way.) That was when I decided to attach the Accelerometer to the cable end of the motor and a wheel on the business end, and he multiplied the vlaue of x by -1, and we accidentally made a segway. We were elated.


@gloomyandy: We're working on the code, I'll see if I can get my friend (the one who has the NXT, since I can't afford one) to videotape it running the code. I'll also post it when it's done, as we're priming it and adding calibration and such, so that when it falls down it stops.

[muntoo]

Here's an image I wasted time making. I was planning on asking a question at physics.stackexchange.com, but I'm too lazy. I hope one of you finds it useful.

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.

[sarcasm]I'm no expert like Striker[/sarcasm] , but wouldn't the acceleration be 9.8m/s because of gravity?

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.

EDIT: Sarcasm BBCodes haven't been implemented yet?

[gloomyandy]

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?