Yorick: A journey begins
This is very late — about a year late.. so I am late but that’s ok because I’m making cool stuff! here’s a picture of Steve saying hi to distract you from my lateness.
What, another spider?
Yes, but this one’s different. Steve ( his story ) was a prototype and he was meant to be the beginning of an awesome journey, I’m well on my way now. But the journey has completely changed, I’ve gone from building a robot spider as a platform to build other things to building mayhem and fun at the same time as the odd spider because they’re cool.
Yorick is the unstable project, just like Debian has the Sid version that has the newest and most unstable tools; Yorick is where all of the new ideas I am working on will go. He will always be the most shiny spider and he’ll be in a constant state of re-invention.
I haven’t got him walking yet and he’s already got a backlog of updated parts to print and install.
Do we have a plan?
Yes, but to know where we’re going we need to know where we’ve been.
Steve has a single Arduino Mega, a concise comms protocol a smilie screen and no sensor capability what so ever. He is the robotic spider equivalent of an RC car. His success criteria was that he could walk forward and backward and rotate on the spot — done, next!
Steve is not just limited though, his processor and the nostalgia of “my first robot” means he can’t be upgraded.
Yorick needs to grow faster than I can learn and be limited only by my time. It’s time for more ambitious success criteria!
The user stories below show what will mark Yorick’s success:
As Yorick, a henchman of the robotic spider apocalypse:
1. I want to be able to navigate myself up and down a flight of stairs, so I may better hunt my prey.
2. I need to be large enough to strike fear into the hearts of the strong, so I may weaken their defences.
3. I need to be able to keep my battery charged for an extended period of time, so I may continue do my job while everyone sleeps *evil laugh*
To answer and realise these user stories Yorick needs a bunch of things:
- he needs to be large
- lots of battery life (taking into account he’s large so he’s heavy)
- the ability to self-charge
- to use smart-walking rather than macro’s
- sensors to measure a lot of things
- some sort of perception thing — maybe camera’s
- powerful servo’s
- plenty of processing power and very good software
- obviously some sort of turret for all the killing
- he needs to look cool because it makes sharing his story better!
I don’t know enough to complete this project but I know enough to start.
For this reason I started scribbles on paper:
I proceeded to work on the chassis while researching everything else. Realising something visually and in the real world has a startlingly positive effect on motivation.
The plan thus far is:
- get the core chassis done
- build some legs
- build power delivery
- wire up servo control
- build a basic running core using Steve’s firmware — make him walk using symmetric 4 up — 4 down pattern
- still using Steve’s firmware use IK calculations to build 2 up 6 down walking models
- develop core engine in rust
- develop sensory walking systems
- go to 9
- something something machine learning on neural network the dark side
- get Yorick to fetch the remote
- fetch the remote for Yorick
Moving on! Steady as she goes
This is where I’m at.
Size — how small is too small?
After much investigation and some deliberation I threw out all the outcomes and guessed. It makes sense in all sorts of ways to just pick a number. I decided he needs to have a 1m + leg span.
I am now at iteration 3 of the chassis, he did get up to 1.6m but the torque required was simply too much for sub $100 servos — lets not forget I need at least 24 servos.
Here’s a time lapse of the ~18 hours of construction of revision 3 of the legs:
Battery and power
Long legs need powerful servo’s. Powerful servo’s need lots of current, lots of current needs really big batteries, big batteries need big regulation, big current needs big cables. And I need very specific voltages for servo’s (turns out).
After burning out several power boxes and quite a few servos ($60 each!!) I built the 8 channel power grid. I am using 3 channels per side for the legs and two channels for logic and cooling. I call it a power grid because the circuit diagram looks like a grid..
Then batteries.. currently his belly has 8x 3.7V 2900mAh 18650 batteries but I will be at least doubling this.
I’ve not built this yet but it makes sense that he can charge himself so I will be building a charger that has a locator on it so he can find the charger and be inductively charged.
This is a really basic way to say that he:
- calculates where his legs need to be based on where they are and where they are going
- can walk over uneven surfaces
- can control roll, pitch and yaw to allow tilting and climbing (within reason)
To do this I need to employ a few great buzz words and acronyms.
IK/FK or Inverse and Forward Kinematics
This is a pretty cool way of saying “chained trigonometry”. Each one of the legs has 3 servos that move on one axis only, they have fixed length and limited angles of movement. Forward Kinematics is when you say “all of the motors are at these angles, where is the foot?” whereas Inverse Kinematics is when you say “I want the foot to be here, what position should I move the servos to?”.
Machine Learning / Neural network training
To perfect the walking algorithms I am using a combination of what makes sense to me and realistic feedback from things like legs breaking, smoking motors and general mayhem. I’m pretty obsessed with spiders and there’s a bit of physics knowledge in my head which means I can get a long way and besides there’s no real way to prove me wrong right?
Wrong, machine learning is a very broad topic and I am not knowledgeable enough to give a good overview of what it is in a general sense but specifically to this task I plan to virtualise the physics of the spider and use a neural network backed machine learning system to determine whats good walking and whats not.
Most machine learning is based on a set of true outcomes and the training system validates the best approach by how much of those outcomes are validated. My plan will be to use a graded learning system that allows multiple success structures for complicated subjects, for example its easy to say “The spider’s chassis should be as level as possible” and
“The spider’s upper limbs should retain similar angles of movement front to back” and both of these hold true for walking on flat ground but if this were true while walking up an incline, the outcome would be bad.
More on that when I know what I’m learning about.
There’s two main area’s of sensors that I am focusing on.
For walking, because the servo’s wont know how far they have to move, I need to constantly measure where they are and whether the feet are touching the ground. In the event of ground-contact I can quickly say “hey, you, all the servos on leg 3 — yes you , stand still laddy”. I can buy servos that are really strong and really fast and I can buy servos that have analog feedback but I can’t buy both.. So I wired it up myself… This instructable basically sums up what I did : http://www.instructables.com/id/Servo-Feedback-Hack-free/
The goal of Yorick’s complex walking is complete autonomy, he needs varying levels of awareness to do this. For starters I will focus only on very simple perceptive awareness, specifically gyroscopic sensors.
This really is just a fleeting concept at this stage. To walk up a set of stairs we’re going to need a lot more than sensors on the feet detecting contact.
I will need to identify whether there’s an obstacle, then decide whether the obstacle is within tolerances to climb on top.
Then topographical mapping, waypoint planning target acquisition… it all gets very complex.
For now I will focus on locating and getting him to his charger so he can auto-charge. This will require a single camera to find the charger and a sonic sensor to detect distance.
After unintentionally setting fire to a few hundred dollars worth of components I took a very close look at what I needed and learned some new math stuff. The torque leverage equation was particularly helpful:
It looks a little complicated but the long and the short of it is that if you have an 8 legged spider that weighs 9.5Kg and its standing on 4 legs, the torque on the main lifter motors can be worked out
0 degrees (aka the legs are vertical) we have 2.5kg * length * zero (sin(o))
90 degrees (aka the legs are horizontal) we have 2.5kg * length * 1 (sin(90))
So if the legs are 30cm (spiders don’t walk with their legs fully extended) long we need:
* Zero kg/cm to do nothing
* 90kg/cm to stand statically
Taking that into account, you can’t run servo’s at more than 20–30% of their rated stall value or they will degrade.. so I’d need 300kg/cm stall-rated servo’s?
No not really.. I have 2good options that I can see:
1. I can use more elegant walking procedures (walk on 6 etc)
2. I can pre-spring the joints (literally with springs) to reduce the weight on the servo’s — this conveniently will make them faster too!
I’ve worked out that even with pre-loaded joints I’ll need 15–20kg/cm load on the legs so the servos (remember we can’t run servos much higher than 20% of their rating) need to be hugely powerful.
Plenty of processing power and very good software
I need to have sub 20ms detection, calculation and correction for the walking, control for the turret, camera’s motion, sensors and all the things I’m putting on this thing… so I’ve designed a small network of computing power that involves:
- Odroid Xu4 (8 cores in total, 2gb ram etc) core compute engine
- 3–5 * Teensy 3.2’s for sensors and eye/basic motor control
- Amtel32 based servo controller — just translates basic commands to complex motion.
Now all this hooks up pretty interestingly, there’s combinations of USB, RS232, SPI, I2C, wifi, bluetooth and I’ve even sourced a 4g modem for him. Here’s a basic network diagram I’ve designed:
Software wise, I’m still at a bit of a loss of what it will look like in the end but I will be separating concerns enough to run Yorick in a completely simulated way — this is so I can use machine-learning at 100x the physical world!
Most of the platform will be written in C (Arduino stuff) and Rust (all the smart stuff on the Linux machine).
I’m starting with this idea for the software layout:
Think laser targeted, full auto, dual bb-gun 360x360 degree rotating barrel turret.
Well thats the plan anyways. I haven’t developed this idea yet.
Pose for me
He needs to look cool? really? yes. For two reasons really; adding finish quality to good craftsmanship makes things more fun and motivates you to finish and people thus far (to my surprise) have really enjoyed the story and the fun elements of Steve’s journey so making Yorick look and function amazingly is a good thing.
Yes, battle armour, I haven’t finished prototypes yet but he’ll have battle armour that has been printed very thin so as he bumps into things through the course of his live it will get all marked and look badass.
Using 4 TFT screens and code (somewhat modified) from https://learn.adafruit.com/animated-electronic-eyes-using-teensy-3-1/overview I can have Yorick appearing to look around while identifying targets, quick demo here: