After two weeks of debugging inconsistent serial communication, fried ICs, snapped strings, and broken carbon fiber, the latched series-elastic leg finally hops!! In the video below, it hops around 25cm forward and does a little backflip. For now, only 3 out of the 16 springs are installed for testing, but hopefully very soon, we can perform a tree-sized jump at full power.
The leg has two sets of springs, and by releasing both at the same time, it is able to propel itself up and forward. When only one set is released, the force is unbalanced and creates a spin, which can be used to jump at different angles.
It took a lot more intermediate steps than expected to get to this point, and I’ll describe some of them here:
Safety features
Motor temperature
In testing I found that the brushless motors could get very hot to the touch (>100º C), so version 3 of the Ø32controller has a port for an NTC thermistor to monitor the stator temperature. As temperature increases, the NTC’s resistance nonlinearly decreases, measured by a voltage divider. The firmware then figures out the estimated temperature by a lookup table generated using the thermistor B-constant. We haven’t burnt any motors yet, and this feature should help us keep it that way!
Main current sense and inrush
The motors could also fail by drawing too much current. I measured the phase-to-phase resistance to be only around 0.28Ω, so a stall at 12V could be more than 42 amps. Probably okay for very short bursts, but if sustained this would burn up the battery, power electronics, and/or motor.
Each motor drive can sense its own phase currents, but I added additional circuitry on the brain board to sense and cutoff current when overloaded. Conveniently, the load switch I’m using can be configured to limit the inrush current when the robot first powers on. Each motor drive has up to 800uF of bus capacitance, so without the limiting inrush you can hear a pop when you first plug in the battery. (oops)
Lost connection
There is now a watchdog in the motor drive firmware to monitor that the serial connection is working. If the data connector gets unplugged or the brain board dies, the motor will coast to a stop after 100 milliseconds.
Inconsistent serial communication
Sometimes, the RS485 serial communication between the squirrel brain and the motor controllers would experience some sort of error that looked like noise, then the bytes of data get misaligned. I couldn’t figure it out at the time, so as a band-aid fix the motor controller would try to shuffle the bytes around to see if anything makes sense. If not, the data packet was thrown away. This worked well enough previously where the only action was to spin at some power, but data transfer is more important now with the safety features and more precise control. The issue was I didn’t correctly configure the UART RX pin to pullup, so the reception is unpredictable when nothing is driving the RS485 bus. Using the proper UART functions makes the communication basically 100% reliable even when communicating with each motor at 1kHz.
Fried ICs
It was really cold and dry a few days ago, and my fleece jacket and I were shocking everything I touched. For related or unrelated reasons, the squirrel brain suddenly stopped turning on that day, and it turned out that the 5V buck converter broke. It took a while to debug and solder another one back on, made especially difficult by how dense the brain board is.
Snapped strings
I believe the fibers in the twisted strings experience higher forces than on the linkage pulleys and springs because the helical shape causes the fiber tension to not be aligned with the length of the whole string, and there is a large component compressing the string against itself. As a result, the string often snaps when the string is very short and contorted at the end of the leg stroke.
I solved this by making the strings longer, which means there can be more strands of string for the same mechanical advantage and the strings end up less contorted. We’ll buy some more strings to test; it needs to survive the high tension while being thin enough to have high mechanical advantage within a reasonable robot length.
Broken carbon fiber
When I first put the carbon fiber springs on the leg, they broke almost immediately. The leg only started working when I increased the length from 70mm to 85mm.
It looks like the revised spring testing data is still inaccurate, as it showed that a 70mm carbon fiber strip should survive compression until 30mm, which I designed the leg around. Looking at it now, it’s obvious there is something wrong with the measurements! The yellow curve shows that a 0.5mm thick 120mm long strip somehow displaced 150mm. In reality, it bent until the tips touched each other, which would be a 120mm displacement. I’ll need to check the setup again.
Windup tester
Many of the next steps to get a better jump involve tuning the strings, springs, and linkage. Editing the parts directly on the robot takes too long, so we plan on building a simple test stand consisting of a single motor, string, and spring:
If we make the positions of each fixed joint and the motor adjustable, it should be much easier to try different parameters and configurations. We’re also thinking of trying spring steel in place of the carbon fiber (the stuff binder clips are made of?). It’s not often used in jumping robots because it doesn’t store nearly as much energy per gram, but very little of our total robot weight consists of springs and steel may be more reliable.
At robot start up, we don’t know how the strings are wound. We’ll have a calibration sequence where the motor starts winding in one direction and stops when it detects a stall condition from current sensing. Then it will unwind until the encoder detects that the link stops rotating, indicating the string is slack. The windup tester will help us debug this calibration sequence without risk of breaking the robot.
Many small issues appeared these past two weeks, and it’s been satisfying finding solutions to each of the frustrations. I’m very happy that it finally hops, and I hope this project stays just as eventful. 6 weeks until EOH!
-Chris
6 weeks?!!! Can’t wait