Making AlphaRex walk

As it turned out, Making the official AlphaRex model walk properly wasn't easy. Here is the video of AlphaRex walking. The program was written using NXC in Brixcc and is available here. There are several issues making it annoyingly hard to walk consistently. Some tweaks need to be done beyond the official model.





The first is the gears positioning. The two motors, used for tilt and stride, have to be aligned every freaking time before starting a walking program. This is annoying at best. There is simply no feedback about their initial positions and hence some pre-start position has to be assumed by the program.

I solved it by using the touch and light sensors (otherwise uselessly mounted on AlphaRex as decoration) to detect tilt and stride positions. The program then calibrates the robot's alignment before starting walk sequence. During the calibration, it also determines motors' cycles needed for walking (hence, avoiding manual determination of gear ratios and so on).

The second problem is that it has very little ground clearance for the feet, so it's easy for the robot to walk one-step-forward-half-step-backward if the strides are not made at perfect tilt positions where ground clearance is highest. The solution to this is simply to run the motors in turn. You make the strides only when the tilt is maximum or make turning moves with appropriate tilts. Rotating the motors continuously, as demonstrated by the official program, doesn't take advantage of 'maximum tilt position' and also because of positional drifts, the robot just ends up shuffling on the ground.

The third problem is with the firmware's PID control. Since I am positioning the motors rather than rotating them continuously, I needed accurate and fast angular positioning (otherwise, it was a slow walk because of too much settling time). For the life of me, I couldn't tune the PID values for the firmware's implementation, even using Ziegler–Nichols method. Out of frustration, I ended up implementing my own. A quick glance at firmware source code shows the implementation is done for speed control. Perhaps that's the reason why it sucked at position control.

Walking is implemented using state machine. The state of the robot is described by a combination of tilt and stride positions. A state transition table describes what would be next state, given current state and current movement command. This allows the robot to switch to any walking state any moment based on a command. A separate table describes transition actions -- the physical actions needed to perform to get the robot from any given state to any other state.

My implementation is different from the one described here, in the sense that I separated transition states and transition actions, allowing it to walk, turn and stop smoothly without having to enter a 'neutral' state in between. But otherwise, the idea is more or less similar. I think making states and actions separate makes it simpler to understand and put together. Also more flexible in hopping between states as a continuum; just like human doesn't stop before taking a turn. It looks like the walking can be sped up a little bit by starting strides already before tilt got to maximum, but I haven't bothered doing it.

Using the touch sensor sensor was pretty easy because there is a clear 'detection' of tilt extreme.

On the other hand, using the light sensor as proximity sensor was very hard because of ambient light not being uniform everywhere. After trying a lot, including implementing a high pass filter (code) (ambient light is very low frequency; almost DC like), the best way turned out to be to use it to detect object sticking right in front of it. If the object is wide enough, it will block most of the ambient light and hence the reading would be uniform. Since we are talking about dead-on collision of the sensor and object, it was important to have some cushion to avoid strain on AlphaRex's leg. I used the supplied rubber connector to give some springy load to it. Check the video to see how the tilt and stride sensors are added.

The program has three different threads: one is movement (motor control), the second is navigation (obstacle avoidance) and the third is command (user commands). The navigation and command threads are just some test routines and can be easily extended for other fun stuffs. The state table can also be extended to include backward movement and dancing movement etc.