The award winning Shadow Biped has been in development for over ten years and is our longest running project. It has become a real icon for us and others in the robotic community. Without its development a lot of Shadow technologies would not have got off the ground or even been invented.

Click on Biped for enlarged image

Tether - Used to hold the robot in place during balance tests.

Interface Card - Connects computer's expansion bus to Robot's card.

Sensor Interface - Multiplexes Sensors to A/D converter card.

A / D Converter card - Samples Sensors producing a Digital Output.

Output Interface - Drives 12 Volt solenoid Valves.

Pressure Sensor Gauges Modified Bourdon Tubes producing electrical output.

The Shadow Robot uses a wooden skeletal frame on which the muscles and equipment are mounted. In the early stages of development using wood proved to be cost effective and very strong. Maple proved to be the ideal choice because of its fine consistency, which is easily machined.

Control Valves - Regulates the air flow to the muscles.

Actuators - Using Shadow™ Air Muscle technology.

Joint Sensor - measures position of the joint

Contents to this page Why Legs The Prototype Biped The Skeleton The Actuators The Sensors Balancing Computer Interface Software Criteria Software Implementation Standing on two feet Staggering forwards Anthropomorphism, or Why Legs? The need for anthropomorphism in domestic robotics is classically illustrated by the problem of staircases. It is not feasible to alter houses or to remove the staircases. It is possible to design robots with stair-climbing attachments, but these are usually weak spots in the design. Providing a robot with the same locomotive structures as a human will ensure that it can certainly operate in any environment a human can operate in. The development of the robot is facilitated by the extensive research into the anatomy and physiology of the human; it is hoped that eventually the work done by the Shadow Project can have some impact on further research and development in these and related fields, such as prosthetic design. Prototype Biped The most visible (and appealing) piece of "work in progress" at the Shadow Project is the prototype bipedal robot, the Shadow Walker. The Walker is a wooden leg-skeleton, powered by Shadow air muscles. It stands 160 cm tall, its 'upper body' currently consisting of the control valves, the various control electronics and computer interfaces. Its purpose is to permit us to research and develop the necessary designs and techniques of humanoid balancing and walking. The walker is a research prototype, and as such has undergone considerable refinement as control problems are discovered. Skeleton The skeleton of the Walker was designed by David Buckley. It is wooden, and follows the shape of the human skeleton closely (note above), save only in these respects: the lower leg is one piece, rather than the two-bone structure of the human. the knee has a simple joint and as such possesses no kneecap. The foot has only one toe, which is the width of the foot. The hip is a ball-joint, permitting three degrees of freedom; the ankle is a double-axis design, permitting two. Our observations suggest that a different structure might be easier to work with for certain control aspects; but this is the one we have. We do not envisage that any great modifications will need to be made to this design in the course of development, except possibly that it may be necessary to provide more than one toe for balancing. Actuators In order to make the Walker as close as possible in its design to the design of the human, it is necessary to find some substitute for the human musculature. The device we use is the Shadow air-muscle, designed and developed by Richard Greenhill. The air-muscle operates on compressed air at low pressures, whilst providing both power-to-weight ratios and strengths within the range of the human muscles. Its design makes it intrinsically safe. The air-muscle is inherently compliant, but has significant nonlinearities in its behaviour. The air-muscle is described in Eureka, April 1993, and Industrial Technology, April 2000 Despite these dates, it does exist. Twenty-eight air muscles (14 on each leg) act across the eight joints, enabling a total of twelve degrees of freedom. The muscle arrangement closely mimics that of the human muscles, in that the placement of an air-muscle will usually match a corresponding muscle in the human; however, there are significantly fewer muscles on the robot than on the human. Considerations of the problems of replacing muscles, and of mounting attachment points capable of withstanding the strains exerted, has led to the locations of the anchor-points of the muscles on the skeleton not being identical to those of the human muscles. Muscle Control Each air muscle has two control valves, one to fill it from the regulated supply of clean air, and the other to exhaust it. A sensor on the muscle measures the amount of strain in it and a sensor on the air line measures the air pressure in the muscle. As a result of the low-cost criterion, the valve set has been through several significant design iterations. The initial design utilised low-cost surplus AC solenoid valves. These however necessitated high-voltage AC supplies, and extra switching circuitry to isolate 110V AC from the i/o systems. Triacs used in these circuits also had the disadvantage of only switching off during a zero-crossing of the supply, thus restricting control of the valves. Although these valves can be powered from lower voltages if a DC supply is used (50V), this still requires more expensive switching circuitry. Also, we discovered that the valves were optimised for switching high-pressure air, and hence had a low throughput at the low pressures we use. The valves we now use are 12V DC water valves, which switch sufficiently quickly, are relatively noise free (compared to 110V AC) and have a high throughput. These valves are low-cost, and so are not proportional; however, the high-speed control of the switching permits sufficiently fine control of the valves to render this less of a problem than might be expected. Although this is a regular point of some debate within the project team. Sensors There are four types of sensor used on the Shadow Walker. These are; Pressure Each muscle has a pressure gauge attached to its air-line. These sensors were designed by David Trickett, as a modification of the standard Bourden gauge to produce an electrical output, as well as the usual visual indication. Strain Each air-muscle is attached with two pieces of Kevlar ® rope. At one end is a strain gauge. This gives a simple monotonic increasing output with increasing strain on the muscle. Under-Foot Pressure Under each foot are five force sensors, two at the toe, one in the centre, and two across the heel. These provide a fairly good indication of both contact with the ground, and the distribution of the centre of mass of the robot. The sensors were originally opto-reflectors, of the Shadow Project's design; however, recently we have discovered the Interlink force-sensing resistor: this is much easier to use to get an indication of load on something like a heel, although has disadvantages as a high-quality load indicator. Using these has made the sensing of the weight distribution much better. Joint Position Each of the twelve degrees of freedom requires a sensor to measure it. Initial designs used rotary potentiometers however, potentiometers suffer from several problems: when in motion, their wipers make poor contact and pop, thus producing poor-quality readings, and reducing intrinsic safety. The mechanical contact introduces a possible mechanical failure. the requirement to mount on an axis of rotation which is sometimes unfeasible. As a result, all joint positions are now measured optically. The hip provides a good overview of the problems involved with the sensors. The upper leg is clamped round a ball that is attached to the torso of the Walker, which provides the necessary three degrees of freedom. To measure this, however, using on-axis potentiometers is impossible without a wholly different construction. Measuring with off-axis potentiometers requires difficult linkages; our experiments foundered either on excessive play in the linkage, or on the existence of some motion which was not transmitted along the link. A traditional technique used for measuring co-ordinates in a difficult -dimensional space is to measure simpler parameters of the system, such that the parameters produce a spanning set for the space. However, in the case of the hip, we would need to mount these sensors in a limited space, and then to resolve their outputs, which would most likely introduce further inaccuracies. Our current solution is to use opto-reflectors to measure two of the degrees of freedom; one by reflecting infrared from the inside leg from a reflective surface on the groin [Conceptually. Think of it as a bel, rather than a specification...] region of the robot, which measures distance from the leg to the groin, and the other by reflecting visible light from a graded scale at a constant distance above the ball, thus indicating position of leg with respect to the scale. The detection of rotation about the length of the leg is not at present finalised; we are performing experiments with magneto-resistive sensors which measure the angle between the sensor and a magnetic field, which would be a permanent magnet mounted within the ball. Balance The human balancing process is greatly aided by the inner ear, which acts as a sensitive 3-axis accelerometer and inclinometer. One of our ongoing projects is the provision of similar sensing capability for the Walker. We currently have an array of mercury tilt switches, which provide crude indications of tilt, and we have mounted commercial accelerometer parts to the Walker, then stolen them for... other experiments... Other measurements necessary for balance are performed by the the under-foot sensors. The other aspects of balance are detailed under standing up. Interface When the electronics were originally designed, in 1987, an 8-bit high-speed ADC was a pricey part. And we needed 80 of them. Not to mention the 56 valves we had to drive. A quick look around led David Buckley to our long-standing design for the biped. Interface card This card maps the robot into the I/O space of a BBC Micro. (Or Acorn Archimedes). The interface is in fact to the 1MHz I/O bus design for these machines. It interconnects most of the daughter cards. A-D converter card This addressed card provides a high-speed 8-bit analogue-to-digital converter, running at approximately 500kHz. It provides select signals for up to 4 daughter sensor interface cards. Sensor interface cards Two of these unaddressed cards are currently used. Each supports 64 sensors, which have a 0-5V range. These are multiplexed under the control of the AD card. Output cards Two of these multiply-addressed cards are used. Each provides 48 pull-down output lines, capable of sinking 500mA each from a load running from up to 50V DC. The outputs are latched. The design has evolved somewhat over time, as improvements in software necessitate electronics improvements. Currently, the system is scheduled for replacement with a whole new electronic system. Control Software The optimistic early work on the control of the Shadow Walker was filled with notions of letting neural networks solve the problems. However, there were and are certain significant obstacles to this technique. The early unreliability of the sensors precluded any use of their outputs directly without significant conditioning of the values. This conditioning proved difficult to determine, due to sensor stability problems. The valves were initially too slow to perform rapid manipulations of the robot. Speed improvements in the control revealed interesting unpredictabilities in the valve behaviour down around the milli-second level. The control of the valves was also poor. This was mostly a software issue, though we've had some fun with current flows down small cables. And, finally, the robot itself was exceedingly fragile, with a mean-time-before-failure of as much as a couple of minutes at times. Incremental improvements in this area have helped a lot, but it still isn't going to be allowed to fall flat on it's front any time soon. Didn't the neural nets solve the problem? Well, to understand the problems here, you have to know a little about the usefulenss of the neural network. A neural net is very good at associating a set of inputs with a set of outputs; a small change in input will tend to produce only a small change in output, and they can be made to have the right outputs for certain classes of inputs. How is this done? Neural networks are trained in one of three ways: Supervised learning This requires that many examples of pairs of inputs and ooutputs can be presented to the network, and the network generalises these to cover the rest of the possible cases. In our case, this would require us to be able to predict the very data that we hoped the network could produce for us, namely the correct responses of the biped to a diverse selection of conditions. Unsupervised learning The network is given a signal ("pain" or "pleasure", depending on the sign) indicating how well it performed on the most recent attempt, and is modified accordingly. The initial actions of the network are essentially random, and only after many, many iterations of the training process will it begin to exhibit good behaviour. When dealing with the problems of standing, for a fragile robot, random behaviour almost always means falling over and damaging the robot. Except, of course, when it means kicking things, or shaking the robot to pieces, or ... Self-organisation Is more useful for pattern recognition tasks, and again requires the presentation of correct data to the network. Software Design The development of the software thus became test-directed; it was necessary to build programs to facilitate the testing of parts of the robot, and the routines written to do this developed in complexity. Programs operating on the robot now have a standard library of routines to draw on, which they augment with further functionality. Robot Standard Library The current standard library of routines for the low-level control of the robot provides these facilities: valve switching to 1 millisecond resolution, asynchronously of the main processes executing, with automatic interlock to prevent simultaneous filling and emptying of the same muscle. reading the sensors. maintaining data of minimum and maximum sensor values over time, and reporting excursions from these bounds. scaling the readings of the sensors to the range 0..255, so higher-levels of software can assume the signals are conditioned. providing standard names for all the sensors and muscles, so software can refer to `left hip 2' rather than `sensor 50'. Providing logging facilities, to record all the sensor values over a time-period, permitting examination later for analysis. It has been stated that some or all of these facilities could be provided in the hardware of the robot directly; however, this would possess several disadvantages: the very large number of sensors (80) and valves (56) would require significant investment in time and complexity to construct further control hardware. The design would become fixed in a manner that, at present, it is not. The hardware would require significant space on the robot, which is not available. The hardware would be expensive, compared to the software costs. Yes, Virginia, software is cheaper than hardware! Control Programs On top of the standard library, a variety of further programs have been developed. Some permit detailed examination of the state of the robot, others provide a `front panel', and still others are part of the actual control of balancing. In 1997 we were able to stand the robot up straight, and have it remain in this position, under its own control, for periods of fifteen or more minutes. Apart from the valve noise, the main indication that the robot is not statically balancing is that it sways up to 10 degrees from the vertical. However, it is not yet capable of recovering from more extreme deviations, nor rapid changes in its orientation. Standing Up The control system that finally enabled the robot to exhibit this fundamental behaviour was a simple fuzzy rule-based controller. Each sensor's input range is divided into a number of bands, or `qualifiers': for a specific sensor value, a mapping gives the proportional activation of the corresponding band. The rules are then specified in terms of these qualifiers. High-Level Control The higher-level control has altered with experience with the system. As mentioned earlier, we spent some time looking at the p[ossiblity of using neural nets, but eventually decided they were not suitable. Instead, we currently use a simple fuzzy-logic system. Sensor values are classified according to their closeness to certain qualifiers, for example, the left hip (`LHip') has qualifiers fore, mid and aft,and then rules take qualifier values and use them to produce actuator commands. A typical code sequence is: LHip Fore : Left 6 LongFill & Left 2 LongEmpty LHip Aft : Left 2 LongFill & Left 6 LongEmpty LHip Mid : Left 2 Off & Left 6 Off which simply acts to restore the hip to the centre position by filling and emptying the muscles (2 & 6) that act on it. Simple control of this sort now lets the Walker stand up straight, swaying gently around within the tolerance of the control. Any significant perturbation of the system (for example, pushing the Walker) will take the state outside the narrow controlled region. We are now augmenting the joint position rules with rules examining the underfoot sensors, to produce control in a larger region of the state space. The augmentation process is entirely manual, for reasons described above. However, we are investigating the possibility of using neural-network systems to broaden the effectiveness of the hand-generated rules. Staggering Forwards The most recent development comes from our new underfoot sensors. These have been improved the reliability of the information from the feet considerably. Using this better-quality output, we've started to put reflexes in to react to significant changes, so when the robot moves (or is moved) outside the envelope of simply standing, the system will take other actions to restore it to standing up. In this case, we were getting the heel sensors to trigger a pushing action with the toe, so if the robot was pushed forwards, the toe would push down and move the robot back. We tried this code, and pushed the robot forwards a few times. And it duly recovered from these small, but significant, perturbations, which it wouldn't have done using just the posture maintenance. Then, we tried pushing it sideways, instead. The entire foot lifted off the floor: the heel sensor reflex acted, but because the foot was off the ground, instead of pressing back, the foot was moved forwards. The change in mass distribution caused the robot to swing back over, and the foot hit the floor. But, because there was nothing to stabilise the side-to-side motion, the robot carried on swinging over, lifting the other foot from the floor. So, the heel reflex for that foot kicked in, and it swung forwards, and the robot swung back onto that side... Unfortunately, luck ran out at that point, and the third step didn't happen: the robot was caught by it's tether and stopped. However, it had taken two steps. Next: to get this to be repeatable. © Richard Walker and The Shadow Robot Company 1999,2000

Shadow Robot Company Ltd. 251 Liverpool Road London N1 1LX tel: +44 (0) 20 7700 2487

If you have any comments on this page, mail the webmaster or contact the Shadow Robot Project at: contact@shadow.org.uk If you have any comments about the site design please mail Rufus Wood. © Copyright Shadow Robot Company Ltd. VAT Registration number: 707 3091 52

Document created: 12^th June 1999
Last Modified: Monday, 12-Feb-2001 20:39:24 GMT