Autonomous COTS Bots

The goal of this project is to use the Commercial-Off-The-Shelf (COTS) Bots platform and add inter-robot communication and autonomy to perform cooperative tasks.

The COTS requirements for our robots are that they are:


 * Affordable (<$500)
 * Easy and quick to assemble (e.g. <30 minutes, no soldering)
 * Computationally powerful
 * Programmable using modern languages and fully featured IDEs.
 * Durable

Most of the people involved in the COTS Bots project have computer science backgrounds and as such, the focus of the COTS Bots project is on the software element of the project rather than the hardware element. The hardware for the bots should then be simple to build and maintain while still allowing for computationally powerful software.

Design Task
A considerable amount of previous work has gone into the designing, building and evaluation of multiple robot designs. The most successful design so far has consisted of three basic components:


 * 1) The "brains" -- typically a smartphone or netbook.
 * 2) The "body" -- the platform from an RC car, tank, truck, or other vehicle.
 * 3) The "spinal cord" -- a microcontroller or motor controller, such as made by Arduino or Phidgets.

The brain controls the robot, the body moves the robot and the spinal cord acts as the communication between the brain and the body.

The primary sensors for the robots are contained in the "brain" and include, in the case of a smartphone, one or two cameras, a microphone, accelerometers, tilt sensors and GPS transceivers. In addition, other sensors, such as bump sensors and infrared or ultrasonic range detectors, can be plugged into the "spinal cord" as well.

The "brain" also comes with easy to access output devices such as speakers and screens.

Problem Statement
Currently, the robots can each perform their own task, such as following an object or driving along a path, but communication between robots has been a challenge. Rudimentary communication is possible using the output devices. With this, for example, an image could be displayed on one robots screen and other robot could see this and react accordingly. There are many limitations to this, the most glaring being that the receiving robot must be behind the sending robot in order to even see the message. The robots would need to switch places to send a reply. A robust method of communication is needed in order for the robots to be able to work together to complete tasks.

Design Goals
Our major project goals are:
 * Simplicity for the end user
 * Small Packet Size
 * Extensibility
 * Flexibility
 * Reliability

Detailed Specifications
The primary requirements of the protocol are as follows:

Background Research
The most recent iteration of the COTS Bots at the University of Idaho currently uses an Arduino-based microcontroller unit (MCU) that communicates with an Android-based smartphone. These two devices communicate over a Bluetooth connection between a Bluetooth module added to the Arduino MCU and the Android's built-in Bluetooth module.

We looked at different microcontroller units that could replace the Arduino with an MCU that had all of the needed communication modules pre-installed. We looked at:


 * BeagleBone
 * Raspberry Pi
 * Different Arduino Boards (such as the Arduino Due)

Final Design
For the current implementation, we decided to use the existing Arduino Romeo v2 MCU that is currently being used by our customers. This MCU has DC motor controllers built in -- installing them ourselves would be time-intensive and violates the COTS Bots ideal that says the robots should be easy to build.

We have also decided to use the XBee Series 1 RF Module with the DigiMesh network protocol firmware installed. The flexibility of not having to rely on a coordinator node while still having a mesh network was important enough that the benefits outweighed the downsides (such as the limited amount of documentation available and the fact that the DigiMesh protocol is proprietary).

The Romeo v2 has a reserved section for attaching an XBee to it so there will be no shield required to use the XBee on the Romeo v2.

The Bluetooth also has a dedicated connection on the Romeo v2 board; however, in order for the Bluetooth and XBee to communicate at the same time, we need to use a Bluetooth shield. This is because both the dedicated Bluetooth and the dedicated XBee devices use the same pins to transmit and receive messages. By using a Bluetooth shield and an Arduino library called "SoftwareSerial", we can redefine which pins are used for transmitting and receiving on the Bluetooth shield.

Chris Waltrip
Computer Science Student

Hometown: Coeur d'Alene, ID

Bio: Chris is a senior undergraduate in Computer Science at the University of Idaho. He is also a NSF Scholarship for Service (SFS) CyberCorps Student and system administrator for the Center for Secure and Dependable Systems (CSDS).

Email: [mailto:walt2178@vandals.uidaho.edu walt2178@vandals.uidaho.edu]



Robert Meine
Materials Science & Engineering Student

Hometown: Fruitland, ID

Bio: Robert is a double major in Computer Science and Materials Science & Engineering at the University of Idaho. He is currently studying Microcontroller & Network Applications and is interested in time synchronization in distributed networks.

Email: [mailto:mein1156@vandals.uidaho.edu mein1156@vandals.uidaho.edu]