The morning started with check 6, the foot press. The first run worked mechanically, but the bathroom scale read 1.5 to 2 times the force the motor torques predicted, so that check isn't passed yet.

Then something more fun: a kick test. A kick pushes the motors much harder than the slow walking gait, so it tests speed and torque. The first version was a small scoop under the hip, which looked nothing like a kick. The second swung the leg from far back to far forward. The version that stuck is a whip kick: the leg starts almost straight and far back, the hip swings forward, and the knee snaps the foot through at the end, the way a person kicks a ball.

I ran it as a ladder, speeding up one step at a time. Each speed is how fast the foot is moving at its fastest point.

Getting to 4 m/s took some work. The first try at that speed stopped itself halfway, because the knee fell too far behind its planned path and the safety check cut it off. Two changes fixed it: stiffer control during the swing only, and spreading the knee snap over a longer part of the kick so the knee needs less torque.

Kicking things

Next came five more 4 m/s kicks, five seconds apart, with something new on a box each time: a tennis ball, a ball held in my hand, a toy car, a black object, and finally nothing. The motors log their torque 500 times a second, so every hit shows up as a spike. From the extra torque at the moment of contact, and the leg's geometry, I can estimate how hard the foot hit.

A 4 m/s kick about to hit a tennis ball (video)

Knee torque during the kicks: each hit is a spike

The hardest hit broke off the PLA foot pad. Before the test I had guessed the printed foot would handle about 35 N from the side. The 36 N tennis ball was fine and the 54 N hit wasn't, so that guess was about right. The next foot needs to handle at least 60 N with some margin.

The 54 N hit that broke the foot pad

A hidden torque limit

Something had bothered me all day. In fast moves the knee never seemed to make much more than 1 N·m, even when the controller asked for much more. Yet during the hits it showed 4.7 N·m. So I gave each motor short torque pulses with the leg swinging freely, and worked out the torque it really delivered from how fast the leg sped up. Both motors fell far short: asked for 4 N·m, the knee delivered about 0.9 in a 10 ms pulse and the hip about 2 in 20 ms. Held still and given time, they always got there. The motors just couldn't build torque quickly.

I ruled things out one at a time. The 48 V supply didn't sag at all during the pulses. A filter setting that looked suspicious in the manual made no difference. What did matter was the gain of the motor's current loop, the controller inside the motor that pushes current through the windings. The factory value is 0.125. Raising it to 0.5 made the current rise about four times faster.

The same current step at three current-loop gains

This is a big deal for the robot. Catching a stumble, landing a jump or swinging a leg fast all need torque within a few milliseconds, and the simulation assumes the motors can deliver it. With the factory setting they couldn't. For now the new gain isn't saved in the motors: the Teensy sets it before each fast test, and a power cycle restores the factory value. I've asked RobStride whether 0.5 is safe to keep.

One more lesson from the day: flashing the Teensy kept hanging for an hour. The cause turned out to be Google Chrome holding the board's USB connection open. Closing Chrome before flashing fixed it.

Next steps

A stronger foot, made to take at least 60 N. The sharper, later knee snap I wanted for the kick, which should work now that the knee can build torque quickly. A longer run of fast kicks to check heat with the new gain. And the foot press, to sort out why the scale and the motor torques disagree.