Making a robotic spider move
A robot without movement is just prop
Prologue
So I built a robotic spider a while ago — called Bobbie, he was the first version of my 3rd model in the robotic spider army.
I had a great deal of joy making him, writing a blog and then that amazing sense of achievement as I took off my creators eyes and let myself marvel for a little bit at the fruits of my labour.
Creators eyes back on again, the biggest issue I can see is that he can’t move which is quite a big problem, in fact when I really think about it, the inability to move makes Bobbie a fairly useless robot! At this point, he’s more of a rather expensive piece of art…
The challenge
I could just use a pre-built macro-based system that I built for Steve The Spider years ago. The biggest challenge here is that the SteveOS code is incapable of dynamic walking (walking over non-flat surfaces) and it isn’t easily expandable.
Expandability is important when I want to start adding on things, like using a Lidar or a 3D camera for mapping out a room.
With this in mind, I need to start again and use ROS as a base — but we’ve got a bigger problem; I have little idea how to make ROS do my bidding.
My plan
Because I always start with a plan.
- Learn how to ROS
- Build virtual Bobbie in ROS
- Build a control system in ROS
- Make virtual Bobbie move using ROS control software
- Do the happy dance (optional)
Learning how to ROS
I decided to learn ROS2, it’s new, it’s what all the cool kids are using and it’s got a lot going for it.
Find someone who knows
First off I have to ask someone who knows, the force of creativity is madness without direction! At my work, I’m fortunate to be surrounded by people who know more than me about everything, it just so happens that a workmate with the same name as the spider, Bobbie, knows a lot about ROS. First thing he says:
Right so you need ROS to do the thing, but why ROS2? Why not ROS1? ROS2 is new and some of the modules you may need haven’t been migrated, to use ROS2 you’ll need a ROS1–2 bridge which is annoying.
And I said:
ROS2 is shiny, it’s new, like all my other new stuff, I’ve got new headphones you know, I like new stuff, shiny is good right?
The silence in his response suggested that shiny was indeed not necessary at this point.
Making good decisions
So, it looks like ROS Melodic is my way forward. As far as I could tell at this point, the ROS2 API has the same outcomes as ROS at least conceptually so learning ROS isn’t going to be a waste at all. Maybe I’ll have to throw away 20% of my code and rebuild later when I move from ROS1 to ROS2.
This is a personal project so instead of waiting till I’m allowed to fix bad stuff, I refactor and rewrite as I go so, truth be told I’ll probably be throwing away more than that whenever I make a change.
Using good tools
I’ve been playing with ROS for a bit using a couple of courses on Udemy from this guy — they’re very good. But I needed to go a lot deeper, thankfully Bobbie (the human) recommended recommended Robot Ignite Academy and a few specific courses to do to upskill.
Make a plan
I decided on a learning plan, Robot Ignite Academy have a few courses and collections of courses called learning paths which I am very interested in:
So my plan is to do all of them but I’ve started with Core foundation with ROS and ROS for beginners.
The training interface is absolutely brilliant, it has a fully virtualised robot ROS, IDE, terminals and a Jupyter notebook for the instructions. You do all of the training within a web browser.
Making Virtual Bobbie in ROS
With my new found ROS’ness, I got started with building a virtual representation of Bobbie in ROS.
ROS uses an XML format called URDF to determine the physical characteristics for the virtual representation of the robots there’s a nice howto here. The simplest way to test the robot is using RVIS, this uses the URDF files and renders it in a 3d space.
After about 15 hours and a lot of work in XACRO (XML macro files) and URDF files, I have Bobbie in the RVIS window and I can make the joints move using the joint state publisher gui application, this is a good thing to start with as it helps you eyeball the way your robot should move.
Virtual version + physics
Now this is where it gets interesting… To properly simulate the robot, I need a physics based environment. I quickly threw together the minimum requirements for Gazebo which includes settings that infer the mass, tension and friction… this didn’t work… the robot either cartwheeled away or exploded into it’s constituent parts.
This wasn’t going to be something I could just fudge together. I found a good tutorial on how to use meshlab to generate the inertial characteristics — which are the characteristics of an object that impact how the forces apply to that object (more science here). With these getting closer to correct — things started to look better! However, I read the instructions incorrectly and thus nothing worked correctly.
After some searching around and getting annoyed with Excel, I opted to save the day (and my sanity) with this Python project. Python to the rescue, how… normal! This project generates the inertial data from the 3d objects rather than doing a multi-step-with-excel (screams in gen-x) process.
After many hours of messing around, I got the physics right.
Motion in gazebo
To get the motors moving in Gazebo I followed this example. It uses ROS Topics to send a call to move the joints to a specified position (in radians).
In a real world, we have real-world limitations and motion constraints. In a virtual world, telling the motor to move to x will make it do that immediately, to make it move in a more-real-world way, I’ll need to tell it to make smaller steps and to make it not jitter from state to state and use a PID controller to smooth out the motion.
For those not in the know, PID stands for proportional, integral, derivative control. I’ll break it down:
P: if you’re not where you want to be, get there.
I: if you haven’t been where you want to be for a long time, get there faster
D: if you’re getting close to where you want to be, slow down.
A demo of PID from one of my favourite YouTubers; James Bruton:
This is another video of a project that relies on a PID controller from James here, it’s 15 mins but very cool.
After following this video: https://youtu.be/gA-O39LrXzI I manually tuned each of the three types of joint; chassis-shoulder, shoulder to lift (humerus) and lift to reach (tibia). I did this by generating sine-like position messages and tweaking the PID live, just like in the video:
Making more complex movements
Cool.. so the motors can move.. For real motion, we need more complex movements involving multiple joints moving at a time, moving in a sequence.
In the Steve project, I figured out that for basic motion using a symmetric gait called alternating tripod gait — this means moving 1/2 the legs in one sequence and the other half in a complementary sequences that propels the robot forward more info here.
In my case, with 8 legs it should probably be called a alternating quadpod gait but that’s not important right now. With this gait, we only need to transition alternating groups of legs between 4 stances to move forwards:
- legs lifted
- legs forward
- legs neutral
- legs backward
In Steve, I just ran these in a sequence, I’ll do the same with Bobbie for the first stages of walking.
Determine Stances
I though up a bunch of stances and guessed the distances by putting my thumb in the air with one eye closed, wiggling the legs and using a metal rule to measure and a bit of paper to record position data.
Using the looks about right scientific method, here’s what I ended up with:
Moving between the stances
I can’t just go from 1/2 the legs up to the other 1/2 of the legs up because the robot will bang it’s chassis on the ground between. I need to add some steps in-between.
To do this, I used a bash script posting a topic to ROS to move the joints in Gazebo — it’s rudimentary and there’s latency between each call so the motion is a bit uncanny but it works. Details in the ROS Control docs here.
Here’s how it looks.
Fin.
I’ve managed to compress several months and 100s of hours into a few minutes reading. Most of that time was spent learning ROS.
But virtual Bobbie moves!! He’s not walking with any kind of intelligence though…
Next steps — there’s a few
The final goal is full dynamic walking, I’m still a long way off this but the next few steps are obvious.
- Make him walk forwards, backwards and rotate using basic macros
- Use inverse kinematics so I can control walking speed
- Use an external controller to set the basic movement plan
- Connect up a camera and drive using FPV!
- Use the ROS SLAM libraries to discover the room
- Use the ROS Navigation libraries to move around in a mapped room
- Develop dynamic walking systems over time
Lots more to come!
