Introduction
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.
Requirements
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 Oscillator …………….
5V |
|
Operating Frequency 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 XSV to Tank’s RF ….. 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.
Design
We divided the control system of Etank into two separate components, the remote component and the central component, as shown in figure 1 below.
Figure 1:
The
main components of Etank’s 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 sound
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.
PC
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.
Remote Control
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
XSV-300 parallel port
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.
XSV-300
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
Counter Module
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
Decoder Module
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.
Remote Component
In this section, we introduce each of the modules that are used to build the remote component of Etank.
Electronic Compass V2X
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.
RF Transceiver
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.
|
Packet Format |
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 Module
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.
PIC Processor
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.
Last Minute Design Additions
The only last minute design change was a modification to the tank to slow it down. We replaced the existing drive motors with slower and higher torque motors. This slowed the tank sufficiently to meet our movement tolerances. The motors still operate using the tank’s existing battery pack, so no modifications were necessary to power the new motors.
Table 3 shows the parts that we needed to accomplish this project.
|
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 |
Analysis
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.
Component Testing
After setting up the circuit for each device, we performed a component testing. 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.
Testing the Sonar
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.
Testing the compass
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.
XSV Tank Controlling Testing
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.
System Testing
After integrating the remote and central component together we performed a overall system test to assure the correct performance of the Etank.
We divided the system testing of the Etank into the distance testing and the rotation testing. To do so, we gathered separate data before moving the Etank and after moving it. Then we compared the result (distance or heading difference) with the expected value to gage the performance.
Distance:
To verify that Etank forward and backward moves, we sent series of commends to it, and measured the results.
Figure 14 below shows the result of issuing a “move forward 300 mm” command.
Figure 14: The distance from the tank to the border before and after moving forward 300 mm
As is shown above, the
original distance of the tank to a wall is 0x05CB mm, and after the command the
new distance is 0x04B3 mm. The
difference between the two is 0x0118 mm, which is 280 mm. The 20 mm difference
is with in the marginal error and therefore accepted.
Figure 15 below shows the result of issuing a “move backward 300 mm” command.
Figure 15: The distance from the tank
to the border before and after moving backward 300 mm
As is shown above, the original distance of the tank to a wall is 0x02F4 mm, and after the command the distance is 0x0406 mm. The difference between the two is 0x0112 mm, which is 274 mm. The 26 mm difference is with in the marginal error and therefore accepted.
Figure 16 below shows the result of issuing a “move forward 600 mm” command.
Figure 16: The distance from the tank to the border before and after moving forward 600 mm
As is shown above, the original distance of the tank to a wall is 0x0685 mm, and after the command the distance is 0x0440 mm. The difference between the two is 0x0245 mm, which is 581 mm. The 19 mm difference is with in the marginal error and therefore accepted.
Figure 17 below shows the result of issuing a “move backward
600 mm” command.
Figure 17: The distance from the tank to the border before and after moving backward 600 mm
As is shown above, the original distance of the tank to a wall is 0x0406 mm, and after the command the distance is 0x0656 mm. The difference between the two is 0x0250 mm, which is 592 mm. The 8 mm difference is with in the marginal error and therefore accepted.
Rotation angle:
To verify the Etank rotation angle, we sent series of commends to it, and measured the results.
Figure 18 below shows the result of issuing a “turning right
30 degree” command.
Figure 18: The angle of the tank before and after turning right 30 degree
As is shown above, the original heading of the tank is 0x012F degree, and after the command the new heading is 0x0157 degree. The difference between the headings is 0x0028 degree, which is 40 degree in decimal. The 10 degree difference is more than the 5 degree tolerance which was included in the logic design. However, the compass is very sensitive to magnetic field, and since we are running it inside the lab with a lot of devices producing the magnetic field, we do not expect an exact turning angle.
Figure 19 below shows the result of issuing a “turning right 60 degree” command
Figure 19: The angle of the tank before and after turning right 60 degree
As is shown above, the original heading of the tank is 0x0137 degree, and after the command the new heading is 0x0011 degree. Since we have turned the tank 60 degree clockwise, and since its initial heading is 0x0137 degree (311 degree), the tank will pass the 0x0168 degree (360 degree) and its heading will reset to zero. Therefore, to calculate the turning angle we do the following:
(0x0168 - 0x0137) + 0x0011 = 0x0042
Therefore, the tank has turned 0x0042 degree, which is 66 degree in decimal. The 6 degree difference is very close to the 5 degree tolerance which was included in the logic design. In result we can say that the tank rotation is in good proximity of the intended angle.
Reviewer comments from Initial Report
Serial method
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.
Control Implementation
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.
Parallel Port Communication
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.
Power Consumption
We will use 4 D-size batteries to power the remote components. This is addressed in the Remote Component section above.
Communication Component
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.
RF Frequencies
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.
Etank’s Movement
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.
Environment
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.
Drawing
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.
Reviewer Comments from Final Report
Sonar Miscalculations
Our review team brought up an important issue about the accuracy of the sonar readings.
Our tank is enclosed in a 20’ x 20’, or 6 meters x 6 meters box. This means that the longest distance the sonar will have to deal with is approximately 8 meters, since the diagonal of the square is approximately 8.5 meters and the tank is 0.48 meter in length. A sound wave traveling 8 meters and back takes about 47 milliseconds. During this time, our tank can travel 1.7 millimeters. A greater error comes from the accuracy of the sonar, which is 2% over the entire range. At 8 meters, 2% error is 160 millimeters. Therefore, net error is about 162 millimeters, which is within our specification of 305 millimeters.
Going in Reverse
Our review team was concerned with backward movement. Since there is a sonar in the front of the tank, we can prevent it from colliding with a wall by checking its distance from a wall. There is no sonar in the rear to prevent backing into a wall when going in reverse. Our review team suggested that we keep track of the tanks location in its environment. Knowing where the tank is within its environment would allow us to not execute any commands that would cause it to impact a wall. We think this is a good idea and have it implemented this feature in our software application.
Turning Issues
Our reviewers had concern about turning when the tank is too close to the wall. If the tank is too close to the wall, then the tank cannot turn. A solution provided by our reviewers was to provide a buffer zone inside the environment that our tank would be large enough to always give our tank enough room to turn in. We decided to implement this inside the user application. The buffer zone we chose was 255 millimeters. This is enough room for our tank to turn within.
Slowing Down
Slowing down our tanks movement is another concern brought up by our review team. If the tank were to move too fast, we would not be able to meet our tolerances. We slowed the tank’s movement by replacing the existing motors with slower servos. We measure the speed of the tank to be 36 millimeters/second for linear motion 9 degrees/second for turning. A packet of data is sent from the RF every 250 milliseconds, alternating between the compass and sonar. As mentioned above, the speed of these servos are sufficient to meet our tolerances of +/- 305 millimeters for forward and backward movement. In half a second, the tank can turn about 4.5 degrees. The compass has an error of +/- 3 degrees. Total error for turning is 7.5 degrees. This is just within our tolerance for turning.
References
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.html