for a Well-fitted Model Driven Control Architecture for Robots Eric - - PowerPoint PPT Presentation

▶

Apr 07, 2023 6 likes •201 views

Robotic Engineers Specifications for a Well-fitted Model Driven Control Architecture for Robots Eric Molin, Nicolas Morette, Cyril Novales, and Pierre Vieyres PRISME Laboratory Orlans University / Bourges SIMPAR 2014, Bergamo

SLIDE 1

SIMPAR 2014, Bergamo

Robotic Engineer’s Specifications for a Well-fitted Model Driven Control Architecture for Robots Orléans University / Bourges

Eric Moliné, Nicolas Morette, Cyril Novales, and Pierre Vieyres

PRISME Laboratory

SLIDE 2

SIMPAR 2014, Bergamo

Robotic Applications are more and more complex: robotician must implement and manage (master) different controls / perceptions / plannings / behaviors …  Separate and Coordinate the Roles

Robotician Problem

Need and Use different innovated Tools new formalisms to master… No choice to perform robotic applications the job is changing base innovation on robotician’s knowledge / knowhow

ur dream: a so powerful and simplistic tool than Grafcet for PLC…

SLIDE 3

SIMPAR 2014, Bergamo

anr-proteus.fr

13 partners

Scenario Problem Algorithms C, C++, Matlab Solution Ros bus PC linux Robots Web

Robotic Portal

Proteus project (2009-2013) RobotML platform/SDK

(Papyrus – EMF)

SLIDE 4

SIMPAR 2014, Bergamo

Informal Architecture

SLIDE 5

SIMPAR 2014, Bergamo

Informal Architecture Formal Model

SLIDE 6

SIMPAR 2014, Bergamo

Separate Roles : Architect-Designer & Programmer-Expert Programmer-Expert : Middleware + OS Architect-Designer : DSL / Framework

Roles & Tools

 High Complexity for a robotician Software Engineering tools Various Middlewares  wich ?  ros Various Frameworks

SLIDE 7

SIMPAR 2014, Bergamo

We propose some Specifications from classical Roboticians to Software Designers to integrate their knowhow in a framework

Some Specifications

Robot

Software model engineers

Robotic designers

Meta Model

Do not master

Design

Can provide concepts, principles, tools to model robotic software architectures

Robotics Model

Define

Robotic experts

Software Architecture

Model to Code Transformation

Adapted to a specific target (robot, middleware and operating system)

Code and implement algorithms

issues How to express needs in terms of characteristics for the robotic model ?

Model to Model Transformation

Simulator ROBOTICIANS

SLIDE 8

SIMPAR 2014, Bergamo

Component

Roboticians get used to manipulate “components” Input ports and out ports to interconnect them  Component based framework

COMPONENT

 Data flow Assumption: All components run in parallel Components have time to process all data Users know it is false, and must manage time of exchange and process  Some tools to help in this management

SLIDE 9

SIMPAR 2014, Bergamo

ALGO

INPUT MANAGEMENT UNIT COMPONENT CORE UNIT

O M U

Separations inside the Component

3 parts for each components Component Core Unit: the algorithm code  Reuse possibility Input Management Unit: the input ports  data consumption policy & trigger Output Management Unit: the output ports  data production policy

SLIDE 10

SIMPAR 2014, Bergamo

Input Management Unit data consumption

Buffer in each input port (in the component) FIFO, LIFO and CYFO buffers  data consumption policy for each component

∞

FIFO 9

CYFO

5 LIFO Clr

 Choose the sampling stragegie + Clear older values option How to consume input data

SLIDE 11

SIMPAR 2014, Bergamo

Input Management Unit Trigger

Separate from the Data Consumption Policy  Selection of the trigger

CYCLE OPERATOR LAG OPERATOR ADD OPERATOR OR OPERATOR ASYNCHRONOUS OPERATOR

How to trigg the core (algorithm)

SYNCHRONOUS OPERATOR (n trigger effect)

IMU

Lag(50, Input 2)

4 LIFO

∞

CYFO

TRIGGER

IMU

Cycle (100)

10 FIFO

Input 1 TRIGGER

SLIDE 12

SIMPAR 2014, Bergamo

ALGORITHM

IMU CCU

Input 2 x Input3

D A T A P A R S E R

4 LIFO

∞

CYFO 5 FIFO

Output 1 Output 2

D A T A P A R S E R

Input 1 Input 2 Input 3

OMU

TRIGGER

The entire Component

The Component Core Unit: only process inputs and delivers output.  Reuse A Parser fits the data in the good format for the CCU. The Output Management Unit: only fits data in the good format

The Component Core Unit: do not manage its own trigg do not manage the consumption policy do not manage the data format

SLIDE 13

SIMPAR 2014, Bergamo

The Data

Time Stamped  XML format Not only a (set of) binary value Add informations/fields: . who produce it (and when) . The unit(s) . Its name . Its type/format . Its identifier …

SLIDE 14

SIMPAR 2014, Bergamo

The Data Flow

No necessary links between an output port and an input port  As Network (udp)  No subscriver / producer paradigm A producer component produce a data and broadcast it A subscriver component read only its identified data on the fly  Use network substract

SLIDE 15

SIMPAR 2014, Bergamo

Pro / Cons

IMU and OMU formalism allows to exchange “easily” a component  No algo change (same CCU)  Only add rules on the parsers . etheir on the OMU Parser of the New component . etheir on the IMU Parser of the other(s) component(s) Trigger & consumption policy are clearly separated  Architect-designer can (pre-)manage time issues XML format of data  IMU and OMU can adapt to a new data type XML format of data flow  time/weight of transmition Broadcast output data  Catch data on the fly

SLIDE 16

SIMPAR 2014, Bergamo

Conclusion and future works

We propose to the architect-designer _ but also to the programmer-Expert _ To manage the time of theirs robotics application, with the same tool, with already known concepts. Validate it thru a strong link with SD researchers This formalism must integrate ‘big’ shared data (like maps)

SLIDE 17

SIMPAR 2014, Bergamo

Thank You

SLIDE 18

SIMPAR 2014, Bergamo

Robotic Engineer’s Specifications for a Well-fitted Model Driven Control Architecture for Robots Orléans University / Bourges

Eric Moliné, Nicolas Morette, Cyril Novales, and Pierre Vieyres

PRISME Laboratory

Robotic Applications are more and more complex: robotician must implement and manage (master) different controls / perceptions / plannings / behaviors …  Separate and Coordinate the Roles

Robotician Problem

Need and Use different innovated Tools new formalisms to master… No choice to perform robotic applications the job is changing base innovation on robotician’s knowledge / knowhow

anr-proteus.fr

13 partners

Scenario Problem Algorithms C, C++, Matlab Solution Ros bus PC linux Robots Web

Robotic Portal

Proteus project (2009-2013) RobotML platform/SDK

(Papyrus – EMF)

Informal Architecture

Informal Architecture Formal Model

Separate Roles : Architect-Designer & Programmer-Expert Programmer-Expert : Middleware + OS Architect-Designer : DSL / Framework

Roles & Tools

 High Complexity for a robotician Software Engineering tools Various Middlewares  wich ?  ros Various Frameworks

We propose some Specifications from classical Roboticians to Software Designers to integrate their knowhow in a framework

Some Specifications

Robotic designers

Robotic experts

Component

Roboticians get used to manipulate “components” Input ports and out ports to interconnect them  Component based framework

COMPONENT

 Data flow Assumption: All components run in parallel Components have time to process all data Users know it is false, and must manage time of exchange and process  Some tools to help in this management

INPUT MANAGEMENT UNIT COMPONENT CORE UNIT

Separations inside the Component

3 parts for each components Component Core Unit: the algorithm code  Reuse possibility Input Management Unit: the input ports  data consumption policy & trigger Output Management Unit: the output ports  data production policy

Input Management Unit data consumption

Buffer in each input port (in the component) FIFO, LIFO and CYFO buffers  data consumption policy for each component

 Choose the sampling stragegie + Clear older values option How to consume input data

Input Management Unit Trigger

Separate from the Data Consumption Policy  Selection of the trigger

How to trigg the core (algorithm)

ALGORITHM

IMU CCU

OMU

The entire Component

The Component Core Unit: only process inputs and delivers output.  Reuse A Parser fits the data in the good format for the CCU. The Output Management Unit: only fits data in the good format

The Component Core Unit: do not manage its own trigg do not manage the consumption policy do not manage the data format

The Data

Time Stamped  XML format Not only a (set of) binary value Add informations/fields: . who produce it (and when) . The unit(s) . Its name . Its type/format . Its identifier …

The Data Flow

No necessary links between an output port and an input port  As Network (udp)  No subscriver / producer paradigm A producer component produce a data and broadcast it A subscriver component read only its identified data on the fly  Use network substract

Pro / Cons

Conclusion and future works

We propose to the architect-designer _ but also to the programmer-Expert _ To manage the time of theirs robotics application, with the same tool, with already known concepts. Validate it thru a strong link with SD researchers This formalism must integrate ‘big’ shared data (like maps)

Thank You

Robotician

Hardware Software

Simulator Robot

Development Expecting Behavior (?) Mission / Scenario

Plan / Architecture

Design a robotic application