51MA Explorer Robot

1

Final Report

51MA Explorer Robot

Ely VanReen Soto

12/15/2001

Table of contents

I.Executive Summary

II.Introduction and Project Background

III.Hardware design and implementation

IV.Software design and implementation

1. High Level Software Design
2. Input/Output Interfacing
3. Communications Interface

V.Interaction between hardware and software

VI.Testing procedure

VII.Final results

VIII.Deviations from the original specification

IX.Conclusions

Appendices

A1.Original approved project specification

A2.High-level hardware design

A3.Detailed hardware design

A4.High-level software design

A5.C source code

A6.Assembly language source code

A7.Time Distribution

A8.Part list with vendors and prices

A9.Specifications Web Links

A10.Specifications of Components

I. Executive Summary

The 51MA Explorer Robot is intended to go unaided into unknown areas while avoiding obstacles. It will accomplish this feat by the use of a rotating infrared proximity sensor. The robot will also transmit the proximity data from its sensor back to a remote unit. The remote unit will display this data on an LCD. This remote unit can also override the automation routines and directly control the robots motors and sensor function. The robot and the remote communicate via a 433Mhz AM Link. The communication has a maximum range of approximately 30 feet.

II. Introduction and Background

The 51MA robot has various control components including a sensor, transmitters, and LCD. These components and the data that they produce need to be processed in order to achieve the aforementioned objective. This could be accomplished by using a custom Integrated Circuit designed specifically for these components and the task. The drawback is that the cost and time needed to design such a circuit would far outweigh the benefit for this initial prototype system. Another tool that could be used is a microcontroller. This tool is much like a microprocessor in that its function is to be a general processing device as opposed to a circuit designed to process a specific job. For this reason, a single chip microcomputer “microcontroller” would be an ideal fit for this job.

III. Hardware Design and Implementation

Most of hardware components were chosen after thoroughly investigating their characteristics (Table 1). Each device fulfilled a specific need while keeping cost acceptable. There were a few tradeoffs that were made during the component selection. The two different types of sensors that could complete the task were the infrared sensor and the ultrasonic sensor. Furthermore, the infrared sensor had specific styles that either measured distance, or hardwired proximity data. The infrared sensor that signals proximity after a specific distance was the best choice because of the low cost and comparable accuracy. Another significant choice that I made was using the Atmel microcontroller. This microcontroller was chosen for the robot platform due to its integration of components such as flash memory and sizable ram. This kept the power and space requirements to a minimum as is needed for a mobile robot. Additionally, the Transmitter and Receiver pair was chosen because of their compatibility with the Encoder and Decoders. Their joint operation was ideal for implementation with a microcontroller. Finally the LCD was chosen because of its display size and the fact that its voltage requirements would work with the rest of the chosen circuitry.

1

Table 1: Component Overview

The components that were directly controlled by the microcontrollers include the LCD, Decoders, Encoders, H-Bridge, Keypad, Sensor, and Servo. Each required specific control line operation to activate its intended function. For example, the LCD required various control characters to be sent via 8 data lines while manipulating 2 control lines. Only by the correct manipulation, as shown in its specification sheet, would the LCD display the correct characters in the correct format. The H-Bridge was simpler, as its control was simply 4 lines that indicated which motor and direction was in need of activation. The Servo required a high pulse at a specific frequency so that it would turn to the specific location required. This was used in conjunction with the sensor, which functioned using a control line to activate the measurement and an output to indicate if an object was within the proximity.

I/O Devices onboard the microcontrollers were used to operate each of these external devices.

The Atmel MCU on the Robot Unit Internal I/O Devices:

• Port A– 4 Inputs from Decoder; 4 Outputs to Encoder
• Port B– 7 Bi-Directional Pins used to process key presses
• Port C– 2 Inputs from Steer Contacts; 1 Output for Encoder Enable; 4 Outputs for H-Bridge Motor Control
• Port D– 1 Input from Steer Contacts; 1 Input and 1 Output for Sensor Control

• External Interrupt 0–Interrupts on low level signal that is a result of a key press on the keypad
• External Interrupt 1– Interrupts on a rising edge when decoder contains valid data

• Output Capture 8bit PWM– Pulse for Servo Control

The Motorola MCU on the Remote Unit Internal I/O Devices:

• Input Capture 1 Interrupt– Interrupts on a rising edge when decoder contains valid data
• IRQ Low Level Interrupt– Interrupts on low level signal that is a result of a key press on the keypad
• Port A– 2 Outputs as control lines for LCD; 1 Output for NPN transistor control for transmitter Power
• Port B– 8 Outputs used as data lines for LCD Characters and Addresses
• Port C– 7 Bi-Directional Pins used to process key presses; 1 Output to trigger Encoder Transmission
• Port D– 4 Outputs used to transfer data to Encoder
• Port E– 4 Inputs used to receive data from Decoder

1

Table 2: Discrete Value Justification

IV. Software Design and Implementation

a. High Level Software Design

Figure 1 shows the basic program flow of the Robot Unit. Most of the function calls are begun within an interrupt or the AI loop. Specifically the Timer 0 Overflows at approximately 64ms and activates the servo movement and processes sensor data. It also executes any functions as indicated by data received from the remote unit. Finally, it terminates transmissions after the required time period has elapsed. The scanner, AI, and transmitter are activated using the timer and flags. This is done because the interrupt must execute quickly in order to continue processing and allow availability of additional interrupts. Finally the Decoder interrupts on reception of valid data. It then stores the decoder data and sending the respective packet to the encoder. Transmitter flags are set and the transmitter is powered up and the encoder is activated. Subsequently, after 64ms the Timer 0 Overflow executes, processing the received data and 500ms later it turns off the transmitter and powers it down.

Figure 1 – High Level Robot Unit Software Diagram

Figure 2 shows the basic program flow of the Remote Unit. The processing is completely interrupt driven by the keypad, decoder, and timer devices. The keypad executes the IRQ low-level handler, which modifies the data to be transmitted, and updates the LCD. The Decoder interrupts on reception of a valid transmission, updates the locally stored data, updates the LCD, and then sets up and activates the transmitter for the next packet. The RTI interrupt, which executes at 32.77ms intervals, checks to see if it is time to disable or enable the transmission of either packet 0 or packet 1. If the timer conditions are met, then the transmitter is either enabled or disabled.

Figure 2 – High Level Remote Unit Software Diagram

Both units are completely interrupt driven due to the heavy use of interrupts and the time sensitive nature of the operations. If any polling were done, either time would be wasted, or some interrupts would be missed to a point were the processing could stall.

The Robot Unit use assembly exclusively due to the unavailability of a compiler and the full control provided. The Remote Unit used C for all functions except those, which created delays, or setup the interrupt vectors.

b. Input/output interface

Figure 3 - LCD Display

Name 51MA Robot█ □█ Proximity

□ ↑ □

Drive Motor0 F/B AI Off/On AI Control

Steer Motor1 L/RScan Off/On Scan Control

Proximity Data will display █ if blocked, □ if not blocked

Drive Motor is either F for Forward, or B for Back

Steer Motor is either L for Left, or R for Right

Figure 4 – 3x4 Keypad Standard Telephone Keypad

1 – Unused

2 – Drive Forward

3 – Unused

4 – Unused

5 – Drive Back

6 – Unused

7 – Steer Left

8 – Steer Center

9 – Steer Right

0 – Drive Off, Steer Center

* – Toggle Scan

# – Toggle AI

c. Communication Interface

The Remote and Robot communicate via a Half Duplex, Synchronous transmission mechanism because they both use 433Mhz Transmitters.

The Remote will initiate the communication at timed intervals using the Real Time Interrupt.

Time (ms)Function

0Remote Transmit Packet 1

250Turn Off Remote Transmitter

0-250Robot Transmit Packet 1

500-750Turn Off Robot Transmitter

750Remote Transmit Packet 2

1000Turn Off Remote Transmitter

750-1000Robot Transmit Packet 2

1025-1500Turn Off Robot Transmitter

1500Reset Timer to 0ms

Robot will upon receiving RX packet 0, send TX packet 0

Robot will upon receiving RX packet 1, sends TX packet 1

The data will be transmitted in at 2, 4bit packets. Each packet contains 4 data bits and 12 address bits. An encoder and decoder use the addresses to filter out bad data. The range of the transmitters is approximately 30 feet.

Figure 3 – Transmission Diagram

Table 3: Transmission Data

V. Interaction between Hardware and Software

The most significant tradeoff that was made between hardware and software was the use of the encoders and decoders. These hardware devices could have been circumvented by the use of the Serial Communications Interface (SCI), the drawback being the increased testing time and complexity. Such system would allow me to devise a far more complex transmission system that could handle errors more adequately than the existing system.

VI. Testing Procedure

The hardware testing procedure was top-down and piecewise because of the various components that had to be verified. Each component was implemented and tested on a breadboard beginning with the LCD and keypad. These two components simplified debugging of the other components significantly. Furthermore, I implemented a keypad on the robot unit simply for testing purposes. I omitted the keypad from the final robot circuit implementation after the other components had been verified on the breadboard. The verification process included a great deal of trial and error especially in during the implementation of the transmitters. The approximation of the power-up delays and probability of a successful transmission at a specific range went into the final setting for transmission time. Once each of the units’ circuits was tested thoroughly, the move from breadboard to circuit board was begun. This allowed the final testing and tweaking of the robot unit, which required this final step to complete the obstacle avoidance routines.

The software testing procedure was closely linked with the hardware as each function or interrupt had at least a 1 to 1 relationship with an I/O device. Thus, the software development also began with the implementation of the LCD code, followed by the keypad code.

VII. Final Results

The project was a success and all devices were implemented for their intended use.

List of internal and external I/O devices implemented and tested successfully:

The Atmel MCU on the Robot Unit Internal I/O Devices:

Port A– 4 Inputs from Decoder; 4 Outputs to Encoder

Port B– 7 Bi-Directional Pins used to process key presses

Port C– 2 Inputs from Steer Contacts; 1 Output for Encoder Enable; 4 Outputs for H-Bridge Motor Control

Port D– 1 Input from Steer Contacts; 1 Input and 1 Output for Sensor Control

External Interrupt 0–Interrupts on low level signal that is a result of a key press on the keypad

External Interrupt 1– Interrupts on a rising edge when decoder contains valid data

Output Capture 8bit PWM– Pulse for Servo Control

The Motorola MCU on the Remote Unit Internal I/O Devices:

Input Capture 1 Interrupt– Interrupts on a rising edge when decoder contains valid data

IRQ Low Level Interrupt– Interrupts on low level signal that is a result of a key press on the keypad

Port A– 2 Outputs as control lines for LCD; 1 Output for NPN transistor control for transmitter Power

Port B– 8 Outputs used as data lines for LCD Characters and Addresses

Port C– 7 Bi-Directional Pins used to process key presses; 1 Output to trigger Encoder Transmission

Port D– 4 Outputs used to transfer data to Encoder

Port E– 4 Inputs used to receive data from

Seiko L2034BJ001 4x20 Character LCD

Sharp SP2D05 IR Sensor

Holtek 12E 4-bit Data Encoder

Holtek 12D 4-bit Data Decoder

TWS-434 Transmitter

RWS-434 Receiver

Hitec HS-300 Servo

4x3 Generic Keypad

74LS11N3 AND3 Gate IC

SN754410 Quadruple Half-H Driver

Generic 5V Steering Motor with Contacts

List of I/O software functions implemented and tested successfully:

LCDinit()

Setchar()

Setcursor()

SetVect()

Irqhandler()

Rtihanlder()

IC1handler()

Servo0Deg()

Servo45Deg()

Servo90Deg()

Servo135Deg()

Servo180Deg()

Interrupt Tim0_OVF()

Interrupt Ext_Int0()

Interrupt Ext_Int1()

Motor1Forward()

Motor1Reverse()

Motor1Off()

Motor2Left()

Motor2Right()

Motor2Center()

Roboai()

TurnRobo()

VIII. Deviations from Original Specification

The original specification assumed that the transmitters would not cause noise when inactive. After realizing that this was untrue, I simply inserted an NPN transistor to switch the power going to the transmitters on each unit. This successfully reduced noise but added a significant ‘power-up’ delay. As a result, I increased transmission times to 250ms for both the robot and the remote. To further optimize the communication timing, I connected the decoder reception indicator line to input capture 1 in order to process incoming data immediately.

IX. Conclusion

The robot successfully detects obstacles in its path and searches for a clear course in which to proceed. Furthermore, the remote and robot units communicate all appropriate information to each other. The only area of difficulty is in the communication’s reliability. Communication becomes sporadic at distances beyond 10 feet and is the only thing keeping me from naming the project a complete success. Perhaps choosing two different pairs of transmitters that operated on different frequencies could solve this. This would both eliminate the power-up delay and allow continuous transmissions in a full duplex mode. It is still possible that I may be able to improve the current communication design by the power output of the transmitter. Furthermore, I suspect that there are considerable optimizations left to be made by fine-tuning the antennas. Other additions that are planned include, a wheel rotation monitor, perhaps by using a Hall effect sensor and magnet. This would allow me to monitor cases were the robot sensor misses an obstacle and becomes entrapped. This will likely be easy to implement.

A1. Original Project Specification

51MA Explorer Robot

Summary:

The Robot is intended to go unaided into areas and transmit proximity data back to the user. The user can take direct control or allow the robot AI to proceed unaided. The AI will attempt to circumvent obstacles and get itself out of traps.

Remote Unit:

Seiko 4x20 LCD, 4x3 Keypad, Encoder IC, Decoder IC, 433 MHZ RF Receiver and Transmitter, Motorola MCU

The remote unit will transmit control data to activate the AI or give direct commands. It will receive proximity data and other robot operation data. The data will be transmitted in at least 2, 16bit packets. Each packet contains 4 data bits and 12 address bits. An encoder and decoder use the addresses to filter out bad data. The range of the transmitters is approximately 150-300 feet. A keypad will be used for all of the user input.

The Motorola MCU platform will be enclosed hand held 7x4x2 inch plastic box with LCD, Keypad, and Antenna visible.

Robot Platform Unit:

2 DC Motors, Salvaged Monster Truck platform, 4x3 Keypad, H-bridge IC, Encoder IC, Decoder IC, 433 MHZ RF Transmitter and Receiver, Atmel MCU

The robot contains two motors, which power the steering and the drive. Activating a H-Bridge IC will control the two motors. There will also be a keypad to enter data directly to the robot. Proximity data is gathered using a Sharp GP2D02 Infrared sensor. It is mounted atop a servo to give it 180 degrees of precision control.

The Atmel MCU is ideal for the robot platform due to its embedded memory and peripherals. I can mount this on a 40pin socket on a small development board on the Truck platform.

A2. High Level Hardware Design