This project provides an introductory programming interface
for beginner programming students. The goal of the project is to enable students
to use their analytical and creative skills by running simple programs that have
physical effects within a specified environment. The project works as follows. A
PC is used to control a tank over a wireless connection. The user provides a set
of instructions to move the tank. The movements allowed are forward, backward,
to the right and to the left. Forward and backward movements have to be supplied
with distance units. Turning to the right and to the left have to be supplied
with turning angles. By providing a mix of these instructions, we can define a
wide variety of paths such as a square or a triangle on which the tank can move.
The environment we provide for the tank is a square flat
surface bounded by a 20’ by 20’ elevated border. The tank will be able to
detect when it is able to move and it will be able to detect errors in movement
such as changes in direction caused by any obstacles.
The components that make up the Etank project are divided
into two main components. There is a central component that includes a PC with a
user interface, an XSV-300 board, a tank’s remote control and an RF
transceiver. Also, there is a remote component, which consists of a tank and a
couple of modules that are mounted on top of it. These modules are a compass, a
sonar ranging module and a PIC processor. The remote component gathers data
about the current position of Etank relative to the borders and sends the data
over the RF transceiver to the central component. The central component decides
if the movement is feasible and reports to the user a result of his command.
Table 1 below shows the requirements of the parts being used in the central and the remote components
Table 1: Part specifications of the central and the remote component
Voltage |
PIC processor ……….............. 5V
- 7.5V Sonar ………………..................
4.5V - 6.8V RF transceiver ……….............
2.7V - 3.5V Compass …………..................
4.75V - 5.25V Tank’s remote control ......... 9V XSV-300 board ………............ 9V |
Operating Frequency |
PIC processor ……….............. 32
MHz Sonar ………………..................
49.4 KHz RF transceiver ……….............
916.5 MHz Compass ……………................ 1
MHz max Tank’s remote control ......... 49 MHz XSV-300 board ………............ 25 MHz Oscillator …………….............. 20 MHz |
Current |
PIC processor ………............. 250
mA Sonar ……………….................
Sleeping = 0.1 A Sonar ……………….................
Xmitting = 2.0 A RF transceiver ………............
Rcving. = 5.5 mA RF transceiver ………............
Xmitting = 12 mA Compass ……………...............
Sleeping = 100 uA Compass ……………...............
Polling = 4 mA Tank’s remote control ........ 55 mA XSV-300 board ………........... 0.55 A |
Communication Speed |
PIC to RF …………................
19200 bits/sec PIC to Sonar ………..............
19200 bits/sec PIC to Compass ................ 4800
bits/sec RF to XSV …………............... 19200 bits/sec Parallel to XSV ...............… Variable as needed |
Code Size |
PIC processor ………............ 8KB x 14 words Flash XSV-300 ……………............... 300,000 gates |
To meet the voltage and current requirements of the PIC
processor, the sonar, the compass and the oscillator, we connect all of them to
4 D-size Alkaline batteries, which provide up to 6V with enough current to run
the system. The XSV-300 board, the tank’s remote control and the RF
transceiver have their own power sources and thus they will not need to use
extra power supplies.
To meet the operating frequency requirements for the remote
components, we use a 20MHz oscillator. Using this clock rate, the PIC can
communicate with the RF transceiver on a baud rate of 19200 bps. Since the
compass data output rate is of a maximum of 1MHz, we use a clock divider on the
PIC. The XSV-300 board is operating at 25MHz, which is the fastest we could run
it currently. Also, we are not concerned with the operating frequency of the
sonar, the RF transceiver and the tank’s remote control, since we use them as
black box modules.
To meet the communication speed, the RF transceiver
communicates on 19200 bps with the XSV-300 board and the PIC. The PIC
communicates with the sonar at 19200 bps and with the compass at 4800 bps.
Finally, we need to set up an environment for Etank to
operate within. This could be a 20’ ´ 20’ box with 20” high wood borders
We
divided the control system of Etank into two separate components, the remote
component and the central component, as shown in figure 1.
Figure
1. The main components of Etank system.
We mount a sonar, a compass , an RF
transceiver, and a PIC processor on the tank. These devices, which we label as
the Remote Component, provide the current status of the tank as it moves in its
environment. By current status we mean the distance of the tank from the border
it is facing and the direction it is pointing at.
The sonar obtains the distance of
the tank from the border of the box. It does so by measuring the time it takes
for the sound to travel from the sonar to the border. The measured time will be
used by the PIC to calculate the actual distance via the following formula:
Distance
= Time ´ Speed of the tank
The compass obtains the current
heading of the tank. The measured heading will be used by the PIC to calculate
the turned angle via the following formula:
Turned
angle = Current heading - Heading before the turn
After calculating the tank’s
distance to a border or the tank’s turned angle, the PIC will format the data
into a packet, and will send it to the RF transceiver for transmission to the
central component. This process is performed periodically every 250ms in
order to keep the central component up to date about the status of Etank.
On the user side, we have a PC, an
XSV-300 board, the tank’s remote control, and the RF transceiver. These
devices, which we label as Central Component, control the movement of the tank.
The XSV-300 board receives data from the PC. The PC contains
the user application used for controlling the tank. Based on the user input, the
XSV-300 board checks for the feasibility of the command using the data polled
from the sonar and the compass on the remote side. To achieve that, the XSV-300
board takes care of unpacking the packet that it receives through the RF
transceiver. It then orders the tank to move or turn using the tank’s remote
control. As the tank moves, the remote component updates the central component
of the current status of the tank, which contains the heading using the compass
and the distance from the border using the sonar.
Central Component
In this section, we introduce each of the components in the central component. We describe the function of each of the modules in detail.
The PC is the interface for someone wishing to control
Etank. The user interface is a custom application that we program in C++.
This application allows the user to send an instruction to the XSV-300 board to
control Etank. The instruction consists of a command and units of
movements. The commands may be: move forward, move backwards, turn left, and
turn right. The units of movement have different meanings depending on what the
command is. If the command is to move forward or backward, then the units will
be in millimeters. If the command is a turn command, then the units will be in
degrees. For example, if the command was “turn left” and the units were
“30”, then the tank should rotate 30 degrees to the left of its current
position.
The application will rely on the DLPortIO library to
communicate the PC to the XSV-300 through the parallel port. This library
provides an interface for sending data to the parallel port.
For actual transmission of data, one byte will be used for the command and two bytes will be used for units of movement.
The supported movement directions are forward, backward,
pivot turning to the left and pivot turning to the right. The remote control
unit is connected to the XSV-300 board through four pins on the XSV-300
board’s right expansion pins. The XSV-300 board is connected to the PC using
the XSV-300 board’s left expansion pins. We use the PPortC program to
communicate the PC to the XSV-300 board using the parallel port. The pins we use
are a write enable (WE) pin, eight data pins, busy (BSY) pin and a ground (GND)
pin. A user interface program on the PC side sends signals through the parallel
port.
Few bit combinations make up the four movements mentioned
above. We programmed sample bit combinations on the XSV-300 using a simple
Verilog module. We used 0x01 to represent forward, 0x02 to represent backward,
0x03 to represent pivot turning to the left and 0x04 to represent pivot turning
to the right. Any other combination has no effect. When the user sends a command
byte, the XSV-300 board receives it through the parallel cable. The board checks
if the command is one of the four movements mentioned above. If the command is
valid, the board expects two more bytes. Those are distance bytes or turning
angle bytes depending on the command. The two bytes are concatenated to form a
16-bit number representing the distance or the turning angle. Those numbers are
used in conjunction with the data polled from the sonar and the compass to find
out if movement if feasible. If the XSV-300 board decides that movement is
feasible, the output pins to the remote control are asserted to move Etank in
the specified direction. A diagram of the control interface can be seen in
figure 2.
Moving the tank involves asserting the following pins
depending on the direction of movement. Moving forward will set pins 2 and 3
high. Moving backward will set pins 0 and 1 high. Pivot turning to the left will
set the pins 0 and 3 high. Pivot turning to the right will set pins 1 and 2
high. The pins that are not set high will carry the value zero (ground). The
pins that are set high will open the corresponding channels on the remote
control unit creating a conducting path and the tank will move as a result in
the indicated direction.
Figure
2: The
interface between the PC, XSV-300 and the Remote Control Unit
We opened the remote control unit to study its
functionality. There are two levers on the remote control unit. Each of them
controls one glider on the tank. We needed to understand how the tank moves
using the levers. Four movement channels in the remote control unit can be seen
in figure 3. The right lever controls two of them and the left lever controls
the other two. When a lever is moved, it presses a conductive material against
another conductive piece to create a path for electricity. By shorting a
channel, the tank moves. Moving one lever will cause the tank to turn by moving
one glider and keeping the other glider stationary. For the purpose of our
project, we need to move the tank forward and backward and also pivot turn the
tank to the right and to the left. Each of these movements needs two channels to
be shortened at the same time. This can be thought of as pressing two levers at
the same time to move the tank.
Figure
3: The
remote control unit movement channels
We use the XSV-300 board to communicate with the remote
control and thus move the tank. We use four XSV-300 board pins to drive the four
channels on the remote control unit. The output on the pins is either 3.3V or
0V. However, the remote control unit uses a 9V battery. If we want to move the
tank, we will need to short a channel. We want to control the channel using an
output pin of the XSV-300 board. Our goal is to short the channel using the 3.3V
output signal of a pin on the XSV-300 board. To do this, we need an NPN
transistor. The collector of the transistor is connected to the high voltage end
of the channel. The emitter of the transistor is connected to the low voltage
(ground) end of the channel. The pin output is connected to the transistor’s
gate. Now, the transistor works exactly like a switch that is activated by the
pin of the XSV-300 board as can be seen in figure 4. We installed four NPN
transistors to the four channels of the remote control unit. Also, we connected
the gates of these four transistors to four different pins on the XSV-300 board.
These four pins are the XSV-300 board’s outputs that are going to drive the
tank. For example an output of 1001 means that pins 0 and 3 are high and pins 1
and 2 are low. This output would pivot turn the tank to the left.
Figure
4: NPN
Transistor as a switch to activate and deactivate the channel
The PC is connected to the XSV-300 board using the parallel
port. We needed to study how the parallel port works in order to send commands
to the XSV-300 board. The board receives three bytes from the PC. The first
represents the direction of movement (forward, backward, right or left); the
second and third bytes are concatenated to produce a 16-bit number that
represents distance (if commanded to move forward or backward) or turning angle
(if commanded to move to the right or to the left). The board decides if
movement is possible depending on the inputs from the sonar and the compass over
the remote component. The XSV-300 board moves the tank accordingly. An example
of when the tank would fail to move is if you instruct it to move forward 50
units while the distance between Etank and the border is only 20 units. The user
would be notified by asserting one of the input pins of the parallel port. The
user interface expects a success pin or a fail pin to be asserted.
The eight data pins of the PC parallel port are connected
to some selected XSV-300 board pins on the left expansion pins. Also, the busy
pin and write enable pin of the parallel port are connected to the XSV-300
board’s left expansion pins. Figure 2 shows the required pins for the parallel
port and the XSV-300 board. The success and fail pins are not implemented in the
design yet because they are under a testing phase.
We encoded the four different movements (forward, backward,
right and left) into binary signals. For example, if we want to move the tank
forward, we send a value on the parallel port that we chose to represent forward
such as 0x01. A Verilog module on the XSV-300 board, which we programmed,
interprets this value. When it sees a 0x01 on the parallel port, it knows that
the movement direction is forward. It expects two more bytes to arrive on the
parallel port. Those two bytes represent the 16-bits distance variable. The
three bytes represented by the direction of movement and the two distance bytes
are stored in registers.
Sending one byte from the PC to the XSV-300 is done as
follows. The user interface asserts the write enable pin notifying the XSV-300
board that data is ready to be sent to the board. The board asserts a busy
signal as a result. Once the PC notices that the busy signal is asserted, it
sends the data byte over the parallel port to the XSV-300 board. Once the
XSV-300 board receives the data, it sets the busy signal low. The PC notices
that the busy signal have gone low and as a result it is able to send the next
byte of data. Once the XSV-300 board receives the third byte, it would have a
complete instruction consisting of a direction byte and two bytes representing
distance or turning angle.
If the XSV-300 board decided that moving the tank is feasible, it pulls the signal on two specific pins to 3.3V. These pins are the ones connected to the two channels that are responsible for moving the tank forward. Namely the two lower channels on the remote control unit. We used a C library called DLPortIO to interface with the parallel port. We were able to send data to the parallel port from the PC and receive it at the XSV-300 board using the handshaking methods provided by that library. The tank will move in the direction provided until it reaches its destination. Reaching destination depends on comparing the current position polled from the sonar and the compass to the given command. When the destination is reached the tank will stop and the XSV-300 board will signal the user interface program with the success or failure of the command.
The XSV-300 board is the central component that takes input
from both the remote component and the PC to control the movement of Etank. Most
of the logic in the XSV-300 board is done in Verilog and is done using the
Xilinx Foundation Series. There are two main modules other than the parallel
port module mentioned above. They are responsible for communicating with the
serial port, where the packets from the RF transceiver arrive. We call the first
module, Counter. This module is responsible for capturing data from the serial
interface. We called the second module, Decoder and it is responsible for
decoding the data from the serial interface and control the tank.
The PC communicates with the XSV-300 board through a PC
parallel interface and the remote component communications with the XSV-300
board through a serial interface. Although there are parallel and serial
ports built in the XSV-300 board, we do not use them during normal operation.
The parallel port is used initially to program the FPGA on the XSV-300 board.
Instead of using these built in ports, we use the left expansion pins on the
board. The reason for this is that using the parallel and serial ports requires
reprogramming the CPLD chip on the XSV-300 board. Any errors in programming the
chip and the XSV-300 board would be permanently damaged. We do not think this
risk is worth taking since the expansion headers work without any complications.
The actual connections to the XSV-300 board are as follows:
Figure 5: XSV-300 Serial Interface
Pin 2 of the RF serial port, which is the receive data pin, is connected to PIN A0 on the XSV-300 port. All data from the remote component is sent through this one line. Pin 5 of the serial port is connected to GND of the XSV-300 board. The XSV-300 board controls the movement of the tank through pins D0-D3. Pins D0-D3 connect to the remote control setup, which we discussed in the remote control section of this report. Asserting these pins will cause the movements as shown in figure 5.
Logical
description of XSV-300 board’s operation
With data from the PC and the remote component, the XSV-300
board can perform the necessary calculations for controlling the tank. The
XSV-300 board continuously receives information from the remote component
updating the tank’s current direction and location. However, when there is no
command to execute, the XSV-300 ignores packets of data from the remote
component. When there is a command to execute, the XSV-300 board decodes packets
of data from the remote component. The format of the data is described in the RF
Transceiver section. Whenever the PC sends a new command, the XSV-300 board
captures the command and asserts a signal to indicate to the PC that it is busy
processing. Therefore, the PC is not allowed to send multiple commands at once
and our tank is either only turns or moves linearly, but not both at the same
time.
When the XSV-300 board receives a command to turn left or
right, the XSV-300 board will take the first data packet received form the
compass after receiving the command and save this information as the tank’s
initial direction. The XSV-300 board can distinguish whether packets are from
the compass or sonar based on the device ID sent along with each data packet.
The initial direction is used to calculate the destination direction, which is
the direction the tank must be at to satisfy the command.
An example will help clarifying the operation described
above. If the command were to turn left 30 degrees and the initial direction of
the tank is 40 degrees, the destination direction is 10 degrees. The XSV will
then assert Pins D1, to make the left wheel go backwards, and D3, to make the
right wheel move forward, which rotates the tank counterclockwise. The XSV-300
board will continue to assert these pins until it receives a packet from the
compass indicating that the tank is at 10 degrees or less. Once the final
position has been reached, the XSV-300 board asserts a pin to indicate to the PC
that the destination has been reached and that it may send another instruction.
The logic for moving forward or backward is similar to
turning left or right. In this case, only packets from the sonar will be used,
but the decoding and controlling process are similar. The XSV-300 saves the
initial position of the tank and determines if the distance is within reason. If
the initial distance were 1000 mm and it receives a command to go forward 400
mm, the XSV first determines that it needs to be 600 mm from the object before
stopping.
We will allow a tolerance in accuracy of the final
position. The compass has a margin
of error of +/- 3 degrees. The XSV
will get a packet of data from the RF every ½ second and in that time.
Depending on how slow we will make the tank move, we will allow +/- 5
degrees of error for time it takes for packet updates.
Therefore, for direction, we aim for a tolerance of +/- 8 degrees.
The sonar has a margin of error of 2% over the distance it returns. Since we are using a 20’x20’ enclosed square, the maximum distance is a little over 28 feet. Two percent of this is half a foot or 153 millimeters. Every update from the sonar takes ½ second. In that time, depending on how slow we make the tank, may travel another ½ foot. Therefore, we will allow a tolerance in distance of 1 feet or about 305 millimeters.
Implementation
Description of XSV operation
Internally, the XSV-300 board’s logic is comprised of two
main logical blocks, called Counter and Decoder, that operate in states. Counter
is responsible for decoding data from the RF serial interface. It takes the
serial stream and converts it to a byte format. Once it has one byte of
data, it is sent to the second logic block. Decoder is responsible for
interpreting the data. The interpreting of data is done in states. Data packets
from the RF are eight byte packets. More information about the data layout
can be found in the RF transceiver section.
The Counter captures data for the serial port as follows.
The input serial data is sent through two D-flip flops to minimize
meta-stability before going into the Counter module. Since the XSV-300 board is
running at 25MHz and the serial interface is running at 19200 Hz, the XSV-300
board needs to know when to sample data from the serial input. Figure 6 will
help illustrate what we mean.
Figure
6: Sampling serial data
The RS-232 format uses a start bit to indicate the start of
a byte of data. This corresponds to point 1 in figure 6 above. Once the Counter
module sees this start bit, it starts a count, call this count1, and counts
until point 2. At point 2, another counter will start, call this count2, and
counts to point 3. At point 3, data is sampled. We do not want to capture
data at point 2 when the serial signal transitions.
The values the two counters should count to are determined
as follows:
Speed of XSV (25MHz)
Count1 =
---------------------------------------------- = 1302
Speed of Serial Input (19200Hz)
Count1
Count2 =
---------------- = 651
2
The Decoder module is responsible for accepting data from
the PC and Counter module and performing the necessary calculations for
controlling the tank to the correct location.
This module is implemented in states and the function of
each state is described below.
State 0:
This is when the To/From byte of the RF data packet is
decoded. This byte is hard-coded to 0x23. Therefore, the RF module used for
transmitting must be set to 3 and the module for receiving must be set to 2.
This byte will also be used to distinguish the start of an RF data packet.
State 1:
This is when the Packet ID byte of the RF message is
received. It is not used in our design.
State 2:
This is when the Size byte of the RF message is received.
This is only used for debugging to verify that the size of transmission is
always 5, one byte for the Start of Transmission (SOT), one for the device ID,
two for data, and one for End of Transmission (EOT).
State 3:
This is when the SOT byte of the RF message is received.
Not used by our design.
State 4:
Captures the Device ID of the device that sent the packet.
This determines whether the data in this packet is from the sonar or from the
compass.
State 5:
The data portion of the message is comprised of the two
bytes captured in this state. These two bytes contain our tank’s current
position. This data is captured in this state. In this state, we capture the
initial position of Etank.
State 6:
This is when the SOT byte of the RF message is received.
Not used by our design.
State 7:
This state is responsible for comparing the current
position of the tank to the destination position. Controlling of the tank is
also done in this state.
In this section, we introduce each of the modules that are used to build the remote component of Etank.
The Electronic Compass Vector 2X is a 2-axis magnetometer
that measures the magnetic field in a single plane. To calculate heading
accurately, the compass needs to be kept level. The compass is accurate
within 2° and requires a 5V power supply. It has a RS232 synchronous
serial port to communicate with the host and three output formats: binary, BCD
and raw. We are only interested in the binary format since it is easy to
interpret on the machine level. Therefore we set the compass to operate in
binary mode. In binary mode, the compass outputs 7 zeros first followed by
9 measurement bits. The following is an example of a binary output:
0000000 |
1 |
0 1 0 1 1 0 1 |
1 |
Header |
MSB |
|
LSB |
That output represents the following values:
256 |
128 64 32 16 8 4 2 |
1 |
MSB |
|
LSB |
Finally, the result of the measurement is as follow:
256+64+16+8+2+1 = 347
The compass has two operation modes: master mode and slave
mode. While in master mode, the compass generates its own clock.
While in slave mode, we need to provide the clock for the device (maximum 1MHz).
We chose to operate the compass in slave mode. The main reason for doing
this is that we like to run all the components of the remote side under the same
clock rate in order to facilitate their intra-communication.
Also, the compass can output data continuously or upon request
(when it is polled). We preferred to poll data when needed rather than
receiving it continuously. This simplifies our system design by removing
the complication due to unwanted inputs to the processor.
To operate the compass, we connected it to the PIC
processor and the power supply as is shown in figure 7.
Figure
7: Pin
connection between the compass and the PIC processor
The PIC processor is responsible for polling the data out of
the compass by driving the following signals: SCLK, SS, P/C, and RESET. The PIC
has to provide these signals considering the timing manner shown in figure 8.
Figure
8: Compass timing manner
When the compass calculates the heading, it will set the EOC (End Of Calculation) to high. This signals the processor that the data is ready. Then the processor outputs the clock to the SCLK pin and starts reading the data from the SDO pin.
The Virtual Wire RF transceiver provides a wireless link
between the remote component and the central component. The wireless link
supports two frequencies, 433.92 MHz and 916.5MHz (default). It also has a RS232
serial communication port to communicate with its host. It requires a power
supply in the range of 2.7V to 3.3V with a pick current of up to 20mA. The data
communication is supported by a link-layer, which assures an error free
transmission. Table 2 shows the format of the input and the output of the
RF transceiver.
Table2: RF message format.
Packet |
To/From
(4 bits/ 4 bits) |
Packet ID
(1 byte) |
Size
(1 byte) |
SOT
(1 byte) |
Message
(32 byte) |
EOT
(1 byte) |
Range |
1-15 | 1-7 | 1-32 | N/A | 1-32 | N/A |
Therefore, we need to encode the data before sending it to
the transceiver and decode it after receiving the data. Using the RF we can send
a packet with a maximum message size of 32 bytes. Considering the number of
bytes that the PIC receives from the compass (2 bytes) and the sonar (2 bytes),
one packet is enough for transmitting that information from the remote component
to the central component.
The communication port of the RF runs on 19200 bps baud
rate and will be connected to PIC processor as shown in figure 9.
Figure
9: Communicating
the RF transceiver with the PIC processor
As shown in figure 9, the communication between the RF and the PIC processor is very simple. The PIC encodes data in the format that RF utilizes and sends it to the RF through the pin 17.
Sonar Ranging Kit includes a Polaroid 6500 ranging module, an output interface cable, and a Polaroid electrostatic transducer. The tool is able to measure distance of objects between 6 inches to 35 feet apart, which has the accuracy within +/- 1% of the reading over the entire range. We refer you to the Polaroid 6500 Ranging Module documentation in the reference section for more detailed technical information on this module.
In our design, we plan to build a rectangular border as Etank’s world. Therefore, this border will be the only object that the sonar module will project on to measure the distance Etank moves. As a result, we will operate the sonar module in single-echo mode. Figure 10 shows the interaction of internal signals in the sonar ranging module.
Figure
10: An
example of single-echo-mode cycle
In general, the transducer transmits sound waves when we
trigger the input signal of the sonar module. The sound waves consist of 16
pulses at frequency of 49.4 KHz. Normally, the sonar module also produces an
internal blanking signal to disable the transducer for a certain amount of time
while waiting for the echo to get back in order to avoid receiving false echoes.
The default blanking time is 2.38 ms in the 6500 ranging module. If we allow
this internal blanking to operate, the minimum distance the module can detect is
approximately 17 inches. However, we can use the blank inhibit signal (BINH) in
figure 10, to manipulate this internal blanking signal to reduce the minimum
detection distance to as small as 6 inches. Therefore, after triggering the
input signal for 0.9 ms, we assert the blanking inhibit signal to high. The
module then asserts the echo output to be high after the sound wave is reflected
off of the border and back to the transducer. We need to measure the time from
when we trigger the input to when we get the echo back. This time is used to
calculate the distance from Etank to the border. In addition, we have to
re-trigger the input signal after receiving each echo output in order to perform
another measurement. Therefore, we need a processor to trigger the input signal
and to measure the transmitted time. This processor also calculates the distance
of the Etank from the border and then packs this information into an RF message,
which is sent later to RF.
After we studied the Micro-controller, the XS40 board and the PIC processor, we found it convenient to build communication between the sonar ranging module and the PIC processor since one member of our group is already familiar with the PIC processor. Figure 11 shows the communication interface between sonar ranging module and PIC.
Figure
11: Sonar ranging module interface with PIC
We used the transducer, which is connected to the Polaroid
6500 ranging module, to transmit sound waves and receive reflections for
measuring the transmission time that we later use to calculate the distance from
Etank to the border. Since the minimum distance that the sonar measures is 6
inches, we will mount the transducer of the sonar module at 6 inches from the
head of Etank. When we calculate the distance from the tank to the border, we
subtract 6 inches to get the actual distance. In addition, the ranging module
has nine I/O lines. We used a cable to connect those lines to a pin socket.
We also found out that echo output is an open collector
transistor output; therefore, we used a 4.7KW to pull up the voltage between VCC
and the output. In addition, we used a capacitor (~ 500pF) to connect across the
power lines in order to avoid voltage drops as the capacitor drains, which can
cause damage to the PIC processor and other circuitry that share the same power
supply.
We connected pin 4 (INIT), pin 7 (ECHO), and pin 8 (BINH) of the sonar to pin 24, pin 12 and pin 26 on the PIC, respectively. In the PIC, pin 24 is just a regular output pin. Pin 12 is an input pin that is associated with an internal timer. We will program the PIC to send a high signal on pin 25 to trigger the INIT input on the sonar module for every 250 ms. At the same time triggering the INIT input, the PIC starts its internal timer associated with pin 12. The pin 26 of the PIC, which is set high 0.9 ms after we triggered the INIT input, is used to block the sonar from premature reading the sound reflection. When the echo signal arrives at the sonar module (ECHO goes high), it sends an interrupt to the pin 12 of PIC. We will then use this internal timer to calculate the distance from Etank to the border.
The PIC processor is the central part of the remote component.
It gathers data from the peripheral devices and sends them to the central
component. The PIC requires a 5V power supply and a clock generator (we used a
20 MHz oscillator). Figure 12 below shows how to connect the oscillator and
power supply to the processor.
Figure
12: The connection between the PIC processor and the oscillator
The
PIC has 3 communication ports, which can be used to drive/communicate with
several devices. The details of the PIC processor connection to all peripheral
devices are discussed in sections related to each device.
Table 3 shows the parts that we needed to accomplish this project.
Table 3. Project parts
Part
Name |
Manufacturer |
Part
# |
Supplier |
Description |
Cost |
Tank |
Hobby Zone |
2050 |
CSE lab |
Move forward and backward; Pivot turn left and
right. |
$99.95 |
Compass |
Precision Navigation |
V2X |
CSE lab |
Output the magnetic field in binary format |
$49.95 |
Virtual Wire Development Kit |
RF Monolithic |
DR1004-DK |
CSE lab |
Transfers messages |
No |
Sonar Ranging Kit |
Polaroid |
R11-6500 |
CSE lab |
Measure distances |
No |
XSV-300 Board |
Xilinx |
XSV300 |
CSE lab |
Process data and control logic movement |
No |
PIC |
Micro-Chip |
PIC16F876 |
CSE lab |
Process information |
No |
Oscillator |
FOX |
F1100E |
CSE lab |
20 MHz |
No |
Transistors |
Radio Shack |
276-1617 |
Self-Supl. |
NPN-type switching transistors |
$2.69 |
Resistors |
Unknown |
Unknown |
CSE lab |
2 of 2 KW
and 1 of 2.7 KW |
No |
Capacitor |
Unknown |
Unknown |
CSE lab |
Approximate 500pF |
No |
PC |
Dell |
Unknown |
CSE lab |
Build user interface |
No |
Batteries |
Unknown |
Unknown |
CSE lab |
Power supply for all components |
No |
The RF serial interface operates at 19,200Hz and we use
counters to keep track of when to sample data. When we determine the values for
the counters, they come out to be fractional numbers. Since we only need to
capture eight bits of data for each byte, this fractional error will only
propagate through eight times. The count values we determined were 1302 and 651,
which are much greater than our error. Therefore, the data sampled will always
be the correct data byte except for the very small chance that meta-stability
manages to corrupt our two flip-flops where serial data comes into the XSV-300
board.
Our current design in the Xilinx foundation series
indicates that we can run our design above 30Mhz, which is above the 25MHz that
we are running the XSV board at.
The power consumption requirements are satisfied as
follows. The PIC processor will be powered with a 6V battery. This battery
is configured to a voltage divider circuit that will bring the voltage down to
5V. This 5V source will also be used to power the sonar, compass, and
oscillator. The RF and XSV-300 board have their own power supplies.
The operating frequencies are satisfied as follows. Since
the PIC processor has to communicate with several peripheral devices operating
at different speeds, we set the frequency of the PIC to match the speed of the
fastest device, which was the RF. To communicate with slower devices, such
as the compass, we use a clock divider to obtain the required frequency by those
devices. The operating frequency of the sonar is not critical since we are only
interested in the amount of time between when INIT signal goes high to when the
ECHO signal goes high, rather than sampling data bits. The clock frequency
of the XSV-300 board is set internally with it’s own clock.
The baud rate requirements will be met as follows. The RF
communication port sends and receives data at 19200 bits/sec. The PIC has
several communication ports. Each port has eight pins, which can be
individually configured as an input or output at a specific baud rate. We
configured port C’s pins 6 and 7, which is the built in UART, to match the RF
speed requirement. We configured port C’s pin 3 and 4 to match the compass
speed requirement. The sonar is connected to port C’s pin 12 and port B’s
pin 4. The speeds of these two pins are not critical for the same reason
the operating frequency of the sonar is not important. The parallel port
interfaces the PC with the XSV-300 board. It interfaces the software on the PC
with the hardware on the XSV-300 board. For that, we need to establish a
handshaking protocol to allow the PC and the XSV-300 to synchronize the PC’s
output and the XSV-300 board’s input.
The PIC has up to 8KB of program memory. Due to
extensive hardware support provided by the PIC, such as interrupt driven pins,
built in timers, and several communication ports, we predict the amount of code
necessary to drive the peripheral devices to be not more than 8KB. Currently,
the PIC is programmed to interface with the RF and the size of code is less than
1KB. The code for interfacing with the compass is very similar to that for
RF. Communicating with the sonar is even simpler than that of the compass.
Therefore, the total size of the code will not be greater than 8KB.
The space available on the FPGA of the XSV-300 is huge comparing to what is needed for this project. Currently, we have a working module that moves the tank in all directions and that module does not exceed 1% of the space available on the FPGA. We will need to write modules to process the inputs from the compass and the sonar, determine if the command given is feasible and send the appropriate signals to the remote control unit. These modules are highly unlikely to exceed the capacity of the FPGA.
For testing the remote component devices, we connect the
PIC to the Hyper Terminal as is shown in figure 13.
Figure
13: The connection between the Hyper Terminal and PIC
We also connect the PIC processor separately to the sonar
or the compass as is shown in the corresponding design sections. Finally, we run
the device driver code of each device on the PIC, and output the results of
their measurements to the Hyper Terminal. In the following subsections we have
provided more details on the testing of each device.
We connected the INIT input signal and the ECHO output
signal from the compass to channel 1 and channel 2 on the oscilloscope to
capture the transmit time of the sound wave in order to compare them with the
output from the Hyper Terminal program. We drew 5.0 V from the power supply to
power up both the PIC processor and the compass module. Watching from the
oscilloscope, we saw that the ECHO output signal went high after the INIT input
signal. The distance we got back from the Hyper Terminal program agreed
with the time value we measured from the oscilloscope. The compass worked fine;
however, the error margin seemed a little bit more than we expected. Right
now, we got the its minimum detection distance is almost 7 inches and the
accuracy is within +/- 2% of the reading over the entire range.
After connecting the power supply (5.0 V) both the PIC
processor and the compass module, we started receiving data from the compass. As
we turned the compass around, the output on the Hyper Terminal was changing
between 0 to 359 accordingly. This was totally what we expected. We also
changed the rate of data polling and realized that the fastest rate is about
200ms.
The following sections present how we go about testing of
the central component.
XSV-300
Serial Interface Testing
There are several methods for testing that our module in
the XSV-300 can properly decode information from the serial port. We test the
module that is responsible for decoding bytes from the RF serial port in two
ways. First, to test that it can properly decode one byte of data, the Hyper
Terminal is used to send one byte of data a time. An LED segment on the XSV-300
board is configured to light up when the byte received is the same as what is
expected. We did this using different characters on the Hyper Terminal. To
ensure that this module can decode a stream of bytes, we used a program that
came with the RF transceiver kit to send actual packets of data. Since we use
the RF to send eight bytes of data at a time in our project, we configured the
XSV-300 board so that eight different LEDs would light up, one for each byte
that matches what we expect. This phase is complete and working.
XSV-300
Parallel Interface Testing
For testing the parallel port interface we need the PPortC
program, the XSV-300 board and the logic analyzer. We connect the PC to the
XSV-300 board using the parallel cable and we connect the parallel cable to the
XSV-300 board using the left expansion pins. We use the right expansion pins to
output the data coming from the parallel port including the write enable signal.
We also route a copy of the busy signal to one of the pins in the right
expansion pins. At the end, we end up with three data outputs to verify and
validate. They are the busy signal, the write enable and the 8-bit data bus.
Those XSV-300 board outputs are connected to the logic analyzer to view the wave
forms. We set our trigger to be the assertion of the write enable signal from
the PC. We send a byte using PPortC and the logic analyzer shows how the signals
propagate and it shows how the handshaking between the XSV-300 board and the PC
progresses. In this test case, we proved the logic analyzer to be a very useful
tool.
The module in the XSV-300 responsible for controlling the
tank is tested in two parts. First, it is tested for its ability to
interpret bytes that it receives. Second, it is tested for its ability to
control the tank.
Testing that this module for decoding bytes is similar to
testing of the first module. Since this module is implemented as states,
we make sure that is goes through all states and compare the data is receive at
each state to what is expected. If data matches with what is expected, a
LED is made to light up on the XSV-300 board.
Once we know that it is decoding bytes correctly, it needs to be tested for whether it performs calculation correctly and controls the tank correctly. For this test, the remote component is used to stream a data to the XSV-300 as it would during normal operation. A command is hard-coded into the XSV-300 board to simulate a real command expect from a PC. The command is triggered using a button on the XSV-300 board to indicate a new command is being sent. An oscilloscope is connected to the output pins of the XSV-300 board, pins D0-D1. These pins connect to the remote control unit. When our button is pressed, we expect controls pins to go high to control the tank depending on what the command is. We can then manually move our compass and sonar to simulate the movement of the tank. The logic is correct if the pins go low when the compass or sonar reached the expected position.
In the initial design package, two methods of decoding data
from the RF serial interface were discussed. One was to use a PIC
processor to capture one byte of data at a time and have it sent off to the
XSV-300 board. The other was to have the XSV-300 board decode the serial stream
of data. We have implemented the second option of decoding the data using the
XSV-300 board. This decreases the number of components needed to implement our
entire design, but it increases the logic needed on the XSV-300 board.
However, the amount of extra logic is not significant and we do not feel it
merits an entire processor for the job.
One comment made by our review team is what will happen in
the case obstacles are in the path of our tank. Our current intention is to have
our tank run in a confined area of with no obstacles.
Another comment about tank movement is that the movement of
the tank will overshoot its desired destination. This is a valid comment
and we address this by allowing a tolerance in the accuracy of the final
destination. For direction, we aim for a tolerance of +/- 3 degrees. For
distance, we aim for a tolerance of +/- 10 millimeters. However, this tolerance
is highly dependent of how much we are can actually slow the movement of the
tank, which is undetermined at this point. Therefore, we may have to increase
our tolerances. The suggestion for controlling the tank in short burst may
be a good idea if we cannot slow the tank down sufficiently with smooth motion.
The reviewers were concerned that we would read the data
off the parallel port and depend on the data being available on the parallel
port until another command is provided. We depended on that fact when we
designed a testing module. However, when we started reading more than one byte
to form an instruction, we stored each byte into a register. The prototype will
work using PPortC handshaking facility and thus the data will be registered at
the XSV-300 board’s side.
We will use 4 D-size batteries to power the remote
components. This is addressed in the Remote Component section above.
We have two RF communication units. One is the tank’s
remote control unit and the second is the RF transceiver used to send the
compass and the sonar data from the remote component to the central component.
The reason for having two RF units is for simplicity. Trying to understand how
the tank’s remote control packages the data into its own RF packet and trying
to understand how the tank deciphers the packet is a challenging issue. The
point of using a tank was the simplicity it provides. We do not need to worry
about how to control movements because the manufacturer provides the interface
and the platform for us. Also, trying to understand how remote control internals
work is well beyond the scope of this class. For that reason, we chosen not to
disturb that interface and treat it as a black box module.
Compass Polling and
Over Steering
The reviewers expressed a concern about how fast the tank
turns. That is a valid concern because the compass polls data at a maximum rate
of 5Hz. That means that the compass will be able to provide data every 200ms.
The tank moves and turns fast enough to over run these rates. That is dangerous
because the tank may poll the next heading angle after it has passed the
destination angle. That will cause inaccurate turning. For that, we are trying
to slow the movement of the tank by experimenting different methods. One is to
send pulses rather than a stream of signals from the remote control unit to the
tank. Adding capacitors can smooth the pulse abrupt boundaries. However, this
issue is still in a testing phase.
The existing remote control’s frequency is 49.86MHz. That
was not specified in the previous design package. That frequency does not
interfere with the frequency of the RF transceiver and it is added to the
requirements of the Etank project.
The movement of Etank is specified more concretely in the
Remote Control and the Parallel Port sections. Basically, an instruction by the
user consists of three bytes that are sent from the PC to the XSV-300 board
using the parallel port using handshaking methods provided by the PPortC
program. These bytes are registered in the XSV-300 board and are processed
against the polled data from the sonar and compass. Once the XSV-300 board
determines that moving the tank is feasible, the tank moves and the data from
the compass and sonar are periodically checked against the destination until
they are equal with some error tolerance. Once the destination is reached, the
tank stops and the user is signaled with success of the instruction. If the tank
faces an unexpected obstacle and it changes direction mistakenly, the user will
be signaled with the failure of the instruction.
We will take the reviewers recommendation and try to design
a 20’ by 20’ border for running Etank. Our team is trying to decide where to
place such an environment and about the logistics of testing Etank in that
environment. The main purpose of having an environment is for the sonar to be
able to determine the distance between the tank and the border. For testing
purposes, we can use a wall to test the forward movement of Etank. Testing the
compass is independent of the environment.
Adding a pen to the tank will require working with another
motor component to lower or higher the pen. That is an expansion feature that we
will add only if time allow us.
XSV Board V1.0 Manual (2000)
XESS Corporation
Polaroid 6500 Ranging Module (2001)
http://www.acroname.com/robotics/parts/R11-6500.html
Implementing Ultrasonic Ranging (1997) http://www.microchip.com/download/appnote/category/16cxx/00597b.pdf
PIC16F876 Device
(2001)
http://www.microchip.com/10/lit/pline/picmicro/families/16f87x/devices/16f876/index.htm
Vector 2X and 2GX Electronic Compass Modules (1998)
http://www.wirz.com/products/0167/files/vector2x_manual.pdf
7400 NAND converter:
http://www.falstaff.demon.co.uk/7400.html
Simple ASCII Table (2001)
http://members.tripod.com/~plangford/ascii.html
The RS232 Standard: A Tutorial with Signal Names and
Definitions (1997)
http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html
Use of a PC
Printer Port for Control and Data Acquisition (1996)
http://et.nmsu.edu/~etti/fall96/computer/printer/printer.ht