Let's Make Robots!

An evolving 2 DOF hexapod - build log

Hello all.

 

I'm going to use this blog as much as a lab book for myself and my partner as I am for fascinating and entertaining you guys, so if it rambles at time, I apologise in advance.

 

The basic premise of this build is to allow a platform that can be hacked apart and upgraded as needed - it's for learning, rather than a finished product. 

 

In terms of philosophy, one of the main goals to to produce something that is mechanically of high quality - I read a quote that a mechanically well built robot saves a huge amount of programming, and I think that's true.

I'm handling the main bulk of the mechanical side and running ahead with the theory side. My mate - Mark - is dealing with most of the electronics and we will be spliting the coding.

 

Start State

We're going to start by building a simple 2 DOF servo driven hexapod with no other major functions.

The designs are here:

http://www.webx.dk/robot-crawler/robot-crawler.htm

I have re-drawn the plans in AutoCAD, because there were a couple of issues with them. Unfortunately, the new designs are currently at work, so check back soon for the full set of plans to download.

Build is basic. 5mm 3-ply plywood for the leg mechanisms and a bonded balsawood ply (1/32" ply/fibreglass/balsawood/fibreglass/1/32"ply ) for the decks to keep the rigidity.

I'm not expecting much in terms of quality for the build. Plywood by itself is not a great material to make something which needs significant amounts of precision out of like a robot, and I think the general pattern of using servos to drive legs is a poor one, as a learning excersise it'll do.

The initial bot will be driven by a single Arduino Uno.

 

End State

End state will be a 3-DOF ( or more - still thinking about this ) walker with additional sensors and intelligence.

I'm really not a fan of designs which are based on servos. Its low in control - lots of back-lash in every joint - and too much flexibility - the cases of servos are not designed to be stressed elements, and so flex themselves, which also introduces errors - which is going to make for a nightmare in coding. I am a *terrible* coder - which is where my build partner comes in! - so if we can eliminate as many work arounds as possible, then all the better for me.

Materials will likely be aluminium ( nice to machine, but heavy ) or a Carbon/plywood/carbon ply ( very light and strong, but a pig to machine ).

Sesors will be a 3-way cluster of accelerometers in x-y-z alignment - this is built already and will be in one of the next blog posts, and a paired gyro arrangement - one in a "normal" gyro mode, and one set up as a heading-lock gyro. This is also built, and will also be the topic of another post.

The maths needed blend these imputs together is getting a bit fierce ( I don't have a Computer Science background - I'm an economist by training - please don't hate me too much - I work in IT now ) so I'm on a learning curve that is nearly vertical involving all sorts of things I was hoping to be able to keep away from, but it's looking like I can't - integrating under differentials, Kalman filters and so on have become topics for lunchtime discussion. The women in the office are *not* finding it either sexy or alluring.

We will also be putting in collision detection and collision sensing although what exactly this form will take isn't yet clear.

With all of the data thats going to be coming in, we're going to be taking a "What would google do" approach. Rather than sit down and go through many cycles of optimisation by hand, we've got the accelerometers and gyros glued to the top of an R/C car at the moment which were running over different surfaces, and recording all the inputs we made on the sticks.

This is going into a Genetic Algorithm system as we build up more and more data, along with outlines of kalman filters. As we throw more data at it, the result will be an optimised set of algorithms for blending all of the sensor data together for various different surfaces. that way. we let a computer do a lot of the "heavy lifting" on the algorithm side.

<<This is where having a spare IBM p790 p-series mini-supercomputer in the office has it's benefits>>

Again, I will post more on this in future blog posts.

 

Facilities

I have a fairly well put together workshop - I have a couple of mills (bridgeport for the big stuff, warco for the smaller stuff ), a good lathe ( Myford Big Bore Super 7 ) and a big lathe - Colchester Student 3100, which is only going to be needed if this project SERIOUSLY goes off track. Also things like bandsaws, scrollsaws, drill presses etc floating about as well.

All machines are DRO'd but I don't have CNC facilities - just becuase it doesn't seen like much fun. I have no issue making any part thats needed - it's just going to take longer - sometimes much longer-  than it would with CNC. But it'll be fun!

In terms of the electronics, we have SMT facilities, UV PCB etch systems ( 0.1mm tracks! -- absolutely pointless but it looks cool --- , scopes etc, and Mark is a genius when it comes to electrical design, so we have a lot of flexibility on this side, as long as RS-Online stays in business!

 

What we don't have much of is TIME. Stupid things like jobs, families and kids get in the way, so this whole thing is going to be built between the hours of 10pm and 1am 2 or 3 nights a week. Not the best times of the week to focus on quality....

Next post: Basic bot mechanicals and a look at the gyros.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
SlowSteve's picture

Thanks for the comments guys.

 

Firstly, the site above isn't mine, I found a link to it on the LMR forum. Not my plans either. I still haven't brought home the plans, so I will make sure I get them up tomorrow.

 

As for coding:

For the "backend" stuff, letting a computer chew through a load of data to help us with stuff like blending gyro and accelerometer data together, we'll be doing most of it in Scala, just because it's a really nice language to use. Functional languages - like Scala - are tailor made for robots - sadly you can't get it to run on an actual bot. But for chewing through data, it's perfect.

For the bot itself, we'll mock up as much as we can in Scala again to get a functional set of algorithms, and then re-write once into Arduino C. Reason for that is that we can both work a lot quicker in a JVM based language - we know Java/Scala/Groovy first, and are learning C at the moment, and the tooling for JVM languages is vastly more advanced, so we may as well let the tools carry the load. we both perfer shaking everything out in Scala first, and only going into C when we're happy it's pretty much right.

 

In terms of patterns, we're planning to follow  of a FSM/Technical Serice type of approach - so we have a set of functions handling, for example the movement of the front legs, one of which is an dimensional invert of the other ( moving the front left leg is the same as the front right, just in a different dimension). The fine grained "services" can be then strung together to make a robot move along. So you have a master control "walk forwards" triggering a series of smaller functions, each of which is a black box. The master routine doesn't care at all HOW the legs move, it just wants to send "move forwards" and get back "Complete" or "failed". 

Similar approach to using the sensors.Then use an even larger scaled meta-"service" to carry out a function such as "walk forwards and don't hit anything".

It's more work to do initially, especially to handle asyncronous stuff, but once the framework is there, it will make hacking the bot about SOOO much easier and quicker. And as the bot is designed to be hacked about, thats a good thing. So something like moving from a 2-DOF to a 3-DOF is going to involve changing two small "services" and in theory nothing else at all. Equally, as new sensors come on board, it's a clear path to add them in and utilise them.

Doing all of this is going to be a bit rough on an Arduino using interupts. If we were doing this whole heartly, we'd write a basic MQ into the kernel and/or bootstrap it in some way. It's totally do-able, but I think that may involve more ASM than is healthy for a hobby. We reckon 6 weeks of work would be needed, and we'd rather use that 6 weeks to do more fun things at the moment. If it gets really cumbersome, we'll buckle down and do it, but I'm hoping to avoid it for a while yet.

 

 

ignoblegnome's picture

I checked out your site. Looks like a very promising project. Thanks for sharing!

robotmaster18's picture

that is nice but what are you using to program it