Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Papyrus/customizations/robotics"

m
(33 intermediate revisions by 6 users not shown)
Line 1: Line 1:
−
The Papyrus for Robotics customizations supports the creations of models that are compliant with the [https://www.robmosys.eu RobMoSys] approach.
+
__NOTOC__
  
−
= Getting started =
+
= Documentation =
  
−
Papyrus for Robotics comes with installed examples to get you started. To run the example, just click ''New->Example'' and accept the default propositions in the wizard. The examples are called ''Robotic examples'' in the category ''Papyrus example''
+
== Introduction ==
  
−
<center>
+
* [[Papyrus/customizations/robotics/installation|Installation]] - Installation instructions
−
[[Image:Papyrus-customizations-robotics-diy-runexample.gif|width=1024px]]<br/>
+
* [[Papyrus/customizations/robotics/getstarted|Getting started]] - Introduction to the concept of ecosystem tiers and the approach for the composition of software components.
−
Run the simple example that comes along with Papyrus for Robotics
+
* [[Papyrus/customizations/robotics/modular|Modular and role based design]] - General Concepts (supported diagrams depending on the modeling viewpoint)
−
</center>
+
  
−
===== The Example Explained =====
+
== User Guidance ==
  
−
==== Introduction ====
+
* [[Papyrus/customizations/robotics/workflow|General Workflow]]
 +
* [[Papyrus/customizations/robotics/robmosys|RobMoSys compliance]]
 +
* [[Papyrus/customizations/robotics/servicedef|Service Definition]] - How to create a service definition
 +
* [[Papyrus/customizations/robotics/compdef|Component Definition]] - How to create a component definition
 +
* [[Papyrus/customizations/robotics/systemdes|System Design]] - How to design a system
 +
* [[Papyrus/customizations/robotics/bt|Task Modelling]] - Use or define new skill definitions to describe robotics tasks as behavior trees
  
−
This example shows how Papyrus4Robotics supports the [https://robmosys.eu/wiki/composition:service-based-composition:start service-based approach for the composition of software components].
+
* [[Papyrus/customizations/robotics/hara|Task-based HARA]] - Learn how to perform hazard analysis and risk assessment (HARA) of robotic behaviors.
 +
<!-- * [[Papyrus/customizations/robotics/fta|Fault tree analysis]] - tbd. -->
 +
* [[Papyrus/customizations/robotics/eitus|Fault Injection]] - Specification of fault injections
 +
* [[Papyrus/customizations/robotics/safecc|Contracts and Assertions]] - How to specify assertions and constraints
  
−
[https://robmosys.eu/wiki/general_principles:ecosystem:start Composition in an Ecosystem organized in tiers] is the approach adopted by RobMoSys to system integration. Next sections discuss how tier 2 and tier 3 participants use Papyrus4Robotics to model a simple service-based composition of a mapper component and a planner component.
+
* [[Papyrus/customizations/robotics/ros2|Code generation (for ROS 2)]]
 +
* [[Papyrus/customizations/robotics/reverse|Reverse Engineering (from ROS 2)]]
 +
* Simulation
  
−
The illustration below corresponds to the role descriptions, as taken from the RobMoSys wiki.
+
== Application Examples ==
  
−
[[Image:Papyrus-customizations-robotics-Service-based-composition-approach.png|width=900px]]<br/>
+
* [[Papyrus/customizations/robotics/demos/pick-and-place|Pick-and-Place use-case from RobMoSys project]] - The description of the pick and place task and its execution with the behavior tree in simulation using ISybot robot
−
Roles and interactions in a service-based composition of software components
+
* [[Papyrus/customizations/robotics/demos/drone|Drone use-case from C4D project]] - Simulated reactive drone navigation and landing using behavior trees
  
 +
== Developer Guidance ==
  
−
==== Domain Expert (Tier 2) ====
+
* [[Papyrus/customizations/robotics/release|Release Roadmap]]
 +
* Development Conventions, see Papyrus [[Papyrus/Code_Standards|coding standards]]
 +
* [[Papyrus/customizations/robotics/quality|Quality Assurance]]
 +
* [[Papyrus/customizations/robotics/devinstall|Installation of the Development Environment]]
 +
* [[Papyrus/customizations/robotics/build|Build process]]
  
−
Tier 2 are robotics experts who define a //complete// characterization of services in robotics domains, e.g., mapping, planning, localization, etc. Tier 2 structures each robotics domain by creating domain-models that cover a number of aspects, including data structures and communication semantics. [https://robmosys.eu/wiki/general_principles:ecosystem:roles:service_designer Service designers] are the domain experts on Tier 2 that design individual service definitions for use by Tier 3.
+
== Other Documentation ==
  
−
The picture below shows a portion of data structures defined for the mapping domain in this example.
+
* Publications
−
 
+
* [[Papyrus/customizations/robotics/faq|FAQ]]
−
[[Image:Papyrus-customizations-robotics-SimpleExampleDataTypes.png|width=800px]]<br/>
+
* Community -- RobMoSys wiki, [https://www.eclipse.org/forums/index.php/f/121/ Papyrus forum] (please prefix a subject with [Robotics] or [Robotics, ROS2])
−
Model of data types for the robotic mapping domain
+
* Bug reporting: use the Eclipse bugzilla to report it. In the following link, the product (Papyrus) and the the component (Robotics) are already selected [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Papyrus&component=Robotics File a Papyrus for Robotics bug]. Use the same naming convention as for the forum, i.e. prefix with [Robotics] or [Robotics, ROS2] and check out whether the bug is eventually already existing (the browser proposes possible existing bugs as you type your bug title]. Please make also sure that the steps to reproduce the bug are clearly described, eventually add your model.
−
 
+
−
Papyrus4Robotics leverages concepts from [https://robmosys.eu/wiki/https://www.omg.org/spec/MARTE/|OMG's MARTE]] NFP and VSL profiles to comply with RobMoSys' specifications on digital data representation. Built-in type definitions can be imported from the ''BasicNFP_Types'' MARTE library and specialized for a specific domain by using a dedicated palette (right side of the picture). Leveraging on MARTE, **Papyrus4Robotics supports physical units descriptions** to formally define unambiguous semantics of units of measurements in data types.
+
−
 
+
−
Once the communicated data structures (Communication Objects, identified with the ''CO'' icon on the top left corner) are defined, the communication pattern usage can be formalized. The next picture shows the model that describes the ''MappingSdef'' service. In this example, ''MappingSdef'' ''uses'' the ''Push'' pattern and selects the ''Map'' data type as communicated data structure.
+
−
 
+
−
[[Image:Papyrus-customizations-robotics-SimpleExampleServiceDef.png]]<br/>
+
−
Model of service definition for the robotic mapping domain}}
+
−
 
+
−
==== Component Suppliers (Tier 3) ====
+
−
 
+
−
Component suppliers at Tier 3 provide models of software component definitions.
+
−
 
+
−
=== AcmeMapper ===
+
−
 
+
−
The model below shows a mapper component developed by a company called AcmeCorp (hence ''AcmeMapper''), which provides a fully compliant implementation of the ''MappingSdef'' service definition above.
+
−
 
+
−
[[Image:Papyrus-customizations-robotics-SimpleExampleComponentDef.png]]<br/>
+
−
Model of mapper that is fully compliant to MappingSdef
+
−
 
+
−
The example focuses on the modeling of a single component port (''pMap'') providing the mapping service. Aligned with the standard UML rules of interface realization, this is achieved by assigning the port a ''ComponentService'' item as a type (''AcmeMapCS'') that ''realizes'' ''MappingSdef''.
+
−
 
+
−
''AcmeMapper'' contains one ''Parameter'' structure, that represents a set of parameters that make the component configurable for reuse in different scenarios by the system builder or even at run-time. The ''Parameter'' structure content is visualized in the model editor by selecting the ''Paramter'' icon and the ''Parameters Settings'' tab in the property view (see below). The selected parameter block has been moved in the screenshot below to keep image dimensions relatively small.
+
−
 
+
−
[[Image:Papyrus-customizations-robotics-SimpleExampleParameters.png]]<br/>
+
−
Visualization of parameter set of AcmeMapper
+
−
 
+
−
In this simple example, ''AcmeMapper'' has 2 configurable parameters with built-in types. However composite value specifications (collection, tuple, choice, etc.) can be specified as well, using the MARTE VSL syntax.
+
−
 
+
−
''AcmeMapper'' defines one activity (it could define more), which is a OS-agnostic representation of a thread. Activities provide wrappers for functions (algorithms). Activities do have set of parameters for configuration (e.g., interarrival range, that is max and min activation frequencies). Similarly to component parameters, activity paramters can be viewed and set through the ''Parameters Settings'' tab in the property view.
+
−
 
+
−
=== EmcaPlanner ===
+
−
 
+
−
The model has a planner component developed by a company called EmcaInc (hence ''EmcaPlanner''), not shown here.
+
−
 
+
−
The example focuses on the definition of two component ports. ''pPlan'' **provides** a implementation of ''PlanningSdef'' (a planning service definition model not discussed in this document). ''rMap'' **requires** a fully compliant implementation of ''MappingSdef''. To model the service requirement, in agreement with the standard UML rules, the ''usage'' item is used to create a dependency between the ''EmcaMapCS'' and ''MappingSdef''.
+
−
 
+
−
==== System Builder (Tier 3) ====
+
−
 
+
−
System builders instantiate component definitions to provide a platform-independent specification of a software system. The model below shows the instantiation and connection of one instance of ''AcmeMapper'' and one instance of ''EmcaPlanner''.
+
−
 
+
−
[[Image:Papyrus-customizations-robotics-SimpleExampleAssembly.png]]<br/>
+
−
Model of system component architecture
+
−
 
+
−
It is now assumed that the mapper component instance must work outdoor. The default configuration of ''AcmeMapper'' component definition was indoor, so the component instance ''m'' must be re-configured by the system builder.
+
−
 
+
−
For a component instance the parameter set is accessible by clicking on the instance itself and selecting the ''Parameters Settings'' tab in the property view. The next picture shows the value of ''indoor'' parameter is set to ''false''. Yellow highlighting visually enforces the message that the parameter value is now different from the default one.
+
−
 
+
−
[[Papyrus-customizations-robotics-SimpleExampleParametersInstance.png]]<br/>
+
−
Re-Configuration of AcmeMapper Instance
+
−
 
+
−
==== Conclusions ====
+
−
 
+
−
This example shows a structural model in the context of composition of software components. It shows how different tiers contribute models to achieve composition of software components, using service-definitions as central architectural element for it. Then it focuses on one instance of the mapper component and shows a simple reconfiguration of one of its parameters.
+
−
 
+
−
===== Do It Yourself =====
+
−
 
+
−
This section is in progress. More content will be added shortly.
+
−
 
+
−
==== Connect ComponentInstance Items ====
+
−
 
+
−
Connections between component instances can be drawn by using the ''connects'' item from the system component architecture palette, see previous diagram (Model of system component architecture).
+
−
 
+
−
First, select ''connects'' from the palette. Then point and click the source and target component ports to be connected. Note that the connection is only possible if
+
−
 
+
−
  * both source and target elements are component ports
+
−
  * both ports provide/require compatible services. In other words, for 2 connected (component) ports, the type represented by a component service must be //instance-of// the same service definition.
+
−
 
+
−
= Supported diagrams =
+
−
 
+
−
== Component definition diagram ==
+
−
 
+
−
== Service definition ==
+
−
 
+
−
== Datatype definition diagram ==
+
−
 
+
−
== System assembly ==
+

Revision as of 05:26, 1 March 2023


Documentation

Introduction

User Guidance

Application Examples

Developer Guidance

Other Documentation

  • Publications
  • FAQ
  • Community -- RobMoSys wiki, Papyrus forum (please prefix a subject with [Robotics] or [Robotics, ROS2])
  • Bug reporting: use the Eclipse bugzilla to report it. In the following link, the product (Papyrus) and the the component (Robotics) are already selected File a Papyrus for Robotics bug. Use the same naming convention as for the forum, i.e. prefix with [Robotics] or [Robotics, ROS2] and check out whether the bug is eventually already existing (the browser proposes possible existing bugs as you type your bug title]. Please make also sure that the steps to reproduce the bug are clearly described, eventually add your model.
Retrieved from "https://wiki.eclipse.org/index.php?title=Papyrus/customizations/robotics&oldid=446987"

Back to the top