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).

Spring 2014 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.

Goals

 * Research and select an upgraded hardware platform that can handle the extra communication channel.
 * Enable phone to phone communication.
 * Improve protocol for robot to robot communication.
 * Positional Awareness - develop a system that would allow the robots to determine the position of other robots in the group.
 * Begin design of the Android application.

Hardware Upgrade
The Arduino MCU that was used on the current COTS robot was the Romeo V2 from DFRobot. The Romeo board is based on the Arduino Leonardo controller. This board has only a single hardware serial port. Two channels would be needed to handle simultaneous communication over the bluetooth and XBee devices. In the previous semester, they had success with using the SoftwareSerial library to create a virtual serial port. However after further testing, interrupt conflicts were observed between the virtual serial port and the motor controller.

Selected MicroController
We chose to stay with the Arduino hardware platform to minimize the need to rewrite the existing code base. Several variants of MCU boards are easily available, and our major requirement for a new platform was that it needed more than a single hardware serial interface. A quick comparison between Arduino boards can be found [here]. Controller boards can be grouped into two sets, those with a single serial port, and those with four lines. Our choice was then between the Uno and Mega families. The COTS program here at the University of Idaho is an on going project that will continue. In order to allow for a high level of expansion available to future projects, access to add-on shields and software support, we selected the Mega platform.

Mega Features
 * CPU - 16MHz
 * Analog I/O pins - 16
 * Digital I/O pin - 54
 * PWM Pins - 15
 * Serial - 4
 * SRAM - 8kb
 * Flash - 256kb

Arduino Software Design
TODO

Arduino Class Diagram

Android Software Design
TODO

Software Test Suite
TODO

Positional Awareness
Successful completion of group tasks by a set of autonomous robots, requires that each member know the locations of the others members. With the addition of robot to robot communication, a method now exists for coordination.

Solution Requirements

 * Easy to incorporate into current COTs design
 * Fit on robot platform
 * Able to be powered using current supply


 * Follows COTS design requirements
 * Commercial solution
 * No soldering


 * Accuracy
 * Distance: resolution < 30cm
 * Direction: +/- 5 Degrees


 * Assumptions:
 * Design of the solution assumes that the robots will have line of sight of each other
 * GPS signal will not be available
 * Other external sources for determining location are not present

Potential Solutions

 * Signal Strength - The XBee wireless chips contain built in methods that record the signal strength for each message received. Strength of the signal could be used to determine distance of the sender. This method can make no determination of the sender's direction. Perhaps in a large network, a graph can be built using the calculated distance of each node to generate a working location map.
 * Strengths:
 * Requires no additional hardware to implement
 * Use the phone's processing power to generate location graph


 * Weaknesses:
 * Signal strength may not have the fidelity to meet our accuracy goals.
 * Location graph may not be possible.
 * Would probably require a large set of robots to provide a usable dataset.


 * Light and Sound - Additional hardware could be added to each robot that would make them capable of displaying a light source, LED, and a speaker and microphone for sending and receiving sound. Distance and direction would be determined by having a distant robot initiate a light and sound pulse at the same instant. The local robot would time the delay between the light and sound signals arriving.


 * Strengths:
 * LED are simple to include on the Arduino platform.
 * Speaker and microphone hardware can be found that meet the COTS requirements.


 * Weaknesses:
 * Synchronizing light and sound pulses.
 * High speed capture of the light and sound pulses to get accurate time stamps.
 * Requires robot requesting the signal to have the distant robot in line of sight.


 * Precise Timing - Using the internetwork communication, timing signals can be relayed throughout the network to keep each robot's clock synchronized. Time stamps on messages could then be used to determine distance between the sender and receiver.
 * Strengths:
 * Requires no additional hardware to implement
 * Use the phone's processing power to generate location graph


 * Weaknesses:
 * Precise timing signals may require faster processing than an arduino platform is capable of providing.
 * Location graph may not be possible.
 * Would probably require a large set of robots to provide a usable dataset.


 * Camera Perspective Size Change - The camera in the attached smart phone could be used to determine the distance to an object of a known size. Relative change in a size of an object based on pixel size can be used to calculate the distance of the object from the camera.


 * Strengths:
 * Uses phone vision software to find a distant target.


 * Weaknesses:
 * Requires robot requesting the signal to have the distant robot in line of sight.
 * Vision software must be able to determine pixel height of the distant object.

Proposed Solution
Camera Perspective Size Change


 * Benefits:
 * Simplest solution.
 * Able to determine both distance and direction.
 * Will require the implementation of an additional wish list goal of creating a method for the attached phone to be able to move independently of the robot.
 * Challenges:
 * Incorporate additional motor and logic controls.
 * Vision algorithms for finding the size of the distant object.
 * Easy to see markers for determining edges of the distant object.

Size Markers
 * Two LEDs separated by a known distance.
 * LEDs placed on a vertical antenna attached to the robot.
 * Vertical alignment allows for 360 degree view
 * There would be a loss in accuracy if tilted along parallel to the viewer.
 * LEDs of different colors could provide visual contrast to assist with discovery algorithms.

Smart Phone Periscope Mount
 * Mount a smart phone to a stepper motor mounted vertically to the robot chassis.
 * No cabling allows continuous rotation.
 * Direction angle maintained by arduino logic. Homing or zeroing function will be needed to set zero angle after power up.

Position Calculation
Using a rotatable mount for the smart phone, a search can be performed where the phone will pivot and scan its surroundings. While performing this scan, vision algorithms will be processing the live images, searching for the designated LED markers. Once they are in the field of view, the pixel measurement between the two LEDs will be used to determine distance. Distance will be estimated using the [pinhole camera model]. Where the ratio of the pixel height of an object over the focal length is equal to the actual height of the object over the distance from the camera.
 * Direction
 * Distance

$$\frac{\text{Pixel Height}}{\text{focal length}} = \frac{\text{Actual Height}}{\text{Distance}}$$

To calculate the distance, we will first need to calibrate the system to determine the focal length. To accomplish this, we would need to set the remote robot a known distance away from the camera to be calibrated. Once the focal length is known, it can then be used to determine distance.

$$\frac{x_1}{f}=\frac{X}{d_1}$$

Where $$x_1$$ is the pixel difference between the LEDs in the camera image. The actual height (X) is known. Distance to the object $$d_1$$ can now be determined.

Accuracy Estimation

Assuming a camera resolution of about 1 megapixel or 1200 x 900 pixels.
 * Distance Accuracy: +/- .33mm per pixel height change.
 * Useful Range: .3m to 269m.

Current Status
TODO

Greg Donaldson
Computer Science

Hometown: ...

Bio: ...

Email: ...



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]

Jason Kemp
Computer Science

Hometown: ...

Bio: ...

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



Matthew Trana
Computer Science

Hometown: Moscow, ID

Bio: Currently working at Schweitzer Engineering Laboratories as an Equipment Programmer. He is currently studying compiler design and his interests include embedded software and data analysis.

Email: [mailto:tran2733@vandals.uidaho.edu tran2733vandals.uidaho.edu]

Design Documentation

 * Team AutoCOTS Master Design Document

Presentations

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