Our project, Etank, is to move a remote control tank using a program on the PC. The tank is equipped with a sonar module, a compass, an RF unit and a small processor. The goal is to be able to send a command to the tank stating which direction the user would like to see Etank move and a number of distance units or turning angles. Etank uses the sonar and compass to determine its location and then moves accordingly. By the end of this project, we hope to have a good educational tool that allows beginners to create small programs and see their effects as movements by Etank.
The table below shows the constraints that we have to accommodate in order to finish the project successfully.
Table 1: Project
requirements
|
Power consumption |
PIC processor:
5V - 7.5V Sonar:
4.5V - 6.8V RF transceiver:
2.7V - 3.5V Compass:
4.75V - 5.25V XSV-300 board:
9V Oscillator: 5V |
|
Operating Frequency |
PIC processor:
32 MHz Sonar:
49.4 KHz RF transceiver:
916.5 MHz Compass:
1 MHz max XSV-300 board:
25 MHz Oscillator: 20 MHz |
| Baud rat |
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:
XSV-300: |
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 system.
Central Component
The central component, which will remain on the user side, includes a PC, the tank’s remote control, a XSV 300 board, and a RF transceiver. The XSV-300 board receives data from the PC, which contains the user application used for controlling the tank. Based on the user input, the XSV-300 commands 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, for example the distance of the tank from the forward objects or the amount of turn by the tank. The RF transceiver in the central component receives solely data from the RF transceiver of the remote component (the link between the two RF is virtually one-directional).
Currently, we have an operational test module that controls the movement of the tank in four directions. They are forward, backward, pivot turning to the left and pivot turning to the right. A program on the PC side sends signals through the parallel port. A signal sent on the parallel port remains on the port until other signals replace it. We verified this using the oscilloscope. We verified that the output of the parallel port remains the same until another signal arrives at the port and then the new signal replaces the old signal. The user is able to send any byte he or she wants. However, 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 combinations will cause the tank to stop. A diagram of the control interface can be seen below in figure 2.
Assuming that the XSV-300 receives a valid bit combination on the parallel port, it will set the four output pins high on the appropriate corresponding channels. 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 below. 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 shorten a channel. We want to control the channel using an output pin of the XSV-300 board. Our goal is to shorten 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 source of the transistor is connected to the high voltage end of the channel. The drain 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 below. 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 with 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 interprets the command and moves the tank accordingly. The eight data pins of the PC parallel port are connected to some selected XSV-300 board pins and connect the ground pin of the parallel port to one of the ground pins on the XSV-300 board. Figure 5 below shows the required pins for the parallel port.
Figure
5. Pins of concern from the parallel port.
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 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. When we send a signal on the parallel port, the signal remains at the port until another input is received. The XSV-300 board receives a signal to move the tank in one direction. The tank will keep on moving in that direction until another signal arrives from the user commanding it to stop or move in another direction.
Remote Component
The remote component, which will be loaded on the tank, includes an electronic compass Vector 2X, a sonar range finder, a PIC processor, and a RF transceiver. The PIC processor constantly polls data from the compass and the sonar. After packaging the data into the RF format, which will be explained below, the processor passes the data to the RF transceiver. Then the data will be transmitted to the central component. The details of each of these components are below.
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 6 below.
Figure 6. Communication between the compass and the PIC processor.
The PIC processor is responsible for polling the data out of the compass when needed. It will do so 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 7 below.
Figure 7. 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 below shows the format of the input and the output of the RF transceiver.
Table2. An 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, which is enough for our needs.
The communication port of the RF runs on 19200 bps baud rate and will be connected to PIC processor as shown in figure 8 below.
Figure 8. Communicating the RF transceiver with the PIC processor.
As shown in the figure above, 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
Sonar Ranging Kit includes a Polaroid 6500 ranging module, an output interface cable, and a Polaroid electrostatic transducer. The tool is able to measure the distance of objects from 6 inches to 35 feet away, 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 the 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 9 below shows the interaction of internal signals in the sonar ranging module.
Figure 9: 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. The module then asserts the echo output to be high after the sound wave is reflected off of the border and back to Etank. We need to measure the time from when we trigger the input to when we get the echo back. When the echo returns to the module, the ECHO output is set to high. This time is proportional to the distance from Etank to the border. The sonar module also produces an internal blanking signal, shown in figure 9 above. The blanking signal is set high 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. In addition, we have to re-trigger the input signal after receiving the echo output. Therefore, we need a processor to control when to trigger the input signal. This processor also has to calculate how far Etank has moved 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 10 below shows the communication interface between sonar ranging module and PIC.
Figure 10: Sonar ranging module interface with PIC
We used a transducer, which we 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. 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 use 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. At the same time, the PIC starts its internal timer associated with pin 12. 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 pin 26 of the PIC, which is set high 9 ms after the reading is triggered and stays high for 0.5 ms, is used to block the sonar from premature reading the sound reflection.
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 1 MHz oscillator). Figure 11 below shows how to connect the oscillator and power supply to the processor.
Figure 11. 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.
The following is a list of the parts 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 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 set 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
compared 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.
As we mentioned above, we divided our project into two components, remote component and central component. Therefore, we test each component separately and then integrate two components at the end.
Remote Component
To test the functionality/operation of the remote component, we broke the task into several segments as follows:
Testing the RF transceiver
To test the RF hardware, we connected it to a PC and ran the application that was provided by the manufacturer. The device worked appropriately. Then, we developed a sample application in C, which outputted a package in the format required by the RF. The package went through correctly. Then, we programmed the PIC processor to output the same package to the RF. For some reason only the first package went through, and to receive the next message, the RF needed a reset command. We will need to look into the detail of the RF communication to solve this problem.
Testing the compass
We have not started testing the compass yet. However, the plan is to first provide the required frequency for the compass through PIC pin 14. When we are sure that the device runs on the correct clock rate, we will add control to the compass’ pins.
Testing the sonar
To test the Sonar hardware, we connected the sonar as described in its manual. After generating the sound, the sonar raised the ECHO line, which is an indication of the detected sound. Next, we will connect the Sonar to the PIC and try to detect when the ECHO line goes high. After that we can enable the PIC timer to measure the time from the time the INIT signal is set and the ECHO line is set high. If this works, the Sonar is under control.
Testing the PIC
When all the pieces work separately, we will combine all the programs together and make sure the combined protocol works.
Central Component
To test the functionality/operation of the central component, we broke the task into several segments as follow:
XSV-300 serial port
Isolated testing of the serial port can be done using the Hyper Terminal program included in Windows 2000. The program is capable of sending one character at a time over the serial port. The XSV-300 board can be designed to indicate what data it has captured using its built in LED display. The program is also capable of sending an entire file at once.
XSV-300 parallel port
A convenient feature of the parallel port is that the pins that are set high on the port do not go low until they are replaced by some other inputs. There is no Hyper Terminal program that is provided by Windows 2000 to communicate with the parallel port. For that, we use the DLPortIO C package to read and write to the parallel port. We were successful in sending bytes to the parallel port and processing them on the XSV-300 board. The next step is to utilize handshaking facilities provided by that package to be able to send more bytes. We would like to be able to send a direction of movement followed by distance units.
During our design and implementation, we have come across the following problems:
Parallel
Port
As mentioned above, the next step in communicating the PC with the XSV-300 board is to allow multiple bytes to arrive at the XSV-300 board. These bytes have to be captures appropriately using handshaking methods. These handshaking methods require a more advanced understanding of the DLPortIO package, which we are currently learning.
Serial
Port
Currently, there are two ways for sending information to the XSV-300 board using the serial port interface. The first method is to send data directly from a serial port into the XSV-300 board. The second method is to take data from the serial port and send it to a PIC processor before routing the data to the XSV-300 board. We prefer the first method because it requires less hardware.
After an attempt to implement the design that just uses the XSV-300 board, we found that capturing data from the serial port is not as easy as we initially thought. The operation of the serial port works as follows. On the serial port, there is a transmit pin. When the data is transmitted, its voltage goes low to –12 V. When there is no data, its voltage goes high to +12 V. The start of transmission of a byte is indicated by a start bit pulse. Right after the bit pulse, the actual data is transmitted. After the last data bit, the transmit pin is set high again indicating the end of transmission. Data is repeatedly sent in this manner. Figure 12 below shows transmission of a sample data packet.
