D6.2 First outdoor robotic platform prototype for the first ...€¦ · D6.2 First outdoor robotic platform prototype for the first experimental loop Due date of deliverable: [31/03/2013]

Grant Agreement number: 288899 Project acronym: Robot-Era

Project title: Implementation and integration of advanced Robotic systems and intelligent Environments in real scenarios for ageing population

Funding scheme: Large-scale integrating project (IP)

Call identifier: FP7-ICT-2011.7 Challenge: 5 – ICT for Health, Ageing Well, Inclusion and Governance

Objective: ICT-2011.5.4 ICT for Ageing and Wellbeing Project website address: www.robot-era.eu

D6.2

First outdoor robotic platform prototype

for the first experimental loop

Due date of deliverable: [31/03/2013]

Actual submission date: [31/12/2013]

Start date of project: 01/01/2012 Duration: 48 months

Organisation name of lead contractor for this deliverable: RT Deliverable author: Giancarlo Teti

Version: [1.3]

Project co-funded by the European Commission within the Seventh Framework

Programme (2007-2013)

Dissemination Level

PU Public

PP Restricted to other programme participants (including the Commission Service)

RE Restricted to a group specified by the consortium (including the Commission Service)

CO Confidential, only for members of the consortium (including the Commission Service) CO

D6.2 - First outdoor robotic platform

prototype for the first experimental loop

File name: robot-era_wp6_d6.2_v1.3.doc

Leader contractor: RT

Participant contractors: - Page 2 of 32

Document H is tory

Version Date Author Summary of Main Changes

1.0 01-04-2013 Giancarlo Teti (RT) First version of the Deliverables

1.3 12/02/2014 Giancarlo Teti Final version






Table o f Contents

Executive summary........................................................................... 4

List of Annexes ................................................................................. 5

1 Introduction ............................................................................. 6

2 Mobile Base ............................................................................ 10

2.1 List of Contents in Annex 1.......................................................................... 11

3 Container and Rollers Conveyor.............................................. 12


4 User Support Handle............................................................... 14


5 Motor Driver ........................................................................... 15


6 Head/Bin Driver ..................................................................... 18


7 Eye PCB .................................................................................. 20


8 Power Board........................................................................... 21


9 Software Architecture............................................................. 23


10 Robot-Era Outdoor Services.................................................... 26

10.1 Drug and Shopping Delivery Scenario ........................................................... 26

10.2 Outdoor Walk ............................................................................................ 31






Execut ive summary

This document is an attachment to Deliverable D6.2 “First outdoor robotic platform

prototype for the first experimental loop” which formally is a prototype and describes the

new hardware and software components developed to update and improve the existing

Outdoor Robot and to adapt the platform for implementing the Robot-Era services.

More in details this document describes:

− the current state of the Outdoor Robot hardware and software architecture;

− the mobile base;

− the container with roller conveyor;

− the user support handle;

− the motor driver;

− the head-bin driver;

− the eye PCB;

− the power board;

− The robot control software.

Details related to the design of the new components are attached to this document as

annexes.

The design of the new components to update, improve and adapt the platform for

implementing the Robot-Era services has been based on the requirements and specifications

reported in deliverable D6.1 “Report on specifications and middleware architecture” which in

their turn have been defined on the basis of the description of the Robot-Era services

identified in Task 2.3 “Robotic service optimization and design” of WP2 “User and town

centred design of Robot-Era services” and reported in Section 4.4 “Structure of the main

services identified in Task 2.3” of Deliverable D2.2 “First report on the structures of Robot-

Era services”.

The document describes also the implementation of the Robot-Era Outdoor Services from

the point of view of the outdoor Robot.

Finally, updated releases of this document and his annexes will be released up to the end of

the Robot-Era project as soon as new update and new components will be developed.






L ist of Annexes

Annex 1 – Mechanical Drawings

1. Mechanical Drawings of the Mobile Base

2. Mechanical and Electrical Specification of Motor Swissdrive 400T

3. Mechanical Drawings of the Container

4. Mechanical Drawings of the Support Handle

Annex 2 – Motor Driver

5. DustCart Motor Driver Specifications.

6. DustCart Motor Driver Schematic

7. DustCart Motor Driver H-Bridge Schematic

8. DustCart Motor Driver CAN Bus Protocol

Annex 3 – Head-Bin Driver

9. DustCart Head-Bin Driver Specifications

10. DustCart Head-Bin Driver Schematic

11. DustCart Head-Bin Driver CAN Bus Protocol

Annex 4 – Eye PCB

12. DustCart Eye PCB Specifications

13. DustCart Eye PCB Schematic

Annex 5 – Power Board

14. DustCart Power Board Specifications

15. DustCart Power Board Schematic

Annex 6 – Software Architecture

16. DustCart ROS Architecure

17. DustCart ROS launch file

Annex 7 - Manuals

18. DustCart Quick Manual – Hardware






1 Introduct ion

The existing outdoor robot DustCart has been updated in order to improve performances

and robustness of the system and to implement the robot era services. More in details

updates and new developments concerns:

− the mobile base to increase the robustness of the robot for navigating in urban

environment;

− the container to implement goods exchange with the condominium robot;

− the user support handle to allow the user to walk close to the robot;

− the localization system;

− the electronics for the control of the mobile base, the head and the container;

− the software.

The new mobile base consists of a mechanical chassis with two central actuated wheels

and four passive rear wheels. The 6 wheels are linked by joints and shock absorbers

allowing the robot to adapt to and compensate road disconnections and to guarantee

constant adherence of the driving wheels to the ground.

The new container consists of a box with actuated rollers on the bottom which can roll

back and forth allowing a box to move outwards and inwards for implementing goods

exchange, and new opening mechanism has been developed to open and close the

container.

The new user support handle consist of a mechanical support fixed on the left side of the

robot frame, a pillow for the user arm and a joystick.

The new localization system consists of two GPS with differential correction applied (DGPS)

and two antennas mounted on the back of the robot providing robot position and orientation

in outdoor.

The electronics of the system has been partially renewed and new electronic boards have

been developed: the ‘motor driver’ for the control of the mobile base, the ‘head-bin

driver’ for the control of the head, the ‘eye PCB’ for the eyes, the container and the

rollers, the ‘power board’ for the management of the power of the robot.

Finally, the ‘robot control software’ (system supervisor and navigation module) has been

completely rewrote from scratch and integrated into ROS and a ’ROS/PEIS interface’ has

been developed to integrate DustCart into the PEIS ecology.

Figure 1. The old and new DustCart robot.






Figure 2. The new mobile base and the new container with rollers.

Figure 3. The user support handle and the new container opening mechanism.






Figure 4. The new hardware architecture.






Figure 5. Position of the new ‘head-bin driver’, ‘motor driver’, power board and

differential gps in the robot.






2 Mobi le Base

The mobile base consists of a mechanical chassis with two central actuated wheels

(Swissdrive 400 T hub motor with electromagnetic brake and encoder by Micro-Motor AG)

and four passive front and rear wheels. The 6 wheels are linked by joints and shock

absorbers (BITUBO SC006YXB01) with a degree of freedom allowing the robot to adapt to

and compensate road disconnections.

Figure 6. The 3D design of new mobile base.

For each side of the base the adaptation mechanism consist of two arms (front and rear)

and two pivots (front and rear) and linked together with a joint. The two arms rotate on

their pivot and rotation is limited by the joint and regulated by the shock absorber. The

possible motions of the arms are shown in the Figure 7.

Figure 7. The adaptation mechanism of the mobile base.






Figure 8. Dimension of the mobile base.

Figure 9. The mobile base.

For each side of the base the adaptation mechanism consist of two arms (front and rear)

and two pivots (front and rear) and linked together with a joint. The two arms rotate on

their pivot and rotation is limited by the joint and regulated by the shock absorber. The

possible motions of the arms are shown in the Figure 7.

Mechanical drawings of the mobile base are reported in Annex 1 section “Mechanical

Drawing of the Mobile Base”.

The drive wheels and motors are Swissdrive 400 T (by Micro-Motor AG, Switzerland). The

Swissdrive 400 T is a hub motor with electromagnetic brake and encoder, voltage 24VDC,

power 400W, max speed 165 RPM, gear ratio 8.78:1, encoder 40 pulses per rotation,

nominal wheel diameter 33.8 cm. Mechanical drawings and specifications of the Swissdrive

400 T mobile base are reported in Annex 1 section “Mechanical and Electrical Specification

of Motor Swissdrive 400T”.

2 . 1 L i s t o f C o n t e n t s i n A n n e x 1

− Mechanical Drawings of the Mobile Base

− Mechanical and Electrical Specification of Motor Swissdrive 400T






3 Container and Rol lers Conveyor

The container consists of a box with an open side on the back and 10 rollers on the bottom.

Rollers are coupled two by two alternatively on the left and right side of the container in

order to form a single chain by means of pulleys and transmission belts. A motor on the

back of the container is linked to the first roller and moves the rollers chain back and forth.

IR receiver and transmitter are positioned on the front and back of the container to detect

the presence and the movement of objects on the rollers. Available space for objects in the

container is 50 x 34 x 30 cm.

Figure 10. The 3D design of new container with rollers.

Figure 11. Available space in the container.

A second motor positioned on the front of the robot frame allows the container to be opened

and closed. For this purpose, two limit switches (magnetic reeds) are positioned on the left

side of the robot frame to detect the closing and opening position of the container. A

magnet, mounted on the right side of the container in correspondence of the reeds,

activates the back reed when the container is closed and the front reed when the container






is opened. Finally a solenoid mounted on the left side of the robot frame allows to

lock/unlock the container.

Figure 12. The opening/closing components of the container.

Finally, to facilitate transportation and exchange of goods with the condominium robot a box

containing the goods of dimension 25 x 25 x 25 cm, about 15 l, is used.

Figure 13. The box for object transport.

Mechanical drawings of the container are reported in Annex 1 section “Mechanical Drawing

of the Container”.


− Mechanical Drawings of the Container






4 User Support Handle

The user support handle consist in a mechanical plate supporting a pillow and a joystick.

The plate is mounted on the left side of the robot thanks to two flanges fixed to the robot

mechanical frame and can be removed form the robot. The height of the handle can be

manually regulated from 100cm to 110 cm according to the user height. Mechanical

drawings of the support handle are reported in Annex 1 section “Mechanical Drawing of the

Support Handle”.

Figure 14. The 3D design of user support handle.

Figure 15. The 3D design of user support handle.


− Mechanical Drawings of the User Support Handle






5 Motor Dr iver

The ‘motor driver’ implements a PI control for two DC brushed/brushless motor with

encoders and its main input/output communication interface is CAN bus. Shortly, the ‘motor

driver’ is powered with 24 VDC, receives high level commands (linear and angular speeds of

the robot) on the CAN bus, enable and disable the motor brakes, computes the proper left

and right motor speeds, reads the encoder pulses, implements the PI control, powers the

motors providing two PWM signals and monitor the current for each motor.

Figure 16. The motor driver.

Figure 17. General scheme of motor driver.

More in details, the ‘motor driver’ consists of two boards: a real ‘motor driver’ board based

on a microcontroller and implementing the low power logic of the control of the motors and

a ‘H-bridge’ board hosting the current sensors and implementing two H bridges for powering

the motors. The ‘motor driver’ board is based on a STM32F103 (part number

STM32F103RBT) microcontroller from the STM32 family by ST Microelectronics. The

STM32F103 is a 32 bit micro controller with CPU ARM Cortex™-M3, 72 MHz maximum

frequency, 256 Kbytes of Flash memory and 20 Kbytes of SRAM. The micro is provided with






3 x 12 bit ADCs, 2 x 12 bit DAC, 38 digital input/output, two quadrature encoder inputs, 2 ×

16-bit motor control PWM, CAN, USB and UART interfaces and is powered with 3.3V. The

PWM control of the motor has been realised using two L6388E L6206 by ST Microelectronics.

The schematics of the ‘motor driver’ and ‘H-bridge’ boards are reported in Annex 2 section

“DustCart Motor Driver Schematic” and “DustCart Motor Driver H-Bridge Schematic”.

The PCB layouts, interfaces and mechanical specifications of the ‘motor driver’ and ‘H-

bridge’ boards are reported in Annex 2 section “DustCart Motor Driver Specifications”.

Table 1. DustCart motor driver specification

Specifications

Power 24VDC, 40 A

Motor 2 x 24VDC, max 20 A (~400W) brushed/brushless motors

Brakes 2 x 24VDC, 0.3 A

Encoders 2 x quadrature encoders, 5V

Communication CAN bus up to 1Mbps

The ‘motor driver’ board receive commands for the motor from the CAN bus. In particular,

the robot receives the desired robot linear speed in m/s (speed_ms) and the robot angular

speed in rad/s (turn_rs). From these parameters the ‘motor driver’ computes the left target

motor speed and the right target motor speed in encoder pulses according to the following

formulas:

rsturndistwheel

msspeedspeedmotor _2

__.1_ ⋅+=

rsturndistwheel

msspeedspeedmotor _2

__.2_ ⋅−=

π⋅⋅⋅−=

diawheel

trevxcountsspeedmotorettpulsesencoder

_

__.arg._

where:

wheel_dist is the distance between the robot wheels in m

wheel_dia is the wheel diameter in m

count_per_rev is the encoder pulses per wheel revolution

t is the time of the control period.

The ‘motor driver’ implements a PI control for each motor computing the PWM or duty cycle

according to this formula:

scaling

IP

K

ErrKtKErrcycledutyprevcycleduty

)(___ ∑⋅⋅+⋅

+=

where:

Err is the error between encoder_pulses.target and the actual encoder pulses.

The KP and KI constants can be set for each motor as well as wheel diameter, wheels

distance, max duty cycle and max current for each motor.






The time of the control period is 20 ms. Moreover, for security reason the speed command

should be provided to the board every 100 ms: if the speed command is not provided for

more than 500 ms the board stop the motors. The status of the ‘motor driver’, including

current robot linear and angular speed, total current, and left and right motor status and

power input level is provided on the CAN bus every 20 ms.

Table 2. DustCart robots control parameters

Wheel

Diameter

Wheel

Distance

KP

Left

KI

Left

KP

Right

KI

Right

Pulse

per Rev

Max

Duty

Max

Current

DustCart 1 Blue 33.50 60.00 200 50 200 50 702 80 22

DustCart 2 Green 33.50 52.80 200 50 200 50 702 80 22

The CAN bus protocol of the ‘motor driver’ board is reported in Annex 2 section “DustCart

Motor Driver CAN Bus Protocol”.

Figure 18. DustCart motor driver connection scheme.


− DustCart Motor Driver Schematic

− DustCart Motor Driver H-Bridge Schematic

− DustCart Motor Driver Specifications

− DustCart Motor Driver CAN Bus Protocol






6 Head/Bin Driver

The ‘head bin driver’ controls the robot head, the LEDs in the left and right eye, the

opening/closing mechanism of the container, the rollers, and the IR transmitters and

receivers connected to the rollers. The ‘head bin driver’ is powered with 24 VDC and

receives high level commands on the CAN bus.

Figure 19. The ‘head bin driver’ board.

Figure 20. General scheme of the ‘head bin driver’ connections.






More in details, the ‘head bin driver’ consists of a boards based on the the STM32F103 (part

number STM32F103RBT) microcontroller from the STM32 family by ST Microelectronics. The

STM32F103 is a 32 bit micro controller with CPU ARM Cortex™-M3, 72 MHz maximum

frequency, 256 Kbytes of Flash memory and 20 Kbytes of SRAM. The micro is provided with

3 x 12 bit ADCs, 2 x 12 bit DAC, 38 digital input/output, two quadrature encoder inputs, 2 ×

16-bit motor control PWM, CAN, USB and UART interfaces and is powered with 3.3V.

Figure 21. Connections between head-bin driver and its devices.

The schematic of the ‘head bin driver’ is reported in Annex 3 section “DustCart Head-Bin

Driver schematic”. The PCB layouts, interfaces and mechanical specifications of the ‘head

bin driver’ board is reported in Annex 3 section “DustCart Head-Bin Driver Specifications”.

The CAN bus protocol of the ‘head bin driver’ board is reported in Annex 3 section “DustCart

Head-Bin Driver CAN Bus Protocol”.


− DustCart Head-Bin Driver Schematic

− DustCart Head-Bin Driver Specifications

− DustCart Head-Bin Driver CAN Bus Protocol






7 Eye PCB

The ‘eye PCB’ controls the LEDs of the dustcart robot eyes. The ‘eye PCB’ hosts 29 LEDs

divided into three groups of LEDs: red LEDS (8), green LEDs (13) and yellow LEDs (8). Each

group of LED can be switched on, in fix or blink mode, or off separately. The PCB can be

configured both has left eye or right eye.

Figure 22. LEDs position in the left and right eye PCB.

The schematic of the ‘eye PCB’ is reported in Annex 4 section “DustCart Eye PCB

Schematic”. The PCB layouts and interfaces specifications are reported in Annex 4 section

“DustCart Eye PCB Specifications”.


− DustCart Eye PCB Schematic

− DustCart Eye PCB Specifications






8 Power Board

The ‘power board’ manages the power of the whole robot. The power board is powered with

24V from battery and distributes the power to all the robot devices, i.e. drivers, actuators,

sensors, PC, touch screen, etc.

The power board is switched on with a ‘key’ and its status (on/off) is shown by a green LED.

Some of the power outputs of the board (typically low power outputs for ‘not dangerous’

devices) are automatically powered when the board is on. Other power outputs (typically

high power outputs for ‘dangerous’ devices such as motor driver) are controlled also by two

emergency inputs. In total, the board has 6 key switched 24V power outputs (max 5A for

each output), 5 emergency switched 24V power outputs (3 max 5A, 2 max 50A) and a 12V

key switched power output (max 1A). Both emergency inputs must be closed to allow power

outputs.

The board has two power inputs, one for the key switched outputs and one for the

emergency switched outputs. The power inputs lines are protected by two different fuses.

Figure 23. Scheme of the ‘power board’.

If the power input (battery level) is lower than 22.6V the power board will not switch on. If

during normal activities power input (battery level) is lower than 20.5V the board switches

off.

The schematic of the ‘power board’ is reported in Annex 5 section “DustCart Power Board

schematic”. The PCB layouts, interfaces and mechanical specifications of the ‘power board’

are reported in Annex 5 section “DustCart Power Board Specifications”.

The power connections of DustCart, including batteries and battery charger connections,

are shown in Figure 24. Fuse 1 is 15A, fuse 2 is 50A.






Figure 24. Scheme of power connections.


− DustCart Power Board Schematic

− DustCart Power Board Specifications






9 Software Architecture

The software architecture of DustCart is based on the Robot-Era general architecture which

is based on a two-layer reference architecture, where:

− at the upper layer, called “Ecology Layer”, the PEIS middleware provides seamless

integration among the heterogeneous Robot-Era devices, including the outdoor robot;

− at the lower layer, called “Device Layer”, each robot and device uses its specific

architecture and middleware internally, while externally it presents a uniform interface

toward the ecology layer through PEIS.

The abstract robot architecture (Device Layer) described in details in Section 6 of D7.1 is

shown in Figure 25.

Figure 25. Abstract architecture of a Robot-Era robotic platform (from Deliverable D7.1

“Report on the interoperability aspects of Robot-Era services”)

The specific architecture of DustCart is an "instance" of the general abstract robot

architecture and is shown in Figure 26.

In DustCart ROS is the middleware software and provides the interface to access all the low

level hardware components (mobile base, robot head, bin/container, GUI, joystick, ecc.)

through the CAN bus or other specific ROS drivers. The ‘robot control system’ manages the

robot hardware components and the internal robot activities including navigation and the

PEIS/ROS interface provides to the PEIS ecology the robot high level functions useful to

implement the Robot-Era services.

The PEIS/ROS interface is used to interact with all the PEIS ecology components, such as

domestic robot, condominium robot, PEIS configuration planner module (CPM), home

sensors and actuators, high level services, etc.






The CPM or other PEIS components provide commands as PEIS tuples to the robot through

the PEIS/ROS interface which translates these tuples into proper ROS commands for the

robot control system. Viceversa, the PEIS/ROS interface translates commands or status

messages from the robot control system into PEIS tuples for the CPM or other PEIS

components to inform about the status of its activities or to send commands.

Figure 26. The software architecture of DustCart, instance of the general abstract

architecture of a Robot-Era robotic platform

In Figure 26 is shown the detailed ROS architecture of DustCart: details of each node are

described in Annex 6 section “DustCart ROS Architecure”.

A ROS launch file called “dcart.launch” has been created to configure and launch the ROS

nodes of DustCart. To start DustCart just run the following commands:

roscore &

roslaunch dcart dcart.launch

The current ROS launch file is reported in Annex 6.


− DustCart ROS Architecure

− DustCart ROS launch file






Figure 27. The new software architecture.






10 Robot-Era Outdoor Serv ices

This section describes the implementation of the outdoor Robot-Era services from the point

of view of the outdoor robot. More details related to the whole implementation of the

services, involving also user, domestic robot, condominium robot, user interfaces

(tablet/voice) are reported in the documents “Drug and Shopping Delivery Scenario

Storyboard”, “Outdoor Walking Support Scenario Storyboard” and “Garbage

Collection Scenario Storyboard” which describe the whole PEIS protocol (PEIS tuples) for

implementing the Robot-Era services.

All services are started by the PEIS Configuration Planner Module (CPM) which send proper

tuples over the PEIS middleware to the outdoor robot. PEIS tuples are catch by the

PEIS/ROS interface of DustCart which manages all the actions essential to achieve the

assigned task. When necessary, for example during a goods exchange procedure, outdoor

robot communicates directly with the condominium robot using the PEIS middleware.

1 0 . 1 D r u g a n d S h o p p i n g D e l i v e r y S c e n a r i o

The following steps summarize the main actions of the Drug/Shopping Delivery Scenario as

reported in the document “Drug and Shopping Delivery Scenario Storyboard”:

− The user orders the drugs/shopping by means of the tablet.

− The order list is sent through the internet to the pharmacy/grocery.

− CPM commands the robot to move to the pharmacy/grocery and wait for it to be there.

− The CPM commands the robot to start HRI for the pharmacy/grocery, and the

pharmacist/shopkeeper puts the drugs/shopping into the outdoor robot opening its

container by means of the touch screen.

− The CMP commands the outdoor robot to move in front of the condominium entrance

and wait for it to be there.

− CMP commands outdoor robot and condominium robot to perform the goods exchange

procedure and wait for its execution.

− CMP command condominium robot to move in front of user home door.

For the first experimental loop a shop has been simulated and the shop location has been

chosen close to the main entrance of the Domocasa Lab. In Figure 28 is shown the map of

the environment surrounding the Domocasa lab with the point selected as location for the

simulated shop (point Pshop). The home location or starting point of the outdoor robot (point

P0) has been selected just in front of the main entrance of the Domocasa building: P0

coincides with the origin of the robot map and its GPS UTM coordinates are 4823902.50 N,

638280.10 E.

To reach the shop the CPM first commands the robot to move from P0 to the intermediate

point P1 and then to the final location Pshop. The same on the way back. The outdoor robot

uses the GPS to localize itself during the navigation to the shop and back. Coordinates of

points P1 and Pshop with respect to the reference frame defined in P0 are shown in Figure 28.

When the outdoor robot is in Pshop CPM starts HRI on the outdoor robot: the user opens the

container with the touch screen and he puts the shop into the robot container. To facilitate

the goods exchange between outdoor robot and condominium robot, the box showed in

section 3 has been used to hold the goods.

When the outdoor robot is back in P0 CPM commands a goods exchange procedure to

outdoor robot and condominium robot. Condominium robot moves to the entrance hall of

Domocasa building in front of the main entrance door and wait for outdoor robot. Outdoor

robot reaches the exchange points defined in the middle of the main entrance of Domocasa

bulding. Since GPS doesn’t work well close to buildings, the outdoor robot uses two optical






beacons detected with the laser to localize itself during the exchange of goods procedure.

The optical beacons have been placed on the sides of the main entrance of the Domocasa

building (Figure 29) and they define a new reference system with the origin in the middle of

them as shown in Figure 30. The goods exchange point has been defined in the middle of

the Domocasa building main entrance, i.e. the origin of the new reference system.

Figure 28. Outdoor surroundings of Domocasa lab and demo points.

Figure 29. Main entrance of Domocasa building and optical beacons.






To reach the goods exchange point, the outdoor robot disables the GPS, enables the optical

beacon odometry and moves to the goods exchange point, rotates 180° in order to have the

container toward the entrance hall and it opens its container.

At this point it commands the condominium robot to dock itself. When dock is terminated

the condominium robot starts its roller in and informs outdoor robot to start its roller out to

transfer the box from outdoor robot to condominium robot. When transfer has been

completed, condominium robot undock itself and informs outdoor robot to close the

container. Outdoor robot close the container and move back to its home position.

Figure 30. Outdoor The beacons and the goods exchange point.

In summary, for the outdoor robot, the steps are:

1. CPM commands the robot to move to P1

2. CPM commands the robot to move to Pshop

3. CPM starts HRI on outdoor robot and shopkeeper puts the box in the container



6. CPM starts the goods exchange procedure:

− outdoor robot moves in the goods exchange point and open the bin

− outdoor robot commands condominium robot to dock itself

− condominium robot docks and commands outdoor robot to start its roller out

− the box moves from outdoor robot to condominium robot

− condominium robot commands outdoor robot to close the bin

− outdoor robot move back to P0

The following table shows an example of the communications between CPM, outdoor robot

and condominium robot to implement the shopping scenario as described above. Figure 31

and Figure 32 show trajectory performed by the outdoor robot to reach the simulated and

move back and the trajectory to reach the goods exchange position.

More details about the implementation of the goods exchange procedure are reported in

the document DustCart ROS Architecture, section “Node goods exchange”.






Table 3. Example of communication between CPM, outdoor robot and

condominium robot to implement the shopping scenario

STEP COMMUNICATION MESSAGE TUPLE USER/ROBOT ACTIONS

CPM → OUTDOOR ROBOT MOVE TO P1 oro1.moveto.1

8.0 0.0 -1.57 MOVETO 8.0 0.0 -1.57

1

OUTDOOR ROBOT → CPM MOVE TO

COMPLETED

oro1.moveto.1

COMPLETED

CPM → OUTDOOR ROBOT MOVE TO Pshop oro1.moveto.2

11.0 -20.0 -1.57 MOVETO 11.0 -20.0 -1.57

2


COMPLETED

oro1.moveto.2

COMPLETED

CPM → OUTDOOR ROBOT TAKE GOODS oro1.takegoods.1 ROBOT SHOWS HRI FOR TAKE

GOODS ACTIVITY

USER PRESS THE BUTTON TO OPEN

THE CONTAINER, USER PUTS THE

ORDER IN THE ROBOT

USER PRESS THE BUTTON TO CLOSE

THE CONTAINER

3

OUTDOOR ROBOT → CPM TAKE GOODS

COMPLETED

oro1.takegoods.1

COMPLETED


8.0 0.0 -3.14 MOVETO 8.0 0.0 -3.14

4


COMPLETED

oro1.moveto.3

COMPLETED


0.0 0.0 -2.35 MOVETO 0.0 0.0 -2.35

5


COMPLETED

oro1.moveto.3

COMPLETED

CPM → OUTDOOR ROBOT GOODS

EXCHANGE

oro1.goodsexchange.1

OUT START DOCKING PROCEDURE

DISABLE GPS

ENABLE BEACON ODOM

MOVETO 0 0 -3.14

OPEN THE BIN

OUTDOOR ROBOT →

CONDOMINIUM ROBOT DOCK

coro1.docking.0

DOCK_ON

DUSTCART_USE_POSE X Y θ

CONDOMINIUM ROBOT →

OUTDOOR ROBOT START ROLLER

oro1.startroller.1

OUT START ROLLER OUT

CONDOMINIUM ROBOT →

OUTDOOR ROBOT BIN CLOSE oro1.closebin.2 BIN CLOSE

MOVETO -8 0 0

DISABLE BEACON ODOM

ENABLE GPS

6

OUTDOOR ROBOT → CPM

GOODS

EXCHANGE

COMPLETED

oro1.goodsexchange.1

COMPLETED






Figure 31. Outdoor Robot trajectory from P0 to Pshop and back during an experiment.

Figure 32. Outdoor Robot trajectory from P0 to goods exchange position during an experiment.






1 0 . 2 O u t d o o r W a l k i n g S u p p o r t

In the outdoor walking support scenario the user moves ‘arm in arm’ with the robot: the

user stands on the robot side, rest his forearm on the support handle and control the robot

with the joystick. The support handles is mounted on the right side of the robot and the

joystick is connected to the USB of the PC. During the walk the robot uses the laser to

detect obstacles in front of the robot and/or the user, and any obstacles along the path is

signalled with acoustic (beep) and visual (red led blinking) signals.

Three control modes are available:

1. the robot just warns the user about obstacles with the acoustic signal and it’s up to

the user to avoid the obstacle.

2. The robot warns the user about obstacles and if an obstacle is on the user or robot

path the robot doesn’t move forward to avoid collision. Only turns are allowed to the

user and it’s up to him to avoid the obstacle.

3. The robot warns the user about obstacles and avoid the obstacle autonomously

without help of the user and independently of the user commands. The user must

follow the robot and take again control of the robot once the obstacle has been

avoided.

The user controls the robot through the joystick lever and buttons:

− move the joystick lever forward to move the robot forward.

− move the joystick lever left to turn on place the robot left (left spin).

− move the joystick lever right to turn on place the robot right (right spin).

− move the joystick lever forward and left to turn the robot left.

− move the joystick lever forward and right to turn the robot right.

− move the joystick lever back to move the robot back. Reverse is allowed only in

mode 2 and 3.

Commands associated to buttons are:

− button 2 to play the horn

− button 3 to decrease robot speed (decrement unit is 0.025 m/s)

− button 4 to increase robot speed (increment unit is 0.025 m/s)

− button 5 to enable motor driver

− button 6 to disable motor driver

− button 7 to release mobile base brakes

− button 8 to start walk service and set the walk mode

Default robot speed is 0.35 m/s. Minimum speed is 0.15 m/s. Maximum speed is 0.8 m/s.

Pressing more times button 8 changes robot control mode. Pressing many times button 8

changes the control mode: current control mode and current maximum robot speed are

shown on the robot GUI. The outdoor walk service can be activated by the CPM with a

specific tuple or directly by the user pressing button 8 on the joystick.

More details about the software implementation of the outdoor walk service are reported in

the document DustCart ROS Architecture, section “Node walk”.






In the first experiment loop the robot was placed in front of the main entrance of the

Domocasa building and user were asked to moves with the robot follow a path which include

also passing in between obstacles represented by street poles: the path is shown in Figure

33. A path followed by a user is shown in Figure 34.

Figure 33. The path the user were asked to follow during the experiment.

Figure 34. A path followed by a user during the first loop of experiment.

D6.2 – Annex 6

File name: robot-era_wp6_d6.2_annex_6.doc





Funding scheme: Large-scale integrating project (IP) Call identifier: FP7-ICT-2011.7 Challenge: 5 – ICT for Health, Ageing Well, Inclusion and Governance


D6.2 Annex 6

Software Architecture




Organisation name of lead contractor for this deliverable: RT

Deliverable author: Giancarlo Teti

Version: [1.0]



Dissemination Level

PU Public






Funding scheme: Large-scale integrating project (IP)

Call identifier: FP7-ICT-2011.7 Challenge: 5 – ICT for Health, Ageing Well, Inclusion and Governance


DustCart ROS Architecure




Organisation name of lead contractor for this deliverable: RT Deliverable author: Giancarlo Teti

Version: [1.0]



Dissemination Level

PU Public





File name: dustcart_ros_architecture.doc



Document H is tory

Version Date Author Summary of Main Changes

1.0 01-06-2013 Giancarlo Teti (RT) First version of the document

1.1 31/01/2014 Giancarlo Teti Last version





Table o f Contents

Introduction ..................................................................................... 4

1 Package dcart........................................................................... 6

1.1 Node can .................................................................................................... 6

1.2 Node net ..................................................................................................... 8

1.3 Node dcart ................................................................................................ 10

1.4 Node dcart_tf ............................................................................................ 13

1.5 Node command.......................................................................................... 14

1.6 Node log ................................................................................................... 15

1.7 Node gps .................................................................................................. 16

1.8 Node beacon_odom.................................................................................... 18

1.9 Node odom................................................................................................ 20

1.10 Node move_base ....................................................................................... 22

1.11 Node goods_exchange ................................................................................ 25

1.12 Node walk ................................................................................................. 29

2 Package dcart_gui .................................................................. 32

2.1 Node gui ................................................................................................... 32

3 Package peis_ros.................................................................... 36

3.1 Node peis_ros............................................................................................ 36

4 Package novatel_driver .......................................................... 40

4.1 Node novatel_driver ................................................................................... 40





Introduct ion

This document describes the ROS architecture of DustCart. The ROS nodes of the

architecture are divided into four ROS packages: dcart, dcart_gui, peis_ros and

novatel_driver.

The dcart package includes the ROS node that manages the robot:

− dcart: this node is the robot supervisor, manages the robot components, get commands

for the robot and publishes the robot status from/to ROS topics.

− can: this node is the ROS interface to the CAN bus, writes/reads messages to/from the

CAN bus and gets/publishes these messages from/to ROS topics.

− net: this node is a TCP/IP server and allows remote Ethernet access to the CAN bus.

The node gets/sends messages from/to client and publishes/get these messages from/to

ROS topics.

− dcart_tf: this node publishes the tf needed by ROS.

− command: this node allows to enter commands for the robot from the keyboard and

publishes these commands to ROS topics.

− log: this node logs all ROS messages published to the rosout topic to a file.

− gps: this is the interface with the Novatel GPS ROS driver and publishes to ROS topics

robot position and heading from the GPS.

− beacon_odom: this node computes robot position and orientation with respect to a

reference frame defined by two optical beacons placed in a known position in the

environment and detected by the laser.

− odom: this node computes and publishes robot odometry estimates on the base of

encoder readings, gps node input and/or beacon_odom node input.

− move_base: this node implements obstacle avoidance navigation of the robot on the

base of odom and laser inputs and compute robot linear and angular speed over the

time to reach a goal location.

− goods_exchange: this node implements the goods exchange outdoor robot and

condominium robot coordinating all the actions required to achieve the task.

− walk: this node implements the walk services, gets commands from the user through

the joystick and publishes linear and angular speed command to user input.

The dcart_gui package includes the ROS node that manages the robot GUI:

− gui: this node manages the GUI running on the touch screen, starts proper graphical

user interfaces, get commands from the user and publishes commands to ROS topics.

The peis_ros package implements the bridge between PEIS and ROS:

− peis_ros: this node gets PEIS tuples and publishes proper messages to ROS topics, vice

versa gets messages from ROS topics and publishes proper PEIS tuples.

Finally the novatel_driver package implements the driver for the Novatel GPS system:

− novatel_driver: the node manage the Novatel GPS, gets GPS position and heading

data and publishes GPS UTM coordinates and heading to ROS topics.

Details of each node are described in the next sections of this document.





Figure 1. ROS architecture of DustCart





1 Package dcart

1 . 1 N o d e c a n

The can node is a ROS driver for the PCAN-PCI board installed on the DustCart PC. The can

node reads and writes all messages from and to the CAN bus, publishes on the

dcart/canread topic all messages read from the CAN bus and writes to the CAN bus all

messages read on the topic dcart/canwrite.

Messages are mainly directed to ‘motor driver’ to control the mobile base and to the ‘head

bin driver’ to control robot head, eye and bin. Node frequency is 50 Hz. Details about the

CAN protocol are reported in the documents “DustCart Motor Driver CAN Bus Protocol” and

“DustCart Head Bin Driver CAN Bus Protocol”.

Figure 2. The can node topics.

Node name

can

Published Topics

dcart/canread (dcart/CAN_msg)

Messages read from the CAN bus.

Subscribed Topics

dcart/canwrite (dcart/CAN_msg)

Messages to write to the CAN bus.

Services

None

Parameters

None





Command-Line Tools

rosrun dcart can

Source code

src/canlib.cpp

src/can.cpp

src/can_node.cpp





1 . 2 N o d e n e t

The net node allows remote access over the Ethernet to the CAN bus of DustCart. The node

is a TCP/IP server and accept TPC/IP connections from remote clients on the socket port

3600: messages from the client are wrote to the CAN bus, messages from the CAN bus are

sent to the remote client. Messages from the remote TCP/IP client are directed to ‘motor

driver’ to control the mobile base and to the ‘head bin driver’ to control head, eye and bin.

Vice versa, messages to the remote TCP/IP client are mainly status messages of these

components.

Messages from/to the remote client are arrays of 10 bytes: first two bytes are the CAN

message header (high bytes first), last 8 bytes are the CAN message payload.

The node publishes on the dcart/canwrite topic all messages from the remote TCP/IP

client and sends to the remote TCP/IP client all messages read on the topic dcart/canread.

The node publishes on the dcart/status topic the connection status: the string “client

connected” is published when the node accept a remote TCP/IP connection and the message

“client disconnected” is published when the connection is closed by the remote client. The

Node frequency is 10 Hz.

Figure 3. The net node topics.

Node name

net

Published Topics

dcart/canwrite (dcart/CAN_msg)

Messages to the CAN bus.

dcart/status (std_msgs/String)

− client connected published when a connection has been established

− client disconnected published when a connection has been closed

Subscribed Topics


Messages from the CAN bus.





Services

None

Parameters

None

Command-Line Tools

rosrun dcart net

Source code

src/net.cpp

src/net_node.cpp





1 . 3 N o d e d c a r t

The dcart node is the supervisor of the outdoor robot. The node gets commands from the

other nodes and manages the robots components (base, head and bin or container) through

the CAN bus.

The node subscribes the dcart/command topic to get command from the other nodes and

the dcart/status topic to get the status from the other nodes. The node subscribes the

dcart/canread topic to get messages from ‘motor driver’ and ‘head bin driver’ through the

‘can’ node: status messages are read and the corresponding status is published to the

dcart/status topic. The node publishes messages to the dcart/canwrite topic to send

commands to ‘motor driver’ and to ‘head bin driver’ through the ‘can’ node.

The node subscribes the cmd_vel topic to get linear and rotational speed from the ‘walk‘

node and the ‘move_base’ node and to send the proper commands to the ‘motor driver’.

The node publishes the voltage battery level every 1 second to the battery topic.

When a remote client is connected through the ‘net’ node this is informed thoriugh the

dcart/status topic and all commands for the ‘motor driver’ are not send. The node frequency

is 20 Hz.

The node set the yellow LEDs to blink mode when the robot is moving, the green led on

when the status of gps is narrow (accuracy is good) and the red led on when the base

motors are disabled.

Figure 4. The dcart node topics.

Node name

dcart

Published Topics

battery (std_msgs/String)

− battery V published every second: V voltage battery level

dcart/canwrite (dcart/CAN_msgs)

CAN Messages for ‘motor driver’ and ‘head bin driver’ trough the ‘can’ node.






− bin is closed published when the bin status change to closed

− bin is open published when the bin status change to open

− bin undefined published when the bin status change to from

open or close to undefined

− roller in published when roller start moving in or backward

− roller out published when roller start moving out or forward

− roller off published when roller stop moving

− motor power on published when ‘motor driver’ and ‘head bin driver’ are powered

− motor power off published when ‘motor driver’ and ‘head bin driver’

are not powered

− motor enabled published when ‘motor driver’ have been enabled

− motor disabled published when ‘motor driver’ have been disabled

− moving published when the robot start moving

− stopped published when the robot stop moving

Subscribed Topics

dcart/command (std_msgs/String)

− base enable to ‘motor driver’ to enable the base

− base disable to ‘motor driver’ to disable the base

− base brake to ‘motor driver’ to release the motor brakes

− base stop to ‘motor driver’ to stop current motion

− base move V T to ‘motor driver’ to set robot linear V and rotational speed T

− base moveto X Y θ to ‘move_base’ node to set robot target to X Y θ (m/rad)

− bin open to ‘head bin driver’ to open the bin

− bin close to ‘head bin driver’ to close the bin

− bin discharge to ‘head bin driver’ to open the bin in discharge mode

− roller forward to ‘head bin driver’ to start roller in forward mode

− roller out to ‘head bin driver’ to start roller in forward mode

with automatic stop

− roller backward to ‘head bin driver’ to start roller in backward mode

− roller in to ‘head bin driver’ to start roller in backward mode

with automatic stop

− roller stop to ‘head bin driver’ to stop rollers

− head side to ‘head bin driver’ to move the head in the side position

− head front to ‘head bin driver’ to move the head in the front position

− head move P to ‘head bin driver’ to move the head in P position (deg)





− led on to ‘head bin driver’ to switch on all LEDs

− led off to ‘head bin driver’ to switch off all LEDs

− led blink to ‘head bin driver’ to switch on in blink mode all LEDs

− led green on to ‘head bin driver’ to switch on green LEDs

− led green off to ‘head bin driver’ to switch off green LEDs

− led green blink to ‘head bin driver’ to switch on in blink mode green LEDs

− led red on to ‘head bin driver’ to switch on red LEDs

− led red off to ‘head bin driver’ to switch off red LEDs

− led red blink to ‘head bin driver’ to switch on in blink mode red LEDs

− led yellow on to ‘head bin driver’ to switch on yellow LEDs

− led yellow off to ‘head bin driver’ to switch off yellow LEDs

− led yellow blink to ‘head bin driver’ to switch on in blink mode yellow LEDs


− client connected from ‘net’ node to be informed that a remote client

is connected. Commands for the mobile base are disabled

− client disconnected from ‘net’ node to be informed that a remote client

disconnected. Commands for the mobile base are enabled.

dcart/canread (dcart/CAN_msgs)

CAN Messages from ‘motor driver’ and ‘head bin driver’ trough the ‘can’ node.

cmd_vel (geometry_msgs/Twist)

− Robot linear and rotational speed to be sent to ‘motor driver’. Analogous to a

‘move’ command for the dcart/command topic.

Services Client

None

Parameters

None

Command-Line Tools

rosrun dcart dcart

Source code

src/ dcart.cpp

src/ dcart_node.cpp





1 . 4 N o d e d c a r t _ t f

The dcart_tf node publishes every 10 ms the tf between “/map” and “odom” and between

“base_link” and “laser”. Node frequency is 100 Hz.

Node name

dcart_tf

Published Topics

None

Subscribed Topics

None

Services

None

Parameters

None

Command-Line Tools

rosrun dcart dcart_tf

Source code

src/dcart_tf.cpp





1 . 5 N o d e c o m m a n d

The command node allows to send commands to the DustCart supervisor from the

standard input, e.g. the keyboard. The node publishes the lines entered on the standard

input to the dcart/command topic.

Figure 5. The net node topics.

Node name

command

Published Topics


Commands to the robot.

Subscribed Topics

None

Services

None

Parameters

None

Command-Line Tools

rosrun dcart command

Source code

src/command.cpp





1 . 6 N o d e l o g

The log node logs on a text file all ROS messages published by the DustCart ROS nodes.

The node creates or opens in append the file “dcart_log_YY_MM_DD.txt” in the .ros folder

and subscribes the rosout topic. All messages on the rosout topic are wrote to the log file

and to the standard output. Node frequency is 100 Hz.

Figure 6. The log node topics.

Node name

log

Published Topics

None

Subscribed Topics

rosout (rosgraph_msgs/Log)

Messages from rosout.

Services

None

Parameters

None

Command-Line Tools

rosrun dcart log

Source code

src/log.cpp

src/log_node.cpp





1 . 7 N o d e g p s

The gps node is the interface with the Novatel GPS ROS driver. The node subscribes the

Novatel ROS driver topics and depending on the GPS status publishes the robot coordinates.

The Node frequency is 100 Hz.

The node subscribes the novatel/position_solution topic where the GPS status and the

position in UTM coordinates are published and the novatel/heading_solution where the

GPS align status and heading position are published. Every 5 seconds, if both status

solutions are “NARROW_INT” the node publishes to the dcart/gps_pos topic the position

and orientation in the robot map. Robot position is obtained from the GPS UTM coordinates,

which is the antenna position, referred to the origin of the robot coordinate system minus

the UTM coordinate of the map origin. Robot heading is obtained from GPS heading sign

reversed, in fact GPS heading is clockwise while ROS map heading is counter clockwise.

The map origin in UTM coordinate and the position of the antenna with respect to the robot

frame origin can be set as ROS parameters named /gps/x_init, /gps/y_init, /gps/x_antenna

and gps/y_antenna.

The node subscribes also the dcart/command topic and publishes messages to the

dcart/status and dcart/command topics. The node publish to the dcart/command topic

the string ‘led green on’ to switch on the green LED and to the dcart/status topic the string

‘gps aligned’ when both solutions are NARROW_INT. The node publish to the

dcart/command topic ‘led green off’ to switch off the green LEDs and to the dcart/status

topic the string ‘gps NOT aligned’ when one solution is not NARROW_INT.

The command ‘gps init’ on the dcart/command topic set the map origin to the current GPS

UTM position.

Figure 7. The gps node topics.

Node name

gps_interface

Published Topics


Commands for the LEDs showing the GPS solution status. Messages published:

− led green on: when both GPS solutions are narrow int

− led green off: when at least one GPS solutions is not narrow int






The GPS status. Messages published:

− gps aligned: when both GPS solutions are narrow int

− gps NOT aligned: when at least one GPS solutions is not narrow int

dcart/gps_pose (nav_msgs/Odometry)

The robot pose and orientation in local map reference frame.


Commands for the GPS. Messages accepted:

− gps init: set map origin to the current GPS UTM pose.

Subscribed Topics

novatel/position_solution (novatel_msgs/Position)

GPS position status and GPS antenna UTM coordinates from the Novatel driver.

novatel/heading_solution (novatel_msgs/Heading)

GPS align status and antennas orientation from the Novatel driver.

Services

None

Parameters

/gps/x_init (double, default: 0)

UTM x coordinate of the map origin.

/gps/y_init (double, default: 0)

UTM y coordinate of the map origin.

/gps/x_antenna (double, default: 0) (NOT YET IMPLEMENTED)

Antenna x coordinate wrt robot reference frame.

/gps/y_antenna (double, default: 0) (NOT YET IMPLEMENTED)

Antenna y coordinate of wrt robot reference frame.

Command-Line Tools

rosrun dcart gps

Source code

src/gps.cpp

src/gps_node.cpp





1 . 8 N o d e b e a c o n _ o d o m

The beacon_odom node computes and publishes robot position and orientation with

respect to a reference frame defined by two optical beacons placed in the environment in a

known position. The node subscribes the scan topic to get laser reads to compute robot

position and orientation and publishes every 5 sec computed position to the

dcart/beacon_pose topic. Node frequency is 10 Hz.

The optical beacons reference system is exactly in the middle of the line linking the two

beacons, whose distance is known. The node uses the laser to detect optical beacons and

their distance and position in polar coordinate (ρ,θ) in the robot reference frame. Then

triangulates, translates and rotates to compute robot position and orientation (x,y,θ) w.r.t.

the optical beacons reference system.

Figure 8. The odom node topics.

The node subscribes the dcart/command topic. The node accepts commands to enable or

disable its outputs (messages ‘beacon enable’ or ‘beacon disable’).

Figure 9. The beacon_odom node topics.

Node name

beacon

Published Topics

dcart/beacon_pose (nav_msgs/Odometry)

− Robot odometry position wrt beacons reference system published every 5 sec.





Subscribed Topics

scan (sensor_msgs/LaserScan)

− Laser readings.


Commands for the beacon_odom node. Messages accepted:

− beacon enable enable outputs to the dcart/beacon_pose topic.

− beacon disable disable outputs to the dcart/beacon_pose topic.

Services

None

Parameters

/beacon_odom/intensity (double, default: 10000)

Lower intensity threshold for detecting an optical beacon.

/beacon_odom/distance (double, default: 2.4 m)

Distance between the two beacons in meters.

Command-Line Tools

rosrun dcart beacon_odom

Source code

src/beacon_odom.cpp

src/beacon_odom_node.cpp





1 . 9 N o d e o d o m

The odom node computes and publishes robot odometry. The node subscribes the

dcart/canread topic to get the motor driver status messages (left and right wheel speed)

to compute robot odometry (position and orientation). Odometry is published every 10 ms

to the odom topic.

Odometry position is updated when a new pose provided by the gps node is available on

the dcart/gps_pose topic or when a new pose estimated by the beacon node is available

on the dcart/beacon_pose topic.

The node subscribes the dcart/command topic. The node accepts commands to enable or

disable updates from the gps node (messages ‘gps enable’ or ‘gps disable’) or from the

beacon nodes (messages ‘beacon enable’ or ‘beacon disable’) or commands to set the

current robot pose (message ‘base pose’).

The node publish every 1 second a string with the robot position to the dcart/status topic.

Figure 10. The odom node topics.

Node name

odom

Published Topics

odom (nav_msgs/Odometry)

− Robot odometry position published every 10 ms.


The odom staus. Messages published every 1 second:

− pos: X Y θ speed: VX VY Vθ

Subscribed Topics

dcart/gps_pose (nav_msgs/Odometry)

The robot GPS pose and orientation in the local map reference frame.






− gps enable enable update of robot odometry pose with GPS pose.

− gps disable disable update of robot odometry pose with GPS pose.

− beacon enable enable update of robot odometry pose with bacon node pose.

− beacon disable disable update of robot odometry pose with bacon node pose.

− base pose X Y θ set robot pose to X Y and θ


CAN bus messages.

Accepted messages: motor driver status messages (header 0x210).

Services

None

Parameters

None

Command-Line Tools

rosrun dcart odom

Source code

src/odom.cpp

src/odom_node.cpp





1 . 1 0 N o d e m o v e _ b a s e

The move_base node implements the obstacle avoidance navigation of DustCart. The node

subscribes the dcart/status topic to get status of ‘motor driver’, the dcart/commmand

topic to get navigation goals from other ROS nodes and to the move_base_simple/goal

topic to get navigation goals from rviz. To compute robot trajectory the node subscribes

also the scan topic to get laser readings to avoid obstacles and to the odom topic to get

robot odometry.

The node publishes to the dcart/command topic commands to enable/disable the mobile

base. Commands for the robot, i.e. linear and angular speed, are published to the cmd_vel

topic: robot commands are published every 100 ms. Finally, the node publishes to the

robot_footprint topic the robot footprint.

The node provide also the service dcart/avoid_obstacle: this service takes as input a

linear and angular speed command for the robot and returns true if there is a collision. If

the result is true the service returns also a free collision linear and angular speed command.

Figure 11. The move_base node topics.

Node name

move_base

Published Topics


− base disable for ‘dcart’ node to disable ‘motor driver’ output

− base enable ‘dcart’ node to enable ‘motor driver’ output


− moveto completed to inform other nodes and PEIS supervisor through

‘peis-ros’ node that a moveto has completed

− moveto failed to inform other nodes and PEIS supervisor

through ‘peis-ros’ node that moveto has completed

with failure


− Robot linear and rotational speed for the ‘motor driver’ through the ‘dcart’ node





robot_footprint (geometry_msgs/ PolygonStamped)

− Robot footprint for rviz

Subscribed Topics


− moveto X Y θ from other nodes or PEIS supervisor through ‘peis-ros’

node to start a moveto command to pose X Y θ (m/rad).

− movefw X from other nodes or PEIS supervisor through ‘peis-ros’

node to start a moveto forward command to X (m).

− stop to stop any moveto command


− motor power off to be informed when ‘motor driver’ are off

− motor enabled to be informed when ‘motor driver’ are enabled

− motor disabled to be informed when ‘motor driver’ are disabled

odom (nav_msgs/Odometry)

− Robot odometry position from ‘odom’ node.

scan (sensor_msgs/LaserScan)

− Laser readings for obstacle avoidance.

/move_base_simple/goal

− moveto goal position from rviz.

Services

dcart/avoid_obstacle (dcart/AvoidObstacle)

− Free collision direction. Service input: linear and rotational speed from other

nodes. Service output: collision status, recommended linear and rotational speed

to avoid the obstacle.

Parameters

/move_base/max_vel_x (double, default: 0.6 m/s)

Max linear robot speed in m/s

/move_base/min _vel_x (double, default: 0.1 m/s)

Min linear robot speed in m/s

/move_base/max_rotational_vel (double, default: 25°/s)

Max angular robot speed in rad/s





/move_base/min_rotational_vel (double, default: 5°/s)

Min angular robot speed in rad/s

/move_base/xy_goal_tolerance (double, default: 0.25 m)

Goal tolerance in m

/move_base/yaw_goal_tolerance (double, default: 15°)

Yaw tolerance in rad

/move_base/slow_dist (double, default: 3.5 m)

Distance in m from the goal from when the robot start slow speed.

/move_base/front_obstacle_margin (double, default: 1 m)

Distance in m in front of the robot from where obstacles are considered for obstacle

avoidance

/move_base/ side_obstacle_margin (double, default: 0.15 m)

Distance in m on the robot side from where obstacles are considered for obstacle

avoidance.

/move_base/max_goal_turnaway (double, default: 45°)

Maximum allowed deviation (in rad) from the optimal goal path to avoid obstacles.

Command-Line Tools

rosrun dcart move_base

Source code

src/move_base.cpp

src/move_base _node.cpp





1 . 1 1 N o d e g o o d s _ e x c h a n g e

The goods_exchange node implements the Robot-Era shopping service and garbage

collection service only in relation to the exchange of goods between outdoor robot and

condominium robot. The node implements also the garbage collection service to collect the

garbage directly from the user and the dock and undock procedures which move the

outdoor robot to the docking position where the transfer of goods take place or to the

undock position.

The exchange procedure from ‘dcart’ to ‘condo’ (command ‘goods exchange OUT’) is the

following:

� Move ‘dcart’ to a pre-docking position where beacons are visible

� Disable ‘gps’ node output and enable ‘beacon’ node output

� Move ‘dcart’ to docking position using the odometry information from the ‘beacon’

node

� Open the bin

� Start ‘condo’ docking through ‘peis-ros’ node providing ‘dcart’ relative position

(x,y,th) wrt to the ‘default docking position’.

� Wait for condo docking to start the rollers to transfer the box from ‘dcart’ to ‘condo’

� Wait for the ‘bin close’ command provided by condo through the peis-ros node

� Move ‘dcart’ to pre-docking position using the odometry information from the

“beacon” node

� Enable ‘gps’ node output and disable ‘beacon’ node output.

Default docking position is the position where condo learned its docking position: (x,y,th) is

get from the current position minus the default docking position.

The exchange procedure from ‘condo’ to ‘dcart’ (command ‘goods exchange IN’) is the

following:

� Move ‘dcart’ to a pre-docking position where beacons are visible

� Disable ‘gps’ node output and enable ‘beacon’ node output

� Move ‘dcart’ to docking position using the odometry information from the beacon

node

� Open the bin

� Start ‘condo’ docking through ‘peis-ros’ node providing ‘dcart’ relative position

(x,y,th) wrt to the ‘pre-set’ docking position in condo

� Wait for condo docking to start the rollers

� Start ‘condo’ rollers through ‘peis-ros’ node to transfer the box from ‘condo’ to ‘dcart’

� Start ‘condo’ undock through ‘peis-ros’ node

� Wait for the ‘bin close’ command provided by condo through the ‘peis-ros’ node

� Move ‘dcart’ to pre-docking position using the odometry information from the

‘beacon’ node

� Enable ‘gps’ node output and disable ‘beacon’ node output.





The node subscribes the dcart/command topic and dcart/status topic to get commands,

status messages and robot position to manage properly the goods exchange procedure. The

node publishes messages to the dcart/command topic and dcart/status topic to inform

about its status and to send command ‘move_base’ node and ‘condominium robot’.

Figure 12. The goods_exchange node topics.

Node name

goods_exchange

Published Topics


− moveto X Y θ to ‘move_base’ node to move the robot in X Y θ

− stop to ‘move_base’ node to stop the base

− base pose X Y θ to ‘odom’ node to set robot pose to X Y θ

− gps disable to ‘gps’ node to disable its output

− gps enable to ‘gps’ node to enable its output

− beacon disable to ‘beacon’ node to disable its output

− beacon enable to ‘beacon’ node to enable its output

− bin open to ‘dcart’ node to open the bin

− bin close to ‘dcart’ node to close the bin

− roller forward to ‘dcart’ node to move roller forward

− roller out to ‘dcart’ node to move roller out

− roller backward to ‘dcart’ node to move roller backward

− roller in to ‘dcart’ node to move roller in

− roller stop to ‘dcart’ node to stop roller

− coro1 dock X Y θ to ‘condo’ robot through ‘peis-ros’ node to start docking

− coro1 startroller out to ‘condo’ robot through ‘peis-ros’ node to start roller out

− coro1 undock to ‘condo’ robot through ‘peis-ros’ node to start undock

− take goods to ‘gui’ node to inform to start take goods procedure






− goods exchange completed to inform PEIS supervisor through ‘peis-ros’

node that goods exchange has completed

− goods exchange failed to inform PEIS supervisor through ‘peis-ros’

node that goods exchange has completed with failure

− start roller completed for ‘condo’ robot through ‘peis-ros’ node

to inform that start roller has completed

− docking to inform that ‘docking’ procedure has started

− docking completed to inform that ‘docking’ procedure has completed

− docking FAILED to inform that ‘docking’ procedure completed with failure

− undocking to inform that ‘undocking’ procedure has started

− undock completed to inform that ‘undocking’ procedure has completed

− undock FAILED to inform ‘undocking’ procedure completed with failure

− garbage collection completed to inform PEIS supervisor through ‘peis-ros’

node that garbage collection has completed

− garbage collection failed to inform PEIS supervisor through ‘peis-ros’

node that garbage collection has completed with failure

Subscribed Topics


− goods exchange OUT from PEIS supervisor through ‘peis-ros’ node

to start the exchange procedure from ‘dcart’ to ‘condo’

− goods exchange IN from PEIS supervisor through ‘peis-ros’ node

to start the exchange procedure from ‘condo’ to ‘dcart’

− start roller OUT to start rollers to transfer goods from ‘dcart’ to ‘condo’

− start roller IN to start rollers to transfer goods from ‘condo’ to ‘dcart’

− garbage collection DISCHARGE from PEIS supervisor through ‘peis-ros’ node

to start the discharge procedure of garbage

− garbage collection CHARGE from PEIS supervisor through ‘peis-ros’ node

to collect the garbage directly from the user

− dock X Y θ to dock ‘dcart’ to the position (X,Y,θ)

− undock X Y θ to undock ‘dcart’ to the position (X,Y,θ)


− moveto completed to be informed when a moveto has completed successfully

− moveto failed to be informed when a moveto has completed with failure

− bin is open to be informed when a bin open has completed

− bin is closed to be informed when a bin close has completed

− roller off to be informed when a start roller has completed

− take goods completed to be informed when the take goods has completed





odom (nav_msgs::Odometry)

To get robot position

Services Client

None

Parameters

/goods_exchange/x_dock (double, default: 0)

X coordinate of the docking position

/goods_exchange/y_dock (double, default: 0)

Y coordinate of the docking position

/goods_exchange/h_dock (double, default: 0)

Orientation of the docking position

Command-Line Tools

rosrun dcart goods_exchange

Source code

src/ goods_exchange.cpp

src/ goods_exchange_node.cpp





1 . 1 2 N o d e w a l k

The walk node implements the Robot-Era walk service. The node subscribes the joy topic

to get commands given by the user through the joystick and publishes motor commands

(linear and angular speeds) to the cmd_vel topic.

During the walk the robot uses the laser to detect obstacles in front of the robot and the

user, and any obstacles along the path is signaled with acoustic (beep) and visual (red led

blinking) signals. The node implements three control modalities.

In the first mode, the robot just warns the user about obstacles with the acoustic signal and

it’s up to the user to avoid the obstacle.

In the second mode the robot warns the user about obstacles and if an obstacle is on the

user or robot path the robot doesn’t move forward to avoid collision. Only turn commands

are allowed to the user and it’s still up to him to avoid the obstacle.

In the third mode the robot still warns the user about obstacles and avoid the obstacle

autonomously without help of the user and independently of the user commands. The user

must follow the robot and take again control of the robot once the obstacle has been

avoided.

The user controls the robot through the joystick lever and buttons. To move the robot

forward move the joystick lever forward. To turn on place the robot left (left spin) move the

joystick lever left. To turn on place the robot right move the joystick lever right (right spin).

To turn the robot left move the joystick lever forward and left. To turn the robot right move

the joystick lever forward and right. Reverse is allowed only in mode 2 and 3: to move back

the robot turn the joystick lever back. Robot turn the head right while turning right or left

while turning left.

Buttons are used to play the horn (button 2), decrease/increase robot speed (buttons 3 and

4), enable/disable motor driver (buttons 5 and 6), release mobile base brakes (button 7),

set the walk mode (button 8).

Default robot speed is 0.35 m/s. Minimum speed is 0.15 m/s. Maximum speed is 0.8 m/s.

Increment/decrement unit is 0.025 m/s.

Table 1. Joystick button commands

Button Command

1 -

2 Horn

3 Speed down

4 Speed up

5 Enable motor driver

6 Disable motor driver

7 Disable motor brakes

8 Set walk mode





The node uses the dcart/avoid_obstacle service to detect any possible obstacles along

the path and to get free collision directions. The node subscribes the dcart/command

topic: the node accepts commands to start the walk service and set the control modality

(‘walk set mode 1’, ‘walk set mode 2’, and ‘walk set mode 3’). The node publishes messages

to the dcart/command topic to enable or disable the mobile base or disable motor brakes

and publishes messages to the gui/message topic to inform the GUI about its status. Node

frequency is 20 Hz.

Figure 13. The walk node topics.

Node name

joy

Published Topics


− Robot linear and rotational speed.

gui/message (std_msgs/String)

Status messages for GUI:

− walking mode MODE max speed MAX_SPEED


− base enable

− base disable

− base brake

− led red blink

− led red off

− led red blink

− head move HEAD_POS

Subscribed Topics


Commands for the node to set the walk mode. Messages command:

− walk set mode WALK_MODE

joy (sensor_msgs/Joy)

Joystick lever position and buttons status.





Services Client

dcart/avoid_obstacle (dcart/AvoidObstacle)

− Free collision direction. Service input: linear and rotational speed (user

command). Service output: collision status, recommended linear and rotational

speed to avoid the obstacle.

Parameters

None

Command-Line Tools

rosrun dcart walk

Source code

src/walk.cpp

src/walk_node.cpp





2 Package dcart_gui

2 . 1 N o d e g u i

The gui node manage the GUI running on the DustCart touch screen. The node subscribes

the dcart/command topic to get commands involving HRI and starts proper graphical user

interfaces and the gui/messages topic to get and display messages on the touch screen.

Messages are supported also by vocal synthesis. The node publishes to the

dcart/command topic user commands given through the touch screen such as command

to open or close the bin or commands to support HRI such as commands to move the head

or switch on/off LEDs. The node publishes to the dcart/status topic the status of its

activities.

Figure 14. The walk node topics.

Node name

gui

Published Topics


− head side to ‘dcart’ node to move the head for HRI activities

− head front to ‘dcart’ node to move the head in default position

− led yellow on to ‘dcart’ node to switch on yellow LEDs for HRI activities

− led yellow off to ‘dcart’ node to switch off yellow LEDs




− take goods completed to PEIS CMP to inform about take goods activities

has completed





Subscribed Topics


− take goods from PEIS CMP to start the take goods procedure

− walk from PEIS CMP to start the walk service

gui/messages (std_msgs/String)

String messages to be published on the GUI

Services Client

None

Parameters

None

Command-Line Tools

rosrun dcart_gui gui

Source code

src/main.cpp

src/main_window.cpp

src/qnode.cpp





Table 2. GUI and ROS topic relations: take goods activity

Messages from dcart/command

topic GUI shown User Action

Messages to dcart/command

topic

Messages to dcart/status

topic

take goods

User Press ‘language’ icon

head side led yellow on

User press the ‘open’ button

bin open

User press the ‘close’ button

bin close

User press the ‘yes’ button

head front

led yellow on

take goods completed





Table 3. GUI and ROS topic relations: walk activity

Messages from dcart/command

topic GUI shown User Action

Messages to dcart/command

topic

Messages to dcart/status

topic

walk

User press the ‘open’ button

bin open

User press the ‘close’ button

bin close





3 Package pe is_ros

3 . 1 N o d e p e i s _ r o s

The peis_ros node is a bridge between the DustCart ROS nodes and the PEIS ecology. The

node listens to PEIS tuples for DustCart and translates these tuples into commands for the

DustCart ROS nodes. Vice versa the node listens to status messages and commands for the

PEIS components (i.e. PEIS configuration planner module, condominium robot, etc.) and

translates these messages into PEIS tuples. The node subscribes the dcart/command

topic to get commands for condominium robot and the dcart/status topic to get status of

the execution of the commands and services.

Figure 15. The peis_ros node topics.

Node name

peis_ros

Published Topics


− take goods to ‘gui’ node to start the take goods interaction

− goods exchange IN to ‘goods_exchange’ node to start a goods exchange

procedure from ‘condo’ to ‘dcart’

− goods exchange OUT to ‘goods_exchange’ node to start a goods exchange

procedure from ‘dcart to ‘condo

− start roller IN to ‘goods_exchange’ node to start a roller IN procedure

− start roller OUT to ‘goods_exchange’ node to start a roller IN procedure

− garbage collection DISCHARGE to ‘goods_exchange’ node to start a discharge

− garbage collection CHARGE to ‘gui’ node to start a take garbage

interaction



− moveto X Y θ to ‘move_base’ node to move the base in X Y θ (m/rad)





Subscribed Topics


− coro1 dock X Y θ from ‘goods exchange’ node to ‘condo’ robot to start

docking and to inform about current docking position

− coro1 undock from ‘goods exchange’ node to ‘condo’ robot to start

undocking procedure

− coro1 startroller out from ‘goods exchange’ node to ‘condo’ robot to start

rollers


− bin is open from ‘dcart’ node to ‘condo’ robot to start


− bin is closed from ‘goods exchange’ node to ‘condo’ robot to start


− moveto completed from ‘moveto’ node to PEIS CPM to inform about

conclusion of the moveto command

− moveto failed from ‘moveto’ node to PEIS CPM to inform about

conclusion of the moveto command with failure

− take goods completed from ‘gui’ node to PEIS CPM to inform about conclusion

of the take goods procedure

− take goods failed from ‘gui’ node to PEIS CPM to inform about conclusion

of the take goods procedure with failure

− goods exchange completed from ‘goods_exchange’ node to PEIS CPM to

inform about conclusion of the take goods procedure

− goods exchange failed from ‘goods_exchange’ node for PEIS CPM to inform about

conclusion of the take goods procedure with failure

− start roller completed from ‘goods_exchange’ node for PEIS CPM to inform about

conclusion of the start roller procedure

− start roller failed from ‘goods_exchange’ node for PEIS CPM to inform about

conclusion of the start roller procedure with failure

− garbage collection completed from ‘goods_exchange’ node to PEIS CPM to

inform about conclusion of the take goods procedure

− garbage collection failed from ‘goods_exchange’ node to PEIS CPM to

inform about conclusion of the take goods procedure with

failure

Services Client

None

Parameters

None





Command-Line Tools

rosrun peis_ros peis_ros --peis-id [peis_id]

[peis_id]: PEIS id of the robot (DustCart1 is 302). Example:

rosrun peis_ros peis_ros --peis-id 302

Source code

src/tuplehandlerdustcart.cpp

src/peisros.cpp

src/peis.cpp

src/main.cpp

Table 4. Correspondence between PEIS tuples and ROS commands

Subscribed Tuples

Tuples Structure ROS topic ROS message

openbin dustcart1.openbin.ID.state= IDLE dustcart1.openbin.ID.parameters = dustcart1.openbin.ID.command = ON

dcart/command bin open

closebin dustcart1.closebin.ID.state= IDLE dustcart1.closebin.ID.parameters = dustcart1.closebin.ID.command = ON

dcart/command bin close

moveto dustcart1.moveto.ID.state= IDLE dustcart1.moveto.ID.parameters = X Y θ dustcart1.moveto.ID.command = ON

dcart/command moveto X Y θ

takegoods dustcart1.takegoods.ID.state= IDLE dustcart1.takegoods.ID.parameters = dustcart1.takegoods.ID.command = ON

dcart/command take goods

goodsexchange

dustcart1.goodsexchange.ID.state= IDLE dustcart1.goodsexchange.ID.parameters = {IN,OUT} dustcart1.goodsexchange.ID.command = ON

dcart/command goods_exchange {IN,OUT}

startroller dustcart1.startroller.ID.state= IDLE dustcart1.startroller.ID.parameters = {IN,OUT} dustcart1.startroller.ID.command = ON

dcart/command start roller {IN,OUT}

garbagecollection

dustcart1.garbagecollection.ID.state= IDLE dustcart1.garbagecollection.ID.parameters = {CHARGE,DISCHARGE} dustcart1.garbagecollection.ID.command = ON

dcart/command garbage collection {CHARGE,DISCHARGE}

Table 5. Correspondence between ROS messages and PEIS tuples

ROS topic ROS message Published Tuples

dcart/command coro1 dock X Y θ coro1.docking.ID.state= IDLE coro1.docking.ID.parameters = DOCK_ON DUSTCART_USE_POSE X Y θ coro1.docking.ID.command = ON

dcart/command coro1 undock coro1.docking.ID.state= IDLE coro1.docking.ID.parameters = DOCK_OFF coro1.docking.ID.command = ON

dcart/command coro1 startroller out coro1.startroller.ID.state= IDLE coro1.startroller.ID.parameters = OUT coro1.startroller.ID.command = ON

dcart/status bin is open dustcart1.openbin.ID.state= COMPLETED

dcart/status bin is closed dustcart1.closebin.ID.state= COMPLETED





dcart/status moveto completed dustcart1.moveto.ID.state= COMPLETED

dcart/status moveto failed dustcart1.moveto.ID.state= FAILED

dcart/status take goods completed dustcart1.takegoods.ID.state= COMPLETED

dcart/status take goods failed dustcart1.takegoods.ID.state= FAILED

dcart/status goods exchange completed

dustcart1.goodsexchange.ID.state= COMPLETED

dcart/status goods exchange failed dustcart1.goodsexchange.ID.state= FAILED

dcart/status start roller completed dustcart1.startroller.ID.state= COMPLETED

dcart/status start roller failed dustcart1.startroller.ID.state= FAILED

dcart/status garbage collection

completed dustcart1.garbagecollection.ID.state= COMPLETED

dcart/status garbage collection failed

dustcart1.garbagecollection.ID.state= FAILED





4 Package novatel_driver

4 . 1 N o d e n o v a t e l _ d r i v e r

The novatel_driver node is the interface with the Novatel GPS system. The node open a

serial connection to communicate with the main unit of the GPS system, configure the GPS,

gets GPS main antenna positions and antennas heading, transform GPS position to UTM

coordinates, and publishes GPS orientation and position to ROS topics.

The node publishes to the novatel/position_solution topic the GPS status and position in

UTM coordinates and publishes to the novatel/heading_solution the GPS align status and

heading. GPS heading is computed wrt to the east axis and positive angles are clockwise.

Status of GPS position and GPS heading are NARROW_INT when the GPS solution is fixed.

Figure 16. The Novatel GPS reference system.

Figure 17. The gps node topics.

Node name

novatel_driver

Published Topics

novatel/position_solution (novatel_msgs/Position)

GPS position status and GPS antenna UTM coordinates.

novatel/heading_solution (novatel_msgs/Heading)

GPS align status and antennas heading.





Subscribed Topics

None

Services

None

Parameters

None

Command-Line Tools

rosrun novatel_driver novatel_driver [serial_port_name]

[serial_port_name]: the serial port the GPS is connected to. Example:

rosrun novatel_driver novatel_driver /dev/ttyS1

Source code

src/Novatel.cpp

src/NovatelNode.cpp

src/SerialPort.cpp

dcart.launch -- Printed on 12/02/2014, 12.19.38 -- Page 1

1 <launch>2 3 <node name="log" pkg="dcart" type="log" respawn="false" />4 5 <node name="can" pkg="dcart" type="can" respawn="false" />6 7 <node name="net" pkg="dcart" type="net" respawn="false" />8 9 <node name="dcart" pkg="dcart" type="dcart" output="screen" respawn="false" />

10 11 <node name="joy_node" pkg="joy" type="joy_node" output="screen" respawn="false">12 <param name="joy_node/dev" type="string" value="/dev/input/js0" />13 </node>14 15 <node name="walk" pkg="dcart" type="walk" respawn="false" output="screen"/>16 17 <node name="tf" pkg="dcart" type="dcart_tf" respawn="false" />18 19 <node name="odom" pkg="dcart" type="odom" respawn="false" />20 21 <node name="laser" pkg="hokuyo_node" type="hokuyo_node" output="screen" respawn="false">22 <param name="frame_id" type="string" value="/laser" />23 <param name="max_ang" type="double" value="1.57" />24 <param name="min_ang" type="double" value="-1.57" />25 <param name="max_range" type="double" value="10" />26 <param name="min_range" type="double" value="0.15" />27 <param name="intensity" type="bool" value="true"/>28 <param name="allow_unsafe_settings" type="bool" value="true"/>29 </node>30 31 <node name="beacon_odom" pkg="dcart" type="beacon_odom" output="screen" respawn="false">32 <param name="intensity" type="double" value="10000" />33 <param name="distance" type="double" value="2.75" />34 </node>35 36 <node name="move_base" pkg="dcart" type="move_base" output="screen" respawn="false" >37 <rosparam file="$(find dcart)/move_base_params.yaml" command="load" />38 </node>39 40 <node name="goods_exchange" pkg="dcart" type="goods_exchange" output="screen"

respawn="false" >41 <param name="x_dock" type="double" value="-0.17" />42 <param name="y_dock" type="double" value="0.17" />43 <param name="h_dock" type="double" value="-3.091670" />44 </node>45 46 <node name="map_node" pkg="map_server" type="map_server" args="$(find

dcart)/incubator_map.yaml" respawn="false" output="screen"/>47 48 <node name="novatel_driver" pkg="novatel_driver" type="novatel_driver" args="/dev/ttyS1" />49 50 <node name="gps" pkg="dcart" type="gps" output="screen" respawn="false" >51 <param name="x_init" type="double" value="638280.10" />52 <param name="y_init" type="double" value="4823902.50" />53 <param name="h_init" type="double" value="0.0" />54 </node>55 56 <node name="peis_ros" pkg="peis_ros" type="peis_ros" args="--peis-id 302" output="screen" />57 58 <node name="gui" pkg="dcart_gui" type="gui" output="screen" respawn="false" />59 60 </launch>61 62

C:\Users\Giancarlo\Documents\RoboTech\Progetti\Robot-Era\Backup\dustcart\ros_workspace_20140127\dcart\dcart.launch -- File date: 18/12/2013 -- File time: 16.00.00