1. MOBILE ROBOTICS COMMUNICATION
Harini Suresh Mentor: Prakash Rajendran
1 Problem Statement
To establish Vehicle to Vehicle (V2V) communication in autonomous mobile robots that enables
the Intelligent Transportation Systems (ITS).
2 Literature Survey
Mobile robots are automatic machines which have the capability to move around in their environ-
ment and are not fixed to one physical location. They are grouped based on the environment in
which they travel as unmanned ground vehicles, unmanned aerial vehicles, autonomous underwater
vehicles and polar robots. Vehicular communication systems are a type of network in which vehicles
and roadside units are the communicating nodes, providing each other with information, such as
safety warnings and traffic information. A VANET (Vehicular Ad Hoc Network) comprises of
radio-enabled vehicles which act as mobile nodes as well as routers for other nodes allowing cars
approximately 100 to 300 metres of each other to connect and, in turn, create a network with a
wide range.
They can be distinguished from other kinds of ad hoc networks as follows:
• Highly dynamic topology
• Sufficient energy and storage
• Geographical type of communication
• Mobility modelling and predication
• Various communications environments
• Hard delay constraints
• Interaction with on-board sensors
VANET helps to provide ubiquitous connectivity and efficient inter vehicle communication that
enable Intelligent Transportation System(ITS) and also to provide internet connectivity so
that users can download music, send emails etc. ITS includes a variety of applications such as
co-operative traffic monitoring, blind crossing, prevention of collisions, and real time detour routes
computation.
Vehicular networking applications include active road safety, traffic efficiency and management
and infotainment. Vehicular networking requirements are derived by studying the needs of the
applications and the use cases. They are classified as strategic, economic and system capabilities.
1
2. Architecture of VANET can be classified into three categories:
• Pure cellular/WLAN
• Ad Hoc
• Hybrid
Dynamic nature of the mobile nodes makes finding and maintaining routes very challenging in
VANETs. The protocols were categorized as:
• Ad Hoc Routing
• Position-Based Routing
• Cluster-Based Routing
• Broadcast Routing
• Geocast Routing
Instead of establishing communication between each and every vehicles, grouping of vehicles
into platoon increases fuel efficiency, reduces collisions and increases capacity of roads. In our
problem we consider a P3-DX and two amigobots to be the mobile nodes.
3 Challenges faced and solutions proposed
1. Platooning
• Each platoon has a fixed driver and a set of autonomous vehicles.
• Each platoon is given a different colour based on the operation like adding to a platoon,
deleting from a platoon.
• A different colour is given to break down vehicles to call for repair.
2. Relaying real time information between the nodes
• Arduino code is written to transmit and receive data.
• LM393 comparator speed sensor module for Arduino can be used to transmit the speed
from the mobile robots.
4 Final Solution
Three mobile nodes and a single fixed node were considered. The mobile robots are operated using
ARIA. Real time information was transmitted and received between the nodes using Arduino
and XBee. To obtain the speed of the mobile robots external speed sensor module is connected
using Arduino.
2
3. 5 Things that I learnt
• The advantages of implementing V2V communication
• Advantages of platooning over normal ITS
• Arduino code to transmit and receive data
• ARIA API used for programming mobile robots
• During my short stint at IIT Madras I learnt how to work as a team and working in the lab
was very helpful.
3
4. Appendix
ARIA stands for ActivMedia Robotics Interface for Application and it is an object-oriented Appli-
cations Programming Interface (API), written in C++ and intended for the creation of intelligent
high-level client-side software. It is a software packages that is used to write high level control
programs for the Pioneer 3 robots (AmigoBots, PeopleBots, Pioneers). ARIA is technically archi-
tecture independent.
The various codes implemented on the P3-DX are actsColorFollowing, demo, gps, gripper,
gyro, joydrive etc. ARIA software must be installed on both the robot and the PC where we in-
tend to compile, test and run the programs. MobileSim software can also be used for simulating
MobileRobots/ActivMedia platforms and their environments, for debugging and experimentation
with ARIA.
ARIA code used to run the P3-DX robot (wander mode):
#include ”Aria.h”
int main(int argc, char **argv)
{
Aria::init();
ArArgumentParser argParser(&argc, argv);
argParser.loadDefaultArguments();
ArRobot robot;
ArRobotConnector robotConnector(&argParser, &robot);
ArLaserConnector laserConnector(&argParser, &robot, &robotConnector);
if(!robotConnector.connectRobot())
{
ArLog::log(ArLog::Terse, ”Could not connect to the robot.”);
if(argParser.checkHelpAndWarnUnparsed())
{
// -help not given, just exit.
Aria::logOptions();
Aria::exit(1);
return 1;
}
}
// Trigger argument parsing
if (!Aria::parseArgs() —— !argParser.checkHelpAndWarnUnparsed())
{
Aria::logOptions();
Aria::exit(1);
return 1;
}
ArKeyHandler keyHandler;
4
5. Aria::setKeyHandler(&keyHandler);
robot.attachKeyHandler(&keyHandler);
puts(”This program will make the robot wander around. It uses some avoidance}n”
”actions if obstacles are detected, otherwise it just has a}n”
”constant forward velocity.}n}nPress CTRL-C or Escape to exit.”);
ArSonarDevice sonar;
robot.addRangeDevice(&sonar);
robot.runAsync(true);
// try to connect to laser. if fail, warn but continue, using sonar only
if(!laserConnector.connectLasers())
{
ArLog::log(ArLog::Normal, ”Warning: unable to connect to requested lasers, will wander using
robot sonar only.”);
}
// turn on the motors, turn off amigobot sounds
robot.enableMotors();
robot.comInt(ArCommands::SOUNDTOG, 0);
// add a set of actions that combine together to effect the wander behavior
ArActionStallRecover recover;
ArActionBumpers bumpers;
ArActionAvoidFront avoidFrontNear(”Avoid Front Near”, 225, 0);
ArActionAvoidFront avoidFrontFar;
ArActionConstantVelocity constantVelocity(”Constant Velocity”, 400);
robot.addAction(&recover, 100);
robot.addAction(&bumpers, 75);
robot.addAction(&avoidFrontNear, 50);
robot.addAction(&avoidFrontFar, 49);
robot.addAction(&constantVelocity, 25);
// wait for robot task loop to end before exiting the program
robot.waitForRunExit();
Aria::exit(0);
return 0;
}
5
6. XBee is a wireless microcontroller made by digi using zigbee protocol to communicate between
two wireless radio. It consists of 20 pins and an antenna and operates at a voltage of 3.3V. XBee
network consists of the following:
• Co-ordinator: It is in-charge of setting up the network. Only 1 per network must be present.
• Router: Used to relay signals from the other routers. Multiple routers can be present.
• End Point: Denotes the end point of a network. It can sleep to save power and multiple end
points can be present in the network.
It works in two modes namely AT and API. FTDI cable can be used for connecting the XBee
to the computer or FTDI adapter can be used after connecting the XBee in the bread board.
XCTU is a free multi-platform application designed to enable developers to interact with Digi
RF modules through a simple-to-use graphical interface. It includes new tools that make it easy
to set-up, configure and test XBee RF modules.
Arduino code for transmitting data using XBee:
#include <XBee.h >
#include <SoftwareSerial.h >
#define XB 1 0x5678
#define XB 2 0x1234
SoftwareSerial mySerial(10, 11); // RX, TX
XBee xbee = XBee();
unsigned long start = millis();
// allocate two bytes for to hold a 10-bit analog reading
uint8 t payload[] = {
0, 0};
//uint8 t payload = 0;
// with Series 1 you can use either 16-bit or 64-bit addressing
// 16-bit addressing: Enter address of remote XBee, typically the coordinator
Tx16Request tx = Tx16Request(XB 2, payload, sizeof(payload));
// 64-bit addressing: This is the SH + SL address of remote XBee
//XBeeAddress64 addr64 = XBeeAddress64(0x0013a200, 0x4008b490);
// unless you have MY on the receiving radio set to FFFF, this will be received as a RX16 packet
//Tx64Request tx = Tx64Request(addr64, payload, sizeof(payload));
TxStatusResponse txStatus = TxStatusResponse();
int pin5 = 0;
byte i=0;
byte flag=0;
6
7. void setup() {
mySerial.begin(9600);
xbee.setSerial(mySerial);
Serial.begin(57600);
}
void loop() {
// start transmitting after a startup delay. Note: this will rollover to 0 eventually so not best
way to handle
if (millis() - start ¿ 15000) {
// break down 10-bit reading into two bytes and place in payload
/* pin5 = analogRead(5);
payload[0] = pin5 ¿¿ 8 & 0xff;
payload[1] = pin5 & 0xff;*/
payload[0]= i;
payload[1]= i*2;
flag=1;
xbee.send(tx);
Serial.print(”Sending data : ”);
Serial.print(i);
Serial.print(” and ”);
Serial.print(2*i);
Serial.println(” ...”);
}
else
{
Serial.print(”Will start transmiting after ”);
Serial.print((15000 + start - millis())/1000);
Serial.println(” seconds....”);
}
// after sending a tx request, we expect a status response
// wait up to 5 seconds for the status response
if (xbee.readPacket(5000)) {
// got a response!
// should be a znet tx status
if (xbee.getResponse().getApiId() == TX STATUS RESPONSE) {
xbee.getResponse().getZBTxStatusResponse(txStatus);
// get the delivery status, the fifth byte
if (txStatus.getStatus() == SUCCESS) {
// success. time to celebrate
Serial.println(”Data Sent”);
i++;
}
else {
7
8. // the remote XBee did not receive our packet. is it powered on?
Serial.println(”Data Not Sent. Unable to locate local xbee”);
}
}
}
else if (xbee.getResponse().isError()) {
//nss.print(”Error reading packet. Error code: ”);
//nss.println(xbee.getResponse().getErrorCode());
// or flash error led
Serial.println(”Other Xbee unable to read data”);
}
else if(flag) {
// local XBee did not provide a timely TX Status Response. Radio is not configured properly or
connected
Serial.println(”Unable to talk to local Xbee”);
}
delay(500);
}
8
9. Arduino code for receiving data using XBee:
#include <XBee.h >
#include <SoftwareSerial.h >
#define XB 1 0x5678
#define XB 2 0x1234
SoftwareSerial mySerial(10, 11); // RX, TX
XBee xbee = XBee();
XBeeResponse response = XBeeResponse();
// create reusable response objects for responses we expect to handle
Rx16Response rx16 = Rx16Response();
Rx64Response rx64 = Rx64Response();
int statusLed = 11;
int errorLed = 12;
int dataLed = 10;
uint8 t option = 0;
uint8 t data[2] = 0,0;
void setup() {
mySerial.begin(9600);
xbee.setSerial(mySerial);
Serial.begin(57600);
}
// continuously reads packets, looking for RX16 or RX64
void loop() {
xbee.readPacket();
if (xbee.getResponse().isAvailable()) {
Serial.println(”Got something ...”);
if (xbee.getResponse().getApiId() == RX 16 RESPONSE —— xbee.getResponse().getApiId() ==
RX 64 RESPONSE) {
Serial.print(”Got an Rx packet - ”);
if (xbee.getResponse().getApiId() == RX 16 RESPONSE) {
xbee.getResponse().getRx16Response(rx16);
option = rx16.getOption();
data[0] = rx16.getData(0);
data[1] = rx16.getData(1);
Serial.print(”It is a 16-bit response : ”);
Serial.print(”Data[0] - ”);
Serial.print(data[0]);
Serial.print(” Data[1] - ”);
9
