Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Material Type: Project; Professor: Czernikowski; Class: 0306 - Ce Design Projects II; Subject: Computer Engineering; University: Rochester Institute of Technology; Term: Fall 2003;
Typology: Study Guides, Projects, Research
1 / 19
This page cannot be seen from the preview
Don't miss anything!
Project Proposal: Distributed Robots for Area Mapping and Maze Solving
Harry J. Eisenbise ( hje3479@rit.edu ) David R. Cox ( drc6915@rit.edu ) David R. Higgs ( drh9296@rit.edu )
Rochester Institute of Technology CE Design Projects II 0306-657-
Instructor: Dr. Czernikowski Version 1.4 - Submitted: September 11, 2003
1. Description The objective of this project is to develop a cooperative system for solving mazes. By using several semi-autonomous robots in conjunction with a smart base station, a solution to a maze can be found in a distributed manner. A graphical user interface at the base station reports the status and allows for manual control of each robot.
Two tank-tread style robots will be tracing a maze of reflective tape strips. A set of six opto- reflector sensors are used to keep the vehicle on track and detect intersections. Two similar opto-interrupter sensors are used to measure distance by counting the gaps in each tread.
Each robot moves through the maze under base station control until it encounters an intersection. The base station will continuously poll the active robots to determine their locations in the maze and issue movement commands. Status and commands are communicated to and from the base station by way of a radio frequency transceiver link.
This project is intended to be a demonstration that much larger applications are possible, but could not be completed within the time period allotted. For instance: the controlling program will be modifiable to handle many more robots, the sensors could be replaced to detect obstacles and map an area, or much more intelligence could be added to the robots to make them self- organizing instead of reliant on the base station.
2. System-Level Diagrams Shown below in the following subsections is some basic information of the individual systems that will compose the project. Included is a brief description of each component, any sub- components involved, and a block diagram.
I. Robots The robots to be developed for this project are only semi-autonomous. They contain only enough logic to move and turn, sense the reflective strip underneath, and communicate with the base station. Figure 1 below shows a simple block diagram for the robots. Figure 1: Block Diagram for Robots
9 - bit interfaces (^) Disable Button^ Left Drive Motor
Microcontroller
RF Receiver^6 and Decoder
Dual H-Bridge Motor Driver
RF Transmitter and Encoder
Right Drive Motor
6x Opto-^6 Left^ Position^ Encoder reflectors Right Position Encoder
ADC inputs 3 Status LEDs
Serial Connection 9 - bit interface
RF Receiver and Decoder
PC Microcontroller
Figure 4: Block Diagram for RF Sniffer
III. Maze Description and Simplifying Assumptions The maze will be of maximum size 9’ by 9’, and will consist of strips of reflective tape at intervals that are multiples of 1 foot. This creates 64 possible locations for intersections within the maze, and defines a 1 square foot “block” unit that the program can use to determine how far each robot has traveled and its relative location in the maze.
Robots may start at any valid node in the maze. The base station GUI will prompt the user for the robot location before it begins solving. The end of the maze is signified by a gap in the outer wall; if a robot is moving along the outer limits of the maze and detects a gap without any other intersecting paths, the end has been reached.
3. Hardware Component Details The sub-systems of this project as described in the section above are comprised of a handful of basic components: microcontrollers, RF transmitters, RF receivers, DC motors with isolated control, and several opto-reflectors. These components are detailed in the following section. Individual research was performed on the robot chassis and motor drive, optical sensors, and RF communication hardware, and is summarized below.
a. Chassis & Drive Motors A reasonable amount of precision in movement and turning is required, and low power is also a desirable factor. High-speed operation is not really a necessity and could be sacrificed for increased torque. Distance encoders will be used to determine the position of the robot. They are also important for making the robot turn in 90-degree increments, and travel in a straight line.
After considering several different robot architectures, a tank-tread design was chosen for the easy application of differential (skid) steering. A bulldozer robot kit has been obtained, which includes the chassis, motors, and gearbox:
Figure 5 - Bulldozer Robot Kit from HVW Technologies
Figure 6 - DC Motor and Gear Box
Overall size of the robot is 5-1/4" wide by 6" long, easily fitting within the desired range. Twin DC motors and gearbox are included with this kit to drive each tread separately. The gearing of Figure 6 allows for the motors to be operated at two different settings – a high speed and a high torque mode. High torque mode is likely to be used - a slower robot is acceptable if it produces enough torque to carry all necessary components through the maze.
Driving Circuitry: These DC motors can obviously not be controlled directly from processor I/O pins; isolation is required. Rather than design a separate motor drive circuit, HVW technologies sells an inexpensive controller interface that is designed to work with the twin motor box. The interface circuit will control 2 motors up to 2 Amps each based on forward, backward, and stop TTL signals. The L298 Motor Controller Interface, shown in Figure 7, will step down the battery input voltage (6-35 volts) to a logic high of 5 volts. Internal thermal protection circuitry shuts down the circuit if it becomes too hot, and a heat sink can be attached to a metal tab if this happens often. The actual drive circuit is an H-Bridge, the basics of which are shown here:
Figure 7 - H-Bridge Circuit and Transistor Truth Table
Figure 9: Receiver and Decoder Circuit
A microcontroller will be used to interface the RF transmitter/receivers to the PCs for the base station and the packet sniffer. This is done to convert from the 8-bit parallel interface of the encoder/decoder to the serial port of the PC. Speed and memory requirements are very low and thus any microcontroller should be sufficient. Even though this is not necessary, it will make things simpler for the students implementing the project.
While it is possible to connect the transmittter/receiver directly to the serial port without using the encoder/decoder, this introduces additional complications. For one, the encoder/decoder on the robot side includes another 10-bits of address information that is sent along with every eight bits of data. This would cause problems for the PC which sends and receives data 8 bits at a time.
It could also be possible to skip the encoders/decoders all together. This would also cut down on the number of I/O pins required. While this makes things easier on the PC side, it complicates things on the robot side. The microcontroller on the robot would have to routinely poll the serial port. The decoder however, can be used to trigger an interrupt whenever new data is available. This allows communication to take place asynchronously with normal robot operation.
Furthermore, after some brief experimentation, using the transceivers in this manner proves rather difficult. The serial data being sent frequently loses framing synchronization. While it could be possible to correct this in software, it would prove more difficult than using the encoder/decoder.
c. Optical Sensors As shown in the system level diagram of the robot, opto-reflectors will be used to determine position on the maze, and possible paths to navigate. The desired photo-reflector component that
will be included in the full multidisciplinary project will be mounted in a face down configuration (as shown in Figure 10 below), and will detect the difference between the reflective tape used and the surrounding maze surface. The component will operate similarly in high or low ambient-light conditions because of the non-reflective maze surface used. The distance between the sensor and the surface is fixed at the optimal operational distance of the photo-reflector, so small variations in the distance due to robot movement or vibrations will not significantly alter the output.
Figure 10 - Opto-Reflector
If the OPB745 part from Interfacing and Digital Electronics were chosen, an interfacing circuit had already been designed for the first lab in that course. It is shown below in Figure 11, with enable functionality that can be connected to pin 1 of the inverter, and a Schmitt-trigger inverter on the output side to prevent output transition noise. The resistors R1 and R2 can be designed to appropriately bias the LED and transistor for maximum brightness and correct output.
Figure 11 – Digital interface circuit for optical sensors
Sample calculations showing the range of resistors to be used are shown below:
ohms mA
Vcc V V R F
max
ohms mA mA
Vcc V R C IL
2 min = −
kOhms nA uA
Vcc V R DARK IH
2 max = −
4. Software Component Descriptions In addition to the hardware design required for this project, software components will be designed and implemented.
a. RF Protocol To prevent contention for the communications medium, the base station will initiate all communication. Robots will speak only when spoken to. Thus, only one transmitter will be active at a time.
Each message is composed of a thirteen-byte packet as depicted below. The frame contains vital information such as source and destination address as well as message type information. Finally, the checksum is included to verify the correctness of received data.
Header (Line Feed – 0x0A) Destination address (G, H, …) Source address (G, H, …) Message type Payload (6 bytes) 1 byte for command or status type 2 bytes for left tread count 2 bytes for right tread count 1 byte for intersection data Checksum (2 bytes) End of Packet (Carriage Return – 0x0D) Figure 13: Message Packet
Destination Address This field is an ASCII character between G, H, I, etc representing the intended receiver. Since the airwaves form a broadcast medium, each receiver will get every message. Therefore, each receiver will be programmed to ignore messages not intended for others.
Source Address Since robots will only communicate with the base station and only one device can transmit at a time, this field will go largely unused. It could (but won’t) be used to implement inter-robot communication.
The main purpose of this field is for network debugging via the “packet sniffer.” This device essentially connects a RF receiver (via a microcontroller) to a terminal for the purpose of watching network activity.
Message Types and Payloads The message type field is one byte that can take any of the six values specified in the table below. The messages are paired up after sending a “status request”, “command”, or “hello”
message, the receiver will reply with type “status reply”, “command reply”, or “hello reply.” For more details on each, see the following sections.
Table 2- Packet Type Encodings Message Type ASCII Encoding Status Request Q Status Reply S Command X Command Reply R Hello H Hello Reply I
The data payload varies with message type. The size of the payload, however, remains a constant six bytes. Any unused bytes will be filled with ASCII zeros (hex 30). In reality, any value could be placed in these bytes as long as the checksum is computed properly (see below).
Status During execution, the base station will run through a loop during which it routinely polls each robot with a message of type “status request.” This is done to initiate communication with each robot, giving it a chance to report its status. The payload for a message for this type is unused.
Status Reply After receiving a message of type “status request”, the robot will send a response of type “status reply.” For the “status reply” message type, the following values represent possible payload data. The first byte of the data payload field will be filled with an ASCII character reflecting the reply value. The remaining five bytes may or may not be used depending on the message (see below).
Table 3 - Status Reply Values Reply Value ASCII Encoding Moving M Waiting W Disabled U Finished Z
Moving – Indicates that the robot is currently in motion. In this state, the robot will not respond to new movement commands. Only this first byte of the payload field will be used.
Waiting – The robot is waiting for its next instruction. Along with the first payload byte indicating the reply value, three additional bytes will be included. These bytes indicate the current tread rotation count and the intersection information. To convert the sensor data into a single byte, the sensor values for each valid path from the following table will be XOR’d together, then converted to ASCII for transmission to the base station. For example, if the all paths are available except the rightward one, the robot would calculate a value of 1101, and send ‘D’ (hex 44).
Hello Reply
After receiving a “hello” message, each robot will respond with a “hello reply”. The payload field for this message is unused. If a robot is not turned on, it will not reply and thus will remain unused.
Checksum To verify the correctness of message transmission, a simple checksum will be employed. The final step to constructing a packet is to compute the checksum, which is computed as follows:
This final value will be placed in the checksum field of the out going packet. This enables the sender to verify an incoming packet. This can be done as follows:
A resulting value of zero indicates that transmission was a success. Any other value indicates failure. Should data become corrupted in transit; the receiver will simply discard the entire packet. Eventually, the data will be retransmitted.
Lost or Corrupted Data The receiver is expected to send a response to each data packet. Should a packet become lost or corrupted, a robot need take no action other than to discard the incorrect data. The base station will automatically handle these by retransmitting the packet or sending a status query packet. The base station will decide a packet has been lost if a second has elapsed without any response.
b. Microcontroller Software The code from the HC-12 mini-project could be re-used in a stripped-down form to control the robots. The software footprint will be somewhat more complex due to the number of peripherals controlled, but at the same time, some existing code can be cut because there is no ‘recipe’ to run
The code driving the PC-to-RF interface microcontrollers need only use parts of the robots’ RF code and some communication code so it can communicate with the PC over the serial port.
c. Base Station Software The decision to implement the majority of the control logic on a PC allows a large amount of flexibility for the construction of the master program. The ease of serial port communication makes Java the high-level language of choice, with GUI capabilities as a secondary factor. Multi-threading may be used to ensure that the generation of the periodic poll signal is not delayed by less important tasks like drawing the GUI.
The strategy employed by the base station to guide each robot in traversing the maze is somewhat complex. At any particular intersection in the maze, the base station will search for the nearest un-visited area that it can reach. If several choices are available at equal distances,
the robot will be directed north, east, south, and westward node in that order. Once a destination has been decided on, the robot is commanded to travel the shortest path toward that node.
The presence of other robots can prevent the first robot from reaching unvisited areas of the maze, so it is possible that a robot may not be able to visit these areas. If this is the case, the base station will choose the nearest node that would be reachable if a robot moved out of the way. This way, two robots will both proceed toward an unvisited intersection, in the hopes that multiple pathways will be encountered, and robots can split up.
Robot movement is done simply: if a robot needs to turn 90 degrees, it will be commanded to turn so that it faces toward that direction. Otherwise, the base station will command either forward or backward as the situation warrants. At each intersection, the algorithm will re- evaluate which node each robot should travel to as described above. The combination of all these methods ensures that any number of robots will explore the maze in the most efficient manner possible while preventing collisions.
When the base station observes that a robot has encountered a path that takes it outside the predefined maze limits (8x8), this is determined to be the goal of the maze. The discovering robot will be directed down this path, and any other robots will be told to abandon their current exploration and to take the fastest available route to the goal.
The maze itself will be represented in the base station software by an array of node objects. Each node knows its location, which neighboring nodes it connects to, and whether it has been visited. As the robots progress across the maze, this information can be filled in for each node as they are encountered. Thus, determining the best route from one node to another is a simple task of graph traversal, a cheap operation for a personal computer.
Collisions are avoided by having each robot take ‘ownership’ of the starting and ending node while in movement. The base station can then ensure that no other robot enters these nodes. Aside from the line-following capabilities of the robot itself, no other effort will be made to prevent collisions.
Additional code will be added to detect and attempt to cope with unusual circumstances like unconnected portions of the maze, non-existent goals, or if a robot ceases communication.
d. User Interface Robot UI is very simple. An enable/disable switch will be available. When a robot is disabled, it can communicate this status to the base station, but will not respond to any commands. Its previously discovered paths, however, will remain in the base station memory. A few simple status bits will be displayed on each robot using three LEDs, as described below:
Table 6 - Robot Status Status Color Moving Green Waiting Yellow Disabled/Error Red Finished All 3 Colors
Figure 14 - GUI Example
5. Cost Estimates Qty Item Price Paid (Spares, S/H) Market Price 2 Robot chassis + motor $50 2 @ $50 = $ 2 High-torque gearbox $28 $ 2 H-bridge $38 $ 2 6-V Batteries $40 $ 1 6-V Battery charger $14 $ 2 3.8-V Molicel battery $0 ?? 4 68HC12S microcontroller Dept 4 @ $150 = $ 4 RF transmitter/receiver $100 4 @ $22.50 = $ 4 Photointerruptors $40 4 @ $4.95 = $19. 12 Reflective object sensors Samples 12 @ $1.123 = $13. 1 DB9 serial cable $13 $ Maze construction equipment Not acq yet est $ Misc. electronic components Dept est $ Total $323 $1,014. 6. Difficulties Anticipated As with any significantly sized project, difficulties are bound to arise. By anticipating these problems ahead of time, their effects can be alleviated or sometimes avoided completely. Below are some potential difficulties that may be encountered in the course of this project.
I. Microcontroller Requirements The microcontroller for each robot (as shown in Figure 1) needs two 8-bit connection ports, four outputs for motor drive, 8 inputs for optical sensors, and other connections for communication interrupt strobes. This is a significant number of I/O pins for a microcontroller. Some of the ADC and PWM channels may be used as inputs or outputs, along with Timer ports for interrupts. If there are not enough ports available, a custom interface board may be built.
Some compromises could be made to reduce the I/O pin requirements. Possibilities include: multiplexing input and output for the RF circuits, switching to 4-bit encoders/decoders, and using PWM outputs for motor control if at all possible.
II. RF Communication Inter-robot communication is not a trivial task. The encoders/decoders should be helpful in filtering out junk radiation. To eliminate contention between the multiple robots, the communication protocol will be designed such that the base station will initiate all communications. It will routinely poll each robot to check its status and issue directives when necessary. Once underway, experiments will be done to determine the maximum range and amount of error that could be encountered in a typical operating environment.
The goal of this project is to design a distributed maze-solving robot, not to develop an error- and loss-tolerant communication protocol. At this point in the design phase, it is will be assumed that checksums and retransmits will be unnecessary, but if noise becomes a significant problem, the protocol could be augmented with a parity bit and/or sequence number to better detect problems.
Harry J. Eisenbise 225 West Squire Dr. Apt. 2 Rochester, NY 14623 (585) 737- hje3479@rit.edu
David Cox 64 Waln St. Wellsboro, PA 16901 (585)-727- drc6915@rit.edu
David Higgs 60-6 Colony Manor Dr. Rochester, NY 14623 (585) 424- drh9296@rit.edu
