April 2009 Archives

The Arduino has a built in hardware UART (a hardware serial port) which works as expected. It allows you to talk to external serial devices but there's only one of it so if you want to have an external device talk to you via a serial port and then you want to talk to something else via another serial port then you're out of luck. Serial ports (at the microcontroller level) are, essentially, just about sending a set of signals of a pre-agreed duration out of an I/O pin. This is where the software serial library for the Arduino comes in (by the way, ignore the page you find if you google for "software serial arduino",you want this one, not that one. The software serial library allows you to send and recv serial data on any of the Arduino's I/O pins, or so they say... This would be handy if you're already using the built in UART for something else.

Unfortunately the devil is in the timing when you're doing serial communications. Whilst the Arduino can manage to send data reasonably well it's slightly more challenged to receive it. Especially if you want to do something with it once you get it. The problem boils down to timing. The signals on the serial line don't wait and so if you're waiting for data and then doing something with that data you're likely to miss any other data that comes in whilst you're processing the data you just got... Since I come from a PC background I'm used to my serial data being buffered for me and, well, it just working. 

In summary the software serial code for the Arduino will likely work nicely if you define an appropriately anal protocol between the sender and receiver. You, the Arduino on the software serial port need to tell the other end when you're ready to receive data. You then need to receive a known quantity of data and once you have it the sender can't send any more until you've processed the data you have and then give it the all clear to send some more. Ideally, you need a flow control line between you and the sender for it to work reliably or you need to drive the software serial recv code from an interrupt and buffer the inbound data (and even then you'd need the flow control line to be reliable given data that exceeds your buffer space). Now, this is all possible to do but takes up another I/O pin for the flow control line and I'd need to write code to do it as the software serial library doesn't support it out of the box....

Anyway....

What I thought I could do is switch to simply sending from the software serial port (which is less likely to be affected by me doing other things, as I can't do other things whilst I'm sending!) and send and recv on the hardware UART... Unfortunately this evenings tests seem to imply that this approach is also unreliable... 

So, right now I am relying on the fact that both serial connections that I require are uni-directional, I'm receiving from the PC and sending to the servo controller... Because of this I can use the hardware UART for both links and use it half-duplex on each. However, this is hardly ideal...

One good thing about tonight is that this evening's journey has exposed me to how cute the Arduino's hardware support libraries are. You simply drop some C/C++ code in a directory and it gets built automatically and made available to the Arduino development GUI. Creating new libraries looks stupidly easy and patching existing ones is just a case of editing the source files...  A very nice interface for people who know how to customise the environment and an equally nice interface for those who don't.

I decided that since I would be using a 5v power supply for most of the bits of this project that I'd grab and old mains transformer and wire up a 5v regulator and run from the mains rather than batteries. Since this took up a chunk of space on my breadboard I decided to make it a little more permanent on some strip board. 

I pretty much followed the Sparkfun power supply tutorial with a little artistic license for the 'front panel' and so had a PTC resettable fuse in there to limit the current in case of short circuits, etc. Anyway, it was the PTC that was causing the problem with the servos. It was doing what it should but the servos were trying to pull more current than it would allow and so it was cutting the power (and resetting the servo controller). 

Anyway, once I realised what I thought was going on I slapped the multimeter into the circuit and watched the PTC cut out as the servos pulled more current than it allowed. 

The new power supply is pretty much the same as the old one without the PTC (I'll rely on the protection in the voltage regulators for this one) and with a 3.3v output as well as a 5v output.

The servos run fine now and the current draw is within the spec of the regulator. One more small piece of knowledge acquired...

They are three quite different books and each has a distinct focus. I read AVR: An Introductory Course first. It's a slim volume that teaches you how to program the AVR family of micros with assembly language. It's a good book and the focus is very much on learning how to program the various facilities available and how to use the various programming constructs to get work done. It has an interesting style whereby the author will explain some machine instructions in the course of solving a programming problem and he'll then ask you to provide the next 'x' lines of the program under construction. There are answers at the end of the book. I haven't yet worked through the book in 'answering the questions' mode, but I expect it has a very good effect on how you learn the assembly language under discussion. The book starts with the simpler microcontrollers and later shows you how to simplify the earlier code that you wrote by using the more advanced facilities available with the more advanced processors. It's a good book and it's a real hands on introduction to the subject. 

I read Atmel AVR Microcontroller Primer: Programming and Interfacing (Synthesis Lectures on Digital Circuits and Systems) next and found it a disappointment. Again it does what it says on the cover, but compared to the other two books it's too simplistic and 'hand wavey' to be a great deal of use. It also seems to be a bit of a cut'n'paste job from a more general 'microprocessor' text book. All in all I could have done without this one.

Programming and Customizing the AVR Microcontroller (Programming and Customizing Microcontrollers) is another good one. The initial sections explain the facilities available and the later sections contain code to help you interface the AVR family with various other devices. After that there are a series of projects with schematics, design rationale and code. The book comes with a CD which contains data sheets and a host of information that you could download, some programming tools and code from the book.  

Here's a new lower leg with three switches, one on the foot, one to the inside of the leg and one to the outside of the leg.  

For example, if we're currently at 10, 20, 30 and we need to move to 30, 30, 30 then the second servo would move once for every two moves of the first servo and the third servo wouldn't move at all. The sequence being (10, 20, 30), (11, 20, 30), (12, 21, 30), etc. rather than simply (10, 20, 30), (30, 30, 30)... This works well and makes the movement much smoother. 

Of course, once I had that working I realised that things MUST work that way to allow for sensors on the legs to have any affect at all. If we just said move to 30,30,30 and the leg hit an obstruction halfway through the movement then even if we had a sensor that triggered when we hit the obstruction we wouldn't be able to do much about it as we a) wouldn't know where the servos were at the point at which we touched the obstruction and b) couldn't stop the servos in time to avoid potentially damaging them. With the smoothed sequence of moves we would, hopefully, get feedback in time to stop the servos and move them back a couple of steps in the sequence to hopefully take the pressure off. We'd also know where we were and so could plan accordingly from this point on.

Unfortunately firing lots of servo commands into the servo Pololu controller caused me some problems. The controller would randomly misread the commands and/or crash. Disconnecting the power supply from the motors fixed the problem so I guess the rapid commands to the motors was causing noise on the power supply (which is currently shared between the electronics and the motors) which was causing something to malfunction. Looks like the servos will need their own power supply sooner than I was expecting... 

The errors were:

Lynxmotion produces a 'servo erector set' (details here) which are brackets for standard sized servos that allow you to put together limbs and other contraptions with relative ease. I can see that the main issue with wanting to build my hexapod from scratch is initially not going to be working out how to design the various pieces that I need but actually fabricating them. There's a nice set of custom machined aluminium brackets on show here. I wonder how hard it is to get that kind of thing made for you in the UK...  

Anyway, I'm a fair way off from needing such things. The next thing on my list of things to do is to build the custom servo controller electronics and firmware. What became immediately apparent from using my quick and dirty servo controller program is that the sequences of servo moves that need to be made to move a limb from one position to another need to be blended so that all of the servos that are taking part can be moved at their own speed. My controller can easily send the three servos a set of position changing commands to move the foot from point A in space to point B in space but the end position, whilst important, isn't all that there is to it. If each of the servos has to move a different distance and you just tell them all where you'd like them to end up then they'll all complete their movement at different times. This works, but is rather, well, robotic to watch. I immediately decided that the controller should allow me to input the 'key frames' on a movement sequence and then be able to work out the intermediate points to move the servos along the way. Rather than using a single command to move each server from A to B I need a sequence of timed commands that move from A to B via a1, a2, etc. where the sequence for servo 2 takes into consideration the number of 'time slots' that it will take servo 1 and servo 3 to compete their moves. Taking this one step further and scaling to multiple legs the blending could be continued between legs to convert a synchronised, robotic, tripod gait into a much more natural 'ripple'. If the servo controller were to be doing this blending in real time then it could add an element of randomness into it which would probably result in an even more realistic movement (or something horrible). Interestingly this seems to be similar to the approach taken by the guys at Lynxmotion with their SEQ-01 servo sequencer product; so at least I seem to be thinking along the right lines.

Then there's the whole question of where to move the foot to and how knowing that position in 3d space we can calculate the required positions of each of the servos that make up the leg. That's where inverse kinematics comes in; see here for the details and the maths.

I had originally planned to build the leg out of wood, perhaps thin plywood, but I didn't have any laying around so instead I used some plastic window board which is relatively light and strong. This was easy to machine (cut with either a hacksaw or a hobby knife) and easy to drill with a drill bit in a hand driver. The results are indeed just as quick and dirty as I was expecting. 

As you can see I cut a slot in the lower leg to mount the knee servo, I also shaped the lower leg so that the foot was small. The knee servo's "horn" is then screwed on to the thigh (which I didn't bother to shape at all) and once that's done the servo horn and thigh can be connected to the knee servo. The other end of the thigh has another servo horn fitted, this time on the other side (this is less than ideal from a mechanical point of view but allows for more mistakes whilst controlling the servos as the lower leg can't impact on the hip servo). The top of the thigh is then attached to one of the hip servos. The two servos that form the hip are currently screwed on to a small piece of plastic board, it's not very clever but it just about holds the two motors in the right place (with the addition of an elastic band or two) to allow for the correct three degrees of movement that I wanted. The two hip servos are set at right angles to each other to give rotation in two planes. The result isn't especially sturdy and probably couldn't take a great deal of weight but is enough for now. It is, after all, just a quick and dirty prototype...

After connecting the servos to the servo controller I threw together a matching quick and dirty C++ application to allow me to send servo control messages to the controller. This allows me to experiment with the movement available by setting each of the servos to particular positions. The controller also allows me to record a series of positions and then replay them to the controller. This results in very simple movement as can be seen from the video below...

Also in the package were my XBee modems and several AVR microprocessors to play with; more on those items later...

Many modern microcontrollers have built in PWM generation capabilities but the number of channels is limited. For example the Atmel AVR ATtiny2313 has 4 PWM channels available. For a hexapod robot with 'standard design' legs each utilising 3 servo motors we need 18 channels. If we want to add a movable head (for sensor targeting, or mandibles) then we could add another 3 servos at least, the list goes on. However, we don't have to use the built in PWM facilities of the microcontroller, we could generate our own PWM signals and use any available I/O pin to output the signal; this means we can generate as many channels as the microprocessor has suitable I/O pins... This method is demonstrated here on a, now obsolete, Atmel AT90S4414. An alternative is to multiplex the available PWM channels to create the required amount of channels, we can do this because hobby servos generally require at most a 2.1ms pulse length with a 50Hz (20ms) refresh. Depending on the clock speed of your microcontroller the PWM signals you can generate are probably much faster than are required for a single servo, so by adding a 74xx138 to the output of each PWM channel from the micro and explicitly switching their channels and the pulse we're generating during the micro's PWM cycle we can create a number of PWM channels running at around 50Hz from a single PWM pin on our micro that runs at a faster refresh... Or so the theory goes.

The current plan for servo control is to multiplex an ATtiny2313's 4 PWM channels using multiplexers into a number of channels. Each micro should be controllable via a TTL serial interface from another controller (or a PC) and, since, potentially we'd need multiple ATtiny's, the serial link should be transparently chainable (that is each micro should only act on requests directed to it and should ignore all others...).  

And then we add another micro that talks to these servo controllers and deals with walking and the required gait to move the legs...

Of course, to get things going, I'm quite happy to use someone else's servo controller to get things moving, so to speak...

Other places of interest and sources of ideas include...

More details can be found here: http://forums.trossenrobotics.com/showthread.php?t=2762 and here: http://blog.trossenrobotics.com/index.php/2009/03/17/a-pod-a-robot-ants-tale/

By day I design and build high performance TCP and UDP servers for the Windows platform, my C++ technical blog is here: www.lenholgate.com. Up until a few weeks ago I'd never done any electronics or embedded programming; I decided that I needed a new hobby and so started tinkering with electronics, breadboarding and the like and, in what tends to be my typical approach to such things, I decided that the best way to push myself into this new hobby was to dive in to reasonably complex project. I started to put together a list of things that I wanted to include in the project and the list looked something like this:

• the end result should be an autonomous mobile robot that isn't tethered to a PC and isn't controlled by an operator.
• all electronics and control gear should be hand made from components rather than bought in (though I'm happy to use bought in things to prototype with as this will speed up the learning process, I hope...).
• all mechanical components should be hand made from components rather than bought in.
• communications between the robot and a PC and between the robot and other robots. 
• some form of 'vision', most likely simple sonar or range finding.
• microprocessor controlled; programmed in C or assembler, I'm a C++ guy at heart and, for  as long as I care to remember the platforms that I've targeted have been powerful and complex. I quite fancy learning about how to work on more limited platforms and perhaps even learning a decent amount of assembly language...

Initially the robot was to be wheeled but then I started seeing walking hexapod robots on the web and, well, they're just way cooler than something with wheels and, quite possibly, way more complex both mechanically and from a programming perspective. I realise that the project is likely to take some time and that I have a lot to learn, but that's the point. Like most projects I expect to break things down into manageable chunks and given the scope of the overall project the chunks should be quite varied. Ideally I'd like to run off and play with the communications side of things when I get bored fighting with servo motors and the mechanical side of things, etc.

So here we are. I'm currently gathering components for the project. So far I have decided to use an Arduino as my simple prototyping platform along with some AVR micro controllers for the main robot control gear. Of course my choice of AVRs may change once I have played around with programming them but they seem like a reasonable choice at this point. I've got three servo motors on order (HS-422's) so that I can start work on a simple leg. I have a couple of XBee radio modules on the way as these look to take the pain out of the communications side of things but I may drop back to using simple RF transmitters and receivers if the XBee's are too heavy or power hungry. 

So, off to build a robot then...