Yorick: the heavy robot
How to un-heavy a robot and getting it moving
Yorick is the 2nd instalment of my robotic spider army (post explaining that to come!). I’ve been working on Yorick for 4 and a bit years. The kick-off story is here and the follow up to v8.0 is here.
It’s all about the size
Yorick V 8.0 is about 10kg and has a 1.2m leg span, he’s a monstrous robot. The size and weight creates implications that lead to time and cost blow-outs.
Why does size and weight cause time/cost blow outs? One word; Torque. I’ve gone into a bit of detail in the past about this but I’ll repeat it here anyways.
Torque
/tɔːk/
A force that tends to cause rotation.
Torque is a measure of force, specifically rotational force. The torque calculation is:
So when you see servo motors rated at 16kg/cm for example this means that at 90 degrees from vertical sin(90) = 1 your servo motor’s absolute maximum lift for an arm of 16cm is 1kg. Usually they are rated at the catches fire and stops working torque.
The weight of the robot, length of the leg and the reach in the step all contribute to the amount of rotational force that needs to be applied to overcome gravity and make the robot lift it’s own weight while moving and hold it’s weight while standing.
So what — he’s heavy?
Because he’s heavy he needs bigger motors and bigger batteries to power the motors, this means that he gets heavier, this idea spirals out of control and ends up making the robot impossibly expensive, as well as size of the steam powered spider in Wild Wild West..
Smarter things
Simply increasing the power isn’t the smart solution! There’s a few smarter things I have to work on to ensure Yorick can walk and not blow up.
Geometries
Making the robot smaller, making the reach less and reducing the angle of attack/reach on the joints while moving is the first step.
Version 1 of Yorick had a 1.6m leg span and a small central chassis, this meant that any reach beyond 45 degrees was an enormous load.
I’ve reduced the leg length over the last several iterations time and increased the size of the base, this means he’s going to walk slower but his weight is distributed better through movements.
Spring pre-loading
After seeing some other robots in circulation I came up with the idea of spring pre-loading the joints and after numerous conversations with smart people, I came up with the idea of changing where the force is applied from a spring’s action by changing how it’s mounted. It’s really hard to describe how this works but with pictures it’s actually quite simple.
The spring is a very strong pull-spring, it’s across the main lifting servo motor’s axis of rotation. As the leg moves into lower angles, the spring moves away from the axis of rotation and can apply more force to the movement even though the spring is shorter — this is because it has more capacity to apply that force.
The design of this part hasn’t really changed from the prototype in Yorick v7 but the geometries have changed a bit.
The springs on the elbow joint don’t help much for walking but they do help for transport because the legs don’t flop around.
Not just stronger but better actuators
As mentioned previously, the motor’s I ended up using are the Dynamixel MX64R servo motors (for lifting) and the MX28r servos for base rotation. Even with a great deal from Tribotix they are expensive for a hobby project but have several added benefits:
- Very high torque delivery
- Low-latency 2mbit data link over rs485 — useful for walking
- Overload shut-down protection — useful for the pocket
- High speed internal CPU and position feedback — useful for walking!
Batteries and cabling
V7 of Yorick couldn’t walk because the current from static couldn’t be sustained and the motors would shut down. V7 had two 40 amp circuits, one for each side.
The Dynamixel servos at full tilt will draw about 4 amps each for the MX64’s and about 2 amp for the MX28’s.
That works out to about 70 amps at full draw constant but the peak power drain is more like 120 amps when they move from static to weight-bearing so I need a bunch of power capacity. Also, with anything battery powered, we need to have a lot more power capability than we will draw to protect the components from surges.
The setup I have built can support four 3s (12V) LiPo batteries that can be turned on individually that all share an output bus, the battery circuits can sustain 40A each and they combine their outputs at a bus point that has five outgoing lines; one per servo hub and one for the high-power processing circuits.
I may eventually have another SSR for the main CPU line where all the computers will be installed but I’m yet to decide what to do with that.
With some creative software coding, I can do cool things like make it so the robot doesn’t walk at full speed unless it’s got 3 batteries, I can let it walk at reduced speed/gait when it has 2.
Other upgrades
Since I began this blog post I've upgraded Yorick to version V8.1 which has a handful of changes.
Cool feet
The shock absorbers have been revamped to have a spring-loaded lower foot that moves on a bearing to account for non-level surface.
The upper shock has about 15mm of travel and presses on a force sensor.
The force-sensor has been wired up to the chassis so the sensors can be measured — this means I can tell when the foot touches the ground which will be somewhat useful when I get around to the process of walking.
Processor board stuff
In the end the main processing system will run Linux and ROS across multiple small computers but it will still need a low-level system to control the frame and measure things at high speed.
Yorick’s power system is controlled by a teensy 3.6, which is my almost new favourite Arduino compatible board, the only reason it’s almost and doesn’t top the teensy 3.2 is because it’s not 5v tolerant.
The teensy 3.6 has been wired in to control the power system and measure the pressure sensor values — it does this at 4,000 reads per second using the PJRC ADC library which is about 18 times faster than a standard AnalogRead() on the same teensy 3.6.
The RS485 interface (MAX485) that I’ve been using for testing is 5v only so I’ve had a second Teensy for control and walking, I tested sending the pressure sensor values between the teensy’s over UART but the latency was higher than I wanted so I’m using a 3.3v RS485 interface and I’ve moved all of Yorick’s test code across.
Next steps
More physical changes
Moar motors — Currently there’s only 3 batteries running but it’s designed for 4, this will allow the robot to draw more current and last longer.
Replacing PLA — the PLA parts are all dying because they are pressure parts and PLA doesn’t like that. I’ll use PETG for the replacement parts.
Better wiring — the cables for the servo hubs are at tension, I want to rebuild the servo hubs so there’s no tension, this means more laser cutting!
Learning about PID — after being inspired by the OpenDog project and watching the videos a few times each, I realise that not knowing how PID works is cool so I’m going to do that.
Advanced walking with Inverse Kinematics and IMU
Inverse and forward kinematics means using trigonometry to calculate the angle of joints. The current system uses a very basic set of stances and transitions between them over time.
Combining IK and/or FK calculations with position sensors in the motors, pressure sensors in the feet and gyroscopic sensors (IMU) will allow me to distribute the weight across all legs on the ground instead of just hope that my angles are right.
I’ve avoided it as long as I could, the re-write of the walking system to dynamically adjust for the sensors is a complete rewrite of about 80% of the code base and includes some of the most difficult coding I’ve ever done.
Advanced processing
Once the platform works being driven with a basic IK/FK model, I can move the whole thing into ROS and build it again. It’s important that I prove the mechanical system before moving to ROS as replicating the spider motion in ROS is time consuming and I want to save a bit of re-work.
ROS is complex and takes a long time to learn, I found a couple of fantastic Udemy courses that I’m working through to upskill.
In particular the first one takes people through the process of making a robot run in ROS and use OpenCV for basic computer vision… pretty much an A-Z of getting into ROS.
The second course is useful because ROS2 is just around the corner and while ROS will be stable and supported for a number of years, ROS2 will become the standard.
