Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Robot Builder's Cookbook: Build and Design Your Own Robots

Robot Builder's Cookbook: Build and Design Your Own Robots

by Owen Bishop

See All Formats & Editions

Owen Bishop introduces, through hands-on project work, the mechanics, electronics and programming involved in practical robot design-and-build. The use of the PIC microcontroller throughout provides a painless introduction to programming whilst harnessing the power of a highly popular microcontroller used by students and design engineers worldwide.

This is a


Owen Bishop introduces, through hands-on project work, the mechanics, electronics and programming involved in practical robot design-and-build. The use of the PIC microcontroller throughout provides a painless introduction to programming whilst harnessing the power of a highly popular microcontroller used by students and design engineers worldwide.

This is a book for first-time robot builders, advanced builders wanting to know more about programming robots and students in Further and Higher Education tackling microcontroller-based practical work. They will all find this book a unique and exciting source of projects, ideas and techniques, to be combined into a wide range of fascinating robots.

· Full step-by-step instructions for 5 complete self-build robots
· Introduces key techniques in electronics, programming and construction - for robust robots that work first time
· Illustrations, close-up photographs and a lively, readable text make this a fun and informative guide for novice and experienced robot builders

Product Details

Elsevier Science
Publication date:
Sold by:
Barnes & Noble
Sales rank:
File size:
20 MB
This product may take a few minutes to download.

Related Subjects

Read an Excerpt

The Robot Builder's Cookbook

By Owen Bishop


Copyright © 2007 Owen Bishop
All right reserved.

ISBN: 978-0-08-055401-3

Chapter One

The Robot Builder's Cookbook

What shall it do?

This is the question we have to answer before we begin to program it as described in Part 5. What it can do depends on the type of robot it is. Mobile robots are discussed first. For gantries, turn to p. 16. From p. 17 onward we discuss the activities common to all kinds of robot.

Activities of mobile robots

Moving around

By definition, all mobile robots move from place to place. They need to be able to move forward, to reverse, and to turn to the left or right. Robots are often operated in confined spaces so it useful to be able to spin on one spot. Variable speed is less important and often unnecessary.

The Quester (Project 4, p. 258) runs on three wheels. Two of these, to the left and right, are the drive wheels. Each has its own electric motor. The third wheel is a castor, used for balance.

The panel on the right tells you where to look for details.

The Scooter (p. 165) also has three wheels, but uses only one motor. Its steering is somewhat erratic but very easy and cheap to build!

Detecting and responding to light

Sight is probably the most important of all human senses. The same applies to mobile robots. Some can detect a lamp which is several metres distant, and aim themselves towards it. Or maybe they will go in the opposite direction, to end up in the safety of a dark corner.

The important feature of light is that it is detectable at a distance. This makes it ideal for long-range sensing.

One of the problems with using light sensors is that they may be confused by room lighting or sunlight. Pulsed light sources are one way out of this problem.

The panel on the right lists where to look for descriptions of a range of light sensors. These references explain how to build the sensors and how to program the robot to make use of them.


Another use for light is for proximity sensing. Proximity sensors tell the robot when it is near to, but not actually touching an object. The word 'object' includes immovable objects such as walls and furniture. In proximity sensing, the source of light is not separate from the robot, but is mounted on it, often aimed in the forward direction.

A light sensor detects a nearby object by detecting the light reflected back from it. If the intensity of the reflected light exceeds a certain level, the robot knows that something is there. A light detector aimed sideways can be used to keep a robot at a fixed distance from a wall.

Wall-following is a common type of behaviour; it is often used by maze-solving robots.

Ultra-sound is an alternative to light in proximity detection. This requires a more complicated circuit but is not subject to interference from extraneous light sources.

Ultra-sonic sensors can be programmed to measure distances, which makes it possible for the robot to map its surroundings and more easily find its way about. However, although such applications are very interesting to attempt, they are not infallible!


By this we mean physical contact between the robot and an obstacle such as a fairly massive object or a wall.

Typically, the robot has bumpers or possibly wiry 'antennae' arranged so that they are touched when the robot runs into anything. The usual response is to reverse a short distance, turn slightly to left or right, then move forward to try again. If the robot has a pair of bumpers, at front left and right, it is possible for the robot to work out which is the best direction to turn.

Side-mounted bumpers can be used for wall-following, instead of a proximity detector.

Other uses for contact detection occur when a robot is designed to sweep an area clear of light objects, or to find and pick up objects.

The fact that a robot is in contact with a sizeable object can often be inferred by monitoring its motion. If the drive motors are swtched on, but the drive wheels are not turning, it is likely that the robot is pushing against an immovable obstacle. A tachometer is used to determine if the wheels are turning or not.

Line following is a special form of contact behaviour. The robot stays in contact with a line painted on the surface over which it is moving. Line following requires two simple light sensors and the programming is easy. It is one of the most reliable techniques for guiding a robot from one place to another.


Most robots need to interact with humans, and those programmed to play games interact more than most. The robot sends messages to the human by flashing LEDs or bleeping.

Communication in the opposite direction is usually a matter of pressing a button or closing a switch.

Another technique uses a sensor that is triggered by sound.

Radio is a way of communicating with another robot to exchange information and coordinate their activities.


Given that a robot is mobile, it seems reasonable for it to know where it is. In practice, this is not as simple as it sounds. There are basic methods of navigation, such as line following, wall following, and homing on a light source. These need the fewest sensors and are the simplest to program. They are are fine for most purposes.

Some operations require the robot to move around in 'free space', without reference to lines, walls or beacons. It might be thought that switching on the drive motors for precisely controlled periods would give good positional information. This does not work in practice. For one thing, the two drive motors do not run at exactly the same speed, even if they are of the same type. With both motors running forward, the robot moves forward but veers slightly to the left or right. When turning, it is not possible to control the turning angle precisely. Errors of this kind are cumulative and it is not long before the robot completely loses its bearings.

We can counteract the differences between motors in several ways. One way is to use a tachometer to count the revolutions and part-revolutions of each drive wheel. Another way is to use stepper motors instead of ordinary DC motors. However, even these may not entirely solve the problem. Depending on the nature of the surface and of the tyres, there is inevitably a small amount of slipping. This occurs most when starting, stopping or turning, and is cumulative. There is little to be done about this.

The best solution is for the robot repeatedly to take its bearings. The advantage is that errors are not cumulative. This disadvantages are that three light beacons are needed, which make setting up dfficult. Also, the maths is complicated.

One novel solution is to use a magnetic compass. Inexpensive compasses with electronic output are available from some robotics suppliers. Unfortunately, their precision is low but they are fun to experiment with.

The most practical solution is a gantry, described in the next section.

Activities of gantry robots

A gantry robot operates over a clearly defined rectangular area. It picks up objects from any point in the area and sets them down at another point in the area.

The tool (often a gripper) is suspended from a small trolley-like frame, and can be lowered and raised. The frame has wheels and runs on a pair of rails so that it can travel from one side of the area to the opposite side. This set of rails is on a larger frame at right angles to the first set, so the smaller can be moved to any point within the area. Thus the location of the tool is defined by two coordinates, its x-position and its y-position.

It is easy to design sensors that can read the x and y coordinates and a gantry robot is therefore much easier to program for applications that require precise navigation.

Gantry robots are used in industry when very heavy loads are to be handled. The hobby versions are suited for less strenuous tasks. They are excellent for playing board games such as chess, draughts and checkers.

Like mobile robots, gantries can be programmed to solve mazes. But mobile robots are apt to lose their bearings. Because the travelling frames can be precisely positioned by keeping track of their x and y coordinates, a gantry robot can never lose its bearings.

When solving a maze, the Gantry does not run along passageways as a mobile robot does. It operates from above the maze, which is figured on paper or card. A narrow laser beam is projected down from the frame to mark its location.


As an example of feedback, take an ordinary domestic refrigerator. When the temperature inside it rises above a given level the refrigerator pump is turned on automatically. It stays on until the temperature has fallen to a given level. In this way the temperature inside the refrigerator is held within close limits.

This type of feedback is called negative feedback because an increase in temperature results in the interior being cooled down. A robotic example is the op amp motor speed regulator circuit on p. 93. The speed regulator circuit depends on the electronic hardware to provide and respond to the feedback.

Feedback can also be effected by software. Imagine a mobile robot running along with a wall on its left. It has an infrared LED directed sideways at the wall and an IR sensor that receives the reflected radiation. The programmed behaviour is designed so as to keep the amount of reflected IR constant. In this way it keeps the robot at a constant distance from the wall.

When the robot veers toward the wall, the amount of reflected IR increases. The sensor detects this increase. The program responds to this increase by steering the robot to the right, making it veer away from the wall. The reverse happens as the robot veers away to the right.

The usual function of negative feedback is to hold things constant. It produces stability. There is also positive feedback. In the case of the wall-following robot described above, suppose that by mistake the output lines to the motors were swapped. Then the slightest deviation from the correct robot–wall distance would cause dramatic results. The robot would either veer permanently away from the wall or crash into it. Positive feedback results in instability, which is something to be avoided in robot behaviour.

There is another type of feedback that is virtually essential in a robot system. For example, a bulldozer-like mobile robot has a pusher in front of it for playing 'football'. This is normally lifted high above ground but is lowered almost to ground level when the robot sees a ball ahead of it. It must be near to but not actually touching the ground, for it might catch on irregularities in the surface.

To solve this problem, the pusher is raised or lowered by a motor which winds or unwinds a length of cord wrapped around its spindle. The switches are microswitches, the kind of switch most suitable for this kind of mechanism. If the motor is made to wind in the cord (turning clockwise in the diagram), the pusher is raised until its supporting lever touches against the lever of switch 1. This closes the switch and a signal is sent to the controller telling it to turn off the motor. If we did not have this system in place, the motor might continue turning until the pusher was damaged or the cord snapped.

The mechanism has a second switch which detects when the pusher has been lowered to a position just a little way above ground level. Switches used in this way, to detect when part of a mechanism has got as far as it can be allowed to go, are called limit switches.

In a similar way, path-following is a matter of moving the robot forward while checking the path sensors at very frequent intervals. Even on a straight path there may be irregularities that divert the robot from its intended course. If it has strayed, negative feedback is applied until it is on track again.

Monitoring output

Feedback from limit switches exemplifies one of the key principles of programming a robot :

Tell it what to do, then quickly check that it has done it.

In the pusher example, tell the robot to raise the pusher, then program a loop to check switch 1 repeatedly until it is raised. When the pusher is raised far enough, switch 1 closes. The input to the controller changes and it then stops the motor.

Random activity

Randomness may sound an unlikely topic for a robotics book but it has its applications. A robot that is reliably built and programmed performs its tasks in an orderly and inflexible manner.

Humans are not normally like this. Indeed, if people are too rigid in their behaviour we may complain that they are 'acting like a robot' or that the person is 'an automaton'.

If a robot is programmed to run for a short, randomly-chosen distance, then turn through a random angle, and continue indefinitely in the same routine its path is totally random. We say that it is literally performing a Monte Carlo Walk. We say 'literally' because the same term can be applied to other random sequences that are not actually walks.

Usually we do not aim for total randomness. For example, a robot detects an obstacle in its path, backs up, turns slightly to avoid the obstacle and then continues forward. The stopping, backing and turning are fixed responses. Whether it turns left or right on a given occasion is determined as random. We can not predict which way it will turn next. This intoduces randomness into its behaviour, but not too much.


Excerpted from The Robot Builder's Cookbook by Owen Bishop Copyright © 2007 by Owen Bishop. Excerpted by permission of Newnes. All rights reserved. No pat of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Meet the Author

Author of over 70 books, mostly electronic and many in the field of science education. Contributor to numerous electronic magazines such as Everyday Practical Electronics, Elektor Electronics, Electronics Australia and Electronics Today International. Former Science Education Advisor in developing countries as staff member of the British Council and as a part of the UN Educational and Scientific Organisation.

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews