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.

Hard to believe you're only getting to this now! Seems like forever ago! I see you've been browing some of my other YouTube videos, too!!

You may be right about the power supply. This was supposed to become an untethered robot and was powered from a Tamiya-style NiCD racing pack. This pack should have supplied 10A easy. Trouble is I never put any capacitors on the regulators. Thre were 4x 5V regulators. One for the TTL circuitry and one for each set of 4 servos. I think that the servos torquing backwards and forwards was deriving rather more power from the regulators than a holding current would have been and this may have been causing momentary dips in the MCU power.

This would also have explained why serial comms was so ropey!

It was a bad hardware designe, too. The servo for shifting the balance was never powerful enough and teh PVC was soft enough to twist. I'd like to do it again with bigger servos, aluminium extrusion and big fat capacitors...

Your battery would have been fine for the job. A servo with decent speed and torque could easily draw an amp or two under load, so one regulator for four servos just isn't going to cut it. it would limit the power to the servos and without caps the whole thing would be very noisy (electrically). When you do try again I should have a nice switchmode regulator design for you to drive the servos with. I'm designing a small DC-DC converter that can take 7.2V - 24V on the input and put out 6V @ 10A or more. From there a low dropout regulator can supply your five volts for logic. If it's fined tuned for a specific load then it can have beter than 90% efficiency although servos are such a variable load I'll be happy with better than 80%


I found the servos drawing only 300mA under stall, so I can only guess they were peaking well past that when they were first powered. I anticipate your circuit with interest. The robot remains assembled and I'm busting to strip it down, so hurry up!!


I haven't fine tuned the component values yet but here's a rough design of a robot power supply I'm building that would be suitable for any robot that has lots of servos.


Click on it for a better view. The datasheet for the IC which includes some sample circuits is here.

If you wanted you could uses a 5V version of the chip and eliminate the LM2940 5V regulator. Run your servos of 5V. I'm designing it this way so that the servos get that extra bit of power. Another bonus is that the LM2940 helps isolate the 5V supply from noise and spikes created by the servos. Since 0.015 ohm resistors don't grow on trees I'm looking at using an automotive fuse. Just have to find one with the right resistance.

This should be an efficent design to maximise battery life. Being a buck converter a draw of 6A @ 6V at the output means a draw of less than 3A off of my 14.4V supply (allowing for some inefficency).

Hope this helps :-)

I'll post the final design once it's up and running as a blog or something.


That works. It'd be nice if it could run off 7.2V, though.
It only runs of 14.4V for me. The design will work of 7.2V with minor component value changes. After more thought I realised your better off making up a 6V battery pack (5x1.2V NiMh). Easier than the DC-DC converter and more efficient. then you can just use the second circuit in my Tip/walkthrough on regulation.

Then I'd need to figure out how to charge the bugger. I was trying to use stuff I had lying around!! letsmakerobotsonthecheap.com.


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.)