Let's Make Robots!

ProtoBox - Junk balancing bot

Stand Still - For the most part - For Now

ProtoBox - B

After experimenting with my Doubtful balancing platform for a while (http://letsmakerobots.com/node/34811), I realized that the motors/gearboxes are simply too weak, too loose and too slow. They were not purchased for that solution anyhow, just happened to have them around to I gave them a try. Obviously a better solution will be needed and search is on.

Sooo while researching for better gearmotors or a solution, I took the Doubtful code, pulled out my old reliable "ProtoBot" platform from years ago and started experimenting. 

Simply turning it up on end, putting the battery up top and adding an IR sensor for tilt angle measurements I get this. This old platform has been around forever as my experimental, or "ProtoBox" platform and has been used with an 68HC11 CPU, a Basic Stamp2, tested with dead reckoning, had different sensor holes drilled and moved around and much more. The old servo based drive motors - and I mean OLD - liked 15-20 years old are just gear boxes. I actually had to replace one due to just being just plain worn out and will replace the other soon.

The servos STILL do not have enough speed to catch anything besides a minor angle correction but they are at least powerful and tight enough to keep the platform upright for extended periods of time and provides a good base for me to continue to play with and tweak the balancing code for this approach.

The platform is very simple; an old Basic Stamp 2 dev board, H-Bridge motor driver, battery and a couple switches and LED indicators and a single Sharp IR sensor. I've run both my normal H-Bridge driver board and the locked Anti-phase one and really do not see much difference. I had thought the locked anti-phase may hold the position better but in reality it seems to have more jitter than the other board.

The green LED lights up when no motor drive is being used, i.e. generally balanced, and the small red lights up when full drive is needed and applied. Just debugging stuff more than anything but has been handy. The bot has a tendancy to slowly lose it's balance backwards over time which I am attributing to the non-linear readings from the IR sensor as the distance changes. I.e. there is more difference leaning forward / shorter distance than backwards. I may play with applying a gain factor to backwards leaning only in the PID to see if that helps.

Overall it can generally balance on carpet for 10 minutes or more in most cases. I can add differential gain to left/right motors to get rotation but will have to work with adding error to the tilt values to try to move forwards/backwards... if that ever works. It really isn't that stable.

Having looked at the output from the sensor it doesn't output much range which forces the P value of the PID to be set pretty high and forces more oscillation during operation. Fun to watch it do it's thing though.

I haven't given up on Doubtful, just going to replace the base with some different motors/gearboxes to play with later.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

2 months later, you maybe well into the gyro version, and I will be interested.

For the IR sensor, perhaps 2 sensors angled 30 degrees or so apart, for and aft, run into a bridge to get the sensor input would be more sensitive and useable.  I think I will try this for my first robot.  Then make the sensor input a bias to the motion control, masking it briefly during start/stop acceleration.  Ramps.and hills will be a real challenge, but a sum or average of the 2 IR' readings vs. the bridge output should get a slope indication somehow.

Then again, I will likely go up a whats-it-all-about ramp for a while getting started..

Thanks for the comments Dan. Actually the encoders are not being read at all in this configuration. This is a very old platform and has been used for various projects. One was using the encoders for dead reckoning and yes the resolution is an issue even for that. It worked but any errors added up quickly. Better than nothing but not very exact. That's why there are so many holes in the box... Different sensors, motors, CPUs etc. I'm using a sharp IR sensor to read the distance to the ground, slightly angled out which again works and has been fun to experiment with but low sensor resolution (larger movements are only 1 or 2 unit reads) and sensor noise in this format makes it a challenge to stay up. Additionally the motors are simple constant rotation servos so speed is really lacking, strong but slow so a slight overshoot can keep the bot from catching itself. I'm still playing with the PID settings trying to find the best balance for this configuration. The more negative "I" that is added helps reduce the jitters but also slows down the corrective response for large angle changes. I am thinking I need to get the D part turned better to dampen but still allow faster recovery but haven't been able to remove the osc that way yet. I think I am about done with playing with the IR sensor and going to give a gyro/accel IMU a try with a complementary filter and see how that works. Been fun playing with it though.

Cool. Looks like you have the problem of it falling over fixed with the new version. The movement looks a bit jerky. I am not certain how you built it, but I may have a suggestion. Are the encoding marks on the inside wheel being used to check how far the motor has turned? If so, perhaps drawing a new one with finer lines could make it more precise. How is it actually determining if it is tipping? one of those triple axis acceleration modules? 

Finally, I am wondering if you are using plain DC motors or steppers? If you are not using steppers, I would think those would give finer, more accurate movement.

If those do not apply, then perhaps it is in how the software code is written. Will you be sharing that with us?

(Hope some of this was helpful.)