Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,109 views

Published on

Slides of the technical briefing we held at the ICSE 2017 conference.

The accompanying paper is available here: http://www.ivanomalavolta.com/files/papers/ICSE_2017_TB.pdf
Involved researchers: Federico Ciccozzi (1), Davide Di Ruscio (2), Ivano Malavolta (3), Patrizio Pelliccione (4), Jana Tumova (5)

1) Mälardalen University (Sweden)
2) University of L’Aquila (Italy)
3) Vrije Universiteit Amsterdam (The Netherlands)
4) Chalmers University of Technology | GU (Sweden)
5) KTH Royal Institute of Technology (Sweden)

Published in: Software
  • Be the first to comment

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

  1. 1. 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
  2. 2. UNIVERSITY OF L’AQUILA 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
  3. 3. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  4. 4. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 4
  5. 5. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  6. 6. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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 • Significant 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
  7. 7. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova Robotic systems • In the last decade, a large number of middleware and code libraries developed by different research laboratories and universities have been produced Arunkumar Ramaswamy, Bruno Monsuez, Adriana Tapus: Model-driven software development approaches in robotics research. In Procs of MiSE at ICSE 2014: 43-48
  8. 8. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  9. 9. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 9 http://robohub.org/ros-101-intro-to-the-robot-operating-system/
  10. 10. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 10 http://robohub.org/ros-101-intro-to-the-robot-operating-system/
  11. 11. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  12. 12. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  13. 13. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  14. 14. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova • 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
  15. 15. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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. H2020 Robotics Multi-Annual Roadmap ICT-2016. http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf
  16. 16. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova What is a Model?
  17. 17. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  18. 18. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova Models Model Intent Subject Consumer The thing that the model is about Model created with the intent that sa9sfies a par9cular purpose Uses the model to sa9sfy/achieve her/his goals
  19. 19. Model-Driven Engineering = Abstraction + Automation + Analysis
  20. 20. Model-Driven Engineering = Abstraction + Automation + Analysis
  21. 21. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  22. 22. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova Use of models in the robotic domain Arunkumar Ramaswamy, Bruno Monsuez, Adriana Tapus: Model-driven software development approaches in robotics research. In Procs of MiSE at ICSE 2014: 43-48
  23. 23. UNIVERSITY OF L’AQUILA 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)
  24. 24. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova H2020 Robotics Multi-Annual Roadmap ICT-2016. http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf Use of models in the robotic domain
  25. 25. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  26. 26. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  27. 27. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  28. 28. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova H2020 Robotics Multi-Annual Roadmap ICT-2016. http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf Use of models in the robotic domain
  29. 29. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 29
  30. 30. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  31. 31. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  32. 32. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  33. 33. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  34. 34. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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 H2020 Robotics Multi-Annual Roadmap ICT-2016. http://sparc-robotics.eu/wp-content/uploads/2014/05/H2020-Robotics-Multi-Annual-Roadmap-ICT-2016.pdf
  35. 35. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  36. 36. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  37. 37. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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
  38. 38. UNIVERSITY OF L’AQUILA Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova 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).

×