Motor Control Problems

In Pi Wars, there are a lot of puzzles and problems to solve. Some are hard, some are easier, but they are all fun, an opportunity to learn, experiment, do something crazy – that’s the whole point! But there is always one (or two!) completely new problem that turns up totally unexpected, usually at the worst possible time, and messes up all your plans. The famous unknown unknowns… These are usually not much fun.

Looks like we’ve run into one of these again.

When we started experimenting with our first prototype, we used small N20 micro metal gear motors. They were slow, but had enough power to drive the small prototype. The movement looked good, including the ability to turn around in place: the legs worked as expected – a little bit wobbly maybe, but nothing too bad.

Then we switched to bigger, more powerful, 600RPM motors for Phantom (the “real” robot): the goal was to make it run much faster, while still having enough torque at low speed. This was never tested properly, but everything seemed to be fine. Controlling the motors manually at low speed was harder: they need a “kick” to start, then you need to cut back the power to keep them going slower. So Phantom always appeared to be too excited or nervous, moving a bit wildly. The idea was to add speed sensors and a PID loop to control the speed, and we assumed this would “just work” and we’d get the best of both worlds: precise (good enough) control at low speeds, but also not going embarrassingly slowly in the Blast Off challenge.

After a lot of hard work adding the speed sensors and implementing the PID control, adding a new GUI, etc. the unexpected problem appeared: it was simply impossible to tune the PID parameters to get reasonable control! Controlling the speed on a “test bench” was OK: after some tuning we could see on the graph the motor power jumping up, followed by the the “measured RPM” value rising, and after just a bit of oscillation, nicely following the set speed. Adding some extra friction made the power rise again, while the measured RPM was still following the set value.

On the ground it looked worse: starting to move in a straight line at low speed is not perfect, but at least it steadies after a few seconds.

Here is how a similar straight line start looks like on the graph: Some oscillations at the beginning, but not too bad – still, a bit slow to start in reality. Green: set RPM (constant 120), yellow: measured RPM, red: motor power.

Turning in place slowly is really bad though. There is probably too much slippage and sudden changes as legs get some traction, then slip or get blocked a bit, then move freely again… The motors don’t seem to have enough torque at low speed to keep moving, so the PID ends up driving the power up and down. The end result is that we can actually turn – much better than trying the same by manually controlling power – but the movement is very jerky.

Again, a similar turn on the graph: lots of oscillations (the compass in the lower right corner also shows how uneven the movement is). Also, there is a very clear difference between left (outer) and right (inner) legs.

It’s not clear how to fix this… There isn’t enough time to find better motors. One option is to just accept this and stop trying to go slowly, just keep running and stopping. But that’s a risky strategy. We can try changing the gear ratio in our “gearbox”, but there really isn’t much room for making big changes – not without a major redesign.

By comparison, here is how the old prototype behaves with the micro metal gear motors (just directly connected to power, no control):

Looks much nicer! So another option could be to ditch the new fast motors, and go back to these tiny ones, hoping they will be enough for a bigger robot. But then it means this is about our top speed (the only speed really – it’s either going slow, or not at all). Our third option is a crazy idea, but that’s still a secret…