AN OVERVIEW OF
ROBOT "BRAINS"
ROBOT "BRAINS"
“Brain, brain, what is brain?” If you’re a Trekker, you know this is a line from one of the
original Star Trek episodes entitled “Spock’s Brain.” The quality of the story notwithstanding
(it is universally regarded as one of the worst, yet paradoxically one of the most
popular), the episode was about how Spock's brain was surgically removed by a race of
temporarily hyperintelligent women who needed it to run their underground environmental
control system. Dr. McCoy was able to create a control mechanism that would allow somebody
to operate Spock's brainless body in order for it to be present when the brain was
found. Without its brain, Spock's body was not much more than a remotely controlled
model car; capable of performing some operations under direct human control, but not able
to operate autonomously. The brains of a person or robot process information from the
environment; then based on the programming or logic they determine the proper course of
action. Without a brain of some type and the ability to respond to different environmental
information, a robot is really nothing more than just a motorized toy.
A computer of one type or another is the most common brain found in a robot. A robot
control computer is seldom like a PC on your desk, though robots can certainly be operated
by most any personal computer. And of course not all robot brains are computerized. A simple
assortment of electronic components—a few transistors, resistors, and capacitors—is all
that is really needed to make a rather intelligent robot. Endowing your robot with electronic
smarts is a huge topic, so additional material is provided in the following chapters to help
you understand how electronic sensors and actuators are interfaced to computers and how
decisions are made on which actions to take.
You can use the wiring from discrete components (transistors, resistors, etc.) to control
a robot. This book contains numerous examples of this type of brain, such as the
line-tracing robot circuits in Chapter 33, Navigation. The line-tracing functionality is
provided by just a few common integrated logic circuits and a small assortment of
transistors and resistors. Light falling on either or both of two photodetectors causes
motor relays to turn on or off. The light is reflected from a piece of tape placed on the
ground.
Fig. 12-1 shows another common form of robot brain made from discrete component
parts. This brain makes the robot reverse direction when it sees a bright light. The circuit is
simple, as is the functionality of the robot: light shining on the photodetector turns on a
relay. Variations of this circuit could make the robot stop when it sees a bright light. By
using two sensors, each connected to separate motors (much like the line-tracers of Chapter
33), you could make the robot follow a bright light source as it moves. By simply reversing
the sensor connections to the motors, you can make the robot behave in the opposite
manner as shown in Fig. 12-1, such as steering away from the light source, instead of driving
toward it. See Fig. 12-2 for an example.
Figure 12-1 Only a few electronic components are needed to control
a robot using the stimulus of a sensor.
Figure 12-2 By connecting the sensors and control electronics differently,
a robot can be made to "behave" in different ways.
You could add additional simple circuitry to extend the functionality of robots that use
discrete components for brains. For instance, you could use a 555 timer as a time delay:
trigger the timer and it runs for 5 or 6 s, then stops. You could wire the 555 to a relay
so it applies juice only for a specific amount of time. In a two-motor robot, using two
555 timers with different time delays could make the thing steer around walls and other
obstacles.
Over the past 15 years, robotics expert Mark Tilden has been designing and testing a
class of unique robots that fall into their own classification, which he calls BEAM. These
small robots, which can generally be built in an afternoon using mostly reclaimed parts
from various electronics devices found around the house, are an excellent way to learn
about different robot motors and actuators as well as to see electronic devices working in
ways that their designers definitely never intended. Along with the learning aspects of
BEAM technology and robots, there are a number of competitive events that have been
designed around different basic BEAM operations that are fun and inexpensive to compete
in.
BEAM is an acronym for:
- Biology. These robots often not only mimic the different structures and behaviors of living organisms, but with their simple construction BEAM robots are meant to evolve through humans continually improving them. It must also be pointed out that an important feature of BEAM technology is the use of renewable energy sources (primarily photocells) for power, which the robots feed from. This need for feeding is often part of the overall operation of the robots.
- Electronics. The control and motor drivers used in the robots. As previously noted, many example BEAM robots bend the operation of different components to perform actions that are suited to controlling the operation of the robots.
- Aesthetics. Unlike most robots, BEAM robots are designed and constructed with thought applied to what the robot will look like when it is completed. The desire is to have the function of the robot to be immediately obvious from its form.
- Mechanics. Instead of the traditional robot shapes, BEAM robots are very efficiently designed, both with an eye toward the aesthetics of the design and making the operation of the robot as efficient as possible by using simple electronic parts that do not have to be tailored to specific motors and sensors.
Normally when you are in a surplus store or pulling apart an old VCR, you are looking
at the motors and drive electronics as parts that will be built into a much larger robot. A
BEAM roboticist will be looking at the subassembly the motor is built into and how to use
that as the basis for an entire robot. This difference in approach is what makes BEAM technology
so special.
BEAM robots are a fascinating branch of robots, but the lack of computer control and
their typically small size makes them quite difficult to adapt to more than one application or
multiple environments. In the appendices, different BEAM resources are listed and it is recommended
that you look through them for the technical information and to marvel at the
elegance of their designs.
The biggest downside of making robot controls from discrete components is the work
required to change the hardwired brains to change the behavior of the robot. You either
need to change the wires around or add and remove components. Using an experimenters
breadboard makes it easier to try out different designs simply by plugging components and
wiring into the board. But this soon becomes tiresome and can lead to errors because parts
can work loose from the board.
You can rewire a robot controlled by a computer simply by changing the software running
on the computer. For example, if your robot has two light sensors and two motors, you
don't need to do much more than change a few lines of programming code to make the
robot come toward a light source, rather than move away from it. No changes in hardware are required. This type of programming functionality is demonstrated in Chapter 15 with a
Parallax BASIC Stamp 2 and some of the example applications that it can run.
An almost endless variety of computers can be used as a robots brain. The most common
types that are used are:
- Microcontroller. These are programmed either in assembly language or a high-level language such as BASIC or C. There are literally hundreds of different microcontrollers with a plethora of different interfacing capabilities that you can choose from to control your robot.
- Personal Digital Assistant. An old Palm Pilot provides a lot of processing power in a fairly small space with a number of features that make it very attractive for use as a robot controller. It can be difficult to interface with.
- Single-board computer. A few years ago, complete computer systems built on a PCB were the preferred method of controlling robots. These systems are still used but are much less popular due to the availability of low-cost PC motherboards and more powerful, easy to use microcontrollers.
- Personal computer motherboards and laptops. Very small form factor PC motherboards and laptops are common controllers for larger robots. These controllers can be programmed using standard development tools and commercial, digital I/O add-ons for the interfaces needed for the different robot functions.
Microcontrollers are the preferred method for endowing a robot with smarts. The reasons
for this include their low costs, simple power requirements (usually 2.5 to 5 V), and ability
of most to be programmed using software and a simple hardware interface on your PC.
Once programmed, the microcontroller is disconnected from the PC and operates on its
own. Microcontrollers can either be downloaded with a program that provides all the functions
required of it or execute a tokenized program, which provides a set of basic functions
for the application and the software already built into the microcontroller handling the various
interfaces. Virtually all microcontrollers can be used as either device; the reason for
choosing one over the other really comes down to cost, your experience and skills, available
features, and ease of use.
You shouldn't be scared at the idea of having to come up with all the code that executes
within a microcontroller. If you are familiar with a PC, you know that there are several
megabytes of code for the BIOS (basic input/output system) as well as several hundred
megabytes of code devoted to the operating system. Going by this standard, it will seem like
developing a complete application for a microcontroller is a daunting task. In reality, the
operation of the code within the microcontroller is quite simple, and other than requiring a
few configuration commands, the software is quite straightforward. The advantage of using
a microcontroller that requires a complete application is cost; a microcontroller suitable for use in robots can cost as little as $1.00. A potential drawback to this type of microcontroller
is the cost of a programmer, which can be very substantial for some chips.
When source code is tokenized, it is passed through a compiler, just like regular application
code, but instead of producing a series of instructions, the compiler produces a set
of commands that are executed within the microcontroller. This type of microcontroller can
have a series of very complex commands programmed into it, which makes them available
to new application developers instead of having to puzzle out how to implement them. To
further simplify the operation of this type of microcontroller, a bootloader program is typically
already burned into them, allowing a simple programming operation that does not
require any additional hardware. The Parallax BASIC Stamp 2 discussed later in this book
is a bootloader-equipped microcontroller, which has a simple RS-232 programming (and
console) interface.
Both kinds of microcontroller are fully programmable, but bootloader-equipped microcontrollers,
like the BASIC Stamp 2, are programmed in a high-level language such as
BASIC. Stand-alone microcontrollers can usually be programmed in a variety of different
high-level languages (BASIC, Java, C) as well as assembly language, giving a lot more flexibility
to the application developer.
Microcontrollers are available with 8, 16, or 32-bit processors. While PCs have long since
graduated to 32-bit and higher architectures with protect mode and virtual memory operating
systems, most applications for microcontrollers do not require more than eight bits.
The exact format and contents of an assembly-language microcontroller program vary
between manufacturers. The popular PIC microcontrollers from Microchip follow one language
convention. Microcontrollers from Intel, Atmel, Motorola, NEC, Texas Instruments,
Philips, Hitachi, Holtek, and other companies all follow their own conventions. While the
basic functionality of microcontrollers from these different companies is similar, learning to
use each one involves a learning curve. As a result, robot developers tend to fixate on one
brand, and even one model, since learning a new assembly language and processor architecture
can require a lot of extra work.
Table 12-1 lists a number of different microcontrollers available on the market.
TABLE 12-1 Different Microcontrollers
12.3.1.1 The Complete Computer System on a Chip A key benefit of microcontrollers
is that they combine a microprocessor component with various inputs/outputs (I/O)
that are typically needed to interface with the real world. For example, the 8051 controller
sports the following features, many of which are fairly standard among microcontrollers:
An almost endless variety of computers can be used as a robot's brain. The most common
types that are used are:
- Central processing unit (CPU)
- CPU reset and clocking support circuitry
- Hardware interrupts
- Built-in timer or counter
- Programmable full-duplex serial port
- 32 I/O lines (four eight-bit ports) configurable as an eight-bit RAM and ROM/EPROM bus
Some microcontrollers will have greater or fewer I/O lines, and not all have hardware
interrupt inputs. Some will have special-purpose I/O for such things as voltage comparison
or analog-to-digital conversion. Just as there is no one car that's perfect for everyone, each
microcontroller's design will make it more suitable for certain applications than for others.
It must be pointed out that one of the important features of the microcontroller is the
built-in hardware providing reset control and processor clock support. Many modern microcontrollers
only require power supplied to them along with a decoupling capacitor and
nothing more to run. This makes them an attractive alternative to traditional TTL or CMOS
logic chips.
12.3.1.2 Program and Data Storage The typical low-cost microcontroller will only
have a few thousand bytes of program storage, which will seem somewhat confining (especially
when your PC probably has 512MB or more of main board memory and 40GB or
more of disk storage). Despite seeming very small, this amount of memory is usually more
than adequate for loading in a robot application; many initial robot programs do not require
more than a few dozen lines of program code. If a human-readable display is used, its typically
limited to a small 2-by-16 character LCD, not entire screens of color graphics and
text. By using external addressing, advanced microcontrollers may handle more storage: megabytes of data are not uncommon. For most robot programs, only a few hundred bytes
of storage will be required in a microcontroller.
Some microcontrollers—and computers for that matter—stuff programs and data into
one lump area and have a single data bus for fetching both program instructions and data.
These are said to use the Princeton, or more commonly Von Neumann, architecture. This
is the architecture common to the IBM PC compatible and many desktop computers, but is
only found in older microcontroller architectures. Rather, most modern microcontrollers use
the Harvard architecture, where programs are stored in one place and data in another. Two
buses are used: one for program instructions and one for data.
The difference is not trivial. A microprocessor using the Harvard architecture can run
faster because it can fetch the next instructions while accessing data. When using the Von
Neumann architecture, the processor must constantly switch between going to a data location
and a program location on the same bus. The Von Neumann architecture is superior
for microcontrollers used in a bootloader configuration and in applications that use real-time
operating systems—applications that are beyond the scope of this book.
Because of the clear delineation in program and data space in the Harvard architecture,
such microcontrollers have two separate memory areas: EEPROM (electrically erasable
programmable read-only memory) for program space and RAM (random access memory)
for holding data used while the program runs. A version of EEPROM used in many
microcontrollers is known as Flash. You will often see two data storage specifications for
microcontrollers.
There are some differences in how the two processor architectures are programmed but
learning between the two is not terribly difficult; with the use of high-level languages, the differences
become transparent and should not be used to select a microcontroller for a robot.
Of much greater importance is the availability of the device itself, the resource materials,
development tools, and example applications as well as the ease in which programs can be
loaded into the chip.
12.3.1.3 Chip Programming Microcontrollers used in robots are meant to be programmed
and erased many times over. A few years ago, finding parts with EEPROM or
Flash program memory was not an easy task, and a few microcontrollers (such as the
PIC16F84) became very popular devices for robot developers because they could be reprogrammed
easily without undergoing any special steps. Older PROM and EEPROM-based
microcontrollers were more difficult to work with and required additional tools to erase
them before a new program could be burned into them. With the wide availability of
EEPROM- and Flash-based microcontrollers, the focus now turns to the cost and overhead
of programming applications into microcontrollers.
All microcontroller manufacturers have programmers available for their microcontroller
chips and there are third-party tools that can program a wide variety of different chips. The
cost for these programmers ranges from $25 to several thousand dollars. Another option
for programming microcontroller chips is to build your own programmer, which can cost as
little as $2 to $3, depending on the state of your parts drawer.
Another consideration is application debugging. Many microcontrollers are becoming
available on the market with built-in debugging features, eliminating the need for an in-circuit
emulator and allowing you to debug your applications for just a few hundred dollars.
To perform this debugging, several I/O pins of the microcontroller must be dedicated to the debugger hardware connection and cannot be used for application input and output pins.
In theory, the ability to debug the program running in a robot seems like an outstanding
idea, but in practice, it can be very difficult to implement on a mobile robot.
It may sound ironic, but you should seriously consider a microcontroller that has a debugger
interface built in as this could be used as a programming interface, eliminating the need
to pull out the chip every time the program is updated. By being able to plug a cable into
the robot for programming, the time required to update the program in the microcontroller
as well as the opportunity for damaging the microcontroller chip will be greatly reduced.
The ability and cost of a microcontroller programmer are probably the most important
considerations that you should make when choosing a microcontroller to work with. While
a chip may be ideally suited to the robot application you want to create, if you cannot get a
reasonably priced programmer, then you will find that you are spending a disproportionate
amount of money on something that does not affect the operation of the robot. A less capable
microcontroller with a cheap and simple programming interface will be a lot more useful
to you in the long run.
Palm Pilots and other small personal digital assistants (PDAs) can be used as a small robot
controller that combines many of the advantages of microcontrollers, larger single-board
computers, and PC motherboards and laptops. The built-in power supply and graphic LCD
display (with Graffiti stylus input) are further advantages, eliminating the need for supplying
power to the PDA and providing a method of entering in parameter data or even modifying
the application code without a separate computer. The most significant issue that you
will encounter using a PDA as a robot controller is deciding how to interface it to the robots
electronics. PDAs are becoming increasingly popular as robot controllers and there are a
variety of products and resources that will make the effort easier for you.
There are two primary types of PDAs to consider based on the operating system used.
The Palm O/S was the original, and there are a number of programming languages and
native programming environments to consider. One notable product that is very popular
with robot developers is the HotPaw (www.hotpaw.com/hotpaw) BASIC programming
environment lets you develop, compile, and run BASIC applications on your PDA with a
less than $20 license fee. Windows CE is the other type of operating system used by PDAs
and offers essentially the same features as the Palm-based devices. At the time of this writing,
Microsoft offers a number of eMbedded Visual Tools from their Dveloper's web site
(www.microsoft.com) for Windows CE devices including eMbedded Visual BASIC, which
can be written and tested on a PC before being downloaded into the PDA.
Once you have decided on the device and the programming environment, you have to
decide what is going to be the methodology for connecting the PDA into the robot. You
have two choices: the serial port that is built into the robot or the IRDA infrared data port.
The serial port is similar to a PC’s RS-232 port, but typically only implements two handshaking
lines and generally does not produce valid RS-232 voltage levels—neither of which
is a significant issue, but things that you should be aware of. The IRDA port is a fairly high
speed (from 9.600 to 115.2 kbps) infrared serial port that implements a reasonably complex
data protocol. There are a number of IR transceivers and stack protocol chips (such as
the Microchip MPC2150) that you can use to implement the interface—the total cost for the stack protocol chip, IR transceiver, and miscellaneous electronics will cost you about
$20). It must be pointed out that the IRDA interface will only communicate reliably if the
distance between the PDA and other devices is less than 3 ft (1 m).
In either case, an intelligent device will have to be connected to the serial connections
and used to interface with the robots motor drivers and sensors. The advantage of using
the serial port is lower parts cost while the IRDA port avoids a direct electrical connection
between the robot and the PDA, which eliminates any potential upsets of the PDA due to
electrical noise coming from the robot. You can use a prepackaged serial interface chip or
you can program a small microcontroller, like a BS2, to provide the serial interface to the
robot peripherals.
If you look through older robotics books and magazines, you will see a number of robots
that are controlled by single-board computers or SBCs. Like microcontrollers, an SBC can
be programmed in either assembly language or in a high-level language such as BASIC or
C and contain the processor and memory but also the I/O interfaces necessary to control a
robot. SBCs avoid the programming issues of microcontrollers due to the built-in RS-232
or Ethernet interfaces, which allow simple application transfers. Older SBCs used with
robots were generally based on the Motorola 68HC11 microcontroller because of the large
amount of software and tools available for them.
Another type of SBC that has been popular with roboticists in the past is the PC/104
form factor in which a processor card could be plugged directly into stacking memory, I/O,
or video output cards. Despite the apparent bias in its name, many processor cards are available
for the PC/104 form factor, providing the ability to use a PC processor, a Motorola
68000, MIPs, or Sparc processor with standard hardware. Applications for PC/104 systems
were usually downloaded into on-board EPROM or Flash memory chips. This approach
offered tremendous flexibility although at a fairly high cost.
Most modern single-board computers are full PCs with complete systems built on a small
circuit board. A very popular form factor is the mini-ITX, which provides a complete PC in
a 6.7 in square. These systems can support many hundreds of megabytes of memory and
can run Microsoft Windows or Linux operating systems, allowing standard PC development
tools to be used for program development.
There are three downsides to using SBCs in robots, especially if you are starting out and
are designing your own robot:
- Power required by SBCs is usually more than a single supply and they do not have on-board voltage regulators. A Mini-ITX motherboard requires, +3.3, +5, +12, -5 and -12 V provided to it for proper operation. High-capacity batteries and DCDC converters can provide appropriate voltages, but their weight and size results in the SBC only being used in large robots.
- Installing an operating system and running an application can be very challenging. Disk drives are very unreliable in a robot environment where the robot vibrates as it moves, and also require a great deal of power. A USB Flash memory thumb drive could be used, but this device would have to be loaded with an image of the operating system along with application code. Versions of Linux can be found on the Internet that are suitable for loading in and booting from a thumb drive, but this is not a trivial exercise.
- Adding I/O ports would most likely be through the SBCs USB ports. There are a number of suppliers that have digital I/O as well as different advanced function I/O cards available that connect to a PC via USB. Depending on the interface cards, the software interfaces to the I/O functions can be quick, sophisticated, and difficult to program.
Despite the drawbacks, the use of single-board computers, especially those that are PC
based, offer some intriguing possibilities. As previously discussed, it would be nice to be able
to debug a robot application while it is working in a mobile robot. This is extremely difficult
with microcontrollers, but it could be quite easy to do in an SBC-controlled robot; if it were
equipped with an 802.11 (or any other wireless) network card, the SBC could run the debugger
and make its display available to other PCs on the wireless network via X-Windows.
Another possible application would be to use the network interface to stream video from
the robot to a base station that was controlling the robot. The code required for these applications
is readily available over the Internet and could be added to a robot with very little
extra work.
12.3.3.1 Single-Board Computer Kits To handle different kinds of jobs, SBCs are
available in larger or smaller sizes than the 4-by-4-in PC/104. And while most SBCs are
available in ready-made form, they are also popular as kits. For example, the BotBoard
series of single-board computers, designed by robot enthusiast Marvin Green, combine a
Motorola 68HC11 microcontroller with outboard interfacing electronics. The Miniboard
and HandyBoard, designed by instructors at MIT, are other single-board computers based
on the HC11; both are provided in kit and ready-made form from various sources.
Having your personal computer control your robot is a good use of available resources
because you already have the computer to do the job. Of course it probably also means that
your automaton is constantly tethered to your PC, with either a wire or a radio frequency
or infrared link.
Just because the average PC is deskbound doesn't mean you can't mount it on your
robot and use it in a portable environment. Whether you'd want to is another matter. Certain
PCs are more suited for conversion to mobile robot use than others. Here are the qualities
to look for if you plan on using your PC as the brains in an untethered robot:
- Small size. In this case, small means that the computer can fit in or on your robot. A computer small enough for one robot may be a King Kong to another. Generally speaking, however, a computer larger than about 12 by 12 in is too big for any reasonably sized ’bot.
- Standard power supply requirements. A PC will require +5, +12, -5 and -12 V, and many PCs will also require +3.3 V. Depending on the motherboard that you use, you may discover that the +3.3, +5, or +12 V supply is the one that requires the most current as it is used to power most of the components on the PC. A few will function if the -12 and -5 voltages are absent. It may take a lot of work to figure out which power supplies are required and how much current must be available to each one.
- Accessibility to the microprocessor system bus or an input/output port. The computer won't do you much good if you can't access the data, address, and control lines. The IBM PC architecture provides for ready expansion using daughter cards that connect to the motherboard. Standard motherboards also support a variety of standard I/O ports, including parallel (printer), serial, and Universal Serial Bus (USB). There are a number of I/O cards designed for the USB so this may be the most promising avenue.
- Programmability. You must be able to program the computer using either assembly language or a higher-level language such as BASIC, C, or Java. The open source community has a number of open source compiler projects available for you to choose from.
- Mass storage capability. You need a way to store the programs you write for your robot, or every time the power is removed from the computer you'll have to rekey the program back in. Floppy disks or small, low-power hard disk drives are possible contenders here although the low-cost USB Flash thumb drives are probably your best option. Being solid state, they will be much more reliable in the vibration-filled environment of a robot and they use very little power. Even modest sized (64 MB and less) thumb drives can be loaded with an operating system and application code, eliminating the need for operating systems all together. If these drives are to be used, you will have to make sure that your motherboard can boot from the thumb drive.
- Availability of technical information. You can't tinker with a computer unless you have a full technical reference manual. While manufacturers no longer publish these manuals, there are a number of references available for PCs that you can choose from and many of these will discuss alternative applications for PCs (such as building them into robots).
The PC may seem an unlikely computer for robot control, but it offers many worthwhile
advantages: expansion slots, large software base, and readily available technical information.
Another advantage is that these machines are plentiful on the used market—$20 at
some thrift stores. As software for PCs has become more and more sophisticated, older
models have to be junked to make room for faster processors and larger memories.
You don't want to put the entire PC on your mobile robot; it would be too heavy. Instead,
remove the motherboard from inside the PC, and install that on your ’bot. How successful
you are doing this will depend on the design of the motherboard you are using. The supply
requirements of older PC-compatible motherboards are rather hefty: you need one or more
large batteries to provide power and tight voltage regulation.
Later models of motherboards (those made after about 1990) used large-scale integration
chips that dramatically cut down on the number of individual integrated circuits. This
reduces the power consumption of the motherboard as well. Favor these "newer" motherboards
(sometimes referred to as green motherboards, for their energy-saving qualities), as
they will save you the pain and expense of providing extra battery power.
The keyboard is separate and connects to the motherboard by way of a small connector.
The BIOS in some motherboards will allow you to run the PC without a keyboard detected.
You will want this capability—without it, the motherboard won't boot the operating system,
and you'll need to either keep a keyboard connected to the motherboard or rig up some
kind of dummy keyboard adapter. The same goes for the video display. Make sure you can
operate the motherboard without the display.
12.3.4.1 IBM PC-Compatible Laptops Motherboards from desktop IBM PC-compatible
computers can be a pain to use because of the power supply requirements. A
laptop on the other hand is an ideal robot-control computer. The built-in battery and display
avoid the need for a number of custom power supplies and a display device for the robot.
Check online auction sites such as Ebay, a used computer store, or your local classified ads
for used units.
You should use the laptop as-is, without removing its parts and mounting them on the
robot. That way, you can still access the keyboard and display. Use the parallel, serial, and
USB ports on the laptop to connect to the robot. You should not use the laptops batteries
for powering the robot. While they are quite sophisticated and provide a great deal of
power, they are designed for the load of the laptop, adding a significant load will cause them
to run down faster and be potentially damaged by the extra drain of the robots motors. You
may find that it is impossible to run the robot from the laptops batteries—protection and
monitoring circuitry built into the laptop and the battery packs may detect the additional
load and shut down the system fearing that the additional load is a short circuit or a problem
with the battery pack itself.
12.3.4.2 Operating Systems If you make the decision to use a PC motherboard (or
even a complete PC) in your robot, you will have to make the nontrivial decision on what
type of operating system you are going to run and what features you are going to have on
it. Fortunately, there are a lot of web sites, books, and other resources that will help you set
up the operating system, support libraries, and application code, but you will have to spend
some time thinking about how everything should work and what features you want to have
available.
The first question you should ask yourself is, what features do you want to have available
in the operating system running on your robots PC? The obvious answer is as few as possible
to minimize the amount of space that will be used for the operating system. The reason
behind this answer is correct; but the decision point isn't—the operating system that is
loaded onto the robots PC should be as small as possible, but it should have as many features
built into it as possible.
The reason for wanting as many features as possible is to give you as many options as
possible for how the PC will run. While you should avoid running the PC motherboard from
a hard disk or CD-ROM, you still want to have the drivers loaded and active in the system
in case you want to use them later. Similarly, network interface card (NIC) drivers should be
installed along with USB, serial, parallel, and other motherboard interfaces. You should not
restrict any flexibility in the PC motherboards operation until you have finished and perfected
the robot (which will probably never happen).
The question you should now be asking is, what else is there to take out? If everything is
being left in, there isn't that much space left to save.
Actually there is one big piece that you can take out and that is the graphical user
interface—the Windows interface that you work with is at least half the total size of the
operating system on disk and in memory. With it taken out, you should have an operating
system that will only require 60 MB or so of storage—small enough to fit on a USB Flash
thumb or key drive with the application code included. Loading applications or other files is
as simple as plugging the USB thumb drive into your PC and copying the files into it, just
as you would copy files between folders. If you were not to use a USB thumb drive, you would have to either disconnect the disk drive or eject the CD and update its contents—its a bit more work but still very doable.
Storing the operating system and application on a USB thumb drive will eliminate the
extra power required by a spinning hard disk or CD/DVD drive, as well as avoid the potential
reliability issues of rotating devices running on an electrically noisy and vibrating robot.
There are numerous web sites devoted to providing information required to set up a thumb
drive as a bootable device along with installing an operating system onto it.
Once you have decided where to put the operating system and application code you can
decide which operating system you are most comfortable with. All major operating systems
can be used (Microsoft Windows (all flavors), MS-DOS, and Linux) after the graphical user
interface has been removed from it. There are no significant reasons for choosing one
operating system over another; the important points will be which ones you are most comfortable
with and which ones have the software development tools that you have and are
proficient working with.
Regardless of the operating system used, there are a variety of open source tools that
you can download for application development. These can be found using a quick Google
search or by looking at www.cygwin.com, which is an X-Windows-based environment for
Microsoft Windows that will allow you to simulate the Linux environment and develop and
debug applications for any of the three major operating systems. Even if you are unfamiliar
with Linux or Unix operating environments and do not consider yourself very technical, it
is surprisingly easy to download and work with these tools.
The architecture of robots requires inputs, for such things as mode setting or sensors, as well
as outputs, for things like motor control or speech. The basic input and output of a computer
or microcontroller is a two-state binary voltage level (off and on), usually 0 and 5 V.
For example, to place an output of a computer or microcontroller to high, the voltage on
that output is brought, under software control, to +5 V.
In addition to standard low/high inputs and outputs, there are several other forms of I/O
found on single-board computers and microcontrollers. The more common are listed in the
following sections, organized by type. Several of these are discussed in more detail later in
the book.
The most common type of computer interfacing is known as serial, in which multiple bits
are sent as a series of bits over time on a single wire. There are a number of different types
of serial communications protocols as shown in Fig. 12-3, with asynchronous, synchronous,
and Manchester encoding. Each methodology is optimized for different situations.
The two most likely communications methods that you will have to work with when
interfacing a robot controller to I/O devices is synchronous serial communications, which
consists of a data line and a clock line as shown in Fig. 12-4. There are several different protocols
used for synchronous serial communications, but they all have one characteristic in common: the bit on the data line is saved in the receiver when the clock transitions from
high to low or low to high. The timing of the clock line does not have to be consistent and
in some synchronous serial protocols, there can be multiple devices on the clock and data
lines and part of the protocol is used to determine which device is active at any given time.
The three most common types of synchronous serial communication methodologies are:
- I2C (inter-integrated circuit). This is a two-wire serial network protocol created by Philips to allow integrated circuits to communicate with one another. With I2C you can install two or more microcontrollers in a robot and have them communicate with one another. One I2C-equipped microcontroller may be the master, while the others are slaves and used for special tasks, such as interrogating sensors or operating the motors.
- Microwire. This is a serial synchronous communications protocol developed by National Semiconductor products. Most Microwire-compatible components are used for interfacing with microcontroller or microprocessor support electronics, such as memory and analog-to-digital converters.
- SPI (serial peripheral interface). This is a standard used by Motorola and others to communicate between devices. Like Microwire, SPI is most often used to interface with microcontroller or microprocessor support electronics, especially outboard EEPROM memory.
Figure 12-4 Close-up detail showing how synchronous serial data is only
picked up on the clock edge.
Asynchronous serial communications uses a single wire to send a packet that consists of
a number of bits, each the same length. The most popular data protocol for asynchronous
serial communications is known as non-return to zero (NRZ) and consists of the first bit, the
Start Bit is low and is used by the receiver to identify the middle of each bit of the incoming
data stream for the most accurate reading as shown in Fig. 12-5. There can be any number
of data bits, but for most communications, eight bits, allowing the transmission of a byte,
are used. The following data bits have the same period and are read as they are received.
The stop bit is a high value (the non-return to zero that resets the data line to a high value
so the next start bit will be detected by the receiver) that provides a set amount of time for
the sender and receiver to prepare for the next data packet. An error detection bit can be
placed at the end of the data bits, but this is rarely done in modern asynchronous serial
communications.
Figure 12-5 The asynchronous serial data stream consists of a start bit, which goes low, followed
by a number of data bits. The receiver finds the center of the low start bit and then uses this
point to read the values of subsequent bits.
The most popular form of asynchronous serial communications and one that you have
probably heard of is commonly referred to as RS-232 (although more accurately known as
EIA-232) and changes the normal TTL voltage levels of the serial data from 0 to +5 V to
+12 (0) and -12 (1) V. There are a number of chips available that will make this voltage conversion
simpler, most notably the Maxim MAX232, which generates the positive and negative
voltages on the chip from the +5 V supply. Along with RS-232, RS-422, and RS-485 are commonly used forms of asynchronous serial communications, and like RS-232, these
standards can be implemented using commonly available chips.
Sending and receiving RS-232 data in a computer system may seem like a chore, but it is
actually simplified by the universal asynchronous receiver/transmitter (known by its acronym
UART) that will send and receive NRZ asynchronous data automatically with the computer
system writing to it to start a data send or polling the UART to determine if the last written
data byte has been sent or if data has been received. Along with the send and receive data
bits, there are a number of other lines that can be used with RS-232 for handshaking
(system-to-system communications to indicate that data can be sent or received) but these
lines are largely ignored in most modern communications. The UART generally will provide
an interface to these bits as well.
There are two principle types of data conversion:
- Analog-to-digital conversion (ADC) transforms analog (linear) voltage changes to binary (digital). ADCs can be outboard, contained in a single integrated circuit, or included as part of a microcontroller. Multiple inputs on an ADC chip allow a single IC to be used with several inputs (4-, 8-, and 16-input ADCs are common).
- Digital-to-analog conversion (DAC) transforms binary (digital) signals to analog (linear) voltage levels. DACs are not as commonly employed in robots; rather, they are commonly found on such devices as compact disc players.
- Comparator. This is an input that can compare a voltage level against a reference. The value of the input is then lower (0) or higher (1) than the reference. Comparators are most often used as simple analog-to-digital converters where high and low are represented by something other than the normal voltage levels (which can vary, depending on the kind of logic circuit used). For example, a comparator may trigger high at 2.7 v.
The three major types of pulse and frequency management are the following:
Input capture is an input to a timer that determines the frequency of an incoming digital
signal. With this information, for example, a robot could differentiate between inputs, such
as two different locator beacons in a room. Input capture is similar in concept to a tunable
radio.
Pulse width modulation (PWM) is a digital output that has a square wave of varying duty
cycle (e.g., the on time for the waveform is longer or shorter than the off time). PMW
is often used with a simple resistor and capacitor to approximate digital-to-analog conversion,
to create sound output, and to control the speed of a DC motor.
Pulse accumulator is an automatic counter that counts the number of pulses received on
an input over X period of time. The pulse accumulator is part of the architecture of the
microprocessor or microcontroller and can be programmed autonomously. That is, the accumulator
can be collecting data even when the rest of the microprocessor or microcontroller
is busy running some other program.
There are a variety of other features available in different microcontrollers and computer
systems. From a high level they will make your application much more elegant and probably
simpler, but they can require specialized knowledge that will take you a while to develop.
- Hardware interrupts. Interrupts are special input that provides a means to get the attention of a microprocessor or microcontroller. When the interrupt is triggered, the microprocessor can temporarily suspend normal program execution and run a special subprogram.
- External reset. This is an input that resets the computer or microcontroller so it clears any data in RAM and restarts its program (the program stored in EEPROM or elsewhere is not erased).
- Switch debouncer. This cleans up the signal transition when a mechanical switch (push button, mercury, magnetic reed, etc.) opens or closes. Without a debouncer, the control electronics may see numerous signal transitions and could interpret each one as a separate switch state. With the debouncer, the control electronics sees just a single transition.
- Input pull-up. Pull-up resistors (5 to 10K) are required for many kinds of inputs to control electronics. If the source of the input is not actively generating a signal, the input could float and therefore confuse the robots brain. These resistors, which can be built into a microcontroller and activated via software, prevent this floating from occurring.
To learn more about . . . |
Read |
|
Connecting computers and other circuits to the outside world |
Chapter 14, "Computer Peripherals" |
|
Using the BASIC Stamp microcontroller |
Chapter 15, "The BASIC Stamp 2 Microcontroller" |