Engineering the software of robotic systems - 1 - Introduction [ICSE 2017 - technical briefing]

UNIVERSITY OF L’AQUILA
Federico Ciccozzi1, Davide Di Ruscio2, Ivano Malavolta3,
Patrizio Pelliccione4, Jana Tumova5
1Malardalen University (Sweden)
2University of L’Aquila (Italy)
3Vrije Universiteit Amsterdam (The Netherlands)
4Chalmers University of Technology | GU (Sweden)
5KTH Royal Institute of Technology (Sweden)
Engineering the software
of robotic systems

Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova
Robots increasingly used in the near future
• Facilitating tasks of everyday life
• Social or an industrial facility of the
future (e.g., a hotel, an office, a
hospital, or a warehouse)
• Teams of robots provide services
and accomplish everyday tasks
such as object
handling/transportation, or pickup
and delivery operations
https://www.amazonrobotics.com

Robots increasingly used in the near future
• Automating potentially dangerous tasks
• Substituting/assisting humans with robots is
safe, fast, and cost efficient
• Often the operator will not have the line-of-sight
to the robot
• Impractical and/or impossible to manually
control robots
• Other forms of navigational aids are required
Nuclear incident at Fukushima in Japan
after the 2011 earthquake and tsunami

Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 4

Robotic systems
“Software intensive systems composed of distributed,
heterogeneous software components interacting in a highly
dynamic, uncertain environment”
Arunkumar Ramaswamy, Bruno Monsuez, Adriana Tapus: Model-driven software development approaches in robotics research. In Procs of MiSE
at ICSE 2014: 43-48

Robotic systems
They must work to achieve tasks while monitoring for, and
reacting to, unexpected situations
• Several sensors and actuators to be controlled in real time
• Signiﬁcant uncertainty and noise to be managed
• Concurrently and asynchronously
David Kortenkamp, Reid G. Simmons, Davide Brugali: Robotic Systems Architectures and Programming. Springer Handbook of Robotics, 2nd Ed.
2016: 283-306

Robotic systems
• In the last decade, a large number of middleware and
code libraries developed by diﬀerent research
laboratories and universities have been produced
at ICSE 2014: 43-48

State of the art / state of practice - ROS
• ROS (Robot Operating System)
• A very popular robot middleware package
• Peer-to-peer architecture among nodes over a
network
• Robot functionality split over multiple nodes
(processes)
• Nodes subscribe to and publish messages on
“topics”
• ROS Master runs topic registry
• Topics are named channels over which
messages are exchanged

http://robohub.org/ros-101-intro-to-the-robot-operating-system/

State of the art / state of practice
Usually there are no system development processes (highlighted
by a lack of overall architectural models and methods). This
results in the need for craftsmanship in building robotic systems
instead of following established engineering processes.
H2020 Robotics Multi-Annual Roadmap ICT-2016.
http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf

Need of Turn-key solutions
• A robot pre-equipped and/or configured with the
right sensors for the specific mission
• Specification of the mission in a easy and user-
friendly way
• Robots should be smart, i.e. able to take decisions
on their own so to manage unpredictable situations
• Completely autonomous robots
• When the operator is unable to issue commands (due
to insufficient radio conditions etc.)
• Robots should be able to collaborate with humans

Need of system engineering approaches
• Systematic processes, methods, models, and tools are
needed to create robotic systems for real-world applications
• “make or break” factor in the development of complex robot
systems
• Specification of the overall system architecture
• Re-usable robot building blocks for system integration in the
form of well defined modules with clear semantics and clearly
explained and well-defined properties
• Such a system of modular integration will stimulate component
supply chains and significantly alter the robotics market
place

• Easy to use robots - Enable stakeholder without
expertise in ICT or robotic to “program” or teach
robots and to interact/use them
• Easy to (re-)configure robots – (re-)configure
according to the specific domain and mission needs,
operating environment and external factors (design-
and/or run-time)
• Dealing with uncertainty – ability to adapt to
unknown, unpredictable, and dynamic operating
environment and self-learn
Turn-key solutions: challenges

Key techniques/methods
Model-driven software development (MDSD) and DSL (domain
specific languages) are core technologies required in order to
achieve a separation of roles in the robotics domain while also
improving compose-ability, system integration and also
addressing non-functional properties.

What is a Model?

Model
A simplification of a system built with an
intended goal in mind. The model should be
able to answer questions in place of the actual
system
[Bézivin et al. 2001]
• A model has an intent, a purpose related to
a specific consumer
• It is always an abstraction of the reality
• It describes a subject that exists or that is
intended to exist in the future

Models
Model Intent Subject
Consumer
The thing that
the model is
about
Model created with
the intent that sa9sﬁes
a par9cular purpose
Uses the model to
sa9sfy/achieve
her/his goals

Model-Driven Engineering
=
Abstraction + Automation + Analysis

The promise of MDE
• Improve the time and effort required to program
and design a robotic system to tackle a new task
in a new domain
• efficient reuse of components
• most engineering tasks like robot program
generation will be performed automatically
• The robot designer can concentrate on the
creative tasks

Use of models in the robotic domain
at ICSE 2014: 43-48

Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 23Davide Brugali, Luca Gherardi: HyperFlex: A Model Driven Toolchain for Designing and Configuring Software Control Systems for Autonomous
Robots. In Robot Operating System (ROS): The Complete Reference (Volume 1), pp.509-534 (2016)
• Approach to select and integrate a
coherent set of components providing
required functionalities
• Management of mutual component
dependencies and architectural
mismatches
• Variability-free architectural models are
transformed into configuration files
• deployment of the functional systems
(e.g. the ROS launch files)

Use of models in the robotic domain

Step 1: models are used by persons
Code
generation
• Advantages
• Hide complexity
• Engineers can focus on
more creative activities
• Reusability
• Modularity
• Automating repetitive tasks
• Improve quality

Step 2: Robots use models at run-time
Controller(
Normal
behaviour
Abnormal
behaviour
Yes No
Check
Incoming message
Sending message,
action
(to be checked)
Sending message
(checked)
?m1
?m2
a1
a2
a3
a5
!m3
a4
Local
exceptions
Error
recovery
Failure
exception
Update
• Advantages
• Exploit models to
understand the reality
• Monitor that the execution
of the mission is “correct”
• Understand the
environment
• Understand how to self-
adapt

Step 3: Robots adapt models and improve them
Controller(
Normal
behaviour
Abnormal
behaviour
Yes No
Check
Incoming message
Sending message,
action
(to be checked)
Sending message
(checked)
?m1
?m2
a1
a2
a3
a5
!m3
a4
Local
exceptions
Error
recovery
Failure
exception
Update

ROS – Pros
• Offers standardized interfaces providing
hardware abstraction
• Commonly used in academia and some
industries
• Portability
• Loose coupling
• Nodes substitution
• Scalability till a certain limit

ROS – Cons 1/2
• No support for multiple platforms
• Not fully supported in Windows, OSX
• Scalability
• Overhead of the messaging system
• Performance with a large number of nodes
• Difficult to figure out the communication of the overall system
• Error prone for large and complex systems
• Monitoring
• Limited failure detection and restart
• No detection of network disconnections or runtime
errors
• One failing node can poison the entire system

ROS – Cons 1/2
• Inflexible semantic coupling
• Communication based on an agreed and established set of
topics
• Message delivery issues
• What’s happen is the supposed listener is not (yet) listening?
• Not supporting real-time requirements
• Unsupported management of devices configuration
• Confusing ecosystem
• Difficult to understand the released libraries
• Security/unauthorized listener
• Learning curve/documentation

ROS 2
• Support for
• Real-time requirements
• Multi-robots
• Small embedded platforms
• No ideal network
• …
• Release plan
• Beta 2 – June 14th, 2017
• Beta 3 – September 13th, 2017
• Version 1.0 – December 13th, 2017
Further info: https://github.com/ros2/ros2/wiki

Main barriers: integration and interoperability
• Integration
• Formalisms and algorithms over different modules
(perception, planning, learning, envisioning etc.) are
typically incompatible
• The top performing state-of-the-art modules are often
the hardest to integrate, because they use
sophisticated and incompatible representations and
algorithms that must first be adapted to the needs of
robot control
• Interoperability of robotic components
• Lack of interoperability standards
• Lack of well-defined interfaces with clear semantics

Easy to use robots
• Intuitive Human Robot Interfaces for use
and configuration, teach or specify task
using domain specific terminology
• Interactions and collaborations with
operators and other robots should be
safe, intuitive and appropriate

Easy to (re-)configure robots
• Software configuration may take place at design-time or at run-
time as a result of the end user selection of operating parameters
• Run-time Self-Configuration
• The system can alter its own configuration within a pre-determined
set of alternative configurations designed into the system
• Autonomous Configuration
• The system can alter its own configuration in response to external
factors, for example altering its morphology in response to the
failure of a sensor or actuator

Dealing with uncertainty
• The robot should be able to respond to changes in potentially
unstructured and dynamic operating environments
• Adjustment as a result of perception and the decisional
mechanisms
• Adaptation as a result of self-learning from its experience
• Cooperative missions - teams of both heterogeneous and
homogeneous robots (and potentially in collaboration with
humans) that collaborate and cooperate to accomplish complex
missions

Descriptive vs
Prescriptive models
• The purpose is related to the consumer of the model
and to her/his/its characteristics.
• A consumer might be a human but it can also be a
software system.
• It is then clear that consumer and intent are two
aspects that strongly influence the abstraction level
of the model as well as the concrete syntax used to
describe and present the model, e.g. graphical,
textual, and/or tree-like.
• The importance of a model might vary during its
lifetime.
• By observing a model from the consumer point of
view, it is hard to understand if the model is
prescriptive or descriptive.
Model IntentSubject
Consumer
The thing that
the model is
about
Model created with the intent
that satisfies a particular
purpose
Uses the model to satisfy/
achieve his goals
Descrip(ve
Model
is described by
Subject
Prescrip(ve
Model
prescribes
Subject
Rogardt Heldal, Patrizio Pelliccione, Ulf Eliasson, Jonn Lantz, Jesper Derehag, Jon Whittle (2016) Descriptive vs Prescriptive Models in Industry In:
Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems (MODELS 2016).

Engineering the software of robotic systems - 1 - Introduction [ICSE 2017 - technical briefing]

More Related Content

Similar to Engineering the software of robotic systems - 1 - Introduction [ICSE 2017 - technical briefing]

More from Ivano Malavolta

Recently uploaded

Engineering the software of robotic systems - 1 - Introduction [ICSE 2017 - technical briefing]