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
The current COTS Bots can perform tasks individually, but the current communications methods between robots for coordinated tasks have limitations. For example, the robots have been trained to follow one another by using image-recognition of a particular shape that is mounted to the robots. Typically, a colored foam sphere is attached to a rod which is then attached to a robot. By chaining spheres of different colors together, a train of robots could be formed -- each robot would follow a specific color and then the lead robot could be tasked with following a given path or could even be controlled via remote control (in fact the lead vehicle, if controlled remotely, would not even need to be a robot but just an RC vehicle). The robots could also be connected using a wireless access point -- the "brain" of each robot typically has a WiFi device that can communicate over the 802.11 wireless standard. The range of WiFi however is rather limited and is easily susceptible to electrical interference.

Design Goals
Our project goal is then to find a viable way for the robots to communicate with each other that overcomes limitations such as a low range and electrical interference. So our primary goal is to adopt a physical later and a transport networking standard. We will need to design and develop a protocol for managing all of the robots on our network as well that operates on this networking protocol.

Our main goals for the networking protocol are:
 * Simplicity for the end user
 * Small Packet Size
 * Extensibility
 * Flexibility
 * Reliability

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

Physical Network
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)

A number of initial designs were looked at but discarded for one reason or another. One idea has been to have to a mobile wireless central access point that would travel with the robots. It could even be stationed on one the of robots that was also assigned to a task (i.e. there is no need for the access point to be on a dedicated robot platform). The primary issue with this is one that was seen with all of the initial designs -- If the central access point is destroyed, the entire network is disconnected and the robots will lose their ability to communicate with each other until another access point is deployed and all of the robots are instructed to join the new network.

After this, we decided that a dedicated access point was not a viable solution for our network. We turned to the XBee RF modules that the Romeo v2 boards support. The XBee Series 1 supports a network topology based on the IEEE 802.15.4 protocol which allows for point-to-point (unicast) or star (broadcast) topologies to be used. In point-to-point mode, any loss of robot could leave robots stranded and unable to receive messages from other nodes in the network. In the star topology, the central node (or broadcaster) is a single point of failure. If that robot were to be destroyed then all of the robots would become stranded; if an endpoint were to leave the range of the broadcaster then it would become stranded as well. This last failure will be an issue in any network, but it is more noticeable in this sense because there is only one robot that needs to be outside of the range of the endpoint to cause loss of connection. This issue is remedied as much as it can be in our chosen design.

After looking at the XBee Series 1, we looked at the XBee Series 2 supports the ZigBee Protocol. The ZigBee protocol is based on the IEEE 802.15.4 however allows for a (partially connected) mesh network topology. In the ZigBee protocol however, there is one "ZigBee Coordinator (ZC)" node that is responsible for the initial network creation and stores network information including the Trust Center and is the repository for the security keys for all of the nodes on the network. Then there are "ZigBee Router (ZR)" nodes which are responsible for routing messages from between nodes on the network. Finally, there are "ZigBee End Device (ZED)" nodes which only has enough functionality to send and receive messages to either the ZC or a ZR node (whichever node is its single parent). Once again, just like with the two previous designs, the loss of the coordinator node will severely limit the capabilities of the network. Also, because it stores the Trust Center, if authentication and security become an issue with the project, then the loss of the ZC node becomes catastrophic. The ZigBee Coordinator node is assigned at the firmware and so in the case of a loss of the ZC, a robot will need to be reprogrammed, dispatched and the entire network will need to be recreated. This also requires that an operator be in the area of the robots to be able to actually dispatch the new robot.

During our research we discovered that the previously discarded XBee Series 1 RF module was capable of a mesh network protocol as well. However, instead of the ZigBee protocol that the Series 2 uses, it uses a protocol called the DigiMesh Networking Protocol, which was created by Digi International, the company responsible for creating and manufacturing the XBee RF Module itself. In a whitepaper released by Digi about the differences between the DigiMesh Networking Protocol and the ZigBee Networking Protocol, Digi advertised that the advantages of DigiMesh were:
 * Network setup is simpler
 * More flexibility to expand the network
 * Increased reliability in environments where routers may come and go due to interference or damage

This last point is possible because the DigiMesh has only one node type, the "DigiNode (DN)." The DigiMesh network is a "homogenous network", where "all nodes can route data and are interchangeable" and there are no parent-child relationships. This means that the network is decentralized and the lack of a coordinator node required to setup the network means that the network can gain or lose robots with relatively few issues. Where in the ZigBee network, a ZigBee End Device (ZED) cannot mesh -- they have one specific parent (either a router or the coordinator) -- all DigiNodes are routers and can created a partially or fully connected network.

Network Topology Examples
The following images are recreated from the images found in the ZigBee vs. DigiMesh whitepaper released by Digi International.

Communication Method
The second problem that needs to be solved is that of sending instructions that the robots can process once the robots are on a physical network together. We need a protocol that is small enough that all of the different subsystems (such as the Arduino MCU or the Android phone in the current case) can parse the messages effectively.

One idea was to use the Simple Network Message Protocol (SNMP). SNMP is, as the name implies, relatively simple to use and is quite flexible/extensible because the protocol does not need to know the contents of the data payload that it carries. The problem with SNMP in the case of this project is that it may be unnecessarily large for our needs. The object identifiers (OIDs) in SNMP are unique worldwide -- each corporation that registers to use SNMP has a dedicated set of OIDs assigned to it to use, much like how IP Addresses are reserved in chunks for different uses. One of the other problems with SNMP using the hardware that we currently use in the COTS Bots project is that the available Arduino libraries that implement SNMP can take up a large portion of the available space on the Arduino.

Our next idea then was to create a protocol that was loosely based on SNMP but that did not have the features that we needed. For example, our OIDs could be unique just to the COTS Bots project -- this would reduce the size of each individual packet because fewer bits would need to be reserved for the address and the instruction type. The data payload would be similar to SNMP though because all it consists of is a field for length of the entire payload section and then the data itself. The payload inside the data section could then be formatted however the user wanted, including being nested data payloads.

Current Design
Our goal this semester has been primarily that of research -- our design is not final and is still subject to change throughout the next semester. However, 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.

The Romeo v2 also 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.

We have decided to use a protocol that we have created that is loosely based on the Simple Network Message Protocol (SNMP). This lets us create small packets with any payload. This gives us future extensibility and flexibility for different tasks because the communication protocol does not need to have any information about what the data payload is made to do -- it just passes the information on to whichever node is requesting the information. The Android phone (in the current version of the project) is then responsible for translating the message and sending the necessary command to the necessary subsystem (likely on the Arduino MCU).

Current Progress
A test suite has been developed to help facilitate the construction of properly formatted messages. This test suite then can send these messages (packets) to an Arduino MCU over a USB connection. It is then possible for that Arduino MCU to transmit the packets to a second Arduino MCU over the XBee radios. The second Arduino receives the message and carries out the instruction provided to it. In the test suite, this is just to turn the LED that is installed on the Arduino MCU on and off -- this means that testing can occur without actually having to set the entire robot platform up. The next task then is to move from using the USB connection to the Bluetooth connection. After this, our next goal will be to make network discovery more robust to facilitate the adding and removing of devices on the network. Once robots are on the network the DigiMesh protocol should then be able to handle most of the message rerouting that would have to occur in the case of a node failing for some reason.

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). His interests lie in information assurance and network security.

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]

Design Documentation

 * Team AutoCOTS Master Design Document

Presentations

 * 2014 Mid-Semester CS-480 Presentation
 * 21st Annual Engineering Design EXPO Poster