Let's Make Robots!

Polypod - Taking a Stroll on the Cheap

Yet another walking robot but starting from scratch.

Update August 16, 2011

The PCB boards arrived a day earlier than expected (ordered on a Friday, arrived the following Friday). Eleven brain boards and 66 leg boards. I'd buy fewer if I could but for $145 CAD from GoldPhoenix it's hard to find a better deal.

Here you can see a size comparison between a T-Pro SG90 servo, it's standard connector and the leg controller board.  I decided to use 1.5mm (0.059") spacing connectors.  The female connectors are insulation displacement (IDC) so I can avoid fiddling around with crimp pins. Although the IDC connectors are designed for a finer gauge of wire, the servo wires fit fine (as you can see in the photo - top middle connector).

Sodlering the QFN was not as difficult as I'd feared, nor as easy as I'd hoped.  Nonetheless, my AOYUE hot air station made the job fairly straightforward.  Using a loupe you can see the solder connections in the small half millimeter or so gap between the QFN and the board.  In a few cases where the joint was suspect, I used flux and my soldering iron tip on the pad that extends beyond the chip to wick solder underneath. Seems OK.

On the rear of the board you can see the NPN transistors that I use to level shift to 3.3V control pulse to the 6V for the servo.  There are also 4 N-Channel MOSFETs that I hope to use to turn servos on and off.  To the left you can see the 3.3V regulator that provides power for the dsPIC.  The three sets of pads at the lower left are for setting the leg controller I2C address.  With no bridges this would read as 0b111.

I'm off for a short vacation and then I'll be adapting the existing code to the new board. With luck the transition will be smooth. Afterwards I plan to switch the pulse generation code from using interrupts to using the hardware PWM capabilities of the dsPIC.

 

Update August 10, 2011

Oops numbers 3 and 4.

3) I ended up ordering some dust again.  I wasn't paying enough attention and ordered 3.3pF caps in 0201.  Turns out 0201 in metric is 0603 which is what I though I was ordering but not in metric.

4) I also erred in the dsPIC order.  I ordered dsPIC33FJ128MC804 instead of dsPIC33FJ128GP804.  Although the pins are almost identical the MC component is missing 4 analog ports and the PWM is quite different due to it being aimed at motor control. I'll have to order more dsPICS.

Sigh, nothing a little money can't fix.  It's lucky that digikey delivers overnight in my neck of the woods.  My boards should arrive from China on Friday.  Getting excited.

 

Update August 7, 2011

Isn't it always the way that you spot problems after it's too late.  So far I've spotted one Ohhh and one Oops but nothing fatal so far.

1) I designed the brain board around a micro USB connector.  I'd never heard of micro USB before and confused this in my mind with mini USB.  When the part arrived from digi-key I realized my error.  Not a problem though.  I'll just have to buy a micro USB cable.

2) The second error is more embarrassing.  I forgot to route the micro SD chipselect line and I routed two small components on the wrong side of the board (i.e. under the SD connector).  Duh!  Not show stoppers though.  The one component is a bypass cap and frankly there ought to be enough of these elsewhere so I'll ommit this one.  The second is a pull-up resistor on the /CS line. Since I neglected to route the /CS line I can omit the resistor as well,  I'll just drill a small hole by the resistor pad and connect it to ground with a small jumper to enable the SD card.

Hopefully nothing else shows up.

 

Update August 5, 2011

Time is a limited resource but I've been soldiering along.  Since my last update I've been preparing the final board layouts for the leg controller and brain.  I just sent the gerbers off to GoldPhoenix in China to fab the PCBs.

The leg controller boards are 0.8" x 1.8" and feature a DSPIC33FJ64MC804.  The dsPIC is a QFN part so we'll see how successful I am in soldering.  I have an AOYUE hotair station so it should be OK.  My original design supported 3 servos.  I added a fourth for future projects.  My first code used interrupts to time the servo control pulses but in the next iteration I think I will use the built in PWM hardware.  It supports a one shot mode that should be perfect. This chip supports 4 independent PWM channels hence 4 servos.  The leg controller will normally operate as an I2C slave.  Optionally you can add two pullups to the leg controller and  use it as an I2C master. This way you could gang a few leg controllers together via I2C, change the software and maybe do some animatronics.  Something for the future.

The Brain board (2.5" x 1.9") is more ambitious and time will tell whether everything works. 

main processor is a dsPIC33FJ128GP804
PIC18F2553 (via serial) for USB support
MRF24J40MA (via SPI) for wireless communication
MicroSD slot (via SPI)
LM4880 stereo audio amplifier (power by the dsPIC's dual upsampling audio DACs) for sound
MMA7361L three axis analog accelerometer (for future biped projects)
L3G4200D three axis I2C gyroscope (for future biped projects)
10 connectors for I2C slaves
Single or Dual 6V buck regulators (power leg boards and servos from 3 series LiION batteries)

OK, that's all for now.  This project has been a lot of fun so far.  Routing the boards was challenging but very satisfying when done.  I may kick myself for switching to TQFN, QFN and 0603 parts but I've caught the miniaturization bug. Smaller, smaller, smaller! 

I've heard that rather than using expensive jeweler's loupes or dental loupes to do this fine work you can substitute reading glasses in the +3.5 diopter range.  Anyone have experience with this?  They're pretty cheap compared to $100 head mount loupes.

Gerber view of Brain and Leg controllers

 

 

 

 

 

 

 

 

 

 

 

Update July 5, 2011

I've been converting the VB6 code into C for the last few weeks.  I'm using Q16 fixed point instead of floating point.  I've mounted a leg onto a stand so that I can test things.  I've including a short video that shows the leg going through a gate cycle.  The I2C communication between the brain board and the leg board works really well.

Next I'll be working on the proper brain board.  The substitute I've been using is a bit light on program space.  I'm hoping that before long I can send these off to China to make some proper PCB's and I'll finally be able to have more than one leg. :-)

The cheap servos are looking OK but some are a bit twitchy.  These servos put a lot of noise onto the 5V power supply.  Some 10uF capacitors soldered across the power leads to each servo helped alot but I may have to add more filtering.  Hard to say whether these servos will be a problem but I'm optimistic. 

 

--- Original Post ---

My goal is to build a richly featured walking robot but keeping it simple and cheap.  I'm designing everything from the ground up.  No using other people's code or PCBs.  I'm hoping that by starting from scratch I can maybe contribute some new ideas.  There are some really brilliant walking robots out there and I don't simply want to copy someone elses design.

At the moment, the project consists of three threads that are converging.  The first is the mechanical design.  This involves finding simple and cheap methods of building the required legs and body.  1/8" MDF is light, rigid and easy to work with.  The entire body has been built from this.

The next thread is software.  I started by simulating the robot in VB6.  This allows me to perfect the inverse kinematics routines and methods for generating gaits.  I've avoided looking at how others have done this in the hopes that I might come up with some new ideas or approaches.  The video I've posted shows simulated quadrupeds and hexapods walking about.  I'm nearly done writing the dsPIC33 code for the leg controllers.  Shortly I should have a real leg on the test stand twitching and moving around.  After that I'll program the brain board.

The final thread is electronics.  I like to design and build my own boards.  Each leg will receive a 40MIPS dsPIC33 to do the inverse kinematics and motion while in the air.  It will also sense a couple of tactile switches and an optical sensor.  The code uses signed 15.16 fixed point for speed.  This board exists as a prototype.  I'll probably do one additional revision incorporating what I learn.

The brain board hasn't been designed yet but I have another board I made that has substantially the same capabilities and it will substitute for the time being.  It has a 40MIPS dsPIC33 plus a PIC18F2553 for USB support.

There's a developer diary over at my web site if anyone's interested in following along or reading about things in more detail.  I'll update this post as I reach significant milestones.  Once the project is done I'll share the entire design.

Cheers and happy building.

Comment viewing options

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

Hi Doc :)

I ilke your quadruped ! very good design and and hope you post more videos , (walking videos.

Now i'm going to visit your website.

Keep the good job !

MoX

You asked about magnifiers, here's one I've used, pretty cheap : head magnifier, lighted

How does the weight feel to you, are the servos being overloaded? Cute little quad, looks like fun!

Hi,

I can't say for sure but I'm hopeful.  I've tried to keep everything very light and the legs short so there won't be too much lever action on the servos.  But, this is my first walker so I might be in for a surprise.  At least I'm confident that the design is quite rigid which, based on youtube videos I've watched, appears to be a bigger problem.

The nice thing is that I can easly up the number of legs.  With 6 legs and a tripod gait the weight will be distributed across three legs, so say 200g each.  If I can keep the leg extension to less than 6cm then leverage shouldn't cause more than 1200g/cm at the hip servo.  Since the servos are typically rated in the 1500g/cm plus range, and I'm running at 6V rather than the more common 4.8V, I think (fingers crossed) things will be OK.

Cheers.

 

Dr Iguana

For my Spindelumen project I used just one of these servos powered off of a 5v regulated supply, I found that the speed and power were impressive but that the noise was terrible (high pitched whine). A minor accident in development of the program ment that for one version I sent control signals to the servo 1/4 as often as normal - the servo ran slower but near silently. It might be an idea to build variable PWM refreshes so that lower speed locomotion is also quieter.

 

regards,
Drew.

Hi curly.drew

It's a good question what the ideal refresh rate for these servos is.  In my design the servo update rate is constant.  I picked a rather arbitrary value of 50Hz to start with.  I have one leg on a test stand for the moment as I transfer the VB6 code into C.  Two of the three servos are silent while the third whines a bit.  Interestingly the two servos that are silent have perhaps 3 or 4 degrees of play while the noisy servo is very tight with next to no slack.  Perhaps these are connected.  Having a rather large 'dead zone' around the current position would probably prevent jittering and hance noise.

How often did you update the servo position to produce the quiet movement?  Does the servo run slower because you're playing the same set of servo positions over a longer period?  In my case I'm calculating positions dynamically knowing what the time between servo pulses is.  In theory I can adjust the update rate to any value and the movement should stay the same.

What is your Spindelumen project.  Sounds interesting.  Spinning lights?  Cheers.

Dr. Iguana

Servos are normally refreshed every 20mS (50Hz) but some systems refresh at 15mS.

When a servo does not get a pulse within about 25-30mS it will turn off. This is why Curly's servos juddered. They would shut down, drift under the load and then try to regain the correct position when they finally got a new pulse.

Hi OddBot,

That sounds right; one addendum that I'd make is that beyond a threshold load/refresh rate you get very severe judder, however if your load isn't too high the internal friction of the gear box has a smoothing effect, meaning that your motor runs slower and quieter (at least for these very small, very noisy style servos). Bear in mind that a reduced turning speed equates to less load for a given mass...and also that at a low rate of turn, inertia will keep a free floating mass travelling in the judder direction, reducing the actual judder impact force. As for a servo loaded in one particular direction - I'm not so sure whether it would do any good at a guess it's load dependant and works up to a point.

The motor does judder in all cases of course, but in my case I was offsetting smoothness and noise. It's a hacky way of controlling for motor speed but it does have a few applications, like my screen for example where I can't spend too much time on the motor control, or a robot with very limited processing power available to locomotory control.

Thanks,
Drew

p.s. Do you think that altering the resistance on the position variable resistor of the servo (say a 500 ohm resistor parallel to either side of the variable resistor) reduce it's rotation speed? I know it's hackish again...but I can't helping thinking it would be useful for something.

Hi Drew,

When I use continuous rotation servos I get slower speeds by sending pulses which are only slightly longer or shorter than the centre value of 1.5ms.  The error voltage is small and the servo is slow.  As the pulse lengths deviate further, the speed picks up until it peaks.

To attain slower speeds on my normal servos I "walk" the servos to the new location over time by sending the intermediate location values.  I won't see how they work under load for a while since at the moment I only have electronics for one leg.

 

Hi Oddbot,

Thanks for your comments.

There are no doubt several different kinds of instability in the servos we use.  As you pointed out, servos that use an analog PID may well "forget" the set value if the pulses don't come often enough.  Those that use a digital PID shouldn't have this problem because a microcontroller should remember the last received set value indefinitely. 

In my case, some of my cheap $2.77 servos seem more sensitive to noise on the supply line than others.  They have a 'regular' pattern to their twitches but with the occassional missed twitch.  Some positions seem completely stable whereas a degree away one servo twitches.  If you look at the supply voltage on the scope you can see small upward and downward steps in the voltage.  I'm pretty certain that the twitches occur when the noise from multiple servos reinforce.  A beat pattern.

At the time I was busy coding so I didn't worry about it too much.  When I get ready to make the final version of the leg controller PCB I'll look at this closer and characterize the noise more exactly.  I'm pretty sure that some filter caps on the supply line between servos will largely fix the problem. Or at least I hope so.

Dr Iguana

Hi Dr. Iguana,

I think I was using 40Hz, and accidentally dropped down to 10Hz (I got a prescaler value mixed up). The lower the update speed the more that the servo judders - i.e. turns a small amount, slows and speeds up again, slows and speeds up again, all the way to the target. Under the load of my current project (Spindleumen - basically moving an arm with a writing head on the end) 10Hz is just about perfect (very little judder, noise and a nice slow speed). Note that too slow/too much load and the servo will judder in the same position, never turning the motor enough to overcome the gearbox friction and load. Too fast and the servo just goes mental as it samples the signal too slowly to grab the timing data.

You might well be onto something with the "loose gear equates to less noise/jitter" idea...thinking about it now I'm fairly sure I have observed the same effect without realising it (a couple of my projects have twitchy servos, and also have very stiff gearing - my test servo is very loose and suffers no jitter at all). I suppose one test could be to oil up a jittery servo gearbox and see if the jitter dies back, another to swap gearboxes on jittery and non jittery.

A similar problem (although unrelated) that I have had in the past is that these particular servos go mental when they can't get enough current. When the servo is first powered on it typically rotates a few degrees clockwise. If you don't supply an array of servos (all powered off of the same source) with enough current they all try and pull power at different times, resetting each other and each turning clockwise, I broke a test rig and damaged a servo when this happened (all of the servos started hammering to the right at full power).

Spindleumen is a project that I'm currently working on... it really is spinning lights (by far the best kind in my opinion) - it is a simple text only screen, made out of a record player, a servo, glow paint and 8 UV LEDs. I hope to release code and designs open source version next month. It was inspired by a piece of art produced last year, the original artist is kicking a fuss (see comments on the linked page) because I copied their arts, however I'll end up releasing it anyway, they have no particularly cogent argument for me not to. If your interested, my blog also has a partially completed quadruped (no where near as complex as yours, just 4 DOF) and a video of the Spindleumen in action (the video was taken before I slowed the servo down).

If you aren't too bothered about processing speed, Java has a nice library for communicating over serial and USB serial (called RXTX) that I use for my Spindleumen project (it's basically an output stream that you can drop your data into) and it has fairly good graphics APIs too (e.g. Processing.org). My experience of the C equivalent was problematic - C would never close the TTY correctly, meaning that I had to muck around in the command line to clear the TTY to use it again (That was on Ubuntu - I never really figured out what was going wrong or where - I just switched to Java).

Regards,
Drew.

 

Hi Drew,

I hope it won't be too long before I can mount the legs back onto the robot.  I'm just debugging the leg C code.  "Just" is of course a LOL type of word since debugging sometimes consumes the vast majority of the project time.  Anyway, I HOPE it won't take too long and then I'll be able to tell for sure what works and what doesn't.

As for JAVA, I am illiterate.  In my programming carreer, I have managed to learn APL (now forgotten), VB6 (going strong), C (OK but microcontroller C is a bit odd), Flash actionscript (a now depricated version) and a titch of javascript.  I think I'm too tired to learn yet another language but thanks for the suggestion.

Cheers.

Dr. Iguana