No time for 'bots

And then my life got crazy with work and kids and ...

Not a lot of coding for a long time.

Almost balancing!

Bot nearly balancing! Changed code to use floats rather than ints/longs or fixed points implemented on ints/longs. Tweaked target angle and KP value. Console controller can now set target angle and PID control values. Skew motor power as motors are not equal speed/power.

Problem: Target angle slightly off. Tends to drive forward/backward at fixed angle.

Solution 1: add component that sets target angle based on desired vs actual motor speed. Probably a PID controller to set target angle of current PID controller.

Solution 2: add component that sets target angle based on maintaining fixed location. Probably a PID controller to set target angle of current PID controller.

Problem: Only works when tethered and drawing power from USB. Behaves totally nuts when using onboard 9V battery. No idea why yet, need to debug.

Not enough resolution with integers

Finished code to use Kalman filter. Bot working a lot better than before. Not balancing, but no where near as ill behaved.

Problem: As Self balancing needs moderate power when small angular changes occur I need to have large PID control loop K values. Which means VERY granular changes in speed. For example with Kp=100, we go from speed 0 to speed 100 to speed 200.

Need to either use fixed point or floating point. Some of my old code uses a form of fixed point arithmetic. For example by using milli-gravities and milli-volts rather than gravities and volts. Would be great to use floating point, but I've no idea of the performance issues. In fact, I have no idea of the performance characteristics of the Atmega186 at all.

Solution: I just wrote the sketch Benchmarks/IntLongFloatMult to find out the speed of multiplying int/long/floats. Results: 4M int mults/sec. 2M long mults/sec. 2M float mults/sec.

Floating point is plenty fast. Not much sense in using fixed point. Will rewrite PID, Kalman, and other libraries to use floating point. Much of af the Kalman code already uses floating point so that should be easy ...

Kalman Kompleted

Finish kalman filter. Now need to use it.

Kalman Kode

Integrating gyro and accelerometer data requires a Kalman filter.

First draft based upon the Autopilot project. See:

• http://www.rotomotion.com/downloads/tilt.h
• http://www.rotomotion.com/downloads/tilt.c

with some modifications adapted from:

• http://home.comcast.net/~michael.p.thompson/kalman/AVR_IMU_3.zip

YABB 0.1

First bot should be a "quick and dirty" balancer that tries to either maintain the same position, or tries to maintain zero velocity, whichever is easier.

Body built from cardboard. Solarbotics GM9 motors and L298D motor controller. Standard 9.6V toy RC type battery for juice. Arduino controller. Wrote code to read the H48C. Wrote code for very simple PID controller based on a single prior value. Reused code to drive the motors using 3 wires per motor: enable, forward, reverse.

Motors are typically controlled by 3 wires: right high, left high, and enable. Enable makes the motor responsive to the right high and left high control wires. If enable is low, nothing happens no matter what the right and left control wires say. Right high directs power from the h-bridges high side on the right to the low side on the left. Left high directs power from the left high side to the right low side. If right is high and left is low, the motor spins in one direction. Visa versa and the motor spins in the other. If both are the same the two sides of the motor are connected to each other, and the motor brakes. That is, turning the motor generates an electric current that resists the turning. The resistance acts as a brake and regeneratively recharges the battery. Speed is controlled by PWM'ing the enable line. That is, turning it on and off rapidly. Longer the enable line is turned on relative to the time it's turned off, the faster it goes.

Bought a Parallax H48C 3 axis accelerometer from Hobby Engineering. At the same time purchased a Parallax HM55B compass module.

Problem: Debug output is scrambled. A lot of electrical noise from the motors. Trashes the serial connection between the bot and computer. I now suspect that electrical noise from the motors destroyed a bluetooth module I tried on a previous bot.

Purchased some opto isolators from Jameco. Also some OR gates so I can move from 3 wires per motor to two wires per motor: forward, reverse. Need a second battery for logic, just using a 9volt. Now I get clear debug output. While I was at it I also added "or" gates so that I could control the motors with two wires each: E = R or L. Only isue was that I now have to PWM both R and L rather than just E.

That fixed the noise issue, but later on I found out there are other was to do this that might have worked just as well. Primary being a .1uF capacitor across the motor leads. And a better power supply circuit. I may try those later.

Problem: Doesn't balance. Tends to over shoot. Tried tuning PID kp, ki, and kd parameters to no effect.

Perhaps the bot body is too short, making it very hard to drive the motors under the bot. As a friend said, it's easier to balance a pool cue on your hand than a pencil. Rebuild bot using 1/4" x 3" x 3' piece of birch, with the weight at the top. Batteries, breadboard, motor controller.

Problem: Still doesn't balance. In fact, no apparent change.

Perhaps motors aren't powerful enough. Replace GM9 motor with RM2 motor so that speed and torque aren't a problem. 3 times the torque and twice the speed. And a huge current draw at stall ... L298 tends to overheat. And have killed a few RM2's by stalling. At some point I need to put in a resettable fuse so I stop killing these things.

Problem: Still doesn't balance. In fact, no apparent change.

Careful observation shows that H48C readings do not reflect actual tilt when bot is falling. DUH! while falling there is no substantial change in acceleration. Only when I catch the bot do the X and Z readings change a bunch! Accelerometers alone are too slow. Gyros are supposed to be fast and are "supposed" to be used to balance bots. So, I purchased an IDG300 3 axis accelerometer and 2 axis gyro from SparkFun. I also wonder if it could be done with IR sensors. So I bought some of those from hobby engineering. Haven't done much with them yet, but I will. The IDG300 is $110 a pop. The IR sensors, $21 for a pair. The difference will be important if I have a dozen + bots flocking around.

And that catches us up to Jan 1 ...

YABB

Okay, what do you do after you've got a bot to roll around avoiding obstacles. Build a better bot to avoid obstacles. Build the smallest bot you can. The strongest. One that can go up a steep ramp. Yawn ...

What I needed is a project with legs. Something that is challenging and cool and will take a while to get "done". But that has lots of intermediate steps each of which is possible by a guy with limited time on his hands.

So ... YABB, Yet Another Balancing Bot. Long term goal: create a flock of balancing bots that are aware of each other and people and "flock" using Boyd's algorithm. Massive coolness to stand back and watch a flock of self balancing bots make their way toward some destination. Or no destination at all ...

Or, for people to become part of the flock, so that the people move, the flock moves with them.

Rough roadmap:
- Build a single bot that can stand without falling in roughly the same place.
- Extend so the bot can move without falling.
- Add an arm so the bot can get itself up from the reclining position it takes while not moving.
- Convert arm into a "lance". Extend bot so it can raise and lower the lance maintaining balance.
- Add a second bot with a lance.
- Add recognition so bots no where each other are.
- JOUST!
- Ditch lance but retain ability to stand.
- Add multi object tracking so bots know where each other are. Not sure if bots should keep track of where all flock mates are, or just a subset that are "in sight".
- Add Boyd's algorithm so bots flock.

I figure it'll take a couple years to do this. [22 Feb: It's so far taken a couple months and I still don't have a balancing bot!]

We have ignition ...

So I've been messing around with robotics for about a year now, and decided to move my log to a blog. Never logged about the early stuff, nothing to be missed ;->, but I'm filing the entries before 22 Feb, 2008 after the fact. I'm not making anything up from memory, just moving my old log entries into this Blog. Everything after 22 Feb is filed as I try stuff.