Italian Language Version



Welcome aboard!

Let me introduce myself, my name's Davide (nick: MaNCiO) and I would like to rapidly show you what stuff is this site about.
First of all I apologize for my English writings skills, hope you will understand what I'll try to explain.
This site is an attempt to document, from the design to the implementation phase, the building of an autonomous hexapod robot.
I've seen several of these bots on the Net, someone of which simply awesome. So, few years ago I started thinking '...... what about building one myself??'.
If you have made some research in this direction, or you have made one for real, you certainly know that is definitely not an easy thing to do, particularly if you work and you haven't a lot of spare time! (This robot is not built by a bored student during his sabbatical year!! ;-))).
Building a robot of this kind is a challenging process, it involves inter-disciplinarity and, why not, a little bunch of money.
But, most important, it requires time...... for this reason don't expect to see in few weeks the videos of the robot actually walking, showing complex behaviors and so on.

Few Infos about MaNCiO:
(If you're not interested in this, pass directly to "Today" section)

Building robots has been one of my strongest dreams ever, may be it's just a Frankenstein syndrome, may be is an effort to destroy the remaining few spare time.... but that's it, I always desired that, and actually, I always did it. Ok, with an extreme calm (this robot is the third I built, ....if the first two can be actually called 'robots' !!) as far that the first was built in 1986: it was a 4DOF robotic arm controlled by the (god-bless) Commodore64.
Little DC motors stolen from destroyed_for_that_purpose (!!) cassette recorders and toys that through wormgears gave 'life' to the home-sewed plywood structure. Everything was controlled by the C-64, throughout relays connected to the 'don't remember the name' parallel port, using pokes and peeks.
I believe that very little has survived of that thing!!! Anyway, his movements weren't properly 'smooth' !!!.
The years passed and I loosed focus on this kind of things until I start my first job as an embedded system designer. Thanks to my job, I started to develop the knowledge of micro-controllers. The first that I had put my hands on was a COP8, from National Semiconductors: strictly assembly language programming but absolutely a nice machine. The first summer work-holidays was committed to the learning of the microchip PIC of the microchip PIC (ok ok... now, in the summer, I tend to relax and not programming micros anymore!!!!). I built a simple programmer, bought few parts (16C84) from RS Components and, thank to the impressive documentation you can find on the microchip site and the whole net, I became a quite good PIC programmer!! (now I have considerably changed my target but I don't dislike to keep writing software with so few instructions!!).
Anyway, at that moment I had on my hands a minimal home-brew development system and suddenly the idea lighted-up in my mind: LUCYPHER!!!!!!. Please don't get me wrong!!! I'm not that kind of guy, that was the name of my second robot. He was (actually he still IS) an adapted Toyota Land Cruiser (?!?!).
Ok, let me explain you....... one of my passions is (still!) digging thru scaffolds in toy stores (when I was a child this was my favorite sport!) and that summer, one day I found a little wire-guided jeep (no.. that was not the Mercedes-Benz 'drive-by-wire' system!!).
The big exclamation-like writings on the box stated clearly that that stuff has two motors, one for traction (fwd/stop/rev) and one for steering (a very weird steer_completely_left/off/steer_completely_right kind of thing).
Hey! that's exactly what I needed!!!.
Clearly, the cost was a primary costraint, and infact that toy was a bargain (the kind of thing that modern child never ever observe....).
So, I bought it and I returned home very happily with my brand new toy under my arm!!
The following week, needless to say it, I was submerged by solder-iron smokes and assembly programming of the PIC. Lucypher was born exactly this way, it wasn't fallen from paradise but it raised from a plastic Toyota !!!!!!!!.
Lucypher still works and precisely is an autonomous PhotoVore Robot. Its objective is to move toward the strongest light it sees..... at any cost!!!!
Well, I really can't tell you my emotion when, after I turned off the lights and opened the fridge door, I saw Lucypher pointing in that direction and crashing at full speed into the fridge!! (it hadn't, and it still don't have , proximity sensors!!).
Watching him proceed quickly and deadly toward the light was an adrenaline-rush! My father (the first witness to the miracle) stared at me probably thinking "what's gone wrong in my education?".

Today:

We are in year2k (actually.. is almost finished!) and my target gets bigger. Objective for this year:

Build that hexapod !!!


The fundamental thing to do is without doubts to decide the NAME of the bot (eh eh!):
After have passed asleepy nights on this task, Sonia (my wife and the robot's greatest supporter) picked a name. So, unanimously, from now on the robot will be called:



Now, I don't want to bother you much with the reasons that lead us to this name but, if you didn't before, go reading the play of the great William.


The project:

After have named (with a veeery big effort) the Thing, let's proceed with the description of the whole project.
As I said before, it's since quite long time that I'm stacking up docs on robots, with a particular interest in autonomous six-legged walkers.
It would have be surely more straightforward (and a lot cheaper!) to build a wheeled robot. Only two actuators for motion, differential steering, and the ability to employ a low pin-count (it always returns... the PIC) microcotroller as the 'brain'.
Anyway, as far as this is not my first experience, I choosed a more challenging and complex objective.


In first approximation, desired specs for the bot are as follows:
  • Six 2 D.O.F. legs (Swing+Lift).
  • Moving sensor head (ultrasonic ranger or Cam) with 2 D.O.F. (Pan+Tilt).
  • Ability to contain a deployable micro-robot rover (WOW!).
  • Perimetral IR sensors(4).
  • Force-feedback strain gauges on the six legs.
  • IR or RF communication with other robots or base stations (+ nice debug tool!).
  • 'Subsumption' software architecture (R. Brooks) for autonomous behaviors.
  • Synthetic Vision (low res, Artificial Retina or CMOS camera).
  • ............?????


Clearly, these are the 'most wanted' specs, basicly a few years of hard working starting from NOW!!!.
So, let's remember that I already have a job..... and decide where to start. The first phase of the development was the study of the mechanic: body, servo mounting and legs. I figured out a general idea of dimensions and sketched it on my little paper notebook (... still no valid alternatives to paper and ink !!!!!).
At that point I had to seriously start thinking about the 'brain' of Hamlet: well, 12 servos, a lot of sensors, other servos for the sensor head....... I certainly couldn't think to a 18pins PIC! I equally discarded the 'networked small uCs' alternative just after thinking at the bus's debugging session !!!!!!!!
Ok, let's face it, the requests for the microcontroller were the following:
  • Suitable computational power (based on the full-sensors and actuators worst case scenario).
  • Enough I/O pins (at least 30.......).
  • Cheap development tools for an home based dev site (no expensive emulators...).
  • C language programmable (quick development of SW in my little spare time and avoiding re-identifying forgotten codelines at every programming session!!!!!!!!!!!!).


Since start of Y2K, on magazines like Circuit Cellar, EDN, Embedded System Programming and Electronic Design, started to appear a fairly interesting new microcontroller, well suited to what I was going to do: the Rabbit2000, from Rabbit Semiconductor (a subsidiary of Z-World, well-known off the shelf embedded controllers manufacturer).


This guy is a Z180 derivative with more muscles and speed. The interesting thing is that in the development kit they sold you, along with the microcontroller, there's a C compiler with an integrated serial debugger. So, if you buy their "Rabbit Core Module Development Kit" you'll get: the Core Module itself (a tiny board containing the Rabbit2000, oscillator, Ram and Flash rom (128K and 256K)), a 'development board' which houses the module and owns a nice breadbording area and finally, the software which is Z-World's 'Dynamic C'.


This is an absolutely non-ANSI (who really cares???) compiler that connects thru the com port to the Core Module and downloads directly the executable on the board. Obviously along with the code it downloads a little monitor-debugger that enable you to single-step thru the program, put breakpoints and watch variables.
So far so good, but how much is that? opening any electronic magazine is enough to know this: 169$.
Since I knew from start that the whole project would be not very cheap (14 servos are not for free...), I decided to add this cost, given the benefits it gives me (C compiler and lot of horsepower). The order was placed and the stuff arrived pretty quickly (couple of weeks..), at the moment of the order, the kit wasn't still available.
Bad for me, anyway, the shipment fee was somewhat high and in Italy were added a lot of taxes!
In this moment, however, I got my hands on the kit and I'm going to use it to drive Hamlet.


Functional Block Diagram


Functional Diagram


Ok, with the above scheme in mind, I'm starting to explain Hamlet's control system.
I partitioned the system in functional blocks (in this case they match with physical blocks too) and what attracts your eye is for sure the presence of a 'servo controller'.... Why should I have to use another device to drive servos when I have a quite powerful microcontroller as the Rabbit2000 at my disposal??
The answer is at least triple:
  1. The Rabbit2000 doesn't excel in Timers management (tricky and not enough precise).
  2. If I would have used 12 to 15 lines to drive the servos I will remain low on I/O pins to drive the rest of the devices (one of the Rabbit's ports is devoted to the serial lines and the others have restrictions)
  3. I had a nice Basic Stamp II in my junk-box (I'm sorry but I don't consider it much more than a toy....)

As you probably guessed, the fundamental point is the third!!!
After unveiling the mystery of the 'Servo Controller' I will now describe its functionalities. Servos, broadly used in R/C planes and cars, accept on the control line a positive pulse (1 to 2 msec long).


The output shaft's angular position is proportional to the width of the pulse (roughly between -90° and +90°). The servomotor has a little position controller inside that (in the resistant torque limits) guarantee the shaft's position to be maintained.
Actually there are a few more rules about maximum and minimum frequency of the input pulse. When we send pulses too fast the servo won't hold its position and to loose the setpoint, other than starting to emit veeery strange noises! (maybe to warn us about its sufferings...). On the other hand, when pulses are too distant in time the servo will enter in a kind of 'sleep' mode and the regulation loop stops to function.
I would have preferred to drive all the servos in parallel but, as all of you knows, nothing is more far from multitasking than a Basic Stamp !!!! You just cannot access the timer and code in assembler so I have written a big loop that drives in turns all of the servos. The worst case loop length is about 28ms to drive 14 servos....
This servos update period seems acceptable (it's not very low but we'll see).
Ok, we take for granted that in this version Hamlet won't have Carl Lewis performances but it probably won't be neither a slug! Anyway the first task is to make Hamlet walk, for running we'll see.....
The Basic Stamp II is connected to the Rabbit2000 through a serial line and an handshake line. The working is as follows: the Basic Stamp activates the CTS (clear to send) line and executes a SERIN instruction with a small timeout. If the Rabbit recognize the edge (as it should), it will start to send out the packet with the servos positions. If the Rabbit doesn't send anything for all of the timeout period, the BSII will deactivate the CTS line and drive the servos with the last set of values and returns to the start of the loop where it gives another try to the Rabbit to transmit data.

The sensor's interface section comprises a multichannel ADC, the ultrasonic radar circuit, IR proximity sensors and probably some kind of frontal insect-like whiskers.
All of these are preliminary specs, the part of the project relative to the sensor will be detailed after Hamlet hopefully will take his first steps!

Mechanics:

In this section we'll enter a dark territory... joy and pain for every robot builder with a electronic background. The biggest problem I had was to find materials easy to machine with easily available tools (hand drill, alternative saw, various files....) One thing to keep in mind is: keep it light!.
I would give to Hamlet an all Titanium alloy body (!!) but up to now, all I have found and machined is a sheet of ultra-heavy Plexiglas !!!


This material is rather easy to machine but the weight is just exactly under the servo's collapse threshold.
Given this, the first test I've done on Hamlet was to check that the robot can reliably stand up without a bad crash!. Luckily the experiment turned out a success.... well... until I figured out that there were no batteries on the robot yet!!!
In this early phase this is not a so big problem but if I really want Hamlet to be autonomous I surely have to change the material from which is built. Most probably it will be aluminum sheet with large holes to make the structure even more light.
The problem of weight is one of the most important on legged robots; wheeled ones (or threaded) in fact don't have to use energy just for lift a part of it from the ground. Some solutions to this recommends the use of springs or rubber bands that keeps the robot standing without feeding energy to the motors. Another possible work-around is to rise the servo's voltage supply. Iv seen people feeding the servos with as much as 7.2V (nominal... when sucha NiCd pack is fully charged, the voltage is something like 8.3 Volts!). The most elegant solution anyway is to change the leg's geometry (rising mechanical complexity..). In Hamlet, the leg's design is the simplest (and energy-deficient) possible. The two servos are rigidly connected together and the leg is linked to only one of those.
Practically, the swing servo is mounted on the body of Hamlet, with the output shaft facing the ground. The other servo (responsible for lifting up-down the leg) is joined to the first servo's shaft and plastic accessory with double side foam tape. The output axe of the lift servo is connected finally to the leg. From my notebook you see a sketch of the whole leg mounting....Too bad that my QuickCam hasn't enough resolution :-(((


Throughout complex calculations (The Rule of Thumb!) I have cut in the Plexyglas sheet six perimetral holes to house the swing servos. Those holes has been cut by an alternative saw, a source of potential extreme danger!!

At this point i would like to #include the official disclaimer:

All the trademarks which shows up on this site belong to the legitimate owner. The Author (noneless than I) disclaim all responsibility on any damage or harm that may arise from following instructions (even in C language) that are present on this site and on documents linked to/from this site. To put it short: if while you are building something like Hamlet you manage to harm yourself or someone else, destroy your house or office, start suffering from insomnia, and including patological personality spittings, THOU WILL NOT CONSIDER ME RESPONSIBLE OF NOTHING! All RIGHT?


Uhm.... i was saying, after the completion of the holes for the servos, i drilled the plexyglas sheet to accept the servo's fixing screws and I mounted the swing servos on the body. At this point i used a double sided foam tape from 3M®, really strong, I don't think it will be very easy to divide without damages the two servos joind this way !!!!!!!
I lined up the best that i could the two servos and pressed to make them stick together. I did a rather good job about this. The alternative to this rough method is to build a small joint made of thin metal sheet, that would be able to join the two servos in amore deterministic way!.
Now the two servos, responsibles for the swing/lift movements of the leg are mounted on Hamlet's body. The positioning of the leg (a small aluminum bar with a rubber foot) in place has been done in the following way: I used, as an adapter one of thiose little plastic accessories that you find in servo's boxes, there are of many different shapes but i used the cross-shaped one with little holes on the arms (used to connect ailerons links...). I enlarged two of the holes in the opposite arms of the cross, i drilled two holes with the same distance on the legs and i fixed all togehter with screws and nuts. The final mounting of the leg is what appears in the following picture:


Ok, now the above device has been mounted on the two servo's assembly and, after an afternoon passed sewing, filing, drilling and cirsing, here what you and i were waiting for:

HAMLET!!!!


Finally hamlet exists, how can i say it... it's essentially dumb matter yet, but just seeing it standing with his slender legs makes me whisper... (i don't know how long this feeling could last!!!).
Ehm... well, stop the romanticism and go back to cold, sound technicism. The following pictures (i apologize for the low low quality but i havo only this cam!) are about Hamlet and his legs. Hope they look interesting.



See ya...................more to come........................
Last Update: 12/01/2001


This page have been visited times.



Copyright © Nov. 2000 by Davide Mancini
Site built with AceHTML 4 freeware