Let's Make Robots!

Biped Walking Robot from a piece of PVC Conduit

For now, it does squats. Hopefully, it will eventually walk in a controlled manner.


*** Hot Breaking NEWS ***

I'm reopening this case file. While revisiting the PIC firmware for this, I found a stonking flaw in my servo output timing. My pulses were happening every 48ms. They shouldn't be more than about 1800ms apart. I don't know why I didn't spot this on a scope months ago. This MAY account for the servo jitters mentioned later, but more importantly, my patched software now drives my MG995 servos! This means I now have enough mechanical power to swing the upper torso weight (battery) from side to side!

Watch this space.


Bipedal Walking Robot Concept


There are many walking robots, including bipeds, available from several vendors. They are mostly highly priced: something like the brilliant RoboNova would easily set us back US$1,000. If we aim our sights at a less expensive, less functional piece, it still might run to UK£200. My objective is to create one for under £50, from parts available at any DIY shop (including eBay!) and reusing as much of the stuff I already have lying around.


Having tried several materials, such as right-angle aluminum extrusion, I found none of them suitable and was on the verge of giving up. To have the pieces fabricated would defeat the purpose of the exercise and was going to prove massively expensive. Late in November of 2007, I settled on a most unexpected material: box section PVC plastic ducting.

This stuff is typically used in home extraction fan systems and is sold at most DIY shops in 1m lengths for around £8. If I hadn't botched so many of my first attempts, I'd say that a 1m length would have been plenty to build a functional pair of legs and a body core.

The choice for motorising the legs was not so difficult. It had to be the servos used in radio control toys. These can be positioned quite precisely, have a rotation of about 180 degrees and can be controlled directly from a microprocessor with no worries about position feedback. As it happened I had many of these around as I am a fan of R/C cars. If they're sought new, they can be obtained readily on eBay. At the time of writing, £12 would readily buy you FOUR!

Having been reasonably satisfied with M4 bolts for holding things together (complete overkill for a plastic toy, but readily obtainable and inexpensive) I found these lovely little 4mm plastic rivets on eBay. They hold things together amazingly well.

I've been programming Microchip PICs for a couple of years in their native RISC assembly language and am quite comfortable with that, so the only debate over the choice of control hardware was: which one should I use? (More on that later.)


After prancing around the house for several days, trying to bend only one joint at a time to establish which ones I really needed in order to walk, I concluded as follows. I need:

  • ankles which bend up and down (pitch)
  • knees which bend back and forth (pitch)
  • and hips which bend forward and back and which can rotate (pitch and roll).

Of course this is only one minimum set of required joints. Other minimum sets of required joints to facilitate walking are available. I'm certain many PhDs have been written offering many more options. Also, feel free to correct me, but my understanding is that this equates to four "degrees of freedom" (DOF).

Oh. One more thing comes to mind: when lifting one leg, it's likely to fall over. That's OKay, because when we walk, that's basically what happens. It's a kind of controlled falling. So, how do we control the fall a bit better? We have a heavy torso, which can be twisted and shifted. The best solution I can come up with is to mount the weighty component of this robot (the battery) pretty high up on a beam parallel with the "waist." This beam will be cross-braced (triangulation style) by another servo. Thus, the servo will be able to shift a large weight from side to side to counterbalance.Conduit_.jpg


The Leg Parts

As documented elsewhere, the main material is 56mm flat PVC ducting. This was run up a bandsaw twice to create two lengths of 54mm x 17mm U-section.

Annoyingly, when the duct was cut lengthways, the top edges of the section bent in towards one another. This is probably an effect of the way they are cooled in the factory. In order to make the opposite faces parallel, they were wedged apart with an appropriately sized piece of timber and a blowlamp applied to soften them.

Every effort was made at the design stage (yes, there WAS a design stage) to make the components as similar and generic as possible. Each leg has two identical "leg pieces" (what an inventive name). They are short lengths of the U-section with cutouts at each end and the ends rounded so that they can rotate inside one another. There are holes drilled at the centre of the round edge and more holes for mounting the servos.

The servos are held in place by two means: there is a protrusion in the top which fits quite neatly into a 12mm hole and which takes most of the sideways force. The servos are prevented from rotating by four of the 4mm plastic rivets mentioned elsewhere.
The leg pieces have the drill pattern applied to both sides so that the servo can be mounted in either side (or if the design is rotated, the servo can be mounted "upside-down").

Hip Joints (Pelvis)

Affording a second degree of freedom, these were more awkward than the ankle and knee joints. This time, the servos were mounted facing downwards from the "pelvis" of the robot. Holes are bored in the "top" of the hip joint and the servo head protrudes. The horn is mounted on the underside of the hip joint, to which it is secured with several small screws.
Without this added degree of freedom, the robot would only be able to walk in a straight line. It is hoped that hip rotation will allow it to change direction. Here we see the "hips" from the underside. Only one leg is attached (the far one) and on the near side, we can see the servo head protruding.

Balancing Act

The robot will carry a power source (a 7.2V racing pack of the Tamiya type commonly found in radio-controlled cars). The square frame ("torso") visible at the top of the topmost photo is hinged at every corner (in the same manner as the knee joints). There is a servo mounted on one of the joints, which is capable of deforming the square into aparallelogram. The battery is mounted on top of the topmost beam. With this mechanism, the weight of the batery can be shifted from side to side and it is hoped that this will allow the robot to balance while one foot is off the ground.

Control ElectronicsHipsFrom_Below_.jpg

The interface between the control computer and the servo motors is reasonably uncomplicated from an electronics point of view. A TTL/RS-232 line level converter (MAX-232) acts as the interface between the control computer and a Microchip PIC microcontroller. This microcontroller creates 10 unique square wave outputs. I'm not going to bore you with another description of those outputs unless the thousands of websites which already do such a good job all die. Examples are:

  • Society of Robots
  • Seattle Robotics Society
  • Digital Nemesis
  • Bob Blick
  • Instructables
  • etc.

One note, though: many sites refer to this as "Pulse Width Modulation" and, I suppose this is correct as we are modulating the width of the pulse. That said, don't fall into the trap I fell into when starting out. The "value" of a PWM signal is often derived from the mark to space ratio. Don't assume that the servo position is a function of the mark to space ratio. It isn't. The servo position is derived purely from the width of the "high" pulse. At the same time, the entire duty cycle does need to be between 5 and 25ms.
I noticed that standard Radio Control servos can easily draw 300mA at stall and a bit more when starting to move. This was causing my PIC to reset and my solution was to split the incoming battery power four ways through four 5V regulators. One regulator supplies the PIC and the serial interface and each of the other three supplies power to two or three of the servos.

That aside, my circuit has an LED. I like flashing lights.

By the way, I made this PCB myself. I'll need to create a separate blog to show you how. Sure, it's been done before, too, but I really like my process. This is my first attempt at printing the component side.

Communications Protocol
(Watch this space. It's likely that this protocol, or a superset will be used in the modular robot electronics project.)

In order to allow communications between the robot and a control computer (a PC in the first instance and a Palm Pilot in the final piece), a protocol was devised.

Early on, it became apparent that it would be limiting and require a lot of unnecessary work to devise a system which would only allow specific commands to be sent to specific parts od a specific PIC project. The decision was made to devise a protocol which would allow any RAM address in the PIC to be modified via its USART port. IMP (Inspection and Modification Protocol) was born. As a side effect, it can also be used to inspect and modify the SFRs and plans are afoot to investigate mechanisms to directly address any EEPROM which maybe available.

To start a "conversation", the control computer might send any (or all) of the following commands to the PIC:

  • set bank
  • set address
  • set bit index
  • set value (low byte)
  • set value (high byte)

PCB02_SolderSide.jpgThe commands cause some internal registers to be set in the PIC which hold the bank, address and value, etc. of the bit or byte (or word!) about to be inspected or modified. One these registers are set, they remain set, so if all of the RAM to be accessed is known to be in bank 0, the PIC only needs to be told "set bank 0" once. Likewise, if only one RAM location ever needs modified, it only nees to be told "set address nn" once.

It then follows with one of:

  • modify bit
  • inspect bit
  • modify byte
  • inspect byte
  • modify word
  • inspect word

which causes the information given in the first phase to be used to inspect or modify a location.

Of course, the textual names of the commands given are not actually sent on the serial port: each of the above has a corresponding byte, so each command is actually only one byte in size. NB each item in the first list above also requires a data byte to be sent.

Rather than the user supplying the address of the data to be modified, the client holds a copy of the symbol table, so it is able to look up any given symbol to establish its address.

By way of verification, each command byte sent to the PIC is echoed after it has been executed. this means the PIC does not require a software receive buffer, but that the host is responsible for ensuring that no data byte is sent until the echo from the previous has been received.

Software (PIC)

The embedded software was written in Microchip's native RISC assembly. I'm perfectly comfortable in that environment.

PCB01_ComponentSide_.jpgSoftware (Palm)

Although it was never mounted, I have written the client program in yBASIC on my Palm Pilot Vx. It works really well. The Palm is an amazing robot control device. Join me in campaigning for the introduction of serial port code to iziBASIC.

Software (Windows)

The client used for most of the debugging was written in National Instruments LabVIEW 7.1. It's the ideal control programming language with readily available user interface components, and it's graphical, so it's an option for non-programmers. Unfortunately, a $1,200 pricetag means unless you're using it at work, it's not really an option for homers. (If you're a professor, you can get it for free!)

Not a lot of people know this (and probably fewer care) but LabVIEW is the backbone of the Lego Mindstorms RIS for their RCX product. As I understand it, RIS is basically a cut-down version of LabVIEW.

Summing Up


The design was acceptable. The construction was rapid and the result showed the haste. The pushrods were a mistake. They introduced far too much slack into the system, particularly when the joints were at their most straight. Consequently, movement required to be slow in order to avoid overshooting a slop-point.

Having raved about how great the little plastic rivets were, they turned out not to be so good. The interference-fit rings which held the rivets in place seemed to split reasonably often and in many cases I reverted back to M4 bolts with nylock nuts.


The PIC software was allright. It was always jerky: the bot sometimes looked like it was shivering. I suspect this is because so many clock cycles were used in the main loop that the length of the high part of the output pulse was in a state of flux. I can't see a way of demonstrating this without a digital storage scope. The communications protocol was spectacularly robust.


With analog electronics not my forte, I often wondered if my power distribution (a handful of 1A regulators powered in parallel, each distributing power to a group of the servos) mechanism was the best approach. I couldn't think of an alternative. It didn't overheat, which may be more of a comment on the large chunk of aluminium I hung off it. That aside, I definitely selected the correct microcontroller for the job and the TTL/RS-232 interface is an amazing little chip. I should have included In-Circuit Serial Programming (ICSP).

Future Work

I need to think a little more about the mechanical side of things to reduce the amount of slop in the joints. I need a more powerful motor or a completely different mechanism to shift the balancing weight around.

In summary, for a first project a biped was probably over ambitious. Maybe I should cut my teeth on a hexapod next!

Comment viewing options

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

Excellent project. You writing is very concise and detailed. Great "walk through" (heh).

I have been interested for a while in the mechanics of walking/running. It is very true in all these projects that Walking = Controlled Falling. Have you looked into accelerometers? They are not as fancy as the fiber-optic gyroscopes in the ultimate balancing/falling robot "ball bot" but they are much less inexpensive.

I noticed (although I've never owned one) that robosapien has many re-genetive springs. This mechanical component can enhance walking (shock absorbtion) and lend itself to natural harmonic gates.

Hope you'll walk us through another addition of your project soon.


In the first instance, the goal here was to create a purely scripted robot (no feedback to the processor at all). Granted, the servos are inherently under closed loop control (you set a position and it adjusts until it gets there). The primary aim was to do it for under $100. Although there's too much slop in the frame, I feel that it could be shored up with triangulating braces. I know that the holes drilled for the joints are a major source of slop: I only had a 4.5mm drill and the pins are 4mm. I must invest in a 4.1mm drill for the mark II.

Even thought it seems unlikely that it will walk, as prototypes go, I'm extremely happy with it. If I could find aluminium extrusion of the correct dimensions that would be my material of preference.

So, there was always going to be a mark II. I have triple axis accelerometers which are only a few pennies to buy and manufacturers are only too happy to send frr engineering samples. Unfortunately, I managed to request a CMOS version but my main logic voltage is 5V. I don't think accelerometers on their own are going to be sufficient for balance. They are great at telling you which way is down when stationary, but not while mobile. I think a gyro would be required too. Sometimes you can get R/C gyros on eBay for about $20. First, though, I think I'd go for pressure sensors (probably just momentary switches) in the feet. I'd like for it to be under human control, but autonomous enough to cope with small stairs.

God created the integers; all else is the work of man - Leopold Kronecker

thats wounderfully thought up. i often think about making a biped humanoid and then i tell myself to get back to reality. =)

I've been through the Lego Mindstorms, the DIY line-trackers, the distance sensing and I left only TWO "holy grails".

1) The all-terrain biped (of which this was phase one - the unintelligent flat surface only version)

2) the co-axial wheeled balancing robot. (http://letsmakerobots.com/node/640)

I should probably have cut my teeth on a hexapod. In fact, I think I'll do that next. (After I finish my electronic drumkit, my handsfree adapter for a phone which has no socket for a handsfree adapter and my ultrasonic oiltank depth guage. Oh, and the camera tripod for my friend's wheelchair.)

God created the integers; all else is the work of man - Leopold Kronecker

Rivets_.jpgSplitRing.jpgThese are the little rivets, which at first I thought were great, but then the "rings" which hold them in place started to split. Dunno why: there was never any great force on them.






Also, enclosed is the populated PCB. (You can guess which photo os which.) This  project's at a bit of a standstill due to mechanical problems, but there have been some good lessons from it.PCB03_ComponentSide_.jpg

I was wondering if you can post the diagrams  and the dimensions of the parts

Well, yeah, if I'd drawn any I would post them.

You just get a bit of flat conduit. I'm prety sure it'sall the same size. Rip it up the middle and find a sensible place to mount your servos!

Actually, I wouldn't recommend copying this design. When I finish some of my other projects, I'm going to redesign it. The failing in this one is that it's too flimsy: there's too much play in the joints and not enough leverage provided by the push rods.

The Mark II will probably use pulleys mounted on theservo arms attached to the legs by fishing line. That'll give me more power and less slop. Watch this space. (In about 3 months time.)

I wish I had a better machine shop for stuff like that!
But, the parts can be made out of pbc and i dont think a huge totorque is needed im guesing some analog futaba will make the trick