![](bg2.png)
livery tasks at once. For example, if a robot is deliver-
ing a task A and a new task B within a close distance
has been requested, the robot can finish both task A
and B with not much effort for performing both tasks.
This kind of task allocation is called ’online’ multi-
task allocation (on-MTA) which a robot can receive
more tasks while moving and increases delivery per-
formance. Previous research about the online multi-
task allocation is done in (Jeon and Lee, 2016) and it
shows that the on-MTA increase the performance of
using fleet of robots than STA.
To achieve on-MTA, the robot should be con-
nected to the network at all times. However, when
operating robots in real-world, maintaining the net-
work connectivity of a moving robot at all times is a
challenge job. Even though access points (APs) of the
wireless network are densely installed hospital-wide,
the network is frequently disconnected due to han-
dover of APs of the moving robot. Also, the robot’s
IP addresses can be changed when connected to a new
AP. This unstable network environment can be a criti-
cal problem for fleet management since real-time po-
sitions and task statuses of robots affect overall opti-
mality of task allocation.
Many of the previous researches about control-
ling the multi-robot system assumes robots have
fixed IP addresses with online connectivity.(Ren
and Sorensen, 2008)(Harrisson Fischer, 2016) There
is an approach of designing the control archi-
tecture for the hospital delivery robots assigning
a task via network communication, but it over-
looks the importance of asynchrony and unreli-
able network condition.(Yasuhisa Hirata and Kosuge,
2015) There is a research about the control archi-
tecture of non-communicative environment, but it
has a supervisor which monitors the behavior of
robots.(Alessandro Marino, 2013) However, in our
approach, there is no such supervisor that monitors
the robot’s status.
This paper proposes a control architecture of the
multi-robot system that achieves online connectivity
of robots although online connection is not guaran-
teed. In this architecture, the server has a specific
module called the ’message board (MB)’ to commu-
nicate with the robot. With this architecture, robots
can report their positions and status to the server, and
the server receives the robot’s information through
MB. The server assigns a delivery task of a robot by
posting it on MB, and the robot receives the task mes-
sage from MB. With this module, IP address of the
robot is negligible since the communication is always
initiated from the robot’s side.
Another emerging issue when operating robots in
real-world is the case when robots use common re-
sources such as an elevator. Many of the conventional
hospital allows one or two elevators for the robot-
dedicated use. In this case, the resource controller
should organize the usage when there are multiple re-
quests from different robots. Similar concept is ap-
plied for a narrow corridor and an automatic door.
Two robots cannot cross-over in a narrow corridor,
and the automatic door should maintain opened un-
til a robot completely passes-by. This kind of com-
mon resource management should be performed by
the server in an unstable network environment. The
handshaking process of the message to use the re-
source is explained in section 4.3.
The proposing architecture can cope with the real
world problem which network connectivity is unsta-
ble and the deadlock situation of multiple request
from robots to use the common resource.
2 DELIVERY SERVICE
2.1 Network Environment
In this project, the multiple robots work in a spe-
cial environment that is wide and the network is fre-
quently disconnected. When a robot moves, the han-
dover of the access point (AP) occurs and the robot
loses connection from time to time. Also, the IP ad-
dress of the robot can be changed, in case of dynamic
assignment (DHCP) of AP. Thus, the online connec-
tion between a robot and the server cannot always be
guaranteed.
On the other hand, since the server uses a fixed
IP address, a robot can access to the server’s IP ad-
dress at any time when connected. Therefore, in this
delivery service architecture, the communication is
always initiated from the robot’s side. The connec-
tion is not always online, but, at least, we know that
some time the robot will be connected to the server
and receive messages. So, many of the decisions are
made by the robot itself, for example, planning the
path between delivery positions, avoiding obstacles,
controlling movements, and deciding the human in-
teraction behavior at each states. Network connection
is mandatory only when receiving the new task and re-
questing for usage of common resources. In general,
the robot reports its status to the server when possible.
To enable such communication method, the ’mes-
sage board’ concept is introduced in the server.
Whenever a robot is connected to the network, the
robot sends the heartbeat message to the server’s fixed
IP address and the heartbeat includes information of
the robot about its position and status. The returning
message of the heartbeat is any message that is posted
Multi-robot Control Architecture for Hospital Delivery Service in Unstable Network Environment
271