L'Hexapod: More thoughts on the proto leg
This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here.
I adjusted my quick and dirty servo controller program to calculate the number of moves required for the servo that needed to move furthest and then spread the movement of the other servos across the same number of moves. So, given that the servo controller works in terms on a position from 0 - 254 where 0 is full left and 254 is full right and we have three servos that make up the leg I look at the differences between where the three servos are now and where they will be at the end of the move and then build a sequence of moves to get from here to there.
For example, if we’re currently at 10, 20, 30 and we need to move to 30, 30, 30 then the second servo would move once for every two moves of the first servo and the third servo wouldn’t move at all. The sequence being (10, 20, 30), (11, 20, 30), (12, 21, 30), etc. rather than simply (10, 20, 30), (30, 30, 30)… This works well and makes the movement much smoother.
Of course, once I had that working I realised that things MUST work that way to allow for sensors on the legs to have any affect at all. If we just said move to 30,30,30 and the leg hit an obstruction halfway through the movement then even if we had a sensor that triggered when we hit the obstruction we wouldn’t be able to do much about it as we a) wouldn’t know where the servos were at the point at which we touched the obstruction and b) couldn’t stop the servos in time to avoid potentially damaging them. With the smoothed sequence of moves we would, hopefully, get feedback in time to stop the servos and move them back a couple of steps in the sequence to hopefully take the pressure off. We’d also know where we were and so could plan accordingly from this point on.
Unfortunately firing lots of servo commands into the servo Pololu controller caused me some problems. The controller would randomly misread the commands and/or crash. Disconnecting the power supply from the motors fixed the problem so I guess the rapid commands to the motors was causing noise on the power supply (which is currently shared between the electronics and the motors) which was causing something to malfunction. Looks like the servos will need their own power supply sooner than I was expecting…
