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
A project proposal for a distributed robotic system designed to map areas and solve mazes using a set of semi-autonomous robots and a smart base station. The system utilizes rf communication for coordination and can handle various modifications, including additional robots, sensors, or self-organizing robots. A block diagram, hardware component details, and software components design.
Typology: Study Guides, Projects, Research
1 / 20
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 I 0306-654- Instructor: Dr. Czernikowski Version 1.2 - Submitted: May 14, 2003
1. Description The objective of this project is to develop a cooperative system designed 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. Two tank-tread style robots will be tracing a maze created by placing reflective strips on the floor. A set of six opto-reflector sensors are used to keep the vehicle on track and detect intersections. Each robot moves through the maze 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. As more research is done, this section will be expanded as needed. 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 RF Receiver and Decoder (^) Microcontroller 9-bit interfaces RF Transmitter and Encoder Dual H-Bridge Motor Driver Right Drive Motor 6x Opto- reflectors
ADC or Single-pin inputs
Left Drive Motor Left Position Encoder Right Position Encoder
III. RF Sniffer For debugging purposes, a “sniffer” will be constructed to log all traffic on the wireless network. In essence, this component will be very similar to the hardware for the base station. The major differences between the sniffer and the base station above are that the RF transmitter is not required, and the software will be passively monitoring RF traffic. The sniffer hardware will be connected to a different serial port on the base station PC, or possibly a serial port on a second PC. Figure 4: Block Diagram for RF Sniffer IV. Maze Description and Simplifying Assumptions The maze will be of maximum size 8’ by 8’, and will consist of strips of reflective tape at intervals that are multiples of 1’. 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. The start of the maze will be defined as the southwest corner, so that the base station program can graphically map the maze as it is discovered. All robots will be lined up at the beginning on the maze, and will enter one-by-one as commanded by the base station. Essentially, a “runway” will guide the robots into the maze, and the base station will not consider them as having entered the maze until the first intersection (at the corner) is reached. 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, motors with rotary encoders, 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. Rotary encoders will be used to determine the angular position of the motor. RF Receiver and Decoder PC Microcontroller Serial Connection 9-bit interface
This will be used to measure the distance that the robot has traveled. It is 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 ordered, 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.
b. RF Communications The figure below shows the complete transmission circuit. This block is composed of two separate components: the TWS-434A RF transmitter and the Holtek HT-640 8-bit encoder. The receiver provides a 2.4 kbps serial interface for transmitting data. The encoder chip is used to convert 8-bit parallel data to the required serial format. Additionally, the encoder provides a 10- bit address space for creating up to 1024 different channels using only one frequency. Figure 8: Transmitter and Encoder Circuit Figure 9 below depicts the matching reception circuit. Once again there are two primary components making up the subsystem: the RWS-434 receiver and the Holtek HT-648 8-bit decoder. The receiver takes the RF reception and coverts it into a 2.4kbps serial bit stream. The decoder then converts the serial data into 8-bit parallel data. A valid-transmit pin is included to indicate when new data has arrived. The 10 address lines allow the receiver to listen to any of the possible 1024 channels. 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.
kOhms nA uA
Vcc V R DARK IH
2 max =
The desired photo-interrupter assembly for use on a tank-tread based robot would be mounted in a side-facing configuration as seen in Figure 12 below. The tread would travel horizontally through the photo-interrupter and transition high to low any time a tread gap passed through the sensor’s field of view. The width of the sensor gap would be sufficient to allow the tread to pass freely, and not show anomalous transitions due to tread slack, robot vibration, or ambient light. The accuracy and repeatability of this component should be sufficient such that the microprocessors can calculate the distance each tread travels within an error less than 5%. Figure 12 – Photo-interrupter tread detection The opto-reflector circuit could probably be very easily adapted to interface a photo-interrupter device like the Panasonic ON1120 to the microprocessor. d. Microcontroller Though extensive research has yet to be performed for microcontrollers, possible choices include 68HC12 as supplied by the department or PIC microcontrollers (small, low power, etc.) Another possibility involves using the NEC microcontroller attached to a tank-style robot intended for use in Dr. Cockburn’s robotics class. However, there will probably not be enough I/O ports on this controller. Serious consideration is being given to stripping off the controller and using the pre- assembled (and free) chassis, along with reflective tread encoder sensors. While the robots will be identical, it is not necessary for the base station and the network sniffer to use the same microcontroller devices. For these purposes, any processor available and fitting the requirements can be used. Familiarity with, and availability of the HC12 make it the primary candidate. The department’s new boards, with increased RAM and EEPROM should easily be able to hold all the code necessary for robot movement, maze sensing, and communication. Older boards are likely to be used for the base station and RF sniffer interfaces, since their main function will be to interface parallel data to the serial connection of the PC.
Transistor
Tread
4. Software Component Descriptions In addition to the hardware design required for this project, software components will need to 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 seven byte frame 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. Destination address Source address Message type Payload (3 bytes) Checksum Figure 13: Message Frame Destination Address This field is an ASCII character between 0 and 9 (hex 30-39) 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.
Finished – The robot has completed the maze. The robot will no longer respond to movement commands when in this state. Command A message of type “command” is a message from the base station to the robot telling providing a movement instruction. For a message of “command” type can take the following values. For each message, the second and third bytes of the payload field will go unused. Table 4 - Command Values Reply Value ASCII Encoding Forward F Backward B Left L Right R Command Reply After receiving a “command” from the base station, the destination robot will reply with a message of type “command reply.” Contained in the payload of this message will be the same payload data received in the “command” message. Hello When the control software on the base station first starts up it will run through a loop polling all possible robots with a message of type “hello”. It does this to determine how many robots are ready to traverse the maze and what their addresses. This enables a variable number of robots to be used, even if their addresses are not sequential. The base station will only run through this process once. Each message will be retransmitted a maximum of 5 times. If no one responds, the base station will assume that the robot is not participation in this run of the maze. 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 frame 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 frame. This can be done as follows:
d. User Interface Robot UI is very simple. An enable/disable button will be available, along with reset. When a robot is disabled, it can communicate this status to the base station, but will not respond to any commands. If a robot is reset during maze solving, it will have to start over from the beginning. Its previously discovered paths, however, will remain in the base station memory. A few simple status bits will be displayed on each robot using two LEDs, as described below: Table 5 - Robot Status Status L1 L Moving 0 0 Waiting 0 1 Disabled 1 0 Finished 1 1 The base station will provide a graphical interface to the user for informational and control purposes. The information shown will include the current status of any robots that respond to RF queries, the base station’s current knowledge of the maze, and a command history window showing the most recent RF queries and responses. Control will be present in both system-wide controls and robot-specific manual controls as outlined in the table below. Table 6 - Base Station User Interface Control Name Scope Description Start Global Base station will query RF for any responding robots and start running the maze if any are found. At least one robot must respond with READY and any such enabled robots must be correctly positioned at the starting point. Resume Global Paused maze running will resume, robots cannot have been physically moved except by other UI commands. Reset Global Base station will halt maze running in progress, and erase all prior knowledge of the maze. Before starting again, robots must be physically placed at the starting runway. Pause Global Base station will halt maze running in progress and await further user input, either by manual robot control or a Reset/Pause command. Forward Robot Robot will move forward in the current direction until another intersection is reached. Option is not available when robot is not waiting for user input or if there is not a path in front of the robot. Left Robot Robot will turn 90 degrees left with respect to the current orientation and await further commands. Option is not available when robot is not waiting for user input. Right Robot Robot will turn 90 degrees right with respect to the current orientation and await further commands. Option is not available when robot is not waiting for user input. Run Robot Base station will begin controlling this robot to continue solving the maze. Option is not available after a system-wide reset or if already running. Stop Robot Base station will stop controlling this robot and give the user manual control. Option is not available if robot is already under manual user control.
Figure 13 below is a rudimentary sketch of what the user interface might look like. When options are not available they will be disabled and ‘grayed out’, or replaced with a counterpart option if an appropriate one exists. The graphical representation of the maze is simply a guess at this point – the final result will probably include the location of the robots, a descriptive legend, and other such supporting data. Manual robot control mode is only available when the system is paused. Figure 2 - GUI Example
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. III. Locomotion Getting the robots to travel in a straight line often poses a problem. In addition, accurately measuring distance can be a challenge. In an effort to alleviate these problems, either precisely controllable motors or rotary encoders will be used. These should allow the robots to know their distance traveled and angular positioning directly, or by measuring the data from the rotary encoders. Wheel slippage could pose a problem as well, but this risk should hopefully be alleviated by not running the robot at high speeds and by operating on suitably frictional surfaces with appropriate wheel tread. IV. Mapping and Control Logic The application software running on the PC will be complex. In addition to managing communications, this software is responsible for all decision making. Before any major work is done elsewhere on this project, a significant amount of time and effort will be dedicated to planning and documenting the operation of this software.
7. Incremental Goals & Deliverables - Robot vehicle continuously drives in a square pattern o Motor control o Tread odometry - Robot follows a path of reflective tape o Sensor interfacing o Line following o Error correction - Robot distinguishes intersections o Further line tracing o More sensor logic - Microcontrollers get and send RF data o RF interfacing o Range demonstration o Sniffer functionality - Base station simulator o Command decision logic o Software simulation of robot movement - Base station manual control mode o Software interface to RF o Protocol demonstration - Final Deliverable o Robots communicate with base station o Base station controls robots to explore maze o Robot encounters end of maze o Base station sends other robot(s) to end of maze o Manual override/resume mode still available 8. Team Members 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
