ECE 4006
CONVOYbots
Project Proposal
Anees Elhammali
Michael Malluck
John Parsons
Namrata Sopory
September 22nd 2003
Georgia Institute of Technology
College of Engineering
School of Electrical and Computer Engineering
1
Executive Summary
In the military as well as in scientific expeditions, environments are often deemed too
hazardous for human presence. This project seeks to develop a remotely monitored,
unmanned convoy of robots that could potentially be used for transporting materials over
long distances in such circumstances. A base station will be used to remotely control and
guide the lead robot for the convoy. Visual feedback obtained from the robot will ease
this process. The lead robot will be made to communicate its path to slave robots over an
802.11b wireless connection. The slave robots will then follow, forming an unmanned
convoy. Unique to this project is the use of Arcom’s Olympus development board with
Windows Embedded XP that will function as the robot controller and interface to the
wireless link.
2
Table of Contents
1. Introduction
1
2. Project Technical Details
2
3. Tasks and Schedule
6
4. Proposed Demonstration
7
5. Marketing and Cost Analysis
8
6. Bibliography
10
3
Introduction
Today, numerous development boards with an array of embedded software
capabilities are available in the market. These boards can be interfaced with hardware to
achieve a wide range of functionality with varying costs. The aim of this project is to use
three Arcom Olympus boards (running the Windows Embedded XP operating system),
each mounted atop an Amigobot robot, to a.) control the movement of the robot, b.)
establish wireless links with other boards using a wireless game adapter featuring the
802.11b protocol, and c.) transmit the path traversed by a lead robot to slave robots,
causing them to follow, thus forming an unmanned convoy. Convoys of this nature may
find use in military or scientific expedition scenarios where environments are deemed too
harsh or dangerous for human presence. The Olympus boards will thus be used as robot
controllers.
This project will be divided into different phases. In each phase, the tasks to be
accomplished will be modularized and assigned to one or more team members.
The first phase of the project is research and study. Substantial research and study
will be undertaken by all team members a.) to determine the feasibility of each goal b.) to
identify technology, code and documentation that can be leveraged to accomplish project
goals, and c.) to allow team members to familiarize themselves with the language that
will be used to code the project.
The second crucial phase of the project involves the development of code. This
phase will be modularized to address different aspects of the project. The first among
these is the development of a robot control module that will run on the Olympus board.
The module will be used to interface the board with the robot and control its movement in
4
a given direction. To ensure that correct signaling protocols are used, the Amigobot
manual [1], and code written in previous design projects will be studied. The second
important task is the development of a standard module to enable wireless
communication between two Olympus boards over the 802.11b protocol using the
wireless game adapter. To this end, the features of the game adapter, and ethernet
protocol requirements will be analyzed. The third task in this phase involves determining
an algorithm to guide the lead robot. A control station (laptop) will be used to remotely
control the lead robot based on this algorithm. This calls for the development of a
graphical user interface that will run on the laptop. A fourth aspect of this phase is to get
visual data from a CMUcam mounted on the first robot and transmit this to the control
station
The third phase of the project will involve testing and debugging individual
modules of code. This will be followed by the fourth phase in which the working
modules will be integrated, tested and revised if the need arises. Some time will be spent
earlier on to develop hardware to mount the various components (board, network adapter
and voltage regulators) on top of the amigobots.
If time permits, we will work on our secondary goal which is implementing an
obstacle detection algorithm for the robots in the convoy.
Project Technical Details
A block diagram of the convoy system is shown below in Figure 1. The system
will be comprised of four physical parts. The user will operate the convoy with a laptop
5
and wireless hub. There will be three robots called Bot1, Bot2 and Bot3, making up the
convoy. Bot1 will be the first robot in the convoy and Bots 2 and 3 will follow.
When the system is turned on the laptop will establish communication with Bot1
through the hub. On the user’s command, Bot1 will traverse a path while simultaneously
storing details of its movement. The camera on Bot1 will be used to snap pictures of the
environment that will be sent back to the laptop at regular intervals. The visual feedback
will help the user guide Bot1 further.
To set the convoy underway, the laptop will “wake up” and establish
communication with Bots 2 and 3. Bot1 will do the same. Bot1 will then transmit its path
and movement details to Bots 2 over the 802.11b wireless Ethernet link. Should Bot2
6
catch up to Bot1, it will stop to wait for further instructions from Bot1, which will happen
once Bot1 makes a further movement to get back ahead of Bot2.
Once Bot2 is under way, Bot3 can be activated at any point by the user. It will
begin to operate in the same manner as Bot2 with the exception that it will trail Bot2
rather than Bot1. It will receive path information from Bot1 only as Bot1 receives
confirmation from Bot2 that a segment of the path has been completed. This will keep the
convoy in order and prevent the robots from getting in each other’s way.
The user front end will consist of the GUI depicted in Figure 2. Each of the start
buttons will start that given robot and it will begin to behave in the manner described
previously. When one of the ‘Stop Bot’ buttons is selected, the given robot will be
stopped immediately. Any robots behind it will move normally until they catch up to the
stopped Bot at which time they will then stop. Any bots ahead of the stopped Bot will not
be affected. The ‘Stop All’ button will stop all three bots immediately. The pictures
received from Bot1 will be displayed in the visual feedback window. Finally, indicators
on the right side of the GUI will turn red whenever a Bot is stopped because of a detected
obstacle.
7
If this functionality is completed with time to spare, work will be started on an
algorithm allowing the bots to navigate around an obstacle and get back on the desired
path. This would allow the convoy to make it to its final destination unassisted even if
unexpected obstacles are encountered.
A listing of the possible hardware requirements for this project is stated in Table 1.
Table 1. Anticipated Project Hardware Requirements
Part
CMU Cams
Amigobots
Olympus Dev.
Kit
Olympus Boards
Network Adapter
Wireless Router
(802.11b)
Voltage
Regulators
Part Details
Source
OLYMPUS
SBC-GX1
(Pegasus)
with
WINDOWS
CE (.NET)
OLYMPUS
M0- 16
(with 16Mb
onboard
flash)
WGA11B
(wireless
game
adapter)
BEFW11S4
Arcom
Qty
3
3
1
Arcom
2
Linksys
(get it off
Amazon)
3
Linksys
(get it off
Amazon)
Datel
1
LSN-5/10D12
3
It should be noted that Java will be used to program the Amigobots. One point of
concern is the speed of which Java will execute. Java, being an interpreted language tends
to be slower than lower level languages such as C. The cut in performance has been
weighed against the ease of coding in a higher level language and it was decided that
more could be accomplished by working with Java.
8
Tasks & Schedule
Time management will play an important role in the development of this project.
To complete the project successfully, the project will be broken up into smaller tasks.
These tasks, as well as the people responsible for them can be seen from the Gantt chart
below.
Figure 3. Gantt Chart Showing Projected Timeline.
Due to the modularity of the project, tasks such as coding the robot driver, camera
driver and Ethernet communication drivers may be done in parallel. Part of this is due to
the fact that Java is a high level language and allows for a greater degree of freedom
between the hardware and software aspects of the design. Also, the Object Oriented
nature of Java makes it very easy to break large tasks down into a series of smaller tasks.
One of the key factors to successfully completing this project is organization and
documentation. Substantial amounts of code can be effectively written so long as
9
dependant functions being written in parallel operate as specified. Before actually coding
the various modules, it will be necessary for each method’s function, inputs, outputs, and
global variables to be well documented. This way anyone depending on this code will
know how it is expected to function and can begin to code even if the other group is
behind schedule.
It should be noted that there are some tasks which need to be performed in
sequential order. These are potential stumbling blocks that can hold up the project. The
first of these is the coding of the individual hardware drivers. These drivers are the core
of what will be used to control the robot. Without them, coding the main algorithm is
very difficult. Another point of concern is the second half (back-end) of the user
interface. It is again dependant on the completion of the main algorithm. After the first
robot is completed the user interface can be integrated into the design.
It should be noted that the timeline depicted above is a ‘proposed’ timeline, and is
as such subject to change. Also, depending on the progress made by each team member
in his or her assigned task, support will be provided on a need basis to other team
members.
Proposed Demonstration
The robot convoy project will be tested in an empty classroom in Van Leer. The
environment will contain large obstacles such as boxes and chairs. The laptop control
station will be set up in the room. The wireless hub will also be in place to allow the
establishment of a wireless link to the master and slave robots. Using the user interface
for the project on the laptop, the lead robot (Bot 1) will be guided around the room in a
10
random path. Bots 2 and 3 will be expected to follow the same path with a reasonable
time delay. The convoy will also be expected to stop correctly when directed to do so by
the control station.
Marketing and Cost Analysis
Unmanned vehicles have a wide range of applications that drive a large sector of
today’s technology market. The largest portion of these applications deal with reducing
the risk of losing humans driving vehicles in dangerous situations, and reducing the cost
associated with having humans actually operating these vehicles. Our product will have a
competitive edge in this market because it could be the starting tool to any technology
that aims to achieve such goals.
The primary target for our product is the military. The Department of Defense has
requested over a billion dollars from the US senate to fund the military transformation
project, which contains a variety of projects that use unmanned vehicles [2]. Our product
could be marketed as the starting point of unbound research in such projects. The
approximate cost of our project, as stated in the table 2 is $9600. The cost could be lower
when larger portions are purchased. We believe that the cost of our product is affordable
compared to the time and effort it saves anyone who wants to incorporate such
technology in larger projects. Also, the long lifetime of such a product would enable a
recovery of initial product costs.
11
Table 2. The Estimated Cost of Robot Convoy
Component
Amigobot Robot
Arcom Olympus board
CMU Camera
Linksys (WGA11B) wireless game
adapters
Linksys BEFW11S4 Wireless Router
TOTAL COST
Cost (in dollars per unit)
2000
1000
150
50
One component cost=$3200
Intermediate cost= $9600
70
~$9670
Although substantial research has been done in the field of sensing and
communication for robot convoy navigation [3], this may be the first such convoy using
the Amigobot interfaced with an Olympus board running the Windows Embedded XP
operating system. As such, there is no existing product like this. According to research
done by UCLA team of engineers, there has been a lot of effort to collaborate robots to
accomplish a task in uncertain environments over the past years without much success
[4]. One reason for this may have been the tools used to transmit as well as interpret data.
With this project, we aim to introduce the Olympus board, Windows Embedded XP, the
Amigobot and the 802.11b standard as a platform to achieve results in endeavors
involving collaborative robots. We aim to give a solid starting point product for all
projects that need to deploy unmanned robots in uncertain environments.
12
Bibliography
[1]
ActivMedia Robotics “AmigoBOT Technical Manual,” (2000), Available HTTP:
http://www.ece.gatech.edu/research/labs/diglab/downloads/AmigoTech.pdf
[2]
Department of Defense Transformation Project, Available HTTP:
http://www.defenselink.mil/specials/transform/
[3]
G. Dudek, M. Jenkin, E. Milios, D. Wilkes, ”Experiments in sensing and
communication for robot convoy,” International Conference on Intelligent Robots
and Systems (IROS), pp. 268-273, August 1995.
[4]
M.J. Mataric, G.S. Sukhatme, E.H. Ostergaard, “Muti-robot task allocation in
uncertain environments,” Autonomous Robots, vol. 14, no. 2-3, pp. 255-63, May
2003.
13