RobotML Modeling Platform ************************* .. toctree:: :maxdepth: 1 About Papyrus ============= :term:`Papyrus` is aiming at providing an integrated and user-consumable environment for editing any kind of :term:`EMF` :term:`model` and particularly supporting :term:`UML` and related modeling languages such as :term:`SysML` and :term:`MARTE`. Papyrus provides diagram editors for EMF-based modeling languages amongst them :term:`UML` 2 and :term:`SysML` and the glue required for integrating these editors (GMF-based or not) with other :term:`MBD` and MDSD tools. :term:`Papyrus` provides a very advanced support for :term:`UML` profiles enabling support for "pure" :term:`DSL`. Every part of :term:`Papyrus` may be customized: model explorer, diagram editors, property editors, etc. .. seealso:: `Papyrus website `_ Papyrus tutorials ================= Go to `Papyrus tutorials page `_. DSL detailed ============ One of the objectives of the :term:`PROTEUS` project is to provide domain specific languages (and related tools like editors, consistency checkers, etc) suitable to specify missions, environments and robot behaviours that have been specified by robotics experts involved in the project. The discussions within the :term:`PROTEUS` project have led to the decision of defining three :term:`DSL` s. 1 The :ref:`Architecture DSL` which will ease the definition of specific robotic architectures (reactive, deliberative, hybrid) and specific components that form those architectures (sensors, actuators, planners). 2 The "Control & Communication DSL" that will control the robotic components and will ease the definition of communication mechanisms between components (sending/receiving of events and data). 3 The "Algorithms DSL" that will ease the definition of algorithms which are to be used, triggered with the “Control & Communication DSL” for implementing behaviours in the different components of an architecture described with the :ref:`Architecture DSL`. Domain model ============ The domain model of a given domain specific language defines the concepts and the terminology of the language domain. The relationships between the concepts are described as well. In this section, we present the domain model of the :term:`RobotML` :term:`DSL` s based on the requirements defined in the previous section and on the knowledge base provided by the ontology. We have used :term:`UML` class diagrams to represent the domain model. Figure 1 show a generic view of the RobotML domain model which describe the architecture of the robotic system (ie. its internal structure), the behavior of components (through FSMs or algorithms) , the communications between them and the deployment of robotic systems to specific robotic platforms. .. _architecture_dsl: Architecture DSL ---------------- This section introduces a high-level “executive” summary of the subject matter of the relevant sub- package. It contains an informal and lightweight description that identifies the subject matter itself (key concepts and relationships), the general principles of operation (semantics), design rationale, relationship to other packages and their subject matter, etc. The idea is that, for a cursory reader, this should provide sufficient information of the subject without delving into technical details. .. image:: images/general_architecture_dsl.png :align: center :alt: Proteus architecture domain model package The Proteus architecture domain model package contains six sub-packages: - The :ref:`robotic system package`: describes the concepts that help defining and composing a robotic system, - The system environment package: since we not only model the robotic system but also its environment (for example for simulation purpose), this package defines the concepts composing the “real” environment where robots evolve, - The data types package: defines the data items that will necessarily be exchanged between robotic components, between algorithms, etc, - The robotic mission package: describes the concepts that are needed to define an operational mission and which are used by the components of an architecture performing it, The deployment package: specifies a set of constructs that can be used to define the execution architecture of robotic systems, - The platform package: defines the concept of platform which represents a software, - Execution environment that can be either a robotic simulator or a robotic middleware. Domain model detailed ~~~~~~~~~~~~~~~~~~~~~ .. _robotic_system_package: Robotic System Package '''''''''''''''''''''' A robotic **System** is composed of **Systems** that communicate with other **Systems** through **Ports** and have specific **Evolution Models** (i.e. behaviours). **Systems** could be **Software** or **Hardware**. **Software** systems are detailed in the **RoboticSoftware** package (Figure 6), **Hardware Systems** are detailed in the RobThe environment is the highest possible "container" for the physical objects to exist, and it is considered as part of the architecture of a robotic system. Figure 8 shows the robotic environment package which enables the specification of different types of environments. oticHardware package (Figure 7). .. image:: images/robotic_system_package.png :align: center :alt: Robotic sytem packages The System concept corresponds to the component concept. The term system is more appropriate to describe a robotic component, this is due to the fact that the term system is more meaningful for a robotician than the term component. A System is composed of properties, ports and connectors. .. image:: images/robotic_system_package_properties.png :align: center :alt: Robotic system package: details of properties Figure 4 shows the details of the concept of **property**. A system is composed of **properties** which can be a subsystem or a variable. The **Part** property is typed by a **system** and thus corresponds to a subsystem. The **BasicProperty** is typed by a **data type** and thus corresponds to a variable. .. image:: images/robotic_system_package_ports.png :align: center :alt: Robotic system package: details of ports Figure 5 Shows the details of the concept of **port**. A **port** formalizes an interaction point of a **system**. It is a special kind of **properties** that has a type and a **communication policy**. A **ServicePort** is a **port** that is specific to client/server communications. **DataFlowPorts** enable data flow-oriented communication between systems, where messages that flow across ports represent data items. **ServicePorts** support a request/reply communication paradigm (also called client/server model of communication), where messages that flow across ports represent **operation** calls. **ServicePorts** are typed by an interface which specifies a number of operations without stating how exactly they are implemented. Detail of the robotic software package: Figure 6 shows the details of the robotic software package. A software could be a driver which is the software system part of a DeviceSystem. .. image:: images/robotic_software_package.png :align: center :alt: Details of the robotic software package Details of the robotic hardware package: Figure 7 shows the details of the **robotic hardware** package. A **hardware** could be: • a **physic device**: represents the hardware part of a device system, • a **storage hardware**: represents different forms of memory, • a **computing hardware**: represents physical processing devices capable of storing and executing program code, • a **timing hardware**: represents a hardware entity that is capable of following and evidencing the pace of time. .. image:: images/robotic_hardware_package.png :align: center :alt: Details of the robotic hardware component package .. _robotic_environment_package: Robotic environment package ''''''''''''''''''''''''''' The **environment** is the highest possible "container" for the **physical** objects to exist, and it is considered as part of the architecture of a robotic system. See `RobotML API documentation `_. Installation ============ You need to download the `Eclipse Modelling tools `_. Then extract the modeller on your computer and launch it. You need to install :term:`Papyrus`, with :term:`RobotML` extra feature, :term:`Acceleo`, and :term:`Subclipse`. - To install :term:`Acceleo`, clic on **Help/install Modellign component**, and selection :term:`Acceleo`. - To install :term:`Papyrus` and :term:`Subclipse`, clic on **Help/Install new software...**, and add the following update site Juno version ============ ======================= ======================================================================== Plugin name update site ======================= ======================================================================== :term:`Papyrus` http://download.eclipse.org/modeling/mdt/papyrus/updates/releases/juno :term:`Subclipse` http://subclipse.tigris.org/update_1.10.x ======================= ======================================================================== .. note:: The juno version not support the dynamic validation. Kepler version ============== =========================== ========================================================================= Plugin name update site =========================== ========================================================================= :term:`Papyrus` (nigthly) http://download.eclipse.org/modeling/mdt/papyrus/updates/nightly/kepler :term:`Subclipse` http://subclipse.tigris.org/update_1.10.x =========================== ========================================================================= ----------- :ref:`Up`