Introduction

The Remote Sensory Vehicle (RSV) is a solution used to gather various types of data about an area into which it might be dangerous or impossible for a human to go. The RSV is completely wireless and is complete with an onboard power supply for autonomous operation. It requires no cable that could restrict its movements or cause it to become stuck, making it perfect for exploration nearly anywhere.

 

The Remote Sensory Vehicle comes with many features, including streaming video, physical collision avoidance and terrain information. The vehicle can be used by a remote user or rely on a set of preprogrammed autonomous control algorithms for movement.  The vehicle can operate up to 50 feet from the base station with no line of sight contact necessary.  It is controlled through a keyboard attached to the base station and outputs its data to a computer monitor via its VGA out port.

 

Our system is meant to be a proof of concept vehicle. Our main objective is to get a working platform up and running. The platform will have basic functionality and a sample set of sensors, many of which will be used to enhance the abilities of the device. A full version of the vehicle would have increased range and the ability to add a custom set of sensors to the platform for various tasks.

Requirements

Requirement

Minimum

Maximum

Vehicle Speed

 

4 feet/second

Vehicle Angle of Incline

 

30 degrees

Rangefinder Distance Reading

1 foot

30 feet

Guaranteed stopping distance

 

3 feet

Number of bytes transmitted in one second

 

38

Required baud rate for sensor RF link

304 bits/second

 

Atmel Voltage

4.5 Volts

6.6 Volts

Atmel Current

6.5 mA

25 mA

Atmel Oscillator

 

32 MHz

Atmel Machine Cycles

 

2.67 MHz

Accelerometer Voltage

3 Volts

5.25 Volts

Accelerometer Current

0.6 mA

1.0 mA

Accelerometer Acceleration

 

1000 g

Accelerometer Measurement

± 1.5 g

± 2 g

Accelerometer Noise at 10 Hz

 

2.3 mg

Rangefinder Voltage

4.5 Volts

6.8 Volts

Rangefinder Current

40 mA

2000 mA

Rangefinder Resolution

~ 2 inches

~ 6 inches

Rangefinder Return Time

 

0.1 seconds

Range of RC controller

 

50 feet

Range of RF video link

 

50 feet

RF video link frequency

2.4 GHz

2.484 GHz

Range of Virtual Wireless Development Kit

3 meters

30 meters

Virtual Wireless Development Kit Voltage

4.5 Volts

4.5 Volts

Virtual Wireless Development Kit Baud Rate

 

19200 baud

VGA output frequency

15 Hz

60 Hz

Transistor Collector-Emitter Voltage

 

40 Volts

Transistor Collector-Base Voltage

 

40 Volts

Transistor Emitter-Base Voltage

 

5.0 Volts

Transistor Collector Current

 

200 mA

Design

In order to design this complex system, we divided it into several subsystems. Figure 1 provides a graphical overview of the interaction between these systems. 

Figure 1 - Block diagram of RSV project components

 

As shown in the diagram above, we divided the whole system into a total of five separate systems. These five systems are distinguished in the diagram by different colors and their designs are presented below.

 

Sensors

We start by describing three of the four sensors that are mounted on the actual platform; the two rangefinder arrays and the accelerometer. All of these sensors interact directly with the onboard controllers, as opposed to the fourth, which does not.

 

Rangefinder

The sonar rangefinders are an integral part of creating a vehicle with collision avoidance.  When the RSV is put into autonomous control mode, it must never collide with any obstacle and the rangefinders are a reliable solution for this problem.

 

We constructed two arrays of three rangefinders on the RSV’s platform, one fore and one aft, to cover all the directions the vehicle can move at any one time.  We use a separate Atmel AT89C55 to control each array of rangefinders.  The base station receives the information from the rangefinders via a link provided by the virtual wireless development kit.  The onboard autonomous controller also receives this information so it can provide collision avoidance.

 

The rangefinders are set up with a 4.7kW pull-up resistor on pin 7 (ECHO) as shown in Figure 2.  We connected pins one, two, and eight to ground, and pin nine to 5V.    Pin four (INIT) provides the control for the rangefinder.

Figure 2 - Rangefinder Pin Layout

 

Pin P1_5 on the Atmel AT89C55 drives pin four (INIT) on the rangefinder as shown in Figure 3.  We connected a 4.7kW pull-up resistor to P1_5.   When the 8051 raises P1_5, it drives INIT high, which causes the rangefinder to fire.  At the same time, a 16-bit counter on the 8051 is started.  We use the negated ECHO output of the rangefinder to drive P1_2 (T2EX) on the 8051.  When the rangefinder receives a return, it sets ECHO high causing T2EX to go low.  This triggers the timer two external interrupt, at which time we get an accurate distance reading by examining the 16-bit counter that started when the 8051 raised INIT.  The system fires each individual rangefinder twice per second.

 

Figure 3 - Diagram of rangefinder interface to 8051

 

We connect the inverted ECHO output of the second and third rangefinders in the array to the 8051 pins INT0 and INT1 respectively.  Pins P1_6 and P1_7 of the Atmel drive the INIT pin on the rangefinders.

 

We chose to use the sonar rangefinders over the laser rangefinders for two reasons.  The first is area coverage.  The sonar rangefinders provide information within a conical volume with the emitter at the tip.  We value this more than the single line the laser rangefinder would provide.  The other advantage to using the sonar rangefinder is availability.  The hardware lab already has many in stock whereas we would have to purchase laser rangefinders.

Accelerometer

By attaching an accelerometer to the RSV we can derive the tilt of the vehicle.  The accelerometer interfaces with an Atmel AT89C55 and transmits its data via the virtual wireless development kit to the XSV board.  Our base controller interprets and changes the information from the accelerometer to an angle for display on the monitor.  This provides the user with a sense of the vehicle’s orientation.

 

The output from the accelerometer presents information about acceleration on two separate axes.  We align one axis along the centerline of the vehicle with the other axis perpendicular to it forming a plane parallel to the ground. The base controller uses information from both of these axes to compute the pitch and the roll of the vehicle.  To provide as accurate information as possible, we mount the accelerometer on the chassis of the vehicle, preferably as close to the center as possible.

 

The accelerometer provides data in terms of a duty cycle on a single pin for each axis.  We configure the cycle length (T2) through two capacitors and a resistor to its slowest setting, 10 readings per second.  The attached 8051 uses a 16-bit counter to record the amount of time the accelerometer outputs high (T1) and stores the information to transport it to the communication controller later.  By knowing the cycle time, we can measure the duty cycle of the accelerometer and thus derive the tilt of the vehicle along that axis.

On-board Control

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
 

 

 


Figure 4 - 8051 cluster interface on vehicle

 

A cluster of five Atmel AT89C55 microcontrollers controls the RSV.  Two control an array of three rangefinders each.  One controls the accelerometer.  One provides autonomous control.  The final 8051 creates a communication link between the other four and the base station via the virtual wireless development kit.  The communication controller acts as a master and signals the other microcontrollers to begin the data transmission process.

 

Since we already used all three external interrupts on the rangefinder controllers, we created a protocol that did not require any interrupts on the part of the device controllers.  We configured the device controllers to take readings twice per second.  The communication controller (CCON) collects these readings and sends them to the autonomous controller (ACCON) and the virtual wireless development kit (VWDK) via RS-232 and a line powered RS-232 transceiver.

 

The data collection process begins with the communication controller toggling its interface control signal.  This clears the first rangefinder controller (RCON1) to send its data.  If RCON1 is not ready to send, the communication controller waits until RCON1 is ready.  Conversely, if the RCON1 is ready to send before the signal toggles, it waits for the interface control signal to change.  Once RCON1 is ready and cleared to send, it sets its bus ports to output and writes the first two bytes of data to it.  It also sets the data clock high (see Figure 5.)  RCON1 then pulses the ready to send signal for 10 cycles.  This triggers an interrupt in the communication controller (CCON) and the controller records the value on the bus.  After another 10 cycles have passed, RCON1 sets the data clock low and writes a new value to the bus after it has been low for 3 cycles.  RCON1 sets the data clock high 7 cycles later.  CCON then records this value.  Since the order in which the device controllers send is fixed, CCON knows how many 16 bit values it will receive.  This sets up an effective transfer rate of 16 bits every 20 cycles.  Once RCON1 is finished sending, it toggles its interface control signal, transferring control to RCON2.  RCON2 and the accelerometer controller (ACON) will proceed in the same fashion as RCON1, each tristating the bus after it has finished sending, thus avoiding bus contention issues.

 

Figure 5 - Communications Protocol

 

We chose a data clock period of twenty cycles because of the asynchronous interface between the microcontrollers.  All the 8051s use a 32 MHz clock, but will not be perfectly in phase or have the exact same period.  Thus, in order to ensure a signal is seen, we must hold it for longer than 1 cycle.  We chose the number 20 because it is sufficiently large to ensure data capture and, as we are dealing with a relatively low bitrate stream (14 total readings, each 16 bits, yields 28 bytes every half second,) speed is not our primary concern.

 

Once ACON has finished, all readings have been recorded into CCON and are ready to be transmitted.  As long as the RS-232 RxD line is not busy, CCON will send its 28 byte packet immediately.  This packet goes to the base station via the VWDK and to ACCON.  Since the base station communicates with the RSV, some packet collision and loss is inevitable.  However, since they communicate at different frequencies, twice per second for the device readings and 2.86 times per second for the base station packets, collisions can only occur less than once every seven seconds.  This amount of loss is tolerable, since it is guaranteed by our protocol that there is no loss on the next transmission.  Also, the only information sent from the base station is autonomous or interactive control.  Since it will be sent again 0.35 seconds later, 0.7 seconds is the maximum amount of time the vehicle would take to switch modes.  Conversely, the device reading are sent every 0.5 seconds, so the maximum delay in between device readings is 1 second.  The sensor data transmitted to the base station is displayed only for the user’s benefit, so a one-second delay is tolerable.

 

Movement

We designed the platform to have two modes of control, interactive and autonomous.  In interactive mode, the user directly controls the movement of the platform and the orientation of the camera.  In autonomous mode, the user only controls the orientation of the camera. 

 

While in autonomous mode, the RSV searches the area while avoiding obstacles by using data from its rangefinders.  The autonomous controller is located on the vehicle.  If the RSV travels out of range of the base station, the vehicle reverses direction in an attempt to regain RF communication.  Requiring two-way communication via the virtual wireless development kit allows the vehicle to recognize when it travels out of the range of the base station because the vehicle will no longer receive information from the base station.

 

The tank uses two servos for movement, one servo for each tread to provide the tank with forward and reverse motion and the ability to turn within its own length.  Another pair of servos controls the camera.  One servo rotates the camera parallel to the ground, and the other servo adjusts the camera’s vertical angle.  In this manner, the user has complete control over the camera view independent from the orientation of the vehicle. All of these servos are included with the original tank. In our design we rearrange them to suit our needs.

 

The RC transmitter interfaces with the XSV board through one of the expansion headers.  This provides us with direct interaction with pins on the FPGA.  The transmitter consists of a simple collection of switches.  We control the transmitter through a transistor network that we built to open and close the switches on the transmitter. This allows us to control the movement of the tank via the XSV board, which in turn receives instructions from the keyboard.  In this way, we retain the functionality of the controller while actually controlling the vehicle with the keyboard.

 

We attach the keyboard to the XSV board using the PS/2 port. We capture every 10 bits of the keyboard input from which we remove the start and stop bits.  Keyboard scancodes are composed of a control character followed by one or two instances of a byte representing the key pressed and then another of the same byte when the key is released.  We parse through these packets to determine what the user is typing into the system and react accordingly.

Video

We chose to use an analog signal for our video feed.  For this, we used an off the shelf digital video camera from Trendmasters.  The camera takes a digital picture, translates it into NTSC format and transmits it via a 2.4 GHz radio link to a receiver equipped with RCA jacks. We plug the RCA jack into the XSV board where the built in the Philips Semiconductor SAA7113 decoder microchip digitizes the signal into ITU 656 YUV 4:2:2 format.  We then send the digitized video into the FPGA where we change it into an RGB signal to send to the monitor as seen in Figure 6.

 

 

 

 

 

 

 

 

 

 

 

 


Figure 6 - Video RF interface through XSV board to monitor

 

The YUV format has a resolution of 720 x 525 pixels and stores the information in terms of luminance and red and blue color.  The 4:2:2 ratio indicates that every pixel has its luminance stored, but the red and blue color are only recorded every other pixel.  This turns out to be advantageous.  Since we do not plan to display a full screen image, we can simply ignore every other luminance value without losing much information about the picture as a whole.  This reduces the number of columns to 360.  In order to display a non-distorted image, we drop every other row, giving us 263 rows.  The decoder provides horizontal and vertical synchronization signals and a line locked clock that provides us with our exact location in the image.

 

Lastly, we must convert the current format into a format compatible with a VGA monitor.  The RAMDAC does not accept YUV signals, but will accept RGB, thus we need to convert from YUV to RGB.  We use the following transformation to perform this conversion:

where Y, Cr (U), and Cb (V) are 8 bit values.  This yields 8 bit values for R, G, and B.  Since this transformation will be done on an FPGA, we will approximate the multiplication by using 16 bit variables and truncating all extra bits.  In this manner we now have a 360 x 263 RGB image that we send to the RAMDAC and display on the monitor.

 

There are several reasons why we use this approach over the option of leaving the signal in digital format.  The main reason is parts availability. We found it nearly impossible to find a transmitter that could handle the bandwidth that a digital signal requires. Uncompressed video data from a CIF (352x288) camera requires a 37.5 Mbps link to display at 30 frames per second.  This is an unreasonable amount to transmit over any existing radio frequency link designed to transmit digital data.  One option we investigated involved encoding and decoding the video stream around the RF link.  Several algorithms are available for this, such as MPEG-4 and H.263.  These codecs reduce the needed bandwidth to a reasonable, though still large, amount.  MPEG-4 requires a 1Mbps link to display video at 15 frames per second.  Unfortunately, we found the implementations of these algorithms in integrated circuits difficult to find and costly.  Also, a 1 Mbps RF link, such as Bluetooth, proved to be expensive and unavailable in standard packaging.

 

The NTSC format provides us with a viable alternative.  NTSC is the name of a set of common video formats used to transmit television signals in the US and other countries. Since we know television signals are transmitted reliably via this format and NTSC sender/receiver pairs are readily available in consumer electronics stores, we decided to use this transmission method. We chose the Trendmasters camera because it already integrated digital picture acquisition with an NTSC radio frequency link. The camera proved to be cheaper than a stand-alone NTSC transmitter/receiver pair. Since we no longer have to focus on the video link we can spend more time on processing the video in the Xilinix FPGA.

 

User Interface

The user controls the RSV through a keyboard and receives information from a VGA monitor.  The keyboard allows the user to control both directions of all four servos and change the vehicle between interactive and autonomous modes.  The monitor displays the video feed in the upper right corner with information from the accelerometer and rangefinders in the upper left.  The lower portion of the screen displays status information about the vehicle along with what mode it is currently operating in.

Figure 7 - VGA Layout

Both the keyboard and the monitor are plugged directly into the XSV board.  We chose this approach rather than using a PC to control the devices because all members of the team have experience with interfacing the keyboard and monitor with the XSV board.  Also, the XSV board provides every type of port we need, including PS/2, RCA, monitor, serial, and direct interfacing to pins on the FPGA.

Parts

 

Hardware

 

Quantity

Manufacturer

Part Number

Description

Comment

1

Horizon Hobbies

 

M1A1 Abrams Tank

This is the Radio Controlled tank on which we build the RSV.  It operates at 27.145 MHz.

1

Trendmasters

 

Digital Video Camera

This module provides our video feed.  It captures digital images, converts them to NTSC (standard TV) format and broadcasts the signal to a nearby base station. It operates in the 2.4 GHz range.

6

Acroname

R14-SONAR1

Polaroid Instrument Grade Sonar Ranging Package

The sonar range finders provide us with the ability to detect a possible collision with a physical object.

1

Analog Devices

ADXL210EB

Dual Axis Accelerometer Evaluation Board

The accelerometer board gives us information about the platform’s movement from which we can derive its velocity and the amount of tilt the vehicle is experiencing.

1

RF Monolithics

DR-1004DK

Virtual Wireless Development Kit

This kit gives us the ability to send digital signals to and from the platform in order to provide control and receive telemetry data. This link is in the 900 MHz range.

1

Xess

XSV300

Virtex Prototyping Board

This FPGA prototyping board provides us with many interfaces and is required for the integration of all the components of the RSV.

5

Atmel

AT98C55-33PC

8051 DIP Microcontroller

The Atmel 8051 is used to control the various sensors on the RSV.

5

Fox Electronics

F1100E-320

32.0 MHz clock

This oscillator is used to drive the Atmel 89C55 microcontroller.

1

Dallas Semiconductor

DS275

Line-Powered RS-232 Transceiver Chip

This chip allows us to interface the Atmel AT89C55 to the serial port on the virtual wireless development kit.

6

Fairchild Semiconductor

2N3906

PNP General Purpose Amplifier

We will use these transistors to control the switching on the RC controller for the tank.

1

Texas Instruments

SN74LS32

Quad 2-input

OR gate

This TTL is used in the 8051 cluster interface.

2

Texas Instruments

SN74LS00

Quad 2-input NAND gate

This TTL device will provide inverters for use with rangefinder and RS-232 interfaces to the Atmel AT89C55s.

1

 

 

VGA Monitor

The monitor will display the video output and current status of RSV.

1

 

 

PS/2 Keyboard

The keyboard is used to interface

with the RSV.

5

 

 

47 uF Capacitors

Used for power supply decoupling.

6

 

 

AAA batteries

Power for Virtual Wireless Development Kit

2

 

 

9-volt batteries

Power for video camera and RC controller for tank.

1

 

 

Onboard Power supply

We will need a 5V power supply to provide power to the accelerometer, range finders and onboard  8051s.

 

Software

Manufacturer

Program

Description

Kiel

C51 Compiler

Compiles C programs into hex code for the 8051 microcontroller.

Xilinx

Foundation Series

Creates FPGA configurations from schematics and Verilog modules.

Analysis

An analysis of the major portions of our design shows that it meets the design requirements. In this section, we investigate each of the major subsystems below.

 

Rangefinder

There are several main issues that came up when using the rangefinder.  The first is whether multiple rangefinders firing at the same time could cause erroneous values (from returns generated by the other rangefinders).  We decided that there could potentially be a problem here, so by our design, we do not allow any of the front three rangefinders to fire at the same time.  We apply the same constraint to the rear rangefinders as well.

 

A second issue is the power consumption of the rangefinders.   The data sheets state that when the rangefinder is fired, it can draw a maximum of 1A.  This would cause a problem because 6 * 1A = 6A.  This value is not including any of the other components on the RC tank such as the accelerometer or the 8051 microcontrollers.  However, upon testing a rangefinder firing once every 0.8-0.9 seconds we discovered only 40mA of current is drawn.  With six rangefinders, we get 40mA * 6 = 240mA, which is manageable.

 

Another issue is the speed with which we can switch between rangefinders within an array.  We want to get data from each rangefinder every half second.  With the speed of sound equal to approximately 300m/s, and the range of the rangefinder equal to 11m (total distance round trip is 22 m), we decided the maximum amount of times we could fire the rangefinder and switch to another rangefinder is 10.  Due to this, we changed our design to have only three rangefinders per 8051 (as opposed to 6).  Three rangefinders, firing two times a second, gives us a total of 6 which is a good distance below our upper bound of 10.  This also allows us to increase the number of checks per second to three if we feel we need that degree of accuracy.  In addition, this allows us to use the three external interrupts on the Atmel 89C55 (timer 2, INT0, and INT1).

 

 

Accelerometer

To ensure we get a precise enough reading to give an accurate calculation of the angle the vehicle is currently at, we use a 16-bit counter in the controller.  We set the accelerometer to the slowest setting, 10 Hz, giving us the smallest root mean square noise, .0023g.  At this setting we only transmit once every 5 readings.  We average four of the five values by using shifts and adds while paying careful attention to any overflow to provide the most accurate reading possible.

 

Autonomous Control

When the vehicle leaves the range of the base station while in autonomous mode, it will detect it is no longer in range because it won’t receive the periodic messages from the base station.  In this case, we will reverse direction without turning until we find the signal again, then turn in a different direction and continue exploring.  If it is unable to return the way it came, for example a new obstacle was placed behind it, it will simply stop and wait to be placed back in range of the base station.  This method is used because the vehicle could get into an area it could not get out of, such as traversing over a ledge.  If the vehicle were to continually explore, it could end up traveling far away and we would have no record of the direction in which it went.

 

 

When using the vehicle in interactive mode, the autonomous controller still retains a small amount of control over the vehicle.  In order to implement physical collision avoidance, the autonomous control needs to override the users commands in the event of an imminent collision.  Since the autonomous controller receives all the data from the rangefinders, it has enough information to decide when an object is too close to continue in its current direction.

 

Basic motor functions

This system came with the basic platform. The basic movement controls of the platform already exist via the RF link. Furthermore, the control signals that the existing system uses to operate the motors attached to the treads are simple voltage levels. The only thing that we need to modify in this system is to insert the logic so that the autonomous controller can take control and rearrange some of the servos into a usable camera mount.

 

Full motion video

The processing of the video will be the difficult part of this subsystem. We need to convert the NTSC data to a digital format (YUV) that in turn will be translated into RGB. We can do this in one of two ways; we can built the logic ourselves or use the RAMDAC to convert it for us.

 

Virtual Wireless link

We treat the RF link provided by the virtual wireless kit like a half-duplex RS232 port. We use this link to send control signals to and receive telemetry data from the platform. Since we are using a half-duplex connection for full-duplex communication, there is the potential for collisions. However, the virtual wireless boards are capable of communicating at 19.2 Kbps, or 2400 bytes per second and we will be transmitting no more than 38 bytes in the worse case. The virtual wireless boards are more than adequate for our needs.

 

Base Station

Although a XSV300 FPGA is the heart of the base station, there is plenty of space on it to accommodate all of the functionality that we need to have. We can accomplish much of the basic layout of the screen for the user interface by using sprites and/or seven segmented displays. The user status portion of the board will be a set of registers recording state. Identifying keyboard strokes can be done easily. Since we don't anticipate using over a dozen keys, a simple set of and gates may be sufficient to recognize patterns. Alternatively, we could use some of the keyboard recognition logic that we developed in CSE 467 last quarter.  The biggest challenge is controlling the video feed and processing it the way that we want as previously mentioned.
Testing

In order to ensure our projects robustness, we will test our project each module individually.  Once each component is in working order, we will test the integration of these modules.  The main modules of our project are the sensors, RF link, RC control, autonomous control, and video link.

 

Sensors

Rangefinder

We will test the rangefinders in several stages.   At first, we test one rangefinder connected to the 8051.   This allows us to determine if our code for configuring the 8051 is correct.  We are using Hyperterminal and the serial port to communicate with the 8051’s transmit and receive pins.  This allows us to retrieve any relevant data from the rangefinder such as the distance to the target.  By physically measuring the distance from a given object and performing some calculations, we can determine if the values are increasing at the rate we expect them to increase (these values should increase linearly.)  We use Hyperterminal to test our ability to turn on and off the rangefinder (we do not want to have all three of the frontal rangefinders firing at once) by embedding a case statement in the rangefinder program that allows us to switch between two states upon a given key input.

 

After completion of the first stage, we integrate the additional two rangefinders into the array, for a total of three rangefinders.  Although the additional rangefinders are tied to different interrupts, the setup for them is essentially the same as the timer 2 external interrupt, making this part of the integration simple.  To toggle the rangefinders on and off, we use six different inputs from the keyboard.  Again, we use Hyperterminal to determine if we are getting the correct distance values from each of the rangefinders. 

 

For the third stage of testing the rangefinder, we configure the system to automatically switch from one rangefinder to the next.  By using an oscilloscope, we monitor the response of the INIT line on all three rangefinders and determine the order in which they fire.  This portion of testing is not as difficult as the previous two sections.

 

Lastly, we modify the rangefinder code to place its output data on the pins in the 8051’s port 0 according to the protocol specifications outlined above.  To make sure we get the correct data for all three rangefinders in the correct order, we hook up a logic analyzer to port 0 and examine the results.  To make sure we get consistent data, we place cardboard obstacles at fixed distances from each rangefinder.  If we get different results (equating to more than a few inches distance,) we know that the data has been placed on the pins incorrectly because the first two stages verified the correctness of the range. In this way we will debug the system.

 

Accelerometer

The accelerometer is easier to test than the rangefinders. This is due to the pre-calculated values we have from the data sheet for the accelerometer.  To test the accelerometer, we mount the accelerometer onto a breadboard, and fixing the breadboard to some flat platform (piece of plywood or thick cardboard).  By using an oscilloscope, we measure the difference in the high time between T2 and T1.  Once we have those values, it is a simple matter to compare them with the given values given on the accelerometer data sheet.

 

Once we finish that stage of testing, we integrate the accelerometer with an 8051, and convert the T2 and T1 values into a 16-bit integer value.  We can see that everything is working correctly by connecting a logic analyzer up to the 8051, and examining the outputs.

 

RF Link

We already completed some testing of the RF link.  We tested how the RF link handles overflow and/or collisions.  We tested the RF link by using the DOS program that came with the Virtual Wire Development kit.  We found out that the RF link loses data in the case of a collision, but with our system configuration, this should not be a big issue.

 

Control for RC car

The control for the RC tank is largely tested through trial and error.  In the first step, we connect the RC controller to the XSV and use the push buttons on the XSV board for control.  In the next step, we map the keyboard keys (up arrow moves the tank forward, left arrow turns the tank to the left, etc).  For this we have pre-existing code that already works, although some minor changes may be necessary. One thing that we need to make sure of is that only one direction change at a time can be done (for example, holding the up and down arrows at the same time should not cause any damage to the car).

 

Autonomous Control

There are three main stages in testing for autonomous control.  At first, we have the tank perform a pre-planned sequence of moves.  This allows us to test that the 8051 microcontroller can truly control the tank.  Since we know the sequence of moves we programmed onto the 8051, we can easily determine if it is following those directions.

 

The second stage is to test the rangefinders in conjunction with the autonomous control.  If the tank gets too close to a wall or object, it should stop and turn to a different direction before continuing.  We can test this by placing the tank in a confined area such as a cubicle and seeing how it reacts.

 

The last stage is total autonomous control.  The best way to test this would be to place it in a relatively small area, and watch to see if it can avoid hitting the walls.

 

Video RF

This stage has been verified.  Since the video RF was pre-made, our testing consisted of hooking it up to a TV, and seeing if we could get a picture.  Testing for video RF range will be done in conjunction with the testing of the RC tank range. The camera will be mounted on the tank and then we will send the assembly varying distance from the base station. This gives us an idea of how accurate the specified range of 50 feet is.

Design Issues

We face several design problems with this project. We will address each in its major area of involvement.

 

Video

Although most of the solution is already contained in the ready made camera and we do have all the connections that we need to complete this portion of the project, we still need to determine how we will process the video data that is coming into the board and how we will display it. We may be able to process the video in real time, or, alternatively, be able to set up a double buffering system in the RAM available to the XVS300 board. Either way there are still a number of design issues to be overcome in this area.

 

Base Station

Besides the video and the data link, there are a number of other inputs and outputs that we need to work with. Although we are confident that all of these modules will fit on the board, we are unsure exactly how they will be able to interact. This is especially true of the video solution and its output to the monitor. Most of the other functionality should be fairly simple.

 

Onboard Functionality

Although we have determined how the 8051 controllers will interact with each other, we anticipate that there may be timing issues involved in the actual operation of the machine that will need to be dealt with. Also, at this stage of the design we don't know if we will have to define additional protocols for sending the data, especially from the accelerometer. Although our solution looks good on paper and seems pretty solid, there may be holes that we haven't quite discovered yet.

 

Portable Power Supply

As of yet, we do not have a portable power supply for the devices on the vehicle.  This could pose a problem because of the large number of mircocontrollers and sonar rangefinders on the platform.  The rangefinders, each having high current spikes when emitting pulses, can be decoupled from the power supply with capacitors evening the current to 40 mA per rangefinder.  The microcontrollers each require 25 mA.  The accelerometer requires less than 1 mA.  This yields a current need of 366 mA.  Commercial low dropout voltage regulators are available, as are high current power supplies, but we will need to consider battery life as well as lead time and cost.

 

Technical References

XSV Board manual version 1.0, a local copy can be found at http://www.cs.washington.edu/education/courses/cse477/CurrentQtr/admin/Handouts/xsv-300/xsv-manual-1_0.pdf

XL210 evaluation board manual (for the accelerometer) http://www.analog.com/techsupt/eb/xl210eb.pdf

XL202 accelerometer data sheet

http://www.analog.com/pdf/ADXL202_10_b.pdf

Virtual Development Kit Manual, DR 1004-DK and DR 1005-DK

Atmel AT89 Series Hardware Description Manual

Atmel 89C55 Manual

Fairchild Semiconductor 2N3906 PNP General Purpose Amplifier Data Sheet

Dallas Semiconductor DS275 Line-Powered RS-232 Transceiver Chip Manual

Analog Devices ADXL202 Dual Axis Accelerometer with Digital Output Data Sheet