This document outlines the complete design for the Mars Explorer LITE project. This EE552 design project consists of the digital system used to control a small vehicle with attached measurement equipment for remote surveying, à la the Mars Sojourner. The controlling station will transmit target coordinates to the remote system. The remote vehicle will then autonomously navigate to the specified location and take a number of measurements using onboard sensors. Upon acquisition, sensor data will be transmitted back to the control station using an optional RF transmitter. Additionally, the system will be capable of operating with minimal user intervention to permit applications where a low latency link is unavailable, i.e. planetary exploration.

All control logic is contained in an Altera EPF10K20RC240-4 FPGA. The ASIC is mounted on a chassis with two stepper motors and appropriate power transistor drivers. Other external hardware includes a TTL to RS-232 level converter, a buzzer and assorted LEDs and interconnect.. An external PC equipped with an RS-232 port is also required to receive serial data transmitted by the system. No sensors were actually used for the system. Sensor inputs were simulated using DIP switches and a PC parallel port.

The design was completely implemented using VHDL. Altera’s Maxplus2 CAD software was used to simulate and synthesize the design.

Included is an internal divide by 2 clock. Maximum system clock frequency is 35.38MhZ

The motor control signals can be interfaced to four phase stepper motors. The motors must have a driver circuit as the board cannot power the motors directly.

The serial out pin can be interfaced to any standard RS-232 port at 9600 baud

New target coordinates will be latched when robot busy is low and Pin_CoordReady is high.

An active low reset is included.

The chip consists of a number of semi-independent VHDL modules. Each module is responsible for a subset of the overall chip functionality. Major subsystems are the Motor Controller, the Navigation Module, the Instrumentation Module, and the RS-232 Output Module.

This VHDL entity was implemented using two behavioral finite state machines, one for each motor. These FSMs decode the input move instructions with each state representing one of the four possible output states, each with two different phases triggered. State transitions are then made as required to execute the desired command. As the stepper windings can operate at a maximum frequency of less than 1 kiloHertz the FSMs need a clock divider. By increasing the clock speed to the state machines the vehicles speed can be increased.

A behavioral finite state machine was used to implement this entity. This FSM handshakes with the motor controller to determine when the robot is ready to accept new move commands.

The Instrumentation Module will interface with the Navigation Module and the RS-232 Output Module. This module will latch the survey readings of the onboard instruments and send them to the RS-232 module for transmission back to the base station. Kryptonite level readings are sent continuously, whereas MsrType readings are only taken when the Navigation Module indicated that a target location has been reached. If the level readings at the target location are sufficiently high (exceed a preprogrammed threshold), a third type of measurement, indicating quality, is taken. Additionally the Instrumentation Module will monitor environmental readings from other onboard instruments. When hazardous or undesirable conditions are detected, the Instrumentation Module will attempt to compensate. This includes turning on a cooling fan if the external temperature exceeds the rated operating temperature, or activating external lights if ambient light levels fall too low.

The instrumentation entity contains no processes of its own but connects individual entities responsible for each of the sensors giving it a structural architecture. The major component of these is the Kryptonite entity. A behavioral FSM is used to insure that sensor readings are taken at appropriate times. It is also responsible for sending all data to the RS-232 module for transmission.

The Output Module will generate an RS-232 stream of survey and system data. This serial data can be transmitted back to the base station via a radio link or cable. Each data reading will include a timestamp indicating the system time the measurement was taken at, and a binary code to identify the data. Serial communications will be received with a PC terminal, and will use standard settings: 9600,n,8,1. If parity checking or other error detection/correction information is needed it can be added as necessary.

A parallel to serial shift register has been implemented with VHDL to generate the serial bit stream. Each data message consists of two data bytes and the necessary framing bits. Data is transmitted using one start bit and one stop bit, for a total of ten bits for each frame. For the two data frames a twenty-bit shift register is used with the bit positions corresponding to start or stop bits being hardcoded to the appropriate logic level. The output of an 8-bit counter providing the system time is connected to the first 8 data bits. This counter starts at 0 and runs at 0.25 Hz. giving a maximum mission time of 2048 seconds. If this is insufficient, the system clock can be run at a lower frequency to accommodate the desired time requirements. The second byte of data represents sensor measurements and is provided by the Instrumentation Module. The clock input to the shift register is another clock divider providing a 9600 Baud clock. As there is some error in this derivative of the system clock, it is necessary to occasionally hold the TX line idle to allow the clocks to resynchronize and avoid communications errors caused by propagation of this clock error.

Currently the design consumes 549 of the 1152 logic cells available. This allows room for more complex features and additional modules or features to be added to the system.

System Clock Frequency

The maximum system clock frequency was obtained using the Registered Performance Tool in MaxPlus2. As our maximum clock frequency is less than the system clock on the UP1 board it will be necessary to implement a clock divider to slow down the 25.175 MHz. clock found on the UP1 board to 12.59 MHz.

Some external hardware is required for the system. All digital logic is contained in the ASIC, this external hardware is only used for interfacing non-TTL devices.

A full step actuation technique was used in order to provide greater precision and power compared to a basic technique. The stepper motors require a power output stage that would be able to handle around 300 mA. per phase. Tip 31C power transistors were used. These transistors can handle up to 1 A. This enables our system to upgrade to more powerful motors. The application note on stepper motor control can be consulted for more detailed description on operations. Initially a stepper motor controller was built out of TTL components to test the operation of the motors. Without any documentation on the type of motors that were obtained, this controller enabled us to determine approximate stepping angles, which gave approximate speeds that the motors were capable of.

A LED was used to represent the external lamps of the vehicle. When a low light level condition is detected the LED is turned on. A buzzer was used as a warning signal to indicate that temperature is above a critical level. A cooling fan would be added to this circuit to cool the vehicle when operating at high temperature.

The RS-232 protocol uses ± 12 V levels to signal different logic values. To accomplish this an MC1488 level converter chip is required. This chip will take the 0-5V logic level supplied by the FPGA and convert it to the appropriate RS-232 level. This chip requires a ± 12V supply so a level converter that requires only +5V would be preferable, such as a MAX232.

Since no instruments were actually attached to the vehicle, their inputs had to be simulated. DIP switches were used for some testing but are inconvenient when many inputs are needed and must be changed frequently. To easily model the changing inputs from the instruments signals were taken from a standard LPT port. An expansion board was used to increase the number of available signals to 32 from the standard 8 available.

External components were assembled with a combination of soldering and wirewrapping. These techniques were adequate for our prototype.

The design was first verified with extensive simulation using the Altera CAD tools. Each module was tested independently and then the entire system was tested after integration. After the system was assembled final testing was done to verify the interface to the external hardware.

Figure 1. shows a simulation of the entire system showing all inputs and outputs. Many of the modules in our system run at a much slower clock then the global system clock. For simulation purposes speeding these modules up does not cause adverse effects. The motor control entity clock determines the speed of the pulses sent to the stepper motors. The number of iterations to move one unit of direction is also reduced. The RS232 module clock would normally run at a speed corresponding to a baud rate of 9600.

The specific workings of specific modules will be shown later in more detail.

In this simulation a target coordinate is read in upon ‘PIN_CoordReady’ going low. The target destination is reached at about 23us. At this point the unit will take soil samples and other readings. These operations aren’t evident in this simulation but will be shown more clearly in simulations presented next. The ‘robot_busy’ signal is high when the robot is moving and taking soil samples. There are two sensors , temperature and light level, that are continuously monitored and cause a cooling fan to turn on if the ambient temperature becomes to high, and a lamp to turn on if it becomes too dark.

The purpose of Figure 2. is to show the different types of data sent out via the RS232 port and the times that they occur.

When ‘PIN_CoordReady’ goes high, target locations are latched and the navigation module begins route calculations and sends the robot one unit of movement in the X direction. When movement is done signaled by ‘PIN_Busy’ going low results in soil sampling to begin signaled by ‘PIN_busy_measuring’ going high. MsrType data is then collected followed by Quality measurements. When soil sampling is finished, the robot sits where it is waiting for new target coordinates.

At the same time, data is being sent out via the RS 232 port. ‘PIN_sensor_ready’ and ‘PIN_transmit_ready’ are internal handshaking lines between the Instrumentation module and the Output module that are used to show when data is latched. Upon a high to low transition of ‘PIN_transmit_ready’ , new data is latched into a shift register and sent out of the RS 232 port. Looking at Figure 2. after the first transition, Kryptonite level data is latched while the robot is moving. At the second transition, the robot has finished moving and MsrType data is latched. This data is always sent when the target location is reached. At the third transition Quality data is latched and sent. This type of data is taken by a soil sampler if the Kryptonite level is above a threshold. At the next transition Kryptonite level data is sent and will continue to be sent until the robot makes another move and stops.

Figure 3. will show in detail the signals sent to each of the phases of the motors during a move towards a target location. New coordinates are only latched when the robot is not busy moving or taking measurements. A target location of (6,3) is latched when ‘PIN_CoordReady’ goes high. The initial coordinates of the robot are (4,4). Therefor the robot must move two units in the positive X direction, turn left 90 degrees, move backwards one unit in the Y direction, and then turn right 90 degrees so that the robot always ends a move with the same orientation. The ‘PIN_Phases’ signal is a four bit vector with each bit corresponding to a phase of the stepper motor. A stepping sequence of C,6,3,9(hex) causes the motor to turn forward and C,9,3,6 reverses the motor. During a turn one of the motors turns forward while the other reverses. For this simulation a forward command results in three iterations of the stepping sequence and a reverse results in two iterations. A turn command causes only one iteration.

Figures 4. and 5. show both a general and a detailed view of the serial output module. In particular the operation of the handshaking lines and the reset are demonstrated. The framing and output of the RS-232 stream is also illustrated. Note that after the two data frames are sent, the TX line is held in the idle state to allow the clocks to resynchronize.

Sim 4

Sim5

This 552 project was successful. All required features were functional by the end of the term. The end system achieved our design goals. Our system was flexible and could be easily reconfigured for different user applications simply by modifying the sensors. The system is easily expandable. Only 50% of the FPGA resources were consumed leaving plenty of room for new code. The modular design simplifies adding new functionality. Our main design goal, to create a system which can adapt to changing environmental conditions, was satisfied, but could be improved.

Completing the project however, required a very aggressive schedule. As none of our group members had any prior knowledge of VHDL, coding proved to be difficult. Good planning and verifying the correctness of components as early as possible, reduced the total development time and were directly responsible for the success of this project. After all simulations were complete assembling the system went very smoothly with only a few minor errors discovered. Debug cycles went quickly with the Altera tools. The reprogrammable device was very easy to load and code fixes could be easily tested.