498 A & B Technical Report
Team Members: N. Alvarez
K. Galinet
R. Olmos
J. Peipelman (editor)
Team Number: 19
Submitted to: Professor Grubbs
Professor Ostheimer
Date: May 3, 2002
ECE 498-B
Department of Electrical and Computer Engineering
University of Arizona
Tucson, AZ
The Multi-Robot Team #19 consisted of the following members: From left to right: Keith Galinet, Ramon Olmos, Jason Piepleman, and Noel Alvarez.
Abstract
This report describes four homogeneous robots able to communicate and operate autonomously. These robots were produced to fulfill a need for a multi-robot architecture used to explore the realm of a distributed artificial intelligence. Therobots were built using a TINI board to control and access the robots motors and sensorsand a 3Com ECB to allow each robot to communicate over a wireless LAN. These robots were constructed and programmed to fully demonstrate all the basic capabilities of the robots.
Table of Contents
Introduction
A. Problem Statement
B. Objective
C. Background
History of Design
A.Altoids Bot
B.I2C Bot
C.TINI Bot
Problems Encountered and Changes Made
A. ECB Mishap
B. Copper Shavings Shorting the MSI
C. Power Board Failure
D. Inadequate Voltage to the ECB:
E. Disproportionate Movement Problem:
Functions and Capabilities of the Robot
Recommendations for improvement
Conclusion
Acknowledgements
References
Appendix I
Appendix II
1
498 A&B Technical Report
Introduction
The multi-robot project is based on a group of homogenous robots interactively communicating with each other using a computer over a wireless Local Area Network designed mainly for the use by professors and graduate students at the University of Arizona. Each robot is designed to provide a cost effective and sophisticated mean of allowing application programmers to explore the realm of robotics and distributed artificial intelligence. The Java programming language is used to program the robot, and an easy to use API is given to allow the easy access and control of the robot’s hardware.
A. Problem Statement
Various studies on robust collaborative behavior have emerged from the research on the local interactions of a group of homogeneous robots. Different functions such as being able to determine the position of a specified object and the ability to communicate with other robots to let them know their location, have not yet been accomplished. Such robots also have possible future applications such as the investigation of imbedded systems, mapping protocols, reconnaissance, and other multirobot applications. At this moment there exists a need to build a set of robots that would aid in these studies. Currently at the University of Arizona there have been several attempts to build and program similar but yet distinct robots to perform specified tasks. Till this moment none have proven to be successful. The multi-robot design group is faced with the task to accomplish this goal. The beneficiaries at this present time would be Dr. Bernard Zeigler, Dr. Suvrajeet Sen, and Dr. Jerzy Rosenblit all from the College of Engineering and Mines.
B. Objective
Mapping was chosen as the first application of the robot group. Mapping is the easiest job that the robots can perform because it only requires each robot to be able to move, know its location, and be able to detect obstacles. The communications aspect of the robots would deal with the use of a wireless communication system controlled by a central access point. This will enable the robots to move without restraint and will provide the ability to be programmed from any given destination.
C. Background
Currently at the University of Arizona, the only multi-robot experiments being worked on are those associated with Dr. Suvrajeet Sen.These robots are modified versions of the GrowBot, a small two wheeled robot offered by Parallax that uses a simple BasicStamp processor. The robots are limited by the functions they can perform and the sensing technology they obtain. The robots contain an inadequate amount of sensors, limited processing power, and lack of robust communication. Dr. Bernard Zeigler, who is currently doing studies involving embedded processors, is interested in the idea of using a multi-robot system to incorporate a more advanced processor. This would enable advanced programmers to integrate a communications system within the robots and allow the robots to make use of all their sensing capabilities.
History of Design
A.Altoids Bot
The concept for our project started approximately two years ago with the idea of the ‘Altoids Bot’. This robot was nothing more than a mettle Altoids Mints box with a small breadboard fixed atop it, and a nine volt battery and two stepper motors mounted underneath. This design hosted a small PIC16F84 processor, two whiskers for collision detection, and no communications. This design proved to be too small and unsophisticated to implement an interesting artificial intelligence program.
B.I2C Bot
The ‘I2C Bot’ was our solution to the low complexity of our Altoids Bot. The I2C Bot’s major design upgrade was the concept of a wireless I2C implementation. I2C is a communications protocol developed by Philips, which uses tow lines, data and clock, to communicate between separate components. The normal implementation of I2C is to connect components on a circuit board. The major advantage of this idea was that the system was both original and possibly patentable. However, this solution proved to be beyond our technical capabilities to produce from the ground up. The I2C Bot was also still limited by its processor, which was the PIC16F84, and had limited sensor capabilities.
C.TINI Bot
In our exploration to get funding for the I2C Bot we encountered Dr. Bernard Zeigler. Dr. Zeigler expressed his concern about the processor we were using for the robot. Originally we expected the I2C Bot to be controlled by a base station, which would include a stationary computer terminal. This is an inadequate design because of the time lag encountered between sensor input and computer reactions. Dr. Zeigler introduced us to the TINI processor. TINI stands for Tiny Inter-Net Interface. This processor is made by Dallas Semiconductor and is programmed using the Java programming language. This turned out to be just the idea we needed to get our idea for a distributed robotic network off the ground.
We quickly changed the focus of our project from wireless I2C to utilizing the vast array of inputs and outputs of the TINI processor. Our communications was changed from wireless I2C to a wireless local area network (WLAN) to utilize the powerful communications capability of the TINI over its Ethernet interface.
Next we discovered that, although the TINI is endowed with many advanced serial interfaces, it has very few parallel digital inputs and outputs, and no analog inputs. To overcome this drawback of the TINI, the motor and sensor interface (MSI) board was conceived. This MSI board uses a new advanced PIC processor from Microchip called the PIC16F877. This processor has up to eight analog inputs and twenty-four digital input/outputs.
Upon deciding that our robot would include a TINI, WLAN communications unit, and an MSI board we realized that the weight of the robot was starting to become an issue. Because of this we switched from using the stepper motors for the drivetrain to using a pair of DC motors with a planetary gear set. These motors provided more than ample power to our robot, but required the addition of an H-Bridge to drive them. This H-Bridge was easily incorporated into the MSI board.
Our final decisions included the selection of four infrared rangefinders which were added on each side of the robot, and the addition of four mechanical sensors which were added to each corner of the robot. Wheel encoders were added to each wheel and photo-reflectors where mounted on each motor to allow the robot to detect the speed and distance traveled by each wheel.
Problems Encountered and Changes Made
In the course of building and testing the robots, there are a few problems that we encountered. This section of the report includes a description of the major problems we discovered, how we found them, what the cause of the problem was, and how the problem was handled or resolved. The following problems had clear solutions, and when implemented were completely ramified.
A. ECB Mishap
A labtop ac adapter was mistaken for the ECB adapter, and as a result, the ECB burned out. This was the first ECB that was purchasesd from 3Com, so it was qualified for replacement under 3Coms 90-day warranty. The ECB was shipped back to 3Com and replaced.
B. Copper Shavings Shorting the MSI
Low voltage readings were taken on the receive line of the MSI board causing the serial communications to fail during its operations testing phase. The cause for this was determined to be stray copper shavings that had not been removed from the board after it was traced and milled. All copper residues were removed from the board, and normal voltages were recovered. For further discussion of this problem, reference the Trouble-Shooting section of the Users Guide.
C. Power Board Failure
The power board of one of the robots failed after it collided with another robot during a demonstration.The main cause of failure was a result of the whisker shorting the charging plates. Two robots collided during testing, and one of the whiskers from one of the robots shorted the plates which are connected directly to the positive and negative terminals of the battery as can be seen in Fig. X. This shortage drew too much current from the battery, which caused a rupture in the trace on the power board. A new power board was built to prevent the occurrence of the whiskers shorting any component on the battery.A insulator (heat shrink) was applied to each whisker in order to prevent an occurrence like this from happening again.
The stability of the DC sockets located on the power board was deteriorating. It was noticed that the sockets were getting loose because we were pulling them in and out of the power board in order to cut power to different components on the robot. To remedy this situation, a switch was implemented on the power board to extinguish all power to the robot.
D. Inadequate Voltage to the ECB:
The robots wireless communication was the first part of the robots to stop working after a period of normal use. The reason for this was that the motors were drawing excessive current, which was effectively limiting the voltage required by the ECBs regulator in order to source the required amount of voltage to the ECB. Thus not allowing it to function properly. For more detailed information regarding the specifications of the voltage regulator see the Construction Manual. In the Construction Manual: This voltage regulator requires at least a 1.2V difference between the input and output voltages in order to effectively supply 5.2V to the ECB. In order to extend the operation time of the ECB, a 4700uF coupling capacitor was added across the battery terminals on the Power Board in order to better sustain voltages to the robot components as the battery degraded. There has not been enough time to reliably assess if this was an effective solution. Another possible implementation to rectify this problem is discussed in the Recommendations for Improvement section of this report.
E. Disproportionate Movement Problem:
One problem was that the motors, when supplied equal power, did not run at the same speed, causing the robot to veer during its movement. This was due to inconsistencies in the mechanical and electrical characteristics of the motors. This problem largely affected the way that the robots were stopping. The robots use dynamic braking to stop, which essentially involves shorting the motor leads across the H-Bridge. In order to balance the motor speeds, the duty cycles of the voltage pulse width to each motor were adjusted in the PIC code. Another possible implementation to rectify this problem is discussed in the Recommendations for Improvement section of this report.
Functions and Capabilities of the Robot
The aim of this section is to address the frequently asked question, “What can your robots do?” The primary function of our robots is to enable a sophisticated software program to be run and implemented in a coordinated and synchronized manner. The robots operate in a wireless local area network (WLAN). In this environment, a program can be up-linked wirelessly from a main computer to the TINI processor via access point and ECB. With this software program, the TINI processor can then command the PIC (on the MSI board) to move the robot a certain speed, distance or direction. While executing these instructions, the robots are capable of using their sensors to alert the TINI (which can alert the user) how far it has traveled, in what direction it is traveling, how fast it is going, and what objects surround it.
One good analogy that illustrates the present functions of each of the main components of the robots is the human. The TINI processor is to each robot what a brain is to a human. It does the thinking, commands the movement of the robot, and processes the environment feedback it receives from the MSI’s PIC. The PIC is the “Central Nervous System” of the robots. It acts as a bridge for data that commands and receives that status of the sensors. The robots sensors include motors and wheels (legs), a communications ECB (ears), IR range detectors (eyes), and whiskers (hands). As Einstein once said, “My body is merely a vehicle for my brain,” so are the robots for the TINI.
Recommendations for improvement
Several observations were made on how to improve our robot after the final prototype was built. One of the major observations made was the disproportionate movement of our robot. In order to solve this problem we could have used a more sophisticated microcontroller with a built in compensator. This would allow us to write a program to compensate for the inconsistencies in the motor characteristics.
A more sophisticated motor system would improve the overall movement performance of the robot. This would provide improved motor characteristics and torque allowing us to move at higher speeds. Improved motors will also increase the amount of weight to be added to our robot without decreasing its performance. It would also reduce the amount of compensation needed.
A braking system could be incorporated into our design. Uneven coasting of the motors was occurring when the robot was coming to a complete stop causing our robot to veer in one direction. The braking system would prevent any veering by making the motors stop rotating at the same time.
During the latter stages of our design we discovered that the ECB’s voltage regulator was receiving inadequate voltage while our motors were turning. To accommodate for this problem, a battery rated at a higher voltage could have been used. This would provide enough voltage to the 5.2 voltage regulator to keep it from supplying insufficient power needed for the ECB.
A digital LCD (liquid crystal display) for the MSI board would allow us to observe the actual commands being executed. This would allow us to confirm that the robot is executing the given commands specified. In addition, any problems associated with the MSI board can be detected and displayed.
Power issues are a main aspect of our robot. At the moment there is noefficient way of identifying the status of the battery. To improve this aspect, a battery indicator can be implemented to reveal the life of the battery. This would allow us to program the robot to charge it’s battery when need be.
Conclusion
The completion of four functional robots was accomplished during the time allocated for the Senior Design. The robots were implemented using strategic approaches to meet all the specifications. The evolution of the robots originated from a simple Altoids Bot consisting of a simple design controlled by a processor with undersized stepper motors to a full-fledged robot controlled by a dominant TINI microprocessor incorporating the use of infrared sensors, gear ratio motors, and a highly sophisticated communications system to allow it to communicate with its fellow robots. During the process of our design, we were successfully able to document our procedures in building the robot. This can be found in the construction manual. In addition, this allowed us to demonstrate how to operate our robots. This is information can be found in the users guide. This information will prove invaluable to application programmers who would like to reproduce our design. With these robots, investigations can be made on the local interaction between a set of homogenous robots. Further advances can be made on how to improve the communication techniques between these homogenous robots.
Acknowledgements