I made another robotic spider, Stef
Yes, it’s weird but it’s what I do!
I’ve been slack at writing of late. In my defence; work has been very busy, then I got distracted some time in 2022… also, I was diagnosed with ADHD relatively recently, which does make a quality item in my list of excuses! Moving on :)
Why build another one?
Cause making robots is fun! But also:
Smaller robots are easier to code
Some time in 2020 I finished the physical build of Bobbie and while Bobbie is physically complete, building the system to make him walk proved very complex. I spent a lot of time tweaking but found the size of the robot required a higher level of precision than I could get to, so I figured that building a smaller robot would be a good intermediary step to get a control system working that could be grown to support larger robots.
A small robot to show off to amazing people
In joining my current role in 2019, news of my Robotic Spider projects spread through the internal IOT and Robotics community. Much to my joy and amazement I gained many mentors and peers overnight — most of them are in the US. At the time, while my robots could be transported in cases, none of them were ”put in a backpack and take on a 14 hour flight to the US” portable — I needed a spider that was portable and still capable of demonstrating something.
A low cost, high quality robot to share
I would love to open-source at least parts of my spider projects. To do this, I need the projects to be cost effective and useful, aka have high-quality motion controls.
My first spider; Steve, is a 3D printed spider that costs <$1000AUD. His hobby servos are cost effective but not at all accurate and do not have reliable position feedback — so building adaptive walking isn’t feasible.
The following spiders; Yorick and Bobbie both use Dynamixel MX or X series servos, they come with a hefty price tag — in the “not at all practical” cost category for most people.
Goals — because we always need goals!
- Smol — Stef will be a mini-robot (at least by my terms)
- Accessible in terms of costs — less than $4000AUD in parts is my goal.
- Adaptive systems for walking — at a minimum the spiders need to be able to walk over an uneven surface and adapt. This will require some pretty complex software, position feedback for the actuators, foot-based pressure sensors and a gyroscopic sensor (IMU).
- High-level control — the embedded systems will handle the walking but for higher level operations like navigation and camera integration I will need to run ROS2 on the robot
- Spatial perception and image recognition — a remote control robot is cool and all but we need a camera to start actually doing useful tasks.
Getting started
In building up to this project, I saw the biggest problem was finding servos that were good, fast and cheap — aka unicorn servos. I bought a lot of different servos from AliExpress, Amazon and other places. These were all too big, too slow or didn’t give me the right control/monitoring surfaces.
By chance I found and bought an XGO robotic dog and while playing with it, I noticed that it used daisy-chained smart servos but they were mini! In a cheeky manoeuvre I reached out to the dog manufacturer and asked where I could buy these servos — it turned out that these were built specifically for the XGO2 dog project but they were happy to sell me some at a reasonable price.
This may not be a sustainable source for mass production but it really kicked me into gear, the impossible became possible. Now all I needed was the 3d modelling, wiring and control system skills — CHECK! and a base design to work from CHECK CHECK!.
Conveniently, Bobbie is a perfect template and Steve has rudimentary control systems that can be adapted to suit, so I had all I needed to get started.
What’s in a name?
To quote Shakespeare:
A robot under any other name would still be pretty sweet bro.
Initially this model was meant to mirror Steve’s geometries exactly but with better control systems. While designing the robot I realised that I could hit several birds with one robot by building a mini-version of Bobbie instead of an advanced clone of Steve, by reducing the size I can improve portability, lower cost, simplify the physics and overall reduce the complexity of the build.
But why “Stef”? My ADHD brain is a chaos engine of creativity and spontaneity, so… I’m not 100% sure of where the Stef came from other than “Stef” sounding a bit like “steve” — which is a nice nod to previous achievements.
Getting some data
The biggest challenge with building these robots is that much of the components are part of the frame. Many parts I can just make guesses and move forward but the motors in particular are integral to the dimensions.
Motors
The important dimensions here are servo box-shape and bolt patterns; and the servo horne and bolt hole patterns. To make the design fit the motors, I build an accurate model of the servos and subtract them from the printable parts.
Embedded controller
Based on a Teensy 4.1, my favourite microcontroller for robotics. The Teensy will run the low-level spider software for the walking.
High-level controller
Raspberry pi 4 — everyone knows this awesome little Linux machine — this is where ROS will drive the higher-level operations of the robot. For this build the PI is just a place-holder to allow for it in the final build.
Co Processor
Google Coral is an edge TPU — in the simplest of terms it’s a secondary controller that can execute very specific tasks (like image/facial recognition) much faster and using less power than a normal CPU — this wont be in use for the first prototype but it will be there and powered up in preparation for the next version.
Sensors
Camera
Oak-D Lite this camera is a beast in a small package, it has both stereoscopic cameras and a hi-resolution TOF camera (similar tech to the face recognition on an iPhone) — This will eventually be used for object detection and depth perception but for now, it’s just going in to get the design right. This wont be used until the first production version.
IMU
An Inertial Measurement Unit allows you to measure the robot’s position and motion on many axis at a time. With these readings; we can adapt to surfaces that aren’t on a flat plane and track motion forces as the spider or its environment moves.
Pressure sensors
The pressure sensors go on the tips of the feet (called Tarsis on a spider) and allow me to detect when the foot touches the ground. There are many ways to measure pressure; you can use an analogue Force Sensitive Resistor (like above) and a strain-gauge. Strain gauges are much heavier and larger but are more accurate and consistent. I’m using these mostly as touch sensors with a resolution of no pressure, very light, light, medium, heavy, rather heavy pressure. Because the feet on Stef are TINY, the FSR wins here. There’s some great tutorials on FSR on AdaFruit.
Building v1.0
3D printing
Using my usual workflow of 1000s of lines of OpenSCAD, I model all of the components going into the robot in place, and exclude them from the parts I intend to 3d print.
After numerous and lengthy acts of compulsive tweaking I use my threaded OpenSCAD renderer to use all 20 cores of my gaming PCs CPU and after a surprisingly short amount of time I have lots of parts to print.
I 3d printed the whole thing in Aurarum lime green filament — the Aurarum PETG filament is absolutely brilliant (not just this colour). With the right settings it prints easily and it’s layer adhesion is excellent. Strong prints mean I can make thinner and lighter parts.
Yes, it is weird to print thin and flat panels when I have all the 3D-ness of a 3D printer — for the next version, I want to laser cut them and engrave patterns in the plates so making flat panels is a good trial.
Wiring, so… much… wiring
With 24 motors, batteries, compute boards and serial interfaces, cabling and other madness, we need a lot of wiring — here’s a simplified schematic:
Software stuff
The beginning
I’ve been growing the spider code from the initial development of Steve The Spider but it’s quite unwieldy; with it’s hard-coded dependencies, Steve specific features and overly specific parameters make it almost impossible to use the code for other robots. The code got to a point where almost 60% of it was excluded or included based on compilation defines.
For example; with the motor parameters, Steve uses a single byte to determine a motor position — that is a hexadecimal number specifying a position between 0x00 and 0xFF (0 and 255 respectively) Yorick uses a range of 0x000 to 0xFFF (0 and 4095 respectively) and Stef needs to use between 0x0000 and 0x2003 (0 and 8194 respectively) — considering that I plan to use this code for 5 spider-cores, sticking to ifdef sections this one part would look like this:
That’s just one of 100s of changes, to use compiler defines, I’d end up for more #ifdef blocks than actual code which isn’t just unsightly, it would be totally unmanageable.
The next iteration
For this project I took a long back-step to rewrite the code in a way that it can be used for different robots with different motor controllers and different geometries without using squillions of #ifdef blocks. Using some interesting git tricks I have split out the common functionality and brought that into multiple projects using inheritance, each time I fix something in the core-code, all the robots are improved!
Somewhere during this process I stumbled on a clear definition of a very powerful and equally confusing feature of C++ called void* — so I have a backlog to fix my somewhat bad polymorphism — check it out, it’s super cool.
ROS-ness
During this process I realised that I could actually rip out the Arduino-specific code references and build a pure C++ variant that could run as a ROS node.
But why is that cool? When we simulate a robot in ROS, we either duplicate and refactor the code that runs on our embedded controllers or we scrap together a python script that’s **thumbs in the air** good enough — In my case, good enough isn’t good enough. I want to simulate the actual functionality of the spider, not just copy it.
Software finished?
Just like the builders house or the mechanics project-car, the code is never done but it has evolved from one repository of unmanageable code to several easy-to-manage code repositories, each robot pulls in the shared code and the robot-specific code is only a couple of hundred lines of code (for now!).
The code uses Steve’s rigid tripod (quadpod?) gait to walk, but will have an adaptive sensor-based walking system in future. Because of how I’ve set up the core project, I will only need to implement the adaptive walking system in one place to add it’s functionality to all of my robots!
Sounds easy right? Famous last works :D
Walkies and showing off Stef
Ok so we’ve got a new spider; Stef, she’s glorious in her greenness.
Using the quadpod walking she does pretty well, but oddly slow, I am pretty sure have messed up the motion translation somewhere.
I took her to re:Invent 2023 in Las Vegas and showed her to some of my mentors and friends over there. They had all seen my robots over the web cam and in pictures over the years but never had seen one in person.
I got a great deal of feedback (positive and constructive) about my work and I even heard the only compliment that really hits me where I’m not guarded; they told me that I inspired them and that made the whole project worth while. To inspire a group of great people with incredible skills and experience is the greatest achievement!
fin.
Stef is a little bigger and a lot messier than I wanted and she doesn’t move very fast… But she’s looking great for a v1 and the motion controls are very smooth.
I have already started on V2 — the production version. This will include:
- A much optimised layout
- Plate armour with tattoos!
- Tarsis (spider feet) with sensors and suspension
- Joint pre-load dampening suspension
- More motion control (probably much later)
- ROS navigation
