ROSint - Integration of a mobile robot in ROS architecture

Transcription

Department of Electrical and Computer Engineering
Faculty of Sciences and Technology
University of Coimbra
ROSint - Integration of a mobile
robot in ROS architecture
André Gonçalves Araújo
A Dissertation presented for the degree of
Master of Science in Electrical and Computer Engineering
Coimbra, July 2012
ROSint - Integration of a mobile
robot in ROS architecture
Supervisor:
Prof. Doutor Rui P. Rocha
Co-Supervisors:
Eng. David Portugal
Eng. Micael Couceiro
Juries:
Prof. Doutor Armando Sousa
Prof. Doutor Jorge Lobo
Prof. Doutor Lino Marques
Prof. Doutor Rui P. Rocha
Project report written for the dissertation subject, included in the
Electrical and Computer Engineering Course, submitted in partial fulfillment
for the degree of Master of Science in Electrical and Computer Engineering.
Coimbra , July 2012
Agradecimentos
Em primeiro lugar quero começar por agradecer em especial ao Professor Doutor Rui
Rocha na minha orientação neste trabalho, prezando pelo seu rigor, organização e estimulação constante, onde sempre depositou bastante confiança nas capacidades do meu
trabalho.
Quero também agradecer, pelo apoio incondicional dos meus co-orientadores David Portugal e Micael Couceiro, pela sua persistência, motivação e ajuda nos momentos mais
difíceis deste trabalho. Para além de orientadores, levo desta experiência dois grandes
amigos.
Agradeço também ao Instituto de Sistemas e Robótica, pelas óptimas condições disponibilizadas, bem como todos os meus colegas de trabalho por toda a boa disposição e
companheirismo, que contribuíram para o meu bom estado de espirito, para progredir
neste trabalho.
Aos meus pais, agradeço profundamente pelo empenho, dedicação e paciência que propulsionaram na minha boa formação, dando me sempre a oportunidade de ter tudo de bom
e melhor, obrigado do fundo do coração. Não podendo esquecer, todo o apoio e carinho
prestado pela a minha família e namorada ao longo destes anos: Ângela, avós, tios e
primos.
Não podia deixar de agradecer a todos os amigos de Braga, em especial atenção ao Aníbal,
Bruno, Carlos, Catarina, Joana, Luís, Maura, Rui, Sérgio, Telmo e Vitor por nunca se
esqueceram de mim, apesar do pouco tempo que lhes disponibilizei. Aos amigos de Coimbra, André Oliveira, André Santos, Gonçalo Ferreira, Gonçalo Palaio, João, Nuno, Patrícia Monteiro, Sérgio, as irmãs Patrícia e Filipa Ferraz e muitos outros, que me ajudaram
desde o primeiro dia em Coimbra até ao final.
Um obrigado muito especial, pelo tempo disponibilizado e atenção, por parte das pessoas
v
vi
que contribuíram para a realização deste trabalho Amadeu Fernandes (MRL, ISR), Beatriz Garrido (DEI, FCTUC), Gonçalo Cabrita (LSE, ISR) e Michael Ferguson (University
of Albany / Willow Garage).
Para finalizar, por todos os momentos felizes, pessoas conhecidas, vivências e experiências
passadas e especialmente a pessoa que me tornaste hoje, muito obrigado Coimbra, que
me deixas saudade para a vida.
Abstract
The goal of this work is to provide hardware abstraction and intuitive operation modes
to decrease the development and implementation time of robotic platforms, thus allowing
researchers to focus in their main scientific research motivations, e.g., search and rescue,
multi-robot surveillance, swarm robotics, among others. To that end, this work presents
the development of a compact mobile low-cost robotic platform, denoted as TraxBot, developed and assembled at the Institute of Systems and Robotics (ISR), which has been
fully integrated in the well-known Robot Operating System (ROS) framework.
Furthermore, several available mobile robots are compared and discussed in terms of their
physical dimensions, hardware, sensors, communication abilities, motion, maximum run
time and special features. This provides support to the reader on the decision-making
acquisition process of a cost-effective robotic platform.
Beyond the survey’s results, the robotic system assembly, with a full description of its
components as well as detailed information about the microcontroller programming, development and testing are also presented. The potentialities of the TraxBot are described,
which combined with the herein presented ROS driver; provide several tools for data analysis and easiness of interaction between multiple robots, sensors and teleoperation devices.
In order to validate the approach, several experimental tests were conducted using both
real and mixed teams of real and virtual robots.
Key Words: ROS, Arduino, mobile robot, embedded system, integration.
Resumo
O objectivo deste trabalho é contribuir, através de abstracção de hardware e criação de
modos de operação intuitivos, na redução drástica do tempo de desenvolvimento e implementação de plataformas móveis. Isto permite aos investigadores focarem-se na sua
motivação principal, tal como busca e salvamento, segurança com múltiplos robôs, swarm
robotics, entre outros. Assim sendo, desenvolveu-se no Instituto de Sistemas e Robótica
(ISR), uma plataforma robótica móvel, denominada TraxBot para simplificar este objectivo. A plataforma foi completamente integrada no ROS (Robot Operating System),
bastante em voga actualmente.
Para além disso, é apresentada uma vasta gama de robôs, comparando e discutindo as
suas características físicas, dimensões, sensores incorporados, poder de processamento,
particularidades de hardware, tempo de autonomia bem como a relação qualidade preço.
O TraxBot é apresentado com a total descrição dos seus componentes, dando ênfase a
detalhes sobre programação, unidade de processamento, características sensoriais e abordagem usada para o desenvolvimento deste robô. É de referir ainda, que as potencialidades
da plataforma são discutidas, juntamente com o driver de integração deste robô em ROS.
Esta integração disponibiliza uma grande variedade de ferramentas e métodos de programação, sendo possível a interacção entre múltiplos robôs, sensores e tele-operação, entre
outras aplicações. Para validar a abordagem, foram realizados vários teste, a nível de desempenho da plataforma, bem como testes usando robôs reais juntamente com simulação
de virtuais.
Palavras Chave: ROS, Arduino, robô móvel, sistemas embebidos, integração.
Declaration
The work in this dissertation is based on research carried out at the Mobile Robots
Laboratory of ISR (Institute of Systems and Robotics) in Coimbra, Portugal. No part of
this thesis has been submitted elsewhere for any other degree or qualification and it is all
my own work unless referenced to the contrary in the text.
Copyright © 2012 by André Gonçalves Araújo.
“The copyright of this thesis rests with the author. No quotations from it should be
published without the author’s prior written consent and information derived from it
should be acknowledged”.
xi
“Once we accept our limits,
we go beyond them.”
Albert Einstein
Contents
Agradecimentos
v
Abstract
vii
Resumo
ix
Declaration
xi
Contents
xv
List of Figures
xix
List of Tables
xx
Notation
xxiii
1 Introduction
2
1.1
Context and motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Hardware abstraction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4
Outline of the dissertation . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Related work
6
2.1
Compact mobile robotic platforms . . . . . . . . . . . . . . . . . . . . . . .
2.2
ROS: Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
xv
6
Contents
xvi
3 The TraxBot platform
14
3.1
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2
Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3
Processing and Motion Controller units . . . . . . . . . . . . . . . . . . . . 18
3.4
Sonars and Odometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5
Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6
Batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7
Kinematics
3.8
TraxBot cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.9
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 TraxBot ROS Driver
4.1
4.2
4.3
26
ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2
Gold marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
ROS driver development for TraxBot . . . . . . . . . . . . . . . . . . . . . 29
4.2.1
Driver - version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.2
Driver - version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.3
Driver Features and Potential . . . . . . . . . . . . . . . . . . . . . 35
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Results and Discussion
40
5.1
Odometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2
Sensing and Mapping
5.3
Power Consumption
5.4
ROS Driver Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4.1
Point-to-point Motion . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4.2
Mixed virtual and real robots teams . . . . . . . . . . . . . . . . . . 46
5.4.3
Teleoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4.3.1
5.5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Adaptation of the ROS driver in different platform . . . . 48
ROS Driver Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5.1
Driver first version . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Contents
5.5.2
5.6
xvii
Driver second version . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Conclusions
6.1
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1.1
6.2
52
Published Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
References and Bibliography
54
List of Figures
2.1
Roomba Create. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Bot’n Roll ONE C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Circular GT.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
Hemisson. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.5
Mindstorms NXT.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.6
SRV-1 Blackfin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.7
E-puck. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.8
marXbot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.9
TraxBot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.10 TurtleBot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.11 Pioneer-3DX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1
TraxBot dimensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2
Mechanical structure of the TraxBot. . . . . . . . . . . . . . . . . . . . . . 16
3.3
TraxBot’s main schematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4
OMNI-3MD I2C protocol frame. . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5
Control architecture of the robotic platform. . . . . . . . . . . . . . . . . . 20
3.6
Sonars chain connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7
Encoder signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.8
XBee Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.9
Comparison of capacity and power of rechargeable batteries [Roo10].
. . . 23
3.10 TraxBot kinematics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1
ROS architecture example diagram. . . . . . . . . . . . . . . . . . . . . . . 27
4.2
ROS driver architecture diagram. . . . . . . . . . . . . . . . . . . . . . . . 30
xix
List of Figures
xx
4.3
Rxgraph topics and nodes provided by the TraxBot driver.
. . . . . . . . 31
4.4
Frame protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5
ROS driver architecture diagram - version 2. Comparison with the first
driver (Fig. 4.2), depicting the changes in red and what was unchanged in
green. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6
Network topology example with multiple robots, sensors, teleoperation devices and applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1
Odometry square test evaluation.
a) Clockwise (CW) direction b) Counter-clockwise (CCW) direction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2
Sonar calibration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3
Mapping test. a) Sonars b) Laser. . . . . . . . . . . . . . . . . . . . . . . 43
5.4
Noisy range situations. a) Issue during rotations using lateral sonars b)
This figure illustrates why the front sonar is not used for mapping. . . . . . 44
5.5
Power consumption behavior. . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6
Driver Test. a) Real step test b) Stage simulation. . . . . . . . . . . . . . 45
5.7
TraxBot teleoperation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8
Driver Test. a) Two robots with reactive navigation b) Mixed real and
virtual robots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.9
TraxBot teleoperation devices. . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.10 StingBot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.11 StingBot operating with ROS driver. . . . . . . . . . . . . . . . . . . . . . 48
5.12 ROS driver messages turnaround time for the ROS driver - version 1. . . . 49
5.13 ROS driver messages turnaround time for the ROS driver - version 2. . . . 50
List of Tables
2.1
Comparative robot table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1
TraxBot hardware specifications. . . . . . . . . . . . . . . . . . . . . . . . 17
3.2
Traxbot total cost in euros. . . . . . . . . . . . . . . . . . . . . . . . . . . 25
xxi
Notation
Cs
Slipping offset.
Dl
Number of pulses sent by left wheel encoder.
Dr
Number of pulses sent by right wheel encoder.
Np
Total number of pulses per revolution read by encoders.
Rr
Radius of the robot.
Rw
Radius of the robot wheels.
θ
Angle of rotation between the current and the target position.
xn−1 Component x of the previous robot pose.
xn
Component x of the current robot pose.
yn−1
Component y of the previous robot pose.
yn
Component y of the current robot pose.
d
Distance between the current and the target position.
xxiii
Chapter 1
Introduction
This dissertation describes the integration of a fully developed mobile robot denoted as
TraxBot on Robot Operating System (ROS) [QGC+09]. This project took place at the
Mobile Robots Laboratory of ISR (Institute of Systems and Robotics) in Coimbra. The
main goal of this master degree project is the study and development of robotic drives,
to easily integrate a mobile platform on ROS for future use by the robotics community,
providing hardware abstraction.
There were four main work phases. Starting with the physical assembly of the mobile
robot TraxBot [APC+12], describing the implementation of the electronic modules. The
second phase consisted in the development of the functional architecture of the mobile
robot. Several tests were carried out in order to evaluate the odometry, sonars and other
technical features of the TraxBot. The next phase consisted on studying and implementing
algorithms to fully integrate the mobile robot on ROS. Finally, several tests were carried
out to evaluate the protocols, main functions and full system integration.
This chapter presents the context and motivation for this study, its main goals and gives
an outline of the dissertation.
1.1
Context and motivation
Mobile robotics is a research area that has witnessed incredible advances for the last
decades. Issues like autonomous navigation, active perception, map learning, obstacle
avoidance and self-localization, have been deeply studied for the past years. Mobile robots
2
1.1. Context and motivation
3
are found in industry, transportation and in military and security environments [Pet11].
Also, some mobile robots have emerged as consumer products for entertainment or to
perform daily domestic tasks, like vacuum cleaning [Jon06]. Earlier, the focus of research was especially on large and medium structures. However, with the recent advances
in electronics, sensor miniaturization and in microcontrollers computational power, the
emphasis has been put on the development of smaller and lower cost robots, which enables affordable experimentation with relatively large groups of robots. Several different
robotic systems have been developed for research in different fields like search and rescue,
patrolling, security applications, cooperative robotic systems, human robot interaction
and, nowadays, almost every major engineering institute hosts one or more laboratories
focusing on mobile robotics research. Frequently, the need for practical integration tools
to implement valuable scientific contributions is felt. However, in the robotics research
area, roboticists end up spending excessive time with engineering solutions for their particular hardware setup.
Following the trend of research, this work focuses on a low-cost, open-source mobile robot
that enables researchers, even the ordinary student and robot enthusiasts, to easily step
into the robotics and artificial intelligence world. Hence, this dissertation presents in detail the TraxBot robotic platform [APC+12], its features, price, communication abilities,
autonomy, and module integration, among others. Nevertheless, there is still a major issue
within the robotic community: a common framework to standardize a fully integration
system, thus avoiding the waste of unnecessary assembly and integration time [Miz05].
Robot Operating System (ROS) was create to solve this integration problem. Just as
common operating computer systems, it allows to easily plug and play multiple devices
in a host system.
ROS can be defined as a framework for robot development providing standard operating system services such as hardware abstraction, low-level device control, implementation
of commonly-used functionality, message-passing between processes and package management. It is based on a graph architecture where the processing takes place in nodes. Before
the existence of ROS, the standard procedure encompassed single and out-community development, which became a tremendous disadvantage because robotic software developed
for a particular robot platform required extensive adaptation to deal with different robots
1.2. Hardware abstraction
4
specifities making code reuse non-trivial. In other words, code implementation could not
be abstracted from hardware.
1.2
Hardware abstraction
Hardware abstraction is a set of software routines that emulate some platform-specific
details, giving direct access to the hardware resources. This allows programmers to write
algorithms in a high-level language for high performance applications, thus avoiding standard operating system hardware calls. This makes portability easy in applications and
plug devices.
In this particular case study, hardware abstraction is very important to overtake some
complex issues, like exchanging information between sensors, robots, tracking systems,
multi robot systems, simplify communications, by standardizing the acess to the information.
By using hardware abstraction, the robotic community benefits from the expertize of
other scientific areas like mathematics, biology, health and social interaction, since now
it is possible to implement their theories, algorithms and approaches independently of
hardware details.
1.3
Objectives
The first objective of the present work is the assembly and integration of the various
hardware components of a low cost mobile robot. Secondly, the development of a robot
driver to allow its integration into the ROS framework providing hardware abstraction and
finally, the validation of the work by conducting tests with the robot and the respective
driver in typical situations of their use based on ROS.
1.4
Outline of the dissertation
This dissertation is organized in 6 chapters. The first chapter introduces the context and
motivation, and the objectives of this work.
Chapter 2 reviews some of the most relevant related work, including the comparison to
1.4. Outline of the dissertation
5
other similar mobile robotic platforms.
TraxBot is presented in more detail in chapter 3 , including its assembly and a description
of its main hardware parts and electronic modules.
Chapter 4 presents the driver development to integrate the TraxBot on ROS. In this
chapter, it will be presented a general overview of this meta operating system, as well
as some important features. Also, it is provided detailed information about two driver
development approaches that were followed in different stages of this research. To finish
this section, potential applications of the driver are discussed.
Chapter 5 presents experimental tests that were carried out to validate the robotic platform and the ROS driver that was developed, along with a discussion of the obtained
results.
Finally, chapter 6 sums up the work, providing final conclusions and prospecting future
directions of research.
Chapter 2
Related work
In this chapter, a global overview of compact mobile robots used in academic research
and by robot enthusiasts is presented. A list of popular mobile robots used in the robotics
community are compared with TraxBot [APC+12] in terms of their features, price, communications abilities, size, among others; and also whether they are already integrated
on Robot Operating System.
2.1
Compact mobile robotic platforms
This section focus on similar work, taking into account robots’ mobility in several ground
environments, capability, as well as the size, sensing and perception without compromising processing power. Here, the major features of each platform are emphasized as well
as their drawbacks.
As known, a vast range of mobile robots are available on the market. In this section,
robots with similar scale are presented [APC+12a], allowing to perform comparative considerations to the TraxBot developed in this dissertation. Simpler and low-cost robots
are presented firstly, then more powerful robots are also described.
Roomba Create from iRobot [Kui09] was designed for students and researchers, being
very popular in the robotics community due to its small size and low cost. It is a light
version of the original vacuum cleaning Roomba , including a cargo bay that houses a 25
pin port used for digital and analogic input and output, instead of the original vacuum
system [Jon06]. It consists in a circular platform with approximately 340 mm of diameter,
6
2.1. Compact mobile robotic platforms
Figure 2.1: Roomba Create.
7
Figure 2.2: Bot’n Roll ONE C.
which supports equipment until 2,26kg with extra space for larger sensors (e.g., 3D laser
sensor or Kinect). Many choose to utilize an external computer that supports serial communication to control the Create robot, due to troublesome limitations in storage space
and processing power. In fact, a ROS driver for the Roomba iCreate has already been
developed [Roo12] at the Institute of Systems and Robotics.
Another low cost robot is the SAR’s Bot’n Roll ONE C [SAR10]. It has a differential configuration providing two infrared obstacle detection sensors with possibility to add extra
modules. A USB-Serial (RS232) converter allows the programming of the robot using an
external computer. In general, it is an excellent starting kit for beginners.
Figure 2.3: Circular GT.
Figure 2.4: Hemisson.
The IdMind´s Circular GT robot kit [Idm05], with a circular shape of 150mm of diameter,
supported in a plastic board and differential wheels, is smaller than the Bot’n Roll ONE
C, having more I/O ports to connect self-made extensions. It has five pairs of infrared
sensors, two micro-switches for collision detection and 7 additional links to connect other
sensors.
The Hemisson from K-Team [Col10] is more robust than the IdMind´s Circular GT. The
basic kit only provides limited computational power and a few sensors like 8 infrared light
sensors, 6 of them for obstacle detection and 2 facing the ground. It allows flash-memory
8
programming and supports cameras and ultrasonic sensors beyond others. These extensions may increase both computational power and sensing capabilities.
Figure 2.5: Mindstorms NXT.
Figure 2.6: SRV-1 Blackfin.
The Mindstorms NXT from Lego is an educational, academic robot kit for beginners
[Sha07]. The robot is equipped with drive motors with encoders and a good variety of
sensors, like an accelerometer, light, sound, ultrasound and touch sensors enabling applications in a wide range of scenarios. It also supports Bluetooth and USB communication.
Limited support for interfacing and controlling this robot with ROS is already available.
The SRV-1 Blackfin from Surveyor [CAS08], Fig. 2.6, is a robot equipped with tankstyle quad-motor tracks with differential drive having 120mm length and 100mm width
and an aluminum chassis. This robot has considerable processing power, with a CPU of
1000MIPS at 500MHz capable of running Linux Kernel 2.6. It is equipped with two range
lasers or optional ultrasonic ranging (support up to 4 ultrasonic ranging modules) and
a 1.3MP camera. It also supports Wireless 802.11b/g communication and various I2C
sensors. The robot runs programs stored in the onboard flash memory and can also be
remotely controlled via its webcam (managed by multi-OS).
Figure 2.7: E-puck.
Figure 2.8: marXbot.
The E-puck [MBR+09], illustrated in Fig. 2.7, is an educational platform for beginners.
It is a small-sized robot of 80mm diameter, with the ability to perform mobility tests on
9
Figure 2.9: TraxBot.
a desk. Also, it is equipped with a vast set of sensors like microphones, infrared sensors,
3D accelerometer and a VGA camera, and still offers extension capabilities. According to
its developers, all this technology has a price of around 570€.
The MarXbot [BLM+10] was developed at École Polytechnique Fédérale de Lausanne
(EPFL). It is a fully equipped robot with infrared range sensors, 3D accelerometer, gyroscope, and an omnidirectional camera. It has a good processing power with an ARM 11
processor, at 533MHz. The platform is round with 170 mm of diameter and its price is
surely above 700€.
Finally the mobile robot involved in this dissertation, the TraxBot [APC+12], is a platform with 225mm of length and 204mm width and its mobility is based on tracks. TraxBot
is equipped with three powerful range sonars and the platform is suitable to apply several
extensions. It has a very robust chassis and its tracks enable the operability in most
ground environments, feature that most compact mobile robots do not have.
Figure 2.10: TurtleBot.
Figure 2.11: Pioneer-3DX.
Another platform built from popular off-the-shelf robot components is TurtleBot [Tur11],
shown in Fig. 2.10. This is a modular development platform that was built on top of an
iRobot Create, incorporating a Xbox Kinect and an ASUS eeePC 1215N netbook. The
platform is fully integrated in the ROS architecture [QGC+09]. TurtleBot provides 3D
functionalities and ROS out of the box, being open source and exploring all combined
capabilities of its components. The complete robot kit costs around 1000€.
2.2. ROS: Robot Operating System
10
Larger, more expensive and even more equipped mobile robots than the compact ones
presented are available. These are generally more powerful, with their own embedded
computers, up to 2GHz dual-core processors, and also heavier, slower and without the
agility of compact ones. One of the most popular research robot is Pioneer 3-DX [ZSS11]
(Fig. 2.11). The base platform is assembled with powerful motors with 500-tick encoders,
19cm wheels, tough aluminum body equipped with 8 forward-facing ultrasonic sensors
sonar, the basic platform costs up to 4500€.
2.2
ROS: Robot Operating System
With the exponential growth in the Robotics field, some difficulties have been found in
terms of writing compatible software for distinct robots. Wildly varying hardware makes
code reuse nontrivial. Opposing this tendency, ROS [QGC+09] provides libraries and
tools to help software developers creating robot applications.
The major goals of ROS are hardware abstraction, low-level device control, implementation of commonly-used functionalities, message-passing between processes and package
management. One of its gold marks is the amount of tools available for the community, like
the Stage simulator [GVH03], navigation capabilities [MBF+10], visual SLAM [GSB06],
and 3D point cloud based object recognition [RC11], among others. Regular updates
enable the users to obtain, build, write and run ROS code across multiple computers.
Therefore, integrating robots in ROS is highly beneficial, since it strongly reduces the
development time.
Despite many robotic frameworks presented in the last decade, like Player [GVH03],
YARP [MFN06], Orocos [Bru01], CARMEN [MRT03] or Microsoft Robotics Studio [Jac07];
ROS, which was originally released in 2007, has already became the most popular framework, being used worldwide due to all the advantages pointed out before.
Additionally, since it is highly flexible, with a simple and intuitive architecture, ROS integrates important features of other frameworks like several Player robot drivers, the Stage
2D [GVH03] and Gazebo 3D [SVE11] simulation environments and the Orocos stack,
which wraps this modular framework, mostly used in industrial robots and machine control.
2.3. Summary
2.3
11
Summary
Surveyor
SRV-1 Blackfin
Roomba
iCreate
Lego
Mindstorm NXT
K - Team
Hemisson
Idmind
Circular GT
Bot’n Roll
ONE C
380,00 €
180,0€
290,00 €
275,00 €
260,00 €
175,00 €
225x204x76
2045
*3160
Aluminum
120x100x80
3400
Aluminum
(-/-/90)
Ø 340
150
Plastic
145x97x61
280
Plastic
(-/-/70)
Ø 120
200
Aluminum
(-/-/60)
Ø 150
200
Plastic
220x200x58
1300
Acrylic
24MIPS 16MHz
1000MIPS
500MHz
20MIPS 20MHz
30MIPS 40MHz
5MIPS 20MHz
5MIPS 20MHz
16MIPS 32MHz
ATmega 328
-
ATmega 168
ARM 7
PIC16F877
PIC16F877
Picaxe 40x2
- Camera 1.3 MP
- 2 x Range Lasers
- Temperature
- iR obstacle
detection
- micro-switches to
cliff detection
- Accelerometer
- Touch sensor
- Light sensor
- Sound sensor
- Ultrasonic sensor
- 8x iR 1ight
sensor
- 6x iR obstacle
detection
- 7x iR obstacle
- Wireless remote
control 802.11b/g
- RS-232 serial
- Bluetooth
- USB serial
- USB
- DB9 Serial
-
TraxBot
Aprox. Base Price
485,00 €
*645,00€
ROS
Physical Specifications:
- Dimension (LxWxH) mm
- Dimension diameter mm
- Weight (g)
- Chassis material
Hardware:
- Processor
- µController
Sensors:
(with command module)
- 3x Range sonar
detection
- 2x microswitches
- 2x iR obstacle
detection
Communication:
- USB serial
- Zigbee
Speed:
(cm/s)
Battery:
- Type
- Power
- Autonomy aprox.(hours)
Features:
- USB serial
30
40
13
10
10
10
Ni – MH
12V 4600mAH
2 -3
Li – poly
7,4V 2000mAH
3
Ni-MH
14.8V 3000mAH
3-4
Li-lon AA
9V = 6x1.5V
3–4
Ni-MH
8.4V 150mAh
2
Alkaline AA
6V= 4x 1.5V
2
Ni – MH
12V
2
-
- Xbee (socket)
- LCD (socket)
- Support sensor
expensions
- Buzzer
* with Asus Eee pc
1001PX
Processor:
Intel Atom N450
1,66 GHz
- Linux 2.6
support
- Laser Pointer
- Java-based
console
- Simple base
platform
- LCD display
- Construct any
configuration with
Lego bricks
- Support
sensor and
communication
expensions
- Buzzer
Table 2.1: Comparative robot table.
Table 2.1 presents a comparison of all compact low-cost mobile robots described above.
It can be seen that the Roomba Create robot is the cheapest of all. However, it is very
poor in sensing ability, encoder resolution and processing power, usually needing an external computer deployed on top, which increases the price of the platform. On the other
hand, the SRV-1 Blackfin, is the most expensive, but it has the best onboard processing
power, provides Linux 2.6 support and is the only one that comes with a camera. Nevertheless, the ability to add sensor extensions is limited, due to lack of available space. The
IdMind´s Circular GT is also very cost-effective; but it does not have hardware to enable
communication between robots, being less appropriate for experimentation with teams of
robots. As for the K-Team Hemmisson, its downside is maximum run time (energy autonomy). The Mindstorm NXT, Circular GT and One C are ideal platforms for beginners.
2.3. Summary
12
Note however that, in their present form, most of these robots are limited to very simple
tasks with unreliable odometry. Robots equipped with range sensors are more suitable
for tasks that require precise localization. Hence, the majority of these platforms would
need extensions to their sensing capabilities for more demanding tasks.
Motivated by many limitations on the state-of-the-art of low-cost robots and challenged
to accomplish better value for money, the TraxBot platform [APC+12] was developed
and integrated in ROS [QGC+09]. In this work, the key contributions are the development and description of a driver that enables fast prototyping through the interface and
control of the platform using ROS; and the verification of cooperative behaviors with real
multi-robot systems, but also mixed real and virtual robotic teams.
After conducting a comparative analysis of several platforms of mobile robotics, chapter
3 will present in detail the platform TraxBot that was used in this work.
Chapter 3
The TraxBot platform
The TraxBot is ideal for education and research, since it can provide basics required
for autonomous robot development, both at the hardware level (mechanics, energy, locomotion, embedded electronics, sensors) and software level (control theory, microcontroller
programming, robot navigation trajectory planning, localization, etc). The setting up, development and programming of the robot was motivated by experimentation and research
in cooperative multi-robot systems, more specifically teams of robots with distributed control to perform cooperative patrolling [PR11] and swarm foraging [CRF11] tasks.
In this chapter, the mobile platform is presented in detail. Such platform has been essentially chosen due to the following reasons:
- Robustness: All hardware is either aluminum or stainless steel;
- Low Cost: The platform costs around 485€ (not considering the notebook);
Figure 3.1: TraxBot dimensions.
14
3.1. Hardware
15
- Operability: It has the ability to maneuver in many different types of terrain and
surface topographies. Since it is a tracked mobile robot (TMR), it provides adequate
mobility in unstructured environments;
- Run Time: It can operate continuously around 2-3 hours – robots should have a long
battery life since they may have to operate for a long time during a mission;
- Sensor System: Equipped with ultrasonic range sensor to allow interaction with the
environment;
- Size: It is adequate for both indoor and outdoor experiments. Its detailed dimensions
are illustrated in Fig. 3.1;
- Flexibility: It can incorporate many new extensions and components (e.g., LEDs,
cameras, LIDARs, grippers, etc.);
- Hybrid design: It is able to work with and without a small netbook on top of the
platform according to the user’s computational power requirements;
- Communication: Supports wireless ZigBee communication or Wireless 802.11b/g
communication when the notebook is used;
- ROS-enabled: Ability to use ROS related tools with the robot.
Considering the lack of flexibility and the weaknesses of other compact mobile robots
presented in chapter 2, especially in terms of communication, sensing capabilities and
processing, our research group developed this robot with low cost and open source tools.
The TraxBot is ideal for multi-robot applications, thus covering all the requirements previously addressed. The next section presents the main properties and features of the
robot.
3.1
Hardware
The TraxBot is a tracked mobile robotic platform, which has a differential drive system
built upon the Traxster II Robot educational Kit extended with substantial components
and improvements [TRK11]. The light and robust aluminum chassis is equipped with 2
DC gearhead motors on the front wheels, with quadrature wheel encoders of 624 pulses
resolution. Motors operate at 7.2 Volts, being able to reach 160rpm with 7.2 kg-cm of
torque with no load. Since the original kit is endowed with ABS injection molded plastic
3.1. Hardware
16
Figure 3.2: Mechanical structure of the TraxBot.
Figure 3.3: TraxBot’s main schematic.
3.2. Assembly
17
Table 3.1: TraxBot hardware specifications.
tracks, additional rubber bands were attached to the tracks to increase friction and reduce
slipping during locomotion. It was also added a flat acrylic structure on the top of the
platform to support a 10” notebook and the three ultrasonic range sonars, as presented in
Fig. 3.2. The processing and control units are the Arduino Uno with xBee shield module
and the motor drive OMNI-3MD [BRO11], which were placed inside the Traxbot chassis.
The battery pack is deployed under the TraxBot and held together by two strips of velcro
on the outside for easy access and replacement. The circuit switch power is located in the
shield’s rear. Table 3.1 presents some hardware specifications. The TraxBot presents itself
as a robotic platform ideal for robotics education, since it is based on the Arduino opensource platform board and presents an easy-to-use communication interface, enabling the
easy data exchange between multiple robots or between the robot and a remote unit.
3.2
Assembly
This section describes the assembly of the components inside the platform and the control
architecture. An outline of the electronics of the TraxBot platform is presented in Fig. 3.3.
The Arduino Uno board [Ard10], the Bot’n Roll OMNI-3MD driver and the DC motors
are located inside the robot shield, while the Maxbotix MB1300 sonar range finders are
placed under the acrylic support in a configurable layout. Having the Arduino Uno board
as the central component of the system, the sonar range finders connect through the
analog pins A0, A1 and A2. As for the connection to the OMNI-3MD motor driver, the
3.3. Processing and Motion Controller units
18
pins A4 and A5 are used for I2C connection respectively. Channels A and B of each
motor’s encoders are connected to the OMNI-3MD board through the white and green
wires, respectively. The Universal Serial Bus (USB) jack on the microcontroller connects
to the notebook, which is used to receive (RX) and transmit (TX) TTL serial data decoded
using a USB-to-TTL Serial chip incorporated on the Arduino board.
3.3
Processing and Motion Controller units
The processing unit consists of an 8 bit microcontroller (µC) ATmega 328p from Atmel (in the middle of Fig. 3.3), embedded in an Arduino Uno open-source development
board [Ard10]. This is ideal for compact robots, allowing the optimization of space and
power consumption. A single integrated circuit (IC) has the 3 main components of the
architecture: central processing unit (CPU), memory and input/output (I/O). The CPU
runs at 16 MHz and provides 14 MIPS of peak processing power, it also has 14 I/O digital
pins (6 of them can be used as PWM analog outputs) and 6 analog inputs, up to 32kB of
program memory and 2kB of SRAM. The ATmega8U2 embedded in Arduino Uno board
creates a serial communication over USB to virtualize a COM port, that can be used by
the external computer.
The µC deals with data received from sensors, sends control signals to actuators and
sends information to computers or others devices. Furthermore, it offers advantages over
higher processing systems, such as low-cost and lower power consumption. Additionally,
Arduino has an open-source cross-platform development environment (i.e., runs on Windows, Macintosh OSX and Linux) with extensible software and hardware characteristics,
i.e., the language can be expanded through C libraries (as we shall see in the ROS Driver,
chapter 4) and shields can be plugged on top of the Arduino board, thus extending its
capabilities. In our case a ZigBee shield module was added (see communication section
3.5).
Atmega 328p, as many other µCs, may offer limited flexibility due to its inherent hardware limitations when compared with other processing systems (e.g., embedded PCs).
Still they are the best choice when creating simple electronic devices that will not change
much over time (e.g., swarm robots). In order to overtake these limitations, when re-
3.3. Processing and Motion Controller units
19
Figure 3.4: OMNI-3MD I2C protocol frame.
quired, we use a small and cheap 10” notebook, for external processing, the ASUS eeePC
1001PXD BLACK N455, with an Intel Atom processor at 1.66GHz. It provides a hybrid
design and enables the robot to perform a large variety of tasks, ranging from simple to
computationally expensive tasks. If more computing power is needed, it is possible to use
multiple machines (CPUs), to reduce the computation load on a single computer.
In this work, the ATmega 328p µC controls the platform’s motion through the use of
the Bot’n Roll OMNI-3MD board [BRO11] (right side of Fig. 3.3). It has an embedded
dsPIC30F6010 µC from Microchip and its CPU provides 30MIPS with a 16 bit processor.
It has 144kB of program memory and up to 8kB of RAM memory. This driver has the
ability to control three motors in omnidirectional platforms by sending linear velocity,
direction and speed commands, performing both velocity and position control. In our
case, we use only 2 motors for differential drive. In terms of tension range, motors operate between 7 and 24 VDC. As for current intensity, the driver supports up to 4A. This
driver also features thermic protection to avoid extreme overheat on the driver board,
mainly caused by the DC power amplifiers (Choppers); and current overhead is protected
with self-resettable fuse. On monitoring issues, it is possible to access motor tension for
each motor, firmware version, as well as board temperature. Furthermore, the OMNI3MD board has the flexibility to provide direct number of pulses from encoders, which
can be set with a desire prescaler. For controlling the motors the board provides a closed
loop PID, which is extremely functional. It takes into account the platform configuration,
which is designed to operate in different surfaces and terrains, and support variable load
on top of it.
For Serial Data Connection and Serial Clock Connection, the I2C BUS works with data
exchange rate up to 100 kbit/s in the standard-mode or up to 400 kbit/s in the fast-mode.
For I2C data exchange, a frame with 3 segments is used for address, command and data
(Fig. 3.4). Firstly, the 8bit segment contains the I2C address where the most significant
bit selects write or read mode. The next segment is the specific list of operations commands, and the last segment frames are the data for parameters commands.
3.4. Sonars and Odometry
20
Figure 3.5: Control architecture of the robotic platform.
For protection, if the I2C connection exceeds a greater timeout, the driver automatically
interrupts motors movements. Having specified the hardware and the platform electronics,
the modular control architecture of the robot is summarized in Fig. 3.5.
3.4
Sonars and Odometry
For range sensing, the TraxBot uses 3 ultrasonic range sonars, more precisely 3 LVMaxSonar MB1300 from Maxbotix [MBX05] (left side of Fig. 3.3), with a dead zone of
15 cm, maximum range of approximately 6.45 m, resolution of 2.45 cm, and a configurable
layout. It is possible to use up to 4 sonars in one platform through the available analog
ports of the Arduino Uno board.
These ultrasonic sonars send out a pulse of sound and wait to receive the sound´s echo
off of an obstacle. By measuring how long it takes for the sound to bounce back, the µC
embedded on the sonar board calculates the distance that the sound traveled, and hence,
how far the obstacle is. However, this originates an issue of different sonars “hearing” echos
from the other sonars, which results in faulty detections. Hence, to avoid this crosstalk
3.4. Sonars and Odometry
21
Figure 3.6: Sonars chain connection.
Figure 3.7: Encoder signals.
phenomenon, a chain loop was created to synchronize cadence values from individual
sonars, as shown in Fig. 3.6.
The two DC motors have a quadrature encoder incorporated, with 624 pulses per output
shaft revolution, used to sense position, as well as wheel direction and rotation speed
by converting displacement into digital pulses. Consisting of a disk with coded patterns
of opaque and transparent sectors that is attached to a rotating shaft, the quadrature
encoder converts rotating patterns into two pulse output signals, A and B (Fig. 3.7).
When counted, these pulses determine position. The phase difference between output
signal A and output signal B determines the direction of rotation. For example, if pulse
output A leads pulse output B, the shaft is rotating in the clockwise direction. Conversely,
if pulse output B leads pulse output A, the shaft is rotating in the counter-clockwise
direction [DT06].
3.5. Communication
22
Figure 3.8: XBee Module.
3.5
Communication
TraxBot provides wireless communication, which is fundamental for robot teams. ZigBee
communication is embedded in the TraxBot and Wi-Fi 802.11 b/g/n wireless technology
is also available when using a notebook on top of it.
ZigBee is used for exchanging short messages between robots when operating without a
notebook and running simple coordination algorithms, whereas the Wi-Fi supports larger
bandwidth with heavy data exchange and easy integration in a ROS network (chapter 4).
ZigBee technology provides fast, low-cost wireless communication, featuring low-power
consumption, possibility to support a huge number of networks nodes (theoretically up to
65536) as well as to set point-to-point, peer-to-peer, and multicast communication suitable for cooperative robot teams.
In this work, TraxBot is equipped with a XBee Shield [XBM06] from Maxstream, consisting on a ZigBee communication module with an antenna attached on top of the Arduino
Uno board as an expansion module (Fig. 3.8), operating on the ZigBee protocol at standard IEEE 802.15.4 and using 2.4 GHz ISM band. This Xbee module is powered at 1mW
having a range between 30m to 100m, for indoor and outdoor operation, respectively.
The power consumption of this module is extremely low: 10µA in sleep mode and 50mA
while sending and receiving data. The advantage of being an expansion of Arduino is the
possibility of easily integrating wireless data exchange in the main source code [CFL+12].
The notebook provides communication via Wireless Wi-Fi 802.11 b/g/n to the robot and
is dedicated to run ROS onboard, as previously referred. Wi-Fi is used for remote access
and to enable a ROS network to run and share information.
3.6. Batteries
23
Figure 3.9: Comparison of capacity and power of rechargeable batteries [Roo10].
3.6
Batteries
In order to choose appropriate batteries, several considerations were made, like capacity,
energy density, power, number of cycles, available sizes, recycling requirements and cost.
In Fig. 3.9, the specific energy that represents the capacity that a battery can hold in
watt-hours per kilogram (Wh/kg) and the battery’s ability to deliver power in watts per
kilogram [Roo10]. The battery type chosen in this project was the Ni-MH batteries, due
to the balance between its performance and cost.
Therefore, two packs of 12V 2300mAh Ni-MH batteries, constituted by 8 AA Ni-MH cells,
were placed under the chassis of each robot to ensure good autonomy and the required
power. Note that the notebook operates on its own battery without consuming TraxBot
batteries.
3.7
Kinematics
TraxBot is a differential nonholonomic drive robot (Fig 3.10), with two motors independently controlled from each other. This tracked configuration provides a better stability
and traction, thus allowing to perform a wider range of tasks in different surfaces when
compared to wheeled robots. On the other hand, the tracked locomotion system presents
a slipping effect that needs to be overcome. Hence, in order to control the TraxBot more
effectively, the slipping phenomenon was minimized by considering a slip offset. Slip needs
to be defined in the rotation case (3.1). The offset (Cs ) was determined on a smooth car-
3.7. Kinematics
24
d
Rr
Rw
Figure 3.10: TraxBot kinematics.
pet, for suitable and stable rotation.
Taking into account the wheel radius Rw = 39mm and the robot radius Rr = 102mm;
the combination between encoders and wheel provides Np = 624pulses/revolution, where
each pulse corresponds to a resolution of approximately 0.004 degrees.1
Rotation:
Dr = −Dl = (Dl + Cs )
θ Rr
,
2π Rw
(3.1)
Straight Motion:
Dr = Dl + Cm = Np
d
+ Cm ,
2π.Rw
(3.2)
where the total odometry is represented in spatial coordinates (x, y, θ),



x
n
= xn−1 + d. cos θ
n
= yn−1 + d. sin θ


y
(3.3)
Although the motors model is exactly the same, their behavior is slightly different. It is
not possible to ensure that applying the same voltage on both motors will result in the
same speed. Therefore, it is necessary to compensate one of the motors (Cm ) to obtain a
straight motion (3.2).
Given the previous information, it is possible to obtain a resolution of 0.39 mm for each
pulse.
1
see Notation section.
3.8. TraxBot cost
25
Table 3.2: Traxbot total cost in euros.
3.8
TraxBot cost
The fully-assembled platform presents the following final cost, shown in table 3.2.
Given all its capabilities, TraxBot achieves great value for money when compared to previously described low-cost compact robots. It also provides the flexibility to incorporate
many more expansions ranging from simple sensors like LEDs, microphone and displays;
as well as more complex ones like LRFs and Kinect among others, which is not a common
option in other available robots. In addition, it uses recognized open-source tools like the
Arduino board and ROS for controlling the robot, as it will be seen in the next section.
3.9
Summary
In brief, the TraxBot was fully described, thus presenting the features and architecture
design, the kinematics model, and the final cost of the platform. Next chapter describes
the integration of TraxBot platform in ROS starting with a general overview of ROS
(Robot Operating System).
Chapter 4
TraxBot ROS Driver
In this chapter, the driver to integrate the TraxBot on ROS (Robot Operating System) is
presented and detailed description of the two distinct driver versions is done. Finally, at
the end of this chapter several features and potential applications of the TraxBot in ROS
are presented.
4.1
ROS
The required code to develop real robotic applications can be daunting, as it must contain a deep stack starting from driver-level software and continuing up through perception,
abstract reasoning, and beyond. Robotics software architectures must also support largescale software integration efforts. In the past, many robotic researchers solved some of
those issues presenting a wide variety of frameworks to manage complexity and facilitate
rapid prototyping of software for experiments, thus resulting in the many robotic software systems currently used in academia and industry. Those frameworks were designed
in response to perceived weaknesses of other available frameworks or to place emphasis
on aspects which were seen as most important in the design process. ROS [QGC+09] is
the product of tradeoffs and prioritizations made during this process.
ROS (Robot Operating System) is a meta operating system for robotics that provides
libraries and tools to help software developers to quickly and easily create robotic applications. ROS [QGC+09] is completely open source (BSD) and free to use, change and
commercialize solutions based on it. It is noteworthy that this operating system is not
26
4.1. ROS
27
Stack A
Package
Node A1
Stack B
Float
Message
Package 1
Sensor
Message
Node B1
Range
Message
Stack C
Package
Package 2
Node B2
Int
Message
Package n
Node C1
PointCloud
Message
Node Bn
Type of messages
exchanged in topics
Topics
Subscriber
Topic
Publisher
Topic
Figure 4.1: ROS architecture example diagram.
a reinvented OS but an Unix-based OS. However, ROS is not an operating system in
the traditional sense of process management and scheduling, yet it provides a structured
communication layer above the host operating systems of a heterogeneous computing
cluster.
4.1.1
Overview
ROS has two levels of concepts: i) the file system level; and ii) the computation graph
level.
The file system level can be summarized as ROS resources files which are organized in
groups of packages, which are the main unit for organizing software in ROS. A package
may contain ROS runtime processes (nodes), a ROS-dependent library, datasets and / or
configuration files. Stacks are collections of packages that provide aggregate functionality, such as the well-known navigation stack from ROS community [NS12]. This stack
allows the 2D navigation that takes into consideration the information from odometry and
4.1. ROS
28
sensor streams, returning a target pose and output velocities that are sent to the mobile
platform, using for example, the Adaptive Monte Carlo Localization (AMCL) approach.
The computation graph level is the peer-to-peer network of ROS processes that processes all the data together. The basic computation graph concepts of ROS are nodes,
Master, messages, services and topics, all of which provide data to the graph in different
ways. This concept can be summarized in Fig. 4.1.
The ROS Master provides the name registration and lookup to the rest of the computation graph. Without the Master, nodes would be unable to find each other, exchange
messages, or invoke services. In Fig. 4.1, it is possible to see nodes, which are processes
that perform some computation. ROS is designed to be modular at a fine-grained scale;
a robot control system usually comprises many nodes. For instance, one node controls
a laser range-finder, one node controls the wheel motors, one node performs localization,
one node performs path planning, one node provides a graphical view of the system, and
so on. A ROS node is written with the use of a ROS client library, such as roscpp for
libraries in C++ or rospy for libraries in Python. Nodes send out a message by publishing or subscribing it to a given topic. The topic is a name that is used to identify the
content of the message. Hence, a node that requires a certain kind of data subscribes
to the appropriate topic. There may be multiple concurrent publishers and subscribers
for a single topic, and a single node may publish and/or subscribe to multiple topics. In
general, publishers and subscribers are not aware of each other’s existence. The idea
is to decouple the production of information from its consumption. In other words, one
can think of a topic as a strongly typed message bus. Each bus has a name, and anyone
can connect to the bus to send or receive messages as long as they are of the right type.
Finally, nodes communicate with each other by passing messages via topics. A message
is simply a data structure, comprising typed fields. Standard primitive types (integer,
floating point, boolean, etc.) are supported, as are arrays of primitive types. Messages
can include arbitrarily nested structures and arrays (much like C structs) and users are
able to create custom messages for their applications [RC12].
4.2. ROS driver development for TraxBot
4.1.2
29
Gold marks
ROS is designed to be as “thin” as possible. A corollary to this is that ROS has already integrated some functionalities of OpenRAVE [DK08], Orocos [Bru01], and Player [GVH03].
The preferred development model is to write ROS-agnostic libraries with clean functional
interfaces. In terms of availed languages, besides C++ and Python, other libraries are
being developed for Octave, LISP, java and Lua, making ROS a language-independent
framework.
ROS is easy to test since it is endowed with a builtin unit/integration test framework
called rostest that makes it easy to bring up and tear down test fixtures. In terms of scaling, ROS is appropriate for large runtime systems and for large development processes.
Another key feature of ROS are the tools available for robotics, as stage simulation, navigation, framework for visual SLAM, 3D point cloud based object recognition system,
among others.
4.2
ROS driver development for TraxBot
After assembling the robot, a driver for the TraxBot robot was developed for integration
and control of the platform using ROS Electric Emys version [REE12] running on Ubuntu
11.04 “Natty Narwhal”. To develop the ROS driver, some pre-existent stacks available in
the ROS community were used, being the most relevant for this work the rosserial [RS12]
and the serial_communication [SCS11]. Both stacks have the liability to make the pointo-point serial communication between the Arduino and the PC / ROS side. As we will
see in the next subsections, two drivers were developed. The first one is based on rosserial
stack where some limitations were subsequently found. This version became less efficient
for more complex tasks due to the high overhead imposed by the data acquisition and
commands sent by rosserial, thus resulting in an overflow of the Arduino microcontroller
Atmel 328p SRAM. These problems and limitations of the critical driver of the first version
are presented in Section 5.5.
To overcome such weaknesses, it was necessary to develop a second version of the driver.
This second driver was based on serial_communication being more robust and fast for
more complex applications, such as teleoperation, crossing of sensory information, the
30
Figure 4.2: ROS driver architecture diagram.
integration of the stack robot navigation, among others.
4.2.1
Driver - version 1
For this first version, the rosserial stack [RS12] was adopted to establish point-to-point
serial communication, making use of a general protocol to exchange ROS messages with
the Arduino Uno. The rosserial stack has been used by the ROS community, being open
source and prone to further improvements. This stack has specific client libraries that
can be used in the microcontroller main source code. Such libraries allow users to easily
start ROS nodes by using the ROS server installed in the CPU and rosserial is then used
to set up the connection protocol on the TraxBot driver.
The power motor driver OMNI-3MD provides Arduino libraries to control the motors
(i.e., velocity or position control), read encoders and temperature, as well as setting the
parameters for the initial configurations of the PID controller, among others. The motor
driver is connected to the Arduino Uno through I2C communication. ROS topics and
nodes must be provided by the TraxBot driver.1
1
available for all ROS community at: http://www.ros.org/wiki/mrl_robots
31
Figure 4.3: Rxgraph topics and nodes provided by the TraxBot driver.
Algorithm 4.1 takes into account all the components and their features, which are required
for the robot operation. The remaining architecture of the ROS driver is depicted in Fig.
4.2. All callback functions rely on activation topics for the read commands, avoiding
messages overflow with unnecessary information. For instance, the function to stop the
motors is always available as an external interruption.
C/C++ language was used as the programming language for the ATmega328p microcontroller, combined with ROS client and OMNI-3MD libraries. Algorithm 4.1 illustrates the
resident high-level code of the TraxBot firmware, running on the Arduino Uno board, as
shown in Fig 4.2. Note that ROS provides many different built-in sensor message types
which are appropriately assigned to the topics of each component of the TraxBot driver.
The ROS server runs in the notebook, and the connection node from the rosserial stack
allows starting the communication with the TraxBot, providing the available topics to
subscribe and publish.
One of many ROS tools, rxgraph, is used to allow real time monitoring of the available
nodes, as well as the topics connecting different nodes. In Fig. 4.3, a ROS computation
graph is presented, where the TraxBot driver is connected to TraxBot_DriverTest - a
program developed to test every topic/feature of the platform. The TraxBot_DriverTest
node verifies all functionalities implemented in the TraxBot, subscribing to every topic
32
Algorithm 4.1 TraxBot resident firmware version 1, running in the Arduino Uno board.
published by the TraxBot driver, testing the firmware and the motion of the robot by
sending velocity commands; and continuously reading odometry updates provided by the
encoders.
4.2.2
Driver - version 2
It was necessary to develop a second driver in order to overcome the critical limitations
of the first driver, described before in section 4.2. In this new version, the package
cereal_port [CPP11] from the serial_communication stack [SCS11] developed in the Embedded Systems Lab at ISR, was used. This stack follows the same approach of rosserial
used in the first version of the driver, allowing the point-to-point connection through
serial communication. This package has the versatility of creating a specific protocol to
exchange data between the Arduino and the PC / ROS side. Consequently, this allows
creating a much more customized, transparent and faster communication than the one
33
Figure 4.4: Frame protocol.
originally implemented in the first version.
The protocol developed for the second version of the driver consists on sending a frame
with a specific configuration, as shown in Fig. 4.4. A specific character ‘@’ is used to start
the protocolled frame and commas ‘,’ separate the different parameters. The character
‘e’ is used to identify the end of the frame.
Regarding the content of the protocol, the first parameter corresponds to the action
command. For instance, move motors, encoders read, read sonar, PID definition, and
others (Algorithm 4.2). After the action command, it follows the arguments of the desired functions. For instance, let us suppose that we want the platform to move forward at 40% of its maximum speed, the frame would be, “@9,1,40,1,40e” representing
“@command,direction_motor1,speed_motor1,direction_motor2,speed_motor2e”.
As opposed to the first version, this new version allows to stream data (Algorithm 4.2).
This results in fewer requests, freeing the channel of communication. Another option of
this new driver is the ability to enable and disable a debug option.
Fig. 4.5 presents the driver architecture and compares it to the first version, depicting the changes in red and what was unchanged in green. The most significant changes
were carried out in the TraxBot platform (i.e., Arduino firmware), where the algorithm
was implemented due to the communication protocol mentioned above. In the PC /
ROS side, changes mainly consist on using the functions from the communication stack
serial_communication instead of the rosserial stack. Another relevant change was the upgrade of the "Driver Source Code" which allows interpreting the messages and publishing
or subscribing the relevant information in ROS. That information is then used by other
nodes as Fig. 4.5 depicts, e.g. "TraxBot Source Code". However, the main difference
between the two versions consists on how the ROS topics are published. From the rosserial point of view, libraries are added to the Arduino source code, in order to emulate
ROS language directly in Arduino code. This results in high overhead in communication
between PC / ROS and the Arduino, due to the structures used for example to publish
messages from the Arduino side. On the other hand, using the serial_communication
34
Algorithm 4.2 TraxBot Resident Firmware version 2, running in the Arduino Uno board.
35
ROS Driver
TraxBot Source Code
Driver Source Code
Cereal_port node establish I2C
communication via serial
protocol and Driver source
code Interprets the frame sent
by the firmware program to
Connection node
perform the desired task.
USB cable
connection
Firmware
Implemented in C with specific
protocol frame
I2C
Motor Driver
Power driver to control motors,
Encoders and temperature among others.
Figure 4.5: ROS driver architecture diagram - version 2. Comparison with the first
driver (Fig. 4.2), depicting the changes in red and what was unchanged
in green.
stack, the messages sent from the Arduino only consist of arrays of characters, which are
parsed to integer variables on the PC / ROS side, decreasing the communication load, as
it will be seen later on the results section 5.5.
The next chapter presents some performance evaluation of the two drivers.
4.2.3
Driver Features and Potential
The drivers previously presented offers several features, many of which are inherited by
the direct integration with ROS middleware. These drivers enable the interface with
ROS tools for data processing and analysis of the TraxBot platform, like 3D visualization (rviz), logging real-time robot experiments and playing them offline (rosbag / rxbag),
plotting data (rxplot) and visualize the entire ROS network structure (rxgraph). Beyond
the easiness of using the available tools, ROS also provides effortlessly integration of new
sensors without needing hardware expertise. For instance, the addition of tele-operating
devices like the wiimote to take advantage of its internal accelerometers [SR09], sensors,
such as laser range finders, Xbox Kinect, global positioning system devices (e.g., GPS),
electronic compasses, accelerometers, gyroscopes, among others, can be accomplished by
36
Figure 4.6: Network topology example with multiple robots, sensors, teleoperation
devices and applications.
directly integrating their ROS drivers into the network. This opens a new range of possibilities since several well-known stacks from the ROS community comprises algorithms
for robotics development such as the navigation and slam_gmapping stacks. These are
useful since they avoid programming low-level behaviors by reusing code, and shift the
focus to scientific issues. As a result, the overall time spent in robotics research is greatly
reduced and, therefore, the driver represents a valuable tool that enables fast prototyping
and opens a gateway into the world of ROS.
The interaction between high-level programs and the available resources in the TraxBot
platform allows the hardware abstraction and the possibility of using standard interfaces
of any mobile robotic platform integrated with ROS architecture.
Another interesting feature of the TraxBot driver is the simplicity for enabling multirobot coordination and cooperation. Running the same hardware abstraction layer in all
nodes of the robotic team, ROS takes care of the communication messaging system using
a publish / subscribe mechanism [GM02] which enables all kinds of interaction between
members of the same team. Not only multiple robots are able to cooperate with each
37
other, in heterogeneous networks, through Wi-Fi, ZigBee or Bluetooth by exchanging
messages in common topics of the ROS global network, but they can also be equipped
with distinct sensors.
In Fig. 4.6, an example of a ROS network is depicted. It is also shown how the network
has the flexibility to work with a large variety of integrated solutions, which enables the
assignment of particular tasks for specific members of the team. Robots of the same team
may have different purposes and perform different tasks, thus meaning that heterogeneous
teams with different capabilities can coexist. For example, in a search and rescue scenario, the cooperation of a multi-robot team may arise from performing different tasks
with hundreds or thousands of heterogeneous robots. In a scenario where a swarm of air
scouts are deployed, these scouts may search and mark objective points to pass them on,
in real time, to ground robot surveillance teams.
Not only ROS have the potential to integrate homogenous and heterogeneous robotic
teams, but it also allows the cooperation between mixed real and virtual robot teams.
With the herein presented driver, the same code can be used to drive both real robots
and virtual simulated agents running on Stage or Gazebo [SVE11].
Therefore, the TraxBot driver allows the hybrid integration of different mobile platforms,
as well as virtual robots with different sizes and driving characteristics, as it will be seen
in the results section. In addition, the communication between real and virtual agents
is completely transparent since they are both operating in ROS middleware. This major feature is ideal to perform multi-robot tasks, allowing the use of a large population of
robots when no extra physical robots are available, being cheaper and promoting safer test
scenarios by making interactions between physical and virtual world objects [WCM09].
Multi-robot simulation is available for ROS through a Stage wrapper [SS12], which supports a high number of interacting robots depending on the computational complexity
of the algorithm. However, the opportunity to execute nodes on multiple CPUs in the
same network turns the upper bound of the teamsize arbitrarily high, thus removing the
overloading processing of a single machine. Finally, another particularity of using this
ROS driver is a mean to improve security in multi-robot tasks, for example, in a military operation, where it is possible to create a specific encrypted node for a robot of
the team [WA09], making the system more robust to attacks. Additionally, it is always
4.3. Summary
38
possible to monitor, log and debug at any time all exchanged information and specific
nodes running in the network.
4.3
Summary
This chapter presented a general overview of ROS (Robot Operating System), as well as a
full description of the two developed drivers. Further more, the potentialities and features
of the ROS drivers have been discussed. Chapter 5 presents the experimental results to
evaluate both the TraxBot platform and the ROS drivers.
Chapter 5
Results and Discussion
In order to experimentally evaluate the herein proposed platform, as well as the ROS
drivers, some experiments were conducted on a laboratory scenario, using both real and
virtual TraxBot platforms using stageros [SS12], which provides essential options like the
information about the ground truth pose and the odometry of virtual robots. These
robots are controlled with velocity commands. Other tests were performed to evaluate
the sensing system and the platform autonomy.
Firstly, the odometry of the robot is analyzed. This is followed by an accuracy analysis
of the sensing information provided by two lateral ultrasonic sonars mounted on top of
the robot, which are compared with a range laser sensor. Subsequently, an analysis of the
robot’s power consumption is done.
A more complex experiment with three sonars mounted on top of the robot is conducted to
address obstacle avoidance performance, as well as interaction between real and simulated
robots, tele-operation test was also performed to validate de potentialities of the ROS
driver and the flexibility to integrate several control devices. Finally, the communication
delays between the modules of the system were analyzed for both drivers.
5.1
Odometry
To evaluate the TraxBot odometry, a square trajectory with one-meter of side length was
performed, in both clockwise (CW) and counter-clockwise (CCW) directions. This test is
extremely challenging due to the fact that the robot always turns in the same direction,
40
5.2. Sensing and Mapping
41
Figure 5.1: Odometry square test evaluation.
a) Clockwise (CW) direction b) Counter-clockwise (CCW)
direction.
thus accumulating dead reckoning errors without compensation in the opposite direction.
Fig. 5.1 depicts the trajectories performed by the platform during the experiments. The
trajectories illustrated were collected using an overhead camera mounted on top of the
scenario. The tests were performed relying on the odometry system of the robot and
without the assistance of any external sensor or global localization system. The robot
performs movements in straight line with high accuracy. However, as expected, it exhibits
significant errors when rotating 90°.
Moreover, as the platform rotates, the odometry error increases due to a minor slipping
effect. Nevertheless, the accumulative error in the end of each test, after one lap, is
reduced. In the trial in CCW direction the robot ends with a positional error to its initial
position of 9.67cm and an angular error of -4.93°, while in the CW direction the positional
error is of 7.71 cm and the angular error of +2.13°.
5.2
Sensing and Mapping
In order to convert to centimeters the analog output values given by the sonar readings,
a calibration phase was initially conducted by measuring sonar readings in a straight line
at a distance to a wall between 5 to 200 cm, with an increment of 5 cm. The data was
collected and a curve fitting method by means of a power function f (x) = a.xb + c was
used, converting the analog values to centimeters, as shown in Fig. 5.2. The calibration
5.2. Sensing and Mapping
42
Figure 5.2: Sonar calibration.
function obtained, with the sensor readings (s) as input, was:
f (s) = 1, 1767s0,94657 − 0, 3759
with R2 : 0, 9992.
Note that R2 (or R-square) is a fraction between 0.0 and 1.0, which has no units and
quantifies goodness of fit. Higher values indicate that the model fits the data better
[PR12].
The TraxBot platform was temporarily equipped with a laser range finder (LFR) to
compare its performance against the native ultrasonic range sonars on a mapping task
[RDC05] and to show the flexibility of integrating new sensors in the robot by means of
ROS driver. The Hokuyo URG-04LX is a LRF classified as an Amplitude Modulated
Continuous Wave (AMCW) sensor [KTC+09]. The laser emits an infrared beam and a
rotating mirror changes the beam’s direction. The rotating mirror sweeps the laser beam
horizontally over a range of 240°, with an angular resolution of 0.36°. As the mirror
rotates at about 600 rpm, the scan rate is about 100 msec. The LRF has a quoted range
between 20 and 4095 mm. The quoted measurement error is ±10 mm for distances of less
than 1 m. For greater distances, the error is quoted as ±2%.
In order to test the sonars performance, a scenario with 2 m by 1.6 m in L shape was built,
with a constant width of 1 m and 0.5 m of height (Fig. 5.3). To perform this test, only
two lateral sonars placed at 45 degrees were used, since the goal of this test is to evaluate
the accuracy of sonars by mapping the scenario based on the combination of odometry
5.3. Power Consumption
43
Figure 5.3: Mapping test. a) Sonars b) Laser.
information and sonars readings. The front sonar is usually used for reactive avoidance of
obstacles, given that in mapping situations the projection of walls and obstacles detected
by the cone of the sonar will always be placed in front of the robot, which is highly
unreliable in most situations, as shown for example in Fig. 5.4b. In this test, the robot
movement relies solely on odometry. In Fig. 5.3a it can be seen in the first rectilinear
motion, that the sonars readings are stable (red dots) and coincident with the ground
truth scenario limits (blue line). Green dots represent the midpoint of sonars acoustic
beam.
Some issues arise when there is a rotation of 90 degrees, because the sonar beam cone has
an opening of approximately 36 degrees, thus presenting a loss of resolution, as illustrated
in Fig. 5.4a. In the case of Fig. 5.3b, the Hokuyo range laser sensor was used to perform
the same test. The opening of the laser was set to 180 degrees with a rate of 512 samples
per reading. It is possible to observe some discrepancy in some readings especially at the
end of the movement due the odometry position error accumulated during motion.
This test shows the possibility of integrating more sensors in the TraxBot platform, by
adding, in this case, the hokuyo node in the ROS network.
5.3
Power Consumption
In order to analyze the TraxBot’s power consumption, non-stop circular trajectories stress
tests were performed, at different velocities: Firstly tested at low velocity of 50mm/s,
5.3. Power Consumption
Figure 5.4: Noisy range situations. a) Issue during rotations using lateral sonars b)
This figure illustrates why the front sonar is not used for mapping.
Figure 5.5: Power consumption behavior.
44
5.4. ROS Driver Test
45
Figure 5.6: Driver Test. a) Real step test b) Stage simulation.
then at a regular velocity of 100mm/s and finally at a high velocity of 200mm/s. Fig.
5.5 demonstrates the remaining energy of batteries until they reach a minimum working
voltage of approximately 9 V, for the 3 different velocities tested. As expected with the
variation of speeds, it is possible to observe in the figure that the running time decreases
as speed increases.
The results show that the robot is able to operate continuously for 2-3 hours, depending
on the speed profiles.
5.4
5.4.1
ROS Driver Test
Point-to-point Motion
A ROS driver test that consists in performing a step-like trajectory on a grid map of
400×400mm is shown in Fig. 5.6. In this “step test”, a standalone point-to-point navigation algorithm was adopted, using x, y and theta position commands, retrieving data
from sonars and controlling the robot reactively. Two boxes with different dimensions
were added to the map as reference points. The main goal of the experiment is to test
the connectivity between distinct nodes of the network.
A network composed by two machines was used for distributing the processing load, relieving the eeePC notebook, and replicating the experiment simultaneously in the Stage
simulator. ROS master (roscore) and stageros node ran in a desktop computer and the
eeePC was placed on top of TraxBot running the ROS driver (TraxBot_Driver) and the
algorithm node (TraxBot_DriverTest). As it may be observed in Fig. 5.7 (combined with
46
Figure 5.7: TraxBot teleoperation.
Figure 5.8: Driver Test. a) Two robots with reactive navigation b) Mixed real and
virtual robots.
Fig. 4.3), all nodes operate in the same network and communicate through publication
and subscription to topics. While doing the “step test”, the TraxBot updates the odometry topic in real-time, which is subscribed by the stage node, processing the messages and
replicating the moves in the virtual world using a virtual robot (on the desktop screen),
as shown in Fig. 5.6b. The delay of this whole process is less than one second.
5.4.2
Mixed virtual and real robots teams
In this experimental trial, two TraxBots were deployed in a bounded laboratory arena
running a reactive wandering algorithm as illustrated by Fig. 5.8a. This test was conducted to verify the coordination between multiple robots. In this case, a mixed team of
real and virtual robots was used to demonstrate the ideas presented in section 4.2.3. The
two real TraxBots were replicated in Stage (Fig. 5.8b), and an extra virtual TraxBot,
with exactly the same reactive algorithm, was added. This can be seen as an interesting
47
Figure 5.9: TraxBot teleoperation devices.
feature for programmers, since with minor adjustments it is possible to use the same code
for either real or virtual robots. The blue beams in front of the robots correspond to real
scale range readings of 3 ultrasonic sonars installed in the TraxBot platform. All three
robots were able to coordinate themselves in the environment without colliding to each
other through reactive behavior, as shown in the video of the experiments.
5.4.3
Teleoperation
In this test, a node to teleoperate the TraxBot was developed. With teleoperation, one
can drive the robot using external remote control; e.g., a joystick or a keyboard. In the
case of a joystick like the wiimote or the PS3 controller (Fig. 5.9), since they operate via
a wireless technology; i.e., Bluetooth, the teleoperation node runs in the eeePC netbook,
which is an advantage over using the keyboard, given that this option assumes a static
operator controlling the robot, running the ROS teleoperation node in another computer,
which is connected over the ROS network with the eeePC netbook.
The teleoperation node subscribes to topics which have the information of the joystick
state and assigns functions for each pressed button, publishing then velocity commands,
which are interpreted by the TraxBot driver, resulting on motor commands. In the keyboard case, it is not necessary to subscribe to topics with the keyboard state, because the
teleoperation node uses standard C++ libraries to detect which keys are being pressed.
5.5. ROS Driver Limitations
Figure 5.10: StingBot.
5.4.3.1
48
Figure 5.11: StingBot
operating
with ROS driver.
Adaptation of the ROS driver in different platform
In this test, the portability of the ROS driver to other platforms based on similar hardware is demonstrated. The adaptations basically consist on specific adjustments of the
platforms, however the communication protocol is exactly the same, as well as the operation mode.
As an application example of the portability of this driver, a new differential platform was
used: the StingBot represented in Fig.5.10. This platform has a similar architecture to
the TraxBot, using an Arduino board as the processing unit and the OMNI-3MD driver
to control the motors. For test purposes, the driver was used in the StingBot robot without any modification of the functions developed. From the motor drive side, the only
modification conducted was the assignment of the PID controller gains of the StingBot
motors, because this is a lighter and trackless platform, thus requiring gains of a much
smaller order.
To validate this test, the teleoperation node previously described was used to control the
robot with the same ROS driver (Fig. 5.11).
5.5
5.5.1
ROS Driver Limitations
Driver first version
In order to analyze the driver overhead, the turnaround time of messages exchanged
between the three layers of the system (the OMNI-3MD driver, the Arduino board and
5.5. ROS Driver Limitations
49
Figure 5.12: ROS driver messages turnaround time for the ROS driver - version 1.
ROS) was measured.
It can be seen in Fig. 5.12 that the total turnaround time, between the OMNI-3MD motors
driver and ROS, increases with the number of messages, as expected. However, the values
measured are negligible when considering applications with real robots. For instance, the
average number of messages exchanged per second in the previous experimental trial is
20, which corresponds to a turnaround time of 36ms, a very residual delay which is not
critical when hard real-time constraints do not exist.
However, on the downside, it was also concluded that the Atmega328p microprocessor
used in the robot presents a limitation in terms of SRAM memory. When running the
driver, only 283 bytes of memory are available in the Arduino Uno, which means that for
standard topics (float 32 messages + topic headers), only 7 more topics can be added for
extensions and the message buffer is limited to 70 standard messages. This was the main
reason for migrating the publication of messages in topics to PC / ROS, in the second
version of the driver.
5.5.2
Driver second version
The same test was performed using the second version of the driver, exchanging float32 (4
bytes) messages. The time to pass a message between the PC / ROS side to the Arduino
was drastically decreased. Therefore, a global reduction of around 35% on the turnaround
time can be clearly observed when sending messages. In addition, the exchange capacity bottleneck is in the communication between the Arduino and the Omni-3MD driver,
5.6. Summary
50
Figure 5.13: ROS driver messages turnaround time for the ROS driver - version 2.
therefore the frequency of messages should be set accordingly in the ROS side to avoid
buffer overflow.
Given the reduction of the turnaround time and overtaken the SRAM limitations of the
first version of the driver, the new version presents enhanced robustness and responsiveness, becoming highly superior for the desired applications.
5.6
Summary
In this chapter, results were presented and discussed. In the subsequent chapter, an
overview of objectives accomplished in this work and the associate publications are presented. Finally this dissertation ends with conclusions and future work.
Chapter 6
Conclusions
This dissertation presented the development and experimental evaluation of a compact
robotic platform and its integration in ROS by developing a firmware driver. The next
section states the contributions of this work.
6.1
Contributions
There are two key contributions of this work. First, the development of a low-cost platform, denoted as TraxBot, suitable for reinforcing beginning programming concepts and
exploring algorithms of current interest to the robotics community. In addition, this platform is also useful in the fields of multi-robot systems (MRS) since it is a cost-efficient
off-the-shelf solution. Secondly, two ROS drivers are presented that allows the full integration of the robotic platform within ROS middleware. The advantages of integrating
the platform with ROS middleware were demonstrated, enabling the usage of a wide range
of tools and reducing the development time through code reuse. Beyond providing access
to all ROS tools, the driver simplifies the robotic development by supporting hardware
abstraction to easily control the platform. Moreover, the driver also allows the extension
and integration of all kinds of sensors, and enables multi-robot cooperation and coordination through the operation in a ROS network for real, virtual and hybrid teams of
homogeneous and heterogeneous robots, by running the same code. The results obtained
in the experiments demonstrate all of these features and the negligible overhead imposed
by the driver.
52
6.2. Future Work
6.1.1
53
Published Work
Regarding the first contribution of this work, a paper describing the assembling and
programming of the TraxBot was published in February 2012 in the 4th International
Conference on Agents and Artificial Intelligence (ICAART’2012) [APC+12] and another
one presenting a survey on small and middle-sized compact mobile robotic platforms
was published on the Automatics International Conference (FA’2012) [APC+12a] in June
2012. These works were mainly focused on presenting low-cost, open-source robots, as
well as the developed one, the TraxBot, to enable the ordinary consumer to enter the
robotics and artificial intelligence world, giving an innovative overview of compact mobile
robots used by academic researchers and by robot enthusiasts, and depicting their features,
prices, communications abilities, autonomy and dimensions, among others. Regarding the
second contribution of this work, i.e. the development of a ROS driver, a paper is being
prepared for submission on the 28th Symposium On Applied Computing (SAC’2013).
Also, in May of this year, an article presenting the work contained in this dissertation
was submited to the Robotica Journal on Cambridge, which is still waiting for review and
decision. All these papers are available as attachments and on the dissertation CD.
6.2
Future Work
In the future, a vast possibility of work is now possible: integrate ZigBee communication
directly through ROS, develop new drivers to accommodate different robots in the team
for heterogeneous experiments; integrate ROS navigation stack using an Hokuyo Laser;
integrate a Kinect sensor to endow the robot with the ability for visual SLAM; use an
android phone, together with the robot, to take advantages of its communication capability, as well as its internal sensors (electronic compass, GPS, accelerometers, camera, light
sensor).
[APC+12] A. Araújo, D. Portugal, M. Couceiro, C. Figueiredo and R. P. Rocha.
TraxBot: Assembling and Programming of a Mobile Robotic Platform, in
Proceedings of the 4th International Conference on Agents and Artificial
Intelligence (ICAART’2012), Vilamoura, Algarve, Portugal, February 6-8,
2012.
[APC+12a] A. Araújo, D. Portugal, M. Couceiro, C. Figueiredo and R. P. Rocha. Small
and Compact Mobile Robots Surveying and Comparing Platforms, in Proceedings of the 1st International Automatics Conference of the Technical University of Sofia (AUTOMATICS’2012), Sozopol, Bulgaria, June 1-4, 2012.
[BLM+10] M. Bonani, V. Longchamp, S. Magnenat, P. Rétornaz, D. Burnier, G. Roulet,
F. Vaussard, H. Bleuler and F. Mondada. The MarXbot, a Miniature Mobile
Robot Opening new Perspectives for the Collective-Robotic Research, in Int.
Conf. on Intelligent Robots and Systems, Oct. 18-22, 2010, Taipei, Taiwan,
2010.
[Ard10]
Arduino Uno, 2010, http://arduino.cc/en/Main/ArduinoBoardUno Last
access: 03.07.2012
[BRO11]
Manual Bot’n Roll OMNI-3MD, 2011, http://botnroll.com/omni3md/
downloads/Manual%20OMINI3-MD%2818-07-2011%29.pdf
Last
access:
03.07.2012
[Bru01]
H. Bruyninckx, Open robot control software: the OROCOS project, in Proceedings of IEEE International Conference on Robotics and Automation
(ICRA’01), volume 3, pp. 2523–2528, 2001.
54
[MRT03]
55
M. Montemerlo, N. Roy, S. Thrun, Perspectives on Standardization in Mobile
Robot Programming: The Carneggie Mellon Navigation (CARMEN) toolkit,
in Proceedings of the 2003 IEEE/RSJ International Conference on Intelligent
Robots and Systems (IROS’2003). Las Vegas, Nevada, October, 2003.
[CAS08]
J. Cummins, M.Q. Azhar and E. Sklar. Using Surveyor SRV-1 Robots to Motivate CS1 Students, in Proceedings of the AAAI 2008 Artificial Intelligence
Education Colloquium, 2008.
[CFL+12]
M. S. Couceiro, C. M. Figueiredo, J. M. A. Luz, N. M. F. Ferreira and R. P.
Rocha. A Low-Cost Educational Platform for Swarm Robotics, International
Journal of Robots, Education and Art, IJREA, Volume 2, Issue 1, February,
pp. 1-15, 2012.
[Col10]
Colot, A.:
K-Team Hemisson Manual, K-Team S.A., Yverdon-les-
Bains, Switzerland (2010), http://ftp.k-team.com/hemisson/Manuel_En/
Manual_Hemisson.pdf Last access: 03.07.2012
[CPP11]
ceral_port Package. http://www.ros.org/wiki/cereal_port Last access:
03.07.2012
[CRF11]
M. S. Couceiro, R. P. Rocha and N. M. Ferreira. A Novel Multi-Robot Exploration Approach based on Particle Swarm Optimization Algorithms, in Proc.
of 9th IEEE Int. Symposium on Safety, Security, and Rescue Robotics (SSRR
2011), Kyoto, Japan, pp. 327-332, Nov. 1-5, 2011.
[DK08]
R. Diankov and J. Kuffner, OpenRAVE: A Planning Architecture for Autonomous Robotics, Robotics Institute, Tech. Rep. CMU-RI-TR- 08-34, July
2008.
[DT06]
Data Translation Using Quadrature Encoders/ Decoders for X/Y Positioning
and Rotation, January, 2006.
[GM02]
B. Gerkey and M. Mataric, Sold!: Auction Methods for Multirobot Coordination, in IEEE Transactions on Robotics and Automation, Special Issue on
Multi-robot Systems, 18(5):758-768, October, 2002.
[GSB06]
56
G. Grisetti, C. Stachniss and W. Burgard, Improved Techniques for Grid
Mapping with Rao-Blackwellized Particle Filters, in IEEE Transactions on
Robotics, 2006.
[GVH03]
B. Gerkey, R. Vaughan and A. Howard, The Player/Stage Project: Tools for
Multi-Robot and Distributed Sensor Systems, in Proceeding of the Intl. Conf.
on Advanced Robotics (ICAR 2003), pp. 317-323, Coimbra, Portugal, July
2003.
[Idm05]
IdMind, Engenharia de Sistemas, Lda:
Manual de construção:
Robô
Circular GT. Lisboa, Portugal 2005, http://aprobotica.com.sapo.pt/
ManualCircularGT.pdf
[Jac07]
J. Jackson, Microsoft robotics studio: A technical introduction, in Proceedings
of the IEEE Robotics and Automation Magazine, Dec. 2007
[Jon06]
J. L. Jones, Robots at the tipping point: the road to iRobot Roomba, in IEEE
Robotics & Automation Magazine, 13(1), 76-78, March, 2006.
[Kui09]
M. Kuipers, Localization with the iRobot Create, in Proceedings of the 47th
Annual Southeast Regional Conference ACM (ACM-SE 47), Clemson, South
Carolina, USA, March 19-21, 2009.
[KTC+09] L. Kneip, F. Tâche, G. Caprari and R. Siegwart, Characterization of the
compact Hokuyo URG-04LX 2D laser range scanner, in Proceedings of the
IEEE International Conference on Robotics and Automation, Kobe, Japan,
May 12-17, 2009.
[MBF+10] E. Marder-Eppstein, E. Berger, T. Fully, B. Gerkey and K. Konolige, The
Office Marathon: Robust Navigation in an Indoor Office Environment, in Proceeding of the International Conference on Robotics and Automation (ICRA
2010), Anchorage, Alaska, May 2010.
[MBR+09] F. Mondada, M. Bonani, X. Raemy, J. Pugh, C. Cianci, A. Klaptocz, S.
Magnenat, J. C. Zufferey, D. Floreano and A. Martinoli. The e-puck, a Robot
57
Designed for Education in Engineering, in Proceedings of the 9th Conference
on Autonomous Robot Systems and Competitions, 1(1) pp. 59-65 2009.
[MBX05]
MB1300 XL-MaxSonar®-AE0™ Datasheet (2005), http://www.maxbotix.
com/documents/MB1200-MB1300_Datasheet.pdf Last access: 03.07.2012
[MFN06]
G. Metta, P. Fitzpatrick, L. Natale. Yarp: Yet another robot platform, in
Proceedings of International Journal on Advanced Robotics Systems 3 (1),
pp.43-48, 2006.
[Miz05]
M. Mizukawa. Robot Technology (RT) Trend and Standardization, in Proceedings of the IEEE Workshop on Advanced Robotics and its Social Impacts
(ARSO’05), WAO-1-1, Nagoya, Japan, June 2005.
[NS12]
navigation Stack. http://www.ros.org/wiki/navigation Last access:
03.07.2012
[Pet11]
A. M. Petrina. Advances in Robotics, in Automatic Documentation and Mathematical Linguistics, Vol. 45, No. 2, pp. 43–57, Allerton Press, Inc. 2011.
[PR11]
D. Portugal and R.P. Rocha. On the Performance and Scalability of MultiRobot Patrolling Algorithms, in Proceedings of the 2011 IEEE International
Symposium on Safety, Security, and Rescue Robotics (SSRR 2011), pp. 50-55,
Kyoto, Japan, November 1-5, 2011.
[PR12]
D. Portugal and R.P. Rocha, Measuring Variables Effect to Statistically
Model the Multi-Robot Patrolling Problem by means of ANOVA, in Luis M.
Camarinha-Matos, Ehsan Shahamatnia, Gonçalo Nunes (editors), Technological Innovation for Value Creation, Vol. 372, pp. 199-206, Proc. of 3rd
Doctoral Conference on Computing, Electrical and Industrial Systems (DoCEIS 12), Costa da Caparica, Lisbon, Portugal, Springer Berlin Heidelberg,
Feb. 27-29, 2012.
[QGC+09] M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs, E. Berger,
R. Wheeler, and A. Y. Ng,. ROS: an open-source Robot Operating System,
58
in Proc. Open-Source Software workshop of the International Conference on
Robotics and Automation (ICRA 2009), Kobe, Japan, May, 2009.
[RC11]
R. Rusu and S. Cousins. 3D is here: Point Cloud Library (PCL), in Proceeding of International Conference on Robotics and Automation (ICRA 2011),
Shanghai, China, May 2011.
[RC12]
ROS
concepts.
http://ros.org/wiki/ROS/Concepts
Last
access:
03.07.2012
[RDC05]
R. Rocha, J. Dias and A. Carvalho. Cooperative Multi-Robot Systems: a Study
of Vision-based 3-D Mapping using Information Theory, in Proc. of IEEE Int.
Conf. on Robotics and Automation (ICRA’2005), Barcelona, Spain, pp. 386391, Apr. 18-22, 2005.
[REE12]
ROS
Electric
Emys.
http://ros.org/wiki/electric
Last
access:
03.07.2012
[Roo10]
M. Root. The Tab Battery Book: An In-Depth Guide to Construction, Design, and Use, McGraw-Hill/Tab Electronics, pp. 182, 2010.[ISBN: 9780071739900].
[Roo12]
Roomba ROS driver http://www.ros.org/wiki/Robots/Roomba Last access: 03.07.2012
[RS12]
rosserial
Stack.
http://www.ros.org/wiki/rosserial
Last
access:
03.07.2012
[SAR10]
SAR - Soluções de Automação e Robótica:
Manual Bot’n Roll ONE
C. Guimarães, Portugal, 2010, http://botnroll.com/onec/downloads/
Manual%20Bot%27n%20Roll%20ONE%20C%20PT.pdf Last access: 03.07.2012
[SCS11]
serial_communication
Stack.
http://www.ros.org/wiki/serial_
communication Last access: 03.07.2012
[Sha07]
S. Sharad. Introducing Embedded Design Concepts to Freshmen and Sophomore Engineering Students with LEGO MINDSTORMS NXT, mse, pp.119-
59
120, IEEE International Conference on Microelectronic Systems Education
(MSE’07), 2007.
[SR09]
A. J. Sousa, L. P. Reis. Using Accelerometers to Command a Cleaning Service Robot, in Progress in Artificial Intelligence: Proceedings of the 14th Portuguese Conference on Artificial Intelligence, EPIA2009, pp.288-299, 2009.
[SS12]
stage Stack. http://www.ros.org/wiki/stage Last access: 03.07.2012
[SVE11]
T. Linner, A. Shrikathiresan, M. Vetrenko, B. Ellmann. Modeling and Operating Robotic Environment using Gazebo/ROS, in Proceedings of the 28th
International Symposium on Automation and Robotics in Construction (ISARC2011), Seoul, Korea, pp.957-962, 2011.
[TRK11]
Traxster II Robot kit. http://www.roboticsconnection.com/ Last access:
03.07.2012
[Tur11]
TurtleBot,
Willow
Garage
(2011),http://www.willowgarage.com/
turtlebot Last access: 03.07.2012
[WA09]
A. Wagner and R. Arkin. Robot Deception: Recognizing when a Robot Should
Deceive, in Proceedings of Computational Intelligence in Robotics and Automation (CIRA), Daejeon, Korea, December 2009.
[WCM09]
B.Wunsche, I. Chen, B. MacDonald. Mixed Reality Simulation for Mobile
Robots, in Proceedings of International Conference on Robotics and Automation (ICRA 2009), Kobe, Japan, May, 2009.
[XBM06]
XBee® Multipoint RF Modules Datasheet (2006), http://www.digi.com/
pdf/ds_xbeemultipointmodules.pdf Last access: 03.07.2012
[ZSS11]
S. Zaman, W. Slany and G. Steinbauer. ROS-based Mapping, Localization
and Autonomous Navigation using a Pioneer 3-DX Robot and their Relevant
Issues, in Proceedings of the IEEE Saudi International Electronics, Communications and Photonics Conference, Riad, Saudi-Arabia, 2011.

ROSint - Integration of a mobile robot in ROS architecture

Transcription

Similar documents

pdf presentation

newsletter aug 11

Teen Driver Contract

Emergence of spontaneous proto

Introduction to Robotics

FU-Fighters 2002 (Middle size)

DR.13.2 Robot Automation Industry meets Robotics

EFAS Wandtafel Mitte

Robot Intuition

nEar05 eXperience