3 SOFTWARE
The underlying structure of MOnarCH is a network
of software components. It can be assumed that each
of them was developed independently and that the
communication among them is based on some pre-
defined protocol. The dynamics of each of the soft-
ware components is of major importance to the over-
all stability and performance. A component that does
not clearly broadcast its state can prevent other com-
ponents to run properly. Also, the handling of ex-
ception conditions must be carefully defined, e.g.,
transitions between states must occur cleanly. In a
sense this amount to “controllability”and “observabil-
ity” concerns on the overall system (the relevance
of which has been recognized by some authors, e.g.,
(Naganathan and Eugene, 2009)).
The visible part of the system is composed by the
outer shell of the robot (Figure 1), the corresponding
Human-Robot Interaction (HRI) interfaces, and sen-
sors. The HRI interfaces must be used much in a hu-
man way, meaning that visual effects must be well
coordinated with sound effects so that the observers
get the correct perception and the interaction is effi-
cient. The MOnarCH robot has two 1-dof arms and
a 1-dof neck, variable luminosity eyes and cheeks, a
LED matrix for a mouth, loudspeakers, microphone,
bumpers, touch sensors placed in strategic places of
the body shell, and a RFID tag reader. The adequate
coordination of HRI interfaces can be framed as a sta-
bility problem.
In MOnarCH, a key architectural feature that ac-
counts for this concern is called Situational Aware-
ness Module (SAM). In a sense this is a routing in-
formation matrix that defines what are the informa-
tion exchanges, and, if necessary, applies basic trans-
formations to that information (see (Messias et al.,
2014)).
Moreover, performance and stability concerns
have also been addressed through the inclusion of
watchdog mechanisms (see (MOnarCH Project Con-
sortium, 2016)).
The ROS middleware (www.ros.org) supports the
integration of all components. Key features of the de-
velopment are (i) local networking capabilities with
distributed node representation, (ii) global variables
accessible from any node in the system (the topics
in the ROS middleware), (iii) global networking is
useful for monitoring, (iv) fully independent control
of each component, (v) callback mechanisms to deal
with asynchronous events (actionlib), and (vi) state
machine frameworks (smach) for fast behavior devel-
opment, among others. Structures like the SAM mod-
ule can be easily implemented in the ROS middleware
using the built-in facilities. In a sense, a SAM is a col-
lection of direct mappings between ROS topics.
4 MOTION
Motion is the most basic tool for a robot to interact
with humans. In the particular case of inpatient chil-
dren (in the Pediatrics age range velocity and accel-
eration must be carefully selected. Relatively small
accelerations can be perceived by children as menac-
ing. Similarly, fast decelerations can be perceived as
if the robot is untrusty.
Obstacle avoidance is tightly connected to mo-
tion. Real environments can be really challenging,
e.g., children can move in unpredictable ways (see
Figure 2), and collisions are to be expected. When-
ever a robot collides it is a good practice that it clearly
shows that it knows a collision just occurred. A prac-
tical way is to issue a non-verbal sound that can easily
be associated to a collision, e.g., ouch.
The space in the Pediatrics ward is reasonably
structured (see the pictures presented in the paper).
Using an a priori map built with the gmapping ROS
package, (http://wiki.ros.org/gmapping, 2016), is ob-
tained by teleoperating the robot such that all the ward
is covered it is possible to localize the robot only with
the information from the laser scans. The naviga-
tion system in MOnarCH is based on a potential field
approach combining a fast marching method to con-
struct an optimal path to the goal and the repulsive
fields from obstacles, (Ventura and Ahmad, 2014).
Localization is based on the AMCL package, avail-
able in ROS, (http://wiki.ros.org/amcl, 2016), and
uses information from two laser range finders that
scan the full space around the robot. The accuracy of
the pose estimate is in the order of a few cm and de-
grees and the system has been show to have a remark-
able robustness. Observations so far indicate that, on
average, the robot loses its localization less than once
a day. When this happens the unusual behavior of the
robot is enough for an external observer to recognize
it and either alert the project team or push the robot to
a specific location where it can auto-localize easily.
In addition to the motion of the body of the robot,
the 1-dof neck can rotate right/left and it conveys
quite effectively the idea that the robot has a clear fo-
cus of attention. If the head turns because a person
is detected on that side a child tends to conclude that
the robot knows where the person is. If the head turns
to the opposite side where a person is then a plausi-
ble perception is that the robot does not care about the
person and has some other focus of attention. In both
cases the observations suggest that the motion of the
Lessons from the MOnarCH Project
243