Carnegie Mellon University
- Howie Choset
- David Rollinson
- Andrew Burks
- Florian Enner
The Unified Snake began life a decade ago as an undergrad project. Since then, it has evolved at Carnegie Mellon's Biorobotics Lab as a robust and sophisticated testbed for hyper-redundant robot research.
My own contributions include a study of Series Elastic Actuators (how to implement force control in the next-generation snake robot), as well as a suite of sensor validation tests which are used to guide future design decisions.
Series elasticity is a method for measuring force or torque in a robotic actuator using a spring, while introducing compliance and shock-tolerance to the system.
By measuring the deflection of the spring under load, you can infer the force it is experiencing using Hooke's law. The spring can also absorb big impacts which could otherwise damage your gear train and break your robot. The overall effect is that the actuator can handle natural, unstructured environments more easily. While your actuator can't respond as quickly to commands, this is often a worthwhile trade-off.
Series Elastic Proof of Concept
To see if our snake robot could handle it without a lot of upgrades, I modified a torsion spring test rig to accept a Unified Snake module. Using a combination of MATLAB, Python and Arduino I was able to interface with the custom communication protocols used by the Unified Snake to demonstrate series elastic force control.
The hardware was limited to what the snake currently used - i.e. position feedback from the snake module itself. However, since series elastic actuation requires two position sensors, a second identical encoder from a spare module was also used. This second encoder, as well as a compact torsion spring, would be integrated into the next generation snake module.
Here you can see the module (blue and silver, center) servoing to specified torques (thin black line on the monitor to the left) using a simple torsion spring for proof of concept. The second encoder, measuring output shaft rotation, is hidden on the other side of the test rig.
The large torsion spring is for demonstration purposes and would obviously not fit inside the snake module; a compact assembly with high stiffness and low deflection has been designed by lab members.
Encoder Interference Test
Since a series elastic actuator requires two encoders, and the Unified Snake uses magnetic encoders, the question was raised: how close can we put them before they interfere? I designed a test and built a rig to find out.
A pair of magnetic encoders are separated by a variable distance. Each magnetic encoder is coupled to a capacitive encoder for ground truth. The setup was quick and dirty, but it worked.
It turns out, they need to be about an inch apart. This is encouraging, because it means they can fit inside the current snake module size constraints. The result will drive design decisions in the next generation snake module.
Other Force Control Methods
I explored three other ways to measure the torque output of our snake module:
- a load cell or strain gauge
- motor current measurement
- "virtual elasticity" or proportional error
A load cell is known to accurately measure force, and was used as the ground truth for our experiment. However, the challenges of integration make this a mechanical design project in its own right.
Inferring torque from a motor's current consumption is complicated by nonlinearity and monotonicity introduced by the gear train: you can estimate how much force the motor is imparting, but not what external forces the actuator is feeling.
"Virtual elasticity" is an idea that arose from tacit knowledge of snake operators: to squeeze the snake around a pole, one would simply command an angle that the motor can't reach. The larger the error, the harder the motor works trying to reach it. This is a result of a purely proportional control loop, and in essence you are indirectly measuring the current. As such, it suffers from the same monotonic issues plus additional inaccuracy.
Series elasticity proved to be a viable option, and was pursued further.
Encoder Accuracy Test
A smaller version of our magnetic encoder was released, leading to an electronics design with greater reliability. However, packaging constraints put the new encoders 1mm off-axis. Under these circumstances, how accurate were these new encoders? Can the inaccuracy be corrected in software? While we're at it, how accurate are our CURRENT encoders? The torsion spring test rig was repurposed for yet another experiment.
It turns out the new design was no good - up to 2 degrees of error, and major inconsistencies between two identical sensors that would require individual module calibration. A 10-fold increase in noise was the final nail in the coffin. Again, these results drive future snake module design.
What I learned
My time at the Biorobotics Lab has been a formative experience. I either learned, or got better at:
- planning and executing scientific tests
- mechatronic design
- working with embedded systems
- environmentally hardened mechanical design principles
- writing code that others can read and use
- writing code in MATLAB, Python and Arduino languages
- working with and debugging serial and ethernet communications
- designing and building mechanical components
...and gained a better understanding of:
- the accumulated wisdom and experience of a long-established project
- designing ruggedized, field-deployable robots
- maintaining 40+ identical modular robot components
- satisfying different research interests with one robot platform
- the business aspect of running a research laboratory
- how much you need to know about mechanics, electronics, software and math to be a proper roboticist