Some photos and descriptions of earlier robotic creations and related work
Return to the home page of Robots Australia
|Contact Robots Australia |
I experimented with a lot of different technologies and ideas before starting work on what I consider to be my first truly significant robot design, that of the Quadruped4 creature. This page summarises the journey and is presented more or less in order of when I tackled each topic.
The page is pretty long, so you can jump to the main headings with these links;
Home Built Pneumatics DC Gear Motors/Controller
Evolution of Quadruped Design Quadruped1 Quadruped2 Quadruped3 Quadruped4
PWM Servo Robotics Controller
My first attempt at robot construction was during high school, where I built a rough frame out of lightweight aluminium angle, mounted two drive motors and two casters on the base, and fitted the only computer available to me at the time - the old VZ-300 which was a Z-80 based home computer available in Australia in the 80's. I built at least two drive circuits for it, one relay based, the other H-bridge transistor based, and tried a few different techniques for motor driving the wheels. I don't remember being particularly successful, and it didn't do much more than shudder around. This photo was taken just before the dusty wreck was taken from shed storage and thrown out to make room...
Early university years led me to build the photo sensitive creation pictured to the left. This was a simple circuit with two great looking large photoresistors connected to 555 timers producing PWM for the two motors, basically if the right hand side was more illuminated, the left hand motor would be driven harder. There was also two whiskers made out of bent stiff wire which when hit would contact the edge of a hole they were fed through. The whiskers triggered an avoidance behaviour, though I'm not sure quite how I wired that in to the 555 timers. I had problems with the motor drive slipping on the wheels (the motor shafts were covered in rubber and simply held against the wheels by a rubber band!), but the robot did actually work and managed to track towards light areas.
In 1995 I completed a Electronics & Computer Systems undergraduate degree at Monash University in Melbourne, Australia, and my final year thesis under Professor Ray Jarvis was the construction and programming of a mobile robot equipped with a B&W CCD camera tethered to a PC with a framegrabber.
The project was quite ambitious, and my effort had to be spread pretty thinly over many different areas, but by the end of the year the robot was capable of autonomously (and painfully slowly) moving across a room filled with chairs to a goal position selected by the operator prior to the exercise. The robot contained a vision system capable of recognising chairs, placing them on an internal map using visual ranging techniques along with the robots own tracked movements using wheel encoder odometry, performing optimum path planning using obstable 'growing' (making the mapped obstable bigger by the robots own size to ensure the robot leaves enough clearance when moving past the object) and shortest distance contour following where the map cells are numbered outwards from the goal cell until the robot is reached, and the robot merely follows the steepest slope on its map down towards the goal cell.
The images to the left and right show the vision system detecting chair legs in the rather limited environment the robot was allowed to operate within. The bottom of chair legs were detected and visually ranged using the position in the field of view, then placed on the internal map.
The path planning and mapping process can be seen in this image which represents the results of an actual experiment with the robot. Chairs were configured as shown on the right, and the robot's self created map is on the left. The white line is the path the robot took to get to the goal, the dark grey area is the 'grown' obstacle clearance field, with lighter grey spots within representing actual determined chair leg positions within the map.
The techniques used in this robot are primitive forms of some now quite fashionable fields of research such as 'SLAM' (simultaneous location and mapping). I am happy that my ad-hoc methods devised at the time echo the broader development path that robotics has followed up to the present.
This completed project really represents the classical AI 'brute force' approach to robotics, and I am very glad I had the opportunity to work through it, because despite the success of the robot within its very limited field, it has helped me to focus on broader, less programmed, approaches to robot control where the ability of the robot to learn and develop its own techniques for achieving goals replaces packaged algorithms. The robots I envisage today would bear little resemblence in their control systems to this early project!
Early thoughts on how to implement a reasonable size quadruped robot with reasonable power acuators led to some investigation into do-it-yourself pneumatics. At the time I looked on with excitement at the work done with McKibben Muscles, and I bought an educational kit of tubing and plastic parts from MUTR in the UK, who have come up with a great low cost way of making quite effective low pressure pneumatic cylinders. To experiment with this technology, I built a test platform with one cylinder, two small storage vessels (PET drink bottles!), manual pressure gauge, two 5V driven solenoid valves, a custom controller with pressure sensor and a novel (if I do say so myself!) compressor built out of a dual-action bike pump driven from a crank and gearmotor. To apply this technology to a robot, I intended to use a single high power motor/gearbox to drive a compressor and a larger storage vessel (I envisaged several 1L or 2L PET bottles) and actuation of the robot via the MUTR cyclinders and low power solenoid valves. A legged robot driven from pneumatics will have inbuilt joint compliance, and might be able to offer a more biological style of movement than a set of direct motor driven joints.
The test platform functioned well enough, but I quickly realised that air power was not going to be an easy (or efficient!) way of providing the spark of life to any robot creations. The DC gear motor was very underpowered, and struggled with achieving a decent pressure in the storage tanks, which themselves would only hold enough for maybe three repeat cycles of the cylinder. Of course most air powered robots I have seen are usually supplied from either an external hose from a decent air supply, or use higher capacity storage cylinders and have a limited run time. The process of using a battery to store energy, a DC motor to drive an on-board compressor and then finally using that stored air to drive actuators would be so wasteful of energy as to be limited only to a novelty application I think. So ended my sojourn into air powered robots! I resolved to use DC motor drives as the best option for today's robots at least until more exciting higher power density actuators such as Electroactive Polymers become available!
The RobotWars competitions are a great forum for experimenters and constructors to distil readily available bits and pieces into effective robotic components. One really useful idea I found described on a robotwars web site is to use DC motors and gearboxes from commercially available battery operated drills and cordless screwdrivers. These typically have a very high torque gearbox, often an advanced high strength planetary design, and decent DC motors. What's more, they are available for a song compared to equivalent performance industrial motor/gearbox combinations.
I used Bunnings (an Australian hardware supplier) cheap XU1 brand 12V drills (at the time available for AU$16 ea), extracted the motor/gearbox, modified the clutch mechanism to defeat it and allow maximum torque to be transmitted, and designed and built a bevel gearbox mechanism to transmit the power at right angles to the drill motor. I did this because I wanted to achieve a readily repeatable building block that could be used as knee joint, ankle or hip actuators as well as any other purpose.
I intended to use a network of microprocessor controlled motor drive boards to drive the DC motors, and designed a PIC micro based board with four 10A capable H-bridge configuration motor drive ICs (manufactured for automotive window winder control I think). I intended these boards to be multidrop networked to control as many degrees of freedom as was required. I successfully tested one channel of the prototype, and wrote some quite tricky code to perform four channel PWM via interrupt driven 'bit-banging' techniques, before I discovered the wonderful world of Atmel AVR micros, and designed a successor using a micro equipped with hardware PWM outputs which made the software a lot easier. The new board is however completely untested at this point, and is not actively being developed further.
The Quadruped1 design was based on the bevel gearbox arrangement described above using low cost high torque 12V cordless drill motors and planetary gearboxes. I saw this drill motor/bevel gearbox combination as a standard repeatable block to use in leg construction, and created CAD models of a quadruped design using these drive motors.
The design challenges just
seemed too great however, and the resultant robot would have been very
heavy and power hungry. I did however design and build a DC motor driver board which had four high power motor H-bridge drivers and a little microprocessor.
I resolved to use servo motors from the RC hobby world to short cut the process and develop a working robot in less time, and this led to Quadruped2, which was to have used 13kg.cm torque servos from GWS Servos. Another CAD model was created, however around that time the servo manufacturers started producing higher performance servos specifically for robot use, and I settled on a Hitec servo HSR-5995TG which offered twice the torque and half the weight of the GWS servo (albeit at a much higher per unit cost).
The Hitec HSR-5995TG servo was used as the basis of the Quadruped3 design. This design would have been quite workable, and I proceded with it for quite some time, designing and constructing a robot controller with quite a feature list. I hit upon the idea of using laser cut acrylic or preferrably polycarbonate panels to construct the robot, allowing for smooth curved edges and hopefully a slightly less 'clunky' and more organic look. After getting the mechanical design to a particular point I was reasonably happy with - basic dimensions and parameters worked out, but lacking detailed component mounting design and general refinement, I started work on the robot controller electronics. By the time I actually got mechanical components built, I wanted to have electronics capable of moving joints ready to go so I didn't end up with a boring inanimate object sitting there waiting for the controller. I rejected using off-the-shelf controllers, as the extensive capabilities I had envisaged just don't really exist in low power small controllers, and although I could have used a standard controller with additional capabilities provided by additional boards, I thought this would lead to a less than optimum design in terms of size, features and power consumption. The communications for the robot to a fixed base station (with much larger computing power) were to use a newly developed UWB CableFree USB link which Belkin and a few other companies have pioneered. The main challenge as I see it is to get video from on-board cameras back to the base station. I wanted to avoid using dedicated RF links for standard PAL or NTSC video cameras as well as a bidirectional data link RF system, instead wanting a single link to handle control/sensory data and video streams. I hit upon the idea of using standard USB web cams with the Ultra Wideband (UWB) link between a CableFree USB hub and the controlling PC/laptop. This way the link would be pretty much transparent, and standard software methods could be used for video acquisition from the web cams. The main drawback of the approach would be the range (the Belkin CableFree USB hub only claims single room performance), and possibly difficult to debug software when the video capture drops out due to range issues. The controller was fully designed and constructed, and a lot of firmware written for it, when I made the big decision to cut across to using Robotis Dynamixel networked servos and decided to build an entirely new controller. I do talk further about the capabilities of the original controller in its own section below however.
The discovery of the myriad advantages to using Robotis Dynamixel Servos proved too tempting, and I had to reluctantly abandon the development of Quadruped3 and associated standard RC servo robotics controller in order to build a dedicated controller for the Dynamixel products. The mechanical advantages included flexible mounting with the supply of two useful molded brackets and an idler bearing with each servo as standard allowing simple joints to be constructed without any extra parts.
The electrical advantages are huge too, with networked TTL multidrop connection (or RS485 for the higher end models), on board sensing of current, voltage, temperature, position feedback, and clever compliance control models all built in. On top of all this, the AX-12 model is relatively cheap too! The drawback is the lower torque than the Hitec HSR-5995TG offers. Nevertheless, an entirely new controller offering Dynamixel network control rather than multi-channel standard RC servo PWM control was conceived, and a new mechanical and electronic design using the Dynamixel AX-12 servos was embarked upon. Quadruped4 is an active ongoing development, see the main Quadruped4 robot page for the current status.
The controlling electronics for Quadruped3 was a low power Atmel AtMega2560 based design, controlling a maximum of 15 servos with PWM control. In addition to a standard servo controller however (I could have used the excellent SSC-32), I wanted to sense the load and actual position of each servo. The controller electronics I designed could power on or off each servo, measure the current draw and the shaft position of each as well as the total current draw of the system, monitor LiPoly battery packcell potentials, had 3 axis acceleration sensing, 1 axis gyroscope, USB interface as well as other features. Because the Quadruped3 robot was intended to perform only the lowest level control with a radio link to a base station, I provided serial and USB communications on the controller. The radio link was to be using the then upcoming (now released) UWB CableFree USB hub from Belkin. The robot controller and two web-cams could then each be connected to a USB port on the CableFree hub, and a 'dongle' could be plugged into the base station laptop or desktop. Because the Belkin product had not been released when I designed the controller (and had suffered several delayed release dates!) I decided to hedge my bets and allowed for an on-board WiFi module as well. I selected the DigiConnect ME 802.11 module, though since then I have settled on the Lantronix WiPort due to its higher 921.6k communication speed. The swiss army knife controller was designed and constructed, and a lot of the firmware written for it too, before the killer blow was dealt to the Quadruped3 design when I discovered the Robotis Dynamixel servos and the advantages they would offer. Most of the electronics in the controller were dedicated to controlling standard RC PWM interface servos, and measuring the current draw (and hence torque loading) of each servo, measuring the actual shaft position etc, and the Robotis networked servos do all that for you with an internal microprocessor. Still, the PWM Servo Robotics Controller is pretty much functional, and it could still see use in a future design if conventional PWM controlled servos are used.