REMOTE CONTROL SYSTEMS
The most basic robot designs—just a step up from motorized toys—use a wired control box on which you flip switches to move the robot around the room or activate the
motors in the robotic arm and hand. The wire link can be a nuisance and acts as a tether
preventing your robot from freely navigating through the room. You can cut this physical
umbilical cord and replace it with a fully electronic one by using a remote control receiver
and transmitter.
This chapter details several popular ways to achieve links between you and your robot.
You can use the remote controller to activate all of the robot’s functions, or, with a suitable
on-board computer working as an electronic recorder, you can use the controller as a teaching
pendant. You manually program the robot through a series of steps and routines, then
play it back under the direction of the computer. Some remote control systems even let you
connect your personal computer to your robot. You type on the keyboard, or use a joystick
for control, and the invisible link does the rest.
In previous editions of this book, a joystick taken from an old Atari video game was used as
a build-your-own teaching pendant. Over the years, it has become very difficult to find surplus or used Atari video game joysticks and even the ones that are available are generally in
poor shape because the plastic boot often cracked or pulled out of the plastic base, making
the joystick difficult to use. What should be readily available are PC joysticks or gamepads,
which can be easily adapted into wired controllers for robots.
The PC joystick connects to a PC via a 15 pin D-shell connector and is wired according to Fig. 16-1 The pinout of the PC port is given in Table 16-1 and it can accommodate up to two joysticks. For robot applications in which the joystick will be used to control the motion of the robot, only Joystick A along with its two fire buttons are used. For more complex robots, two joysticks could be wired into the port.
Figure 16-1 Internal wiring of PC joystick. Note that the analog outputs
are part of a voltage divider tied to Vcc with a resistance of 0 to 100k
PIN |
FUNCTION |
1 |
+5 V DC |
2 |
B1A—button 1, joystick A |
3 |
XA—x axis resistance, joystick A |
4 |
Ground |
5 |
Ground |
6 |
YA—y axis resistance, joystick A |
7 |
B2A—button 2, joystick A |
8 |
+5 V DC |
9 |
+5 V DC |
10 |
B1B—button 1, joystick B |
11 |
XB—x axis resistance, joystick B |
12 |
GND/MIDI out |
13 |
YB—y axis resistance, joystick B |
14 |
B2B—button 2, joystick B |
15 |
+5 V DC/MIDI In |
The joystick isn’t a terrible interface, although it can be difficult to work precisely.
Despite the added capability of proportional joysticks, games quickly standardized on a
gamepad similar to that used by Nintendo with a cross joystick that was digital (indicates Up,
Down, Left, or Right). To interface the gamepad digital joystick with the standard PC game
port, the circuit shown in Fig. 16-2 was developed. When the joystick is centered, current
flows through one 50k resistor, which is the same resistance as when the analog joystick is
centered. If the Right or Down button is pressed, the PNP transistor is turned off and current
flows through a second 50k resistor, providing the full 100k resistance of the standard
joystick. Finally, if the Left or Up button is pressed, the resistance drops to zero. This circuit
works quite well and gives the PC the same interface as a basic game machine.
Figure 16-2 Internal circuitry for a PC gamepad to provide 100k when the
Right/Down button is pressed, 50k when no button is pressed, and 0 Ω when the Left/Up button is pressed.
To demonstrate the operation of a gamepad (or an old PC joystick) and turn on an LED
according to whether the joystick is moved to an extreme, the circuit in Fig. 16-3 (and parts list in Table 16-2) was developed. Wires will have to be soldered to the 15 pin female
D-shell connector to allow it to be wired to a breadboard.
Figure 16-3 PC gamepad interface. When a gamepad or joystick control is moved to an
extreme, one or two LEDs will light.
15 pin female D-shell |
15 pin female D-shell connector |
LM339 |
LM339 quad open-collector output comparator chip |
LED1–LED4 |
Visible light LEDs |
R1–R2 |
10k resistors |
R3, R4, R7 |
100k resistors |
R5 |
22k resistor |
R6 |
47k resistor |
R8–R11 |
470 Ω resistors |
Misc. |
Breadboard, breadboard wiring, 4x AA battery clip, 4x AA batteries, breadboard mountable switch |
The circuit uses the two voltages produced by the voltage divider built from R5 through
R7 to compare to the voltages produced by the voltage divider, which uses the gamepad/joystick
internal resistances along with a 100k resistor to find out if any of the axes have gone
to the extreme. The comparator will allow current to flow through the appropriate LED
when the gamepad/joystick resistance is at an extreme. This circuit will be used as the basis
for a robot motion teaching tool in the next section.
With the circuit that will convert the position of a PC-compatible gamepad or joystick into
four digital signals, you can add a microcontroller that will convert the data bits into motor
control values as well as give you the ability to record a set of movements for playback later.
This application is often called a teaching pendant. In this section, the gamepad/joystick
interface circuit will be enhanced to do just that, as well as provide you with a method of
saving the recorded positions for use in other applications.
Fig. 16-4 shows how a BS2 can be added to the gamepad/joystick interface along with
two LEDs and four motor control bits used to control the motion of a differentially driven
robot. Along with the connections for the gamepad/joystick position, the pulled-up A and
B buttons are used as control signals to the recording and playback of the teaching pendant
application.
Figure 16-4 The teaching pendant circuitry. The BS2 communications/programming interface will be used for saving a series of commands for the robot.
The BS2 can be connected to either TTL/CMOS compatible motor drivers or to four
LEDs, which will simulate the operation of the motors. For the prototype, the circuit was
added to a simple DC driven mobile robot to observe the performance of the robot. After
you’ve built the circuit, you can load the following program into the BS2 to demonstrate the
operation of the teaching pendant control.
'BS2 Teaching Pendant - Use BS2 and PC Gamepad for Robot Training''Along with using the PC Gamepad/Joystick for Tethered Robot Remote'Control; it can also be used to record and play back movements'
To operate the pendant, press the A button on the gamepad/joystick to start the recording
operation. Samples of the joystick position are taken every 100 ms and recorded in the
BS2’s built-in EPROM for up to 100 s (1000 samples). To stop the recording, press the B
button. Using the Memory Map function of the BASIC Stamp Editor software, the program
was found to take up EEPROM memory locations $474 to $7FF or 2956 bytes, leaving a
maximum 1140 bytes available for recording. A total of 1000 samples and bytes was chosen
to allow for some expansion of the application later.
To play back the application, press the B button and the robot will perform the actions
in the EEPROM memory, exactly as they were recorded. It’s actually a lot of fun recording
a series of motions and then watching a robot repeat them.
Finally, to dump out the contents of the EEPROM, make sure the robot and BS2 are
connected to a PC with the BASIC Stamp Editor software active. Start up a Debug Terminal
window and press the A and B buttons simultaneously. When this is done, a series of
PBASIC DATA statements are generated, which can be cut and pasted from the Debug
Terminal window into an application or another program editor. These statements can be
put directly into another application (and you might want to put in the RobotMove subroutine
from the previous program as well) for use in it.
There are a number of things that can be done to enhance the teaching pendant; some
have tried the program as shown here while others are just being thrown out for your experimentation:
- Double the memory usage. One hundred seconds of recorded robot motion is probably more than you will ever need, but in the rare case that you will need more samples, you could double up the memory by placing two four-bit samples into each EEPROM byte rather than the one used in the basic program.
- Allow control without recording. Right now, the robot motion is only allowed after the button A is pressed. You might want to modify the program to allow the robot to be controlled at any time with the two buttons controlling recording and playback.
- Don’t erase recorded data on start up. When the application first powers up, it writes a zero to the first EEPROM location. A zero is interpreted as a data stop. If you would like to save the data from one execution instance to the next, delete the “write 0, 0” statement at the start of the program.
- Add a second joystick for robot arm control. This will allow you to control a gripper on the front of a mobile robot or a multi-axis robot arm. Along with this, many gamepads have more than just two buttons—they can have up to four (the second two are used by a second controller) that can be used to enhance the application.
- Use data as escape maneuvers in combat robots. One thing you will find difficult to program a robot for is a series of predefined movements that behave exactly as you would like. You will probably find it easier to record the desired sequence and just play it back when required.
- Use multiple movement recordings in an application. There’s no reason why you wouldn’t want to have multiple recordings in an application. If the robot was a combat robot, you might want to randomize your escape maneuvers to make it more difficult for your opponents.
- Put a B button on a robot to allow playback without the pendant. It is worth the few seconds to add a button wired to the ground in parallel with the gamepad/joystick’s B button to allow the robot to perform the recorded operation without having the pendant attached. Keeping the pendant’s wires away from the movement of the robot can be a pain sometimes, especially when you have a sequence preprogrammed in that you like.
In the 1960s, the first television remote controls appeared, which had two or three basic
functions: on/off, channel change, and sound mute. To change the channel you had to
keep depressing the channel button until the desired channel appeared (the channels
changed up, from 2 through 13, then started over again). What was more amazing than the
remote control itself was how it worked: by ultrasonic sound. Depressing one of the control
buttons struck a hammer against a metal bar cut to a specific length and produced a specific
high-frequency tone. A microphone in the TV picked up the high-pitched ping and
responded accordingly—although it wasn’t unusual for women’s jewelry and other metal
items to produce the same frequencies and cause the channel to change (or worse, the TV
to go off) periodically.
These days, remote control of TVs, VCRs, and other electronic devices is taken for
granted. Instead of just two functions, the average remote handles dozens—more than the
knobs and buttons on the TV or VCR itself. Except for some specialty remotes that use
UHF radio signals, today’s remote controls operate with infrared (IR) light. Pressing a button
on the remote sends a specific signal pattern; the distinctive pattern is deciphered by
the unit under control.
You can use the same remote controls to operate a mobile robot. A computer or microcontroller
is used to decipher the signal patterns received from the remote via an infrared
receiver. Because infrared receiver units are common finds in electronic and surplus stores
(they’re used heavily in TVs, VCRs, etc.), adapting a remote control for robotics use is actually fairly straightforward. It’s mostly a matter of connecting the pieces together. With your
infrared remote control you’ll be able to command your robot in just about any way you
wish—to start, stop, turn, whatever.
Here are the major components of the robot infrared remote control system:
- Infrared remote. Most any modern infrared remote control will work, but . . . the signal patterns they use vary considerably. You’ll find it most convenient to use a universal remote control (about $10 at a department store). These remote controls can work with just about any make and model of TV set, DVD player, VCR, cable/satellite receiver/ decoder available on the market.
- Infrared receiver module. The receiver module contains an infrared light detector, along with various electronics to clean up, amplify, and demodulate the signal from the remote control. The remote sends a signal built from a pattern of on/off flashes of infrared light. These flashes are modulated at about 38–40 kHz to differentiate them from other infrared sources in the receiver’s environment. The receiver strips out the modulation and provides just the on/off flashing patterns (which will be referred to as the signal or packet in this chapter).
- Computer or microcontroller. You need some hardware to decode the light patterns, and a computer or microcontroller, running appropriate software, makes the job straightforward.
Previous editions of the book described the Sharp remote control standard or protocol for
the infrared signal, but in this edition, the Sony format will be used. The reason for changing
to the Sony standard is the fewer number of bits that are used in the data transmission,
the more definite difference between a 1 or 0 of the data, and the greater number of projects
available on the Internet and in books that use it.
Receiving the modulated signal is quite simple; there are a number of different remote
control receivers available on the market, like the Sharp GP1U57X shown in Fig. 16-5.
The receivers are very sensitive to electrical noise, so it is important to provide the 56 Ω
resistor, 47 μF, and 0.1 μF filter capacitors to the circuit as shown. Some older receivers
are built into metal cans, which may require external grounding as shown in the diagram.
The outputs are usually open collector, so a pull-up resistor, like the 10k one shown in
Fig. 16-5 is required.
Figure 16-5 The infrared receiver-demodulator requires
relatively few external components that are primarily used to
filter any noise out of the unit’s power source.
When it comes right down to it, it really doesn’t matter which protocol is used; they are
all built around a similar data packet using the parts that are shown in Fig. 16-6 is required. The first
part is the leader and is used to indicate the start of the packet—for Sony remote controls,
this is 2.2 ms in length. The packet’s data bits (12 in the case of the Sony protocol) start
with a synchronizing pulse with the length of the low pulse being the bit value. The Sony
data bits are either 0.55 ms (550 μs) or 1.1 ms in length.
It might be intimidating at first to think about trying to receive and process remote control
codes. In this and the next section, three different methods will be demonstrated and
there are a number of ways that can be considered for use in a robot. The important
aspects of the differences are the ability to differentiate between a 1 and a 0 and to determine
when an invalid packet (part of it is lost or has been garbled) is received and then
reject it.
The first method is a brute force approach of timing the signals coming in.
Note that for making the code easier to understand, the counter values are assumed to be
directly converted to time values. This is an unreasonable assumption; in a typical application,
a free running clock would be reset before each DO WHILE loop and its value used for
the comparison afterward.
Timing values explicitly, while working quite well, is difficult to use with a robot. There is
a lot of overhead devoted to receiving the signal and it can be very difficult to time the entire
application (especially if a PWM is used to control the motor speeds). A better way is to use
interrupts to produce a virtual IR receive port using code like:
In this interrupt example code, the code does not do anything while waiting for a new
RemoteCode value. In actuality, other tasks can be running in the mainline, and Remote-
Code can be polled periodically to see if it has changed from zero to a code value. The interrupt
code also checks for invalid data bit values, which minimizes the amount of effort the
mainline code has to expend determining whether a packet is valid; the mainline just has to
compare RemoteCode to the robot’s operational values.
After reviewing the code in the previous section, you have probably come to the conclusion
that the BASIC Stamp 2 cannot read the packets from infrared remote controls. Trying
to decode the data using PBASIC statements isn’t possible because of the 250 μs
statement execution time, but it is possible to add hardware to the BS2 as shown in Fig. 16-7, which performs the decoding for the BS2 and stores the value in a 12 bit serial to
parallel decoder that can be read by the BS2. The parts list for the circuit in Fig. 16-7 is
in Table 16-3.
Figure 16-7 A single shot delay can produce the clock signal to pass IR serial data to two
74LS174s wired as six-bit shift registers that can be read by the BS2.
BS2 |
Parallax BASIC Stamp 2 |
IC1 |
38 kHz TV remote control IR receiver (Sharp GP1U57X or equivalent) |
IC2 |
74LA123 dual shot chip |
IC3–IC4 |
74LS174 Hex D-flip flop chips |
R1 |
100 Ω resistor |
R2 |
10k resistor |
R3 |
22k resistor |
C1 |
47 μF electrolytic capacitor |
C2–C5 |
0.1 μF capacitor |
Misc. |
BS2 communications/programming interface, long breadboard, breadboard wiring kit, 4x AA battery clip, 4x AA alkaline batteries |
The IR receiver (IC1) in the circuit passes the demodulated remote control signals to the
trigger input of the 74LS123 as well as the data pin of one of the D-flip flops. When the
incoming signal goes low, the 74LS123 single shot produces an 800 μs long pulse, which
latches in the data bit along with shifting the contents of all the daisy-chained D-flip flops
down. If the data bit is a 1 when the bit is latched into the bit, the next synch pulse will be
active and a 1 will be latched in, otherwise the data bit will still be low and a 0 will be latched
in. The 2.2 ms leader will be read as a zero and then the data will be shifted through and
out of the 12 D-flip flop shift register.
To test the operation of the circuit, the following program was developed.
Despite the simplicity of the code, the circuit works surprisingly well and data bits are read
from the packets with good repeatability. When you build and test the application, there are
three things that you will probably notice. The first is that occasionally, when a button is
pressed on the remote control, the changing value read from the serial register is different
from subsequent values. This is due to the data still being shifted in when the I/O port is
executing. The second issue that you might have is the number of BS2 I/O pins that are
required for the application—only four are left available for controlling the robot. You may
want to shift in the data using the SHIFTIN PBASIC statement with some hardware to arbitrate
between the incoming data and reading it. Finally, to indicate that a value has been
read, you may want to clear the shift register: this could be accomplished by driving pin 1
of the 74LS174s low, but this would require an additional BS2 pin.
Table 16-4 lists some of the different codes provided by a Sony TV remote control using
this circuit and the previous code. By selecting a VCR, DVD, or cable/satellite receiver, you
will get slightly different codes for the different functions.
TABLE 16-4 Sony TV Infrared Remote Control Codes
As noted earlier in this chapter, the software running in the remote control is very simple;
when a button is pressed, a packet of data representing the button is sent out. If it is still
pressed 40 or 50 ms later, then a packet is sent again and each and every 40 or 50 ms until
the button is released.
The real intelligence is built into the device that is being controlled. Understanding how
the remote control works is important to being able to use the remote control to directly
control the robot’s motors.
The remote control output is so simple because as a communications link infrared data
transmission is quite poor, especially compared to other forms of wireless communications.
People rarely point the remote control directly at the controlled device’s receiver (often,
people will point the remote control at the wrong unit altogether); IR communications
depend on the ability of the signal to bounce off various objects in the room as well as the
receiver’s ability to receive and accept very low power signals. Despite this sensitivity and
the ability to reflect off of different objects, quite a few packets are normally lost. The
receiver compensates for this by continuing the last action some length of time after the last
packet was received, beyond the time for the next packet to be received in the expectation
that the next was accidentally lost and subsequent ones will continue the operation. This is
the mode that is used in robots to control the motors.
To illustrate what is being discussed here, consider a typical situation. The motors move
the robot forward when a packet is received and stop when the expected time (50 ms) has
gone by without a repeated signal. The motors are turned off. This is a very simple example.
For a real-world situation, all the codes would be tested and the motors would command
the robot to move forward, reverse, turn left, turn right, etc. In a real robot, motor
PWMs would also be active, controlling the speed at which the robot moves.
The problems with this method of controlling motors are (a) if a packet is missed, the
motors will be stopped, periodically resulting in either the robot “shuddering” or a PWM
action taking place, resulting in less power to move the robot; and (b) if there is a mistiming
between the microcontroller and the remote control, the remote signal will be
missed, resulting in the motors being off for some period of time, again producing a PWM
action and lowering the amount of power available from the drive motors. Note that the
packet received variable RemoteSignal is reset to ensure that any subsequent values of
RobotForwards have been newly received and are not saved values from previous data
receptions.
To prevent these issues, you can plan for missed packets by running the motors for
longer than the time between packets. Many applications use three or four packet delays to
ensure the robot is active while it is being commanded.
In the second example code the SignalCount variable is reset to 15 (three packet intervals
in 10 ms increments) every time a RobotForwards packet is received. Along with eliminating
the potential shuddering or lowered power operation of the motors, the time available
in the PAUSE 10 statement could be put to use for running sensors or expanding the program
to accept different inputs and perform different operations. The first example application
does not allow itself to be expanded as easily.
Regardless of which microcontroller or computer system you prefer, or maybe you don’t
want to use the signal patterns for Sony TVs and VCRs, you can adapt the receiver-demodulator
interface and the software presented in this chapter for use with a wide variety
of controllers, computers, and signal pattern formats. Of course, you’ll need to revise
the hardware and the program as necessary, and determine the proper bit patterns to use.
You will probably find that the signal patterns used with a great many kind of remote
controls will be usable with the circuitry and programs shown in this chapter. Often, you will
merely need to test the remote to determine the values to use for each button press. The
hardware and software will still work even if the signal from the remote contains more data
bits than the 12 provided. For this application, if more bits are sent to the shift registers, the
first bits coming through are discarded, which usually doesn’t matter—you’re not trying to
control a TV or VCR but your own robot, and the code values for its control are up to us.
The only requirement is that each button on the remote must produce a unique value.
If you need to control your robot over longer distances, you should consider using radio signals
instead of infrared. You can hack an old pair of walkie-talkies to serve as data transceivers,
or even build your own AM or FM transmitter and receiver. An easier (and probably
more reliable) method is to use ready-made transmitter/receiver modules. Ming, Abacom,
and several other companies make low-cost radio frequency modules that you can use to
transmit and receive low-speed (less than 300 bits per second) digital signals. Fig. 16-8
shows transmitter/receiver boards from Ming. Attached to them are daughter boards outfitted
with Holtek HT-12E and HT-12D encoder/decoder chips.
Figure 16-8 RF transmitter/receiver modules can be used to remotely control robots from a greater distance than with infrared systems.
The effective maximum range of these units is from 20 to 100 ft, depending on whether
you use an external antenna and if there are any obstructions between the transmitter and
receiver. More expensive units have increased power outputs, with ranges exceeding 1 mil.
You are not limited to using just encoder/decoders like the HT-12. You may wish to construct
a remote control system using DTMF (dual-tone multifrequency) systems, the same
technology found in Touch-Tone phones. Connect a DTMF encoder to the transmitter and
a DTMF decoder to the receiver. Microcontrollers such as the BASIC Stamp can be used as
a DTMF encoder, or you can use specialty ICs made for the job.
Another option that you can consider is the use of hobby remote control transmitters
and receivers. Interfacing to the servo control signals is somewhat more complex than the
digital I/Os of the Holtek chips, but this can be done fairly simply within a microcontroller
(a BASIC Stamp 2 can handle this chore with ease; pass each of the servo outputs to a separate
BS2 pin and use the Pulsout statement to convert the length of the pulse to a numeric
value). If you don’t feel comfortable interfacing the receiver to a microcontroller, then servos
could be used to throw switches and control the robot mechanically or commercial
motor controllers (used for controlling the motors in model airplanes, boats, and cars) can
be used.
To learn more about . . . |
Read |
|
Interfacing and controlling DC motors |
Chapter 20, “Working with DC Motors” |
|
Connecting to computers and microcontrollers |
Chapter 14, “Computer Peripherals” |
|
Using the BASIC Stamp microcontroller |
Chapter 15, “The BASIC Stamp 2 Microcontroller” |