Optimum height for inverted pendulum?

Jay Kickliter

Is there such a thing as an optimum height for an inverted pendulum?

I built a small one last year, and need to build a better one this summer for a project. This one is going to much bigger and heavier. Welded steel, Parallax 12 V motors, and a 7 AH lead acid. My physics gut tells me that I need to concentrate as much of the weight at the top as possible, and the math says that taller falls slower, but I'm curious if there is a theoretical optimum height.

Side question, I used that Kalman code that's been kicking around on the last bot, but I question it's reliability. From everything I've read, a Kalman filter requires a lot of modeling and isn't necessarily drop-in. Can anyone recommend a simpler complementary filter?

And yes, the SLA battery up top will be very well protected.

Leon

At the embedded systems lab run by a friend of mine at a French university inverted pendulums are about 1m long, made from aluminium bar. They are difficult to control, to make it harder for the students. Modeling the system before you build anything or write any code would be very useful and instructive. Scilab comes with demo code for one.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Post Edited (Leon) : 5/18/2010 3:48:41 PM GMT

Jay Kickliter

Thanks Leon, I tired Scilab once, but didn't get it. I'll give it another go.

erco

Every physical variable makes a difference: height, CG, motor torque & speed, wheel diameter & grip, and of course the control system. A real PID system & Kalman filter can make for a very stable robot in most any size if the motors are powerful enough. I love seeing these units work, plenty of videos on Youtube. Even a few modified BoeBots have the balancing thing down, with differing sensors and varying degrees of stability.

These balancers do great in wide, uncluttered spaces, but it seems like a lot of people have chosen these balancing Segway-style platforms to build their general household "robot of the future", such as Anybot. They look elegant, and are a simpler and better solution than bepedal legs for getting around a house and helping carry things and unload a dishwasher (tasks depicted by Anybot and others). Until one wheel gets blocked by some unknown object and the whole thing falls over...

I think in order to be practical, these things need emergency kickstands that are spring-loaded and always ready to pop down quickly in an emergency, when the battery dies or the control system glitches. Some concept scooter/motorcycles have kickstands that automatically come down at stoplights for this kind of assist.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Jay Kickliter

erco, thanks for the kickstand idea. I didn't have anything on the last one I build and it definitely saw a little damage when tuning the PID constants.

On my previous balancing bot I used continuous rotation servos. It balanced a little, but I suspect it would have done a lot better with real motors that could be accurately throttled. Also, I made the mistake of putting the sensors down low, where the accelerometers felt too much noise from the thing trying to correct itself, a bit of a positive feedback loop.

erco

Are you using accelerometers only, or gyros too?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Jay Kickliter

Both. Right now I'm looking for a good filter. Like I said, I don't know much about Kalman filters, or if the one I used in the past is even any good. Everybody at diydrones.com is using something called DCM, but I don't know much about it.

Zoot

Jay -- diydrones actually has a good discussion of Kalman Filters in general, and some really good C examples, which wouldn't be hard to translate to Spin/PROPasm. Check the blogs over there. There's also a Kalman object in the Prop OBEX.

I'm currently working on a small balance-bot (cutting parts on the bench, actually). Given that it is SX driven, I can't implement a Kalman filter per se with the memory available (1 accelerometer, 1 gyro), so I'm doing a dirty fuzzy logic semblance of a Kalman filter (basically relying on the gyro for short fast changes and the acc. for longterm calibration).

Once all the weight is up high, the trick really is torque/speed -- in fact speed matters a bit more than torque -- as you want the wheels to come back under the inverted pendulum's center of gravity. If the weight is high enough, you don't need much torque, but you do need the speed.

Depending on your motoring, it might be a nice trick to use belt drive between motors and wheels -- this would let you change out pulleys if you need a better torque/speed combo. That, or be able to change wheels for different diameters. That will change your center of gravity, though.

In any case, what caught my eye here was erco bringing up the kickstand -- my design has a servo up top that pulls two heavy-gauge music-wire "land gear" type things into position. The two are linked by 1.25" nylon gears, with a spring return on the opposing gear (i.e., the servo "pulls" one gear to lower both struts, the spring pulls the other gear to raise struts when the servo reverses).

I'm planning on having the "kickstands" lower fully when the platform is at rest. When under power, I'm going to take the dampened and scaled absolute tilt error and translate it to servo kickstand values. The idea is that the platform will "put it's hands out" the more it is unstable (or thinks it's unstable). Hopefully the dang thing can stop without human intervention -- just sit there -- then start up again when it's ready. IR rangers will be up top for obstacle detection (along w/batteries, gyro, acc., host, etc).

See attached -- there's a few plan pix, scale PDF plans, plus a rough sketch-up because I wanted to see how it really looked.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Post Edited (Zoot) : 5/19/2010 4:46:48 AM GMT

Jay Kickliter

Zoot. If you're interested, I once translated the Kalman object from the Object Exchange into PASM, including the necessary floating point routines. I posted it in the Propeller forum at one point. It saved a couple cogs, and ran really fast. The point I was trying to make is that from what I understand, you can't just take a Kalman filter and drop it in your project without any modeling. The one in the Obex was translated from something that was translated... And I have no Idea if the original author knew what he was doing, or how he modeled it. I really don't know what I'm doing, I'll admit that, but I feel like that code isn't perfect, even if it appeared to work.