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

Robotic Engineer’s Specifications for a Well-fitted Model Driven Control Architecture for Robots Eric Moliné, Nicolas Morette, Cyril Novales, and Pierre Vieyres PRISME Laboratory Orléans University / Bourges SIMPAR 2014, Bergamo

Robotician Problem Robotic Applications are more and more complex: robotician must implement and manage (master) different controls / perceptions / plannings / behaviors …  Separate and Coordinate the Roles 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 our dream: a so powerful and simplistic tool than Grafcet for PLC… SIMPAR 2014, Bergamo

Proteus project (2009-2013) Algorithms Scenario Robots C, C++, Matlab RobotML Problem Solution platform/SDK PC linux Ros bus (Papyrus – EMF) Web anr-proteus.fr 13 partners Robotic Portal SIMPAR 2014, Bergamo

Informal Architecture SIMPAR 2014, Bergamo

Formal Model Informal Architecture SIMPAR 2014, Bergamo

Roles & Tools Separate Roles : Architect-Designer & Programmer-Expert Programmer-Expert : Middleware + OS Architect-Designer : DSL / Framework Software Engineering tools  High Complexity for a robotician Various Middlewares  wich ?  ros Various Frameworks SIMPAR 2014, Bergamo

Some Specifications Can provide concepts, principles, tools to model robotic Define Software model engineers Meta Model software architectures issues Model to Model How to express needs in terms of Do not master characteristics for the robotic model ? Transformation Design Robotic designers Robotics Model Model to Code Transformation Code and implement algorithms Robot Robotic experts Software Architecture or Simulator ROBOTICIANS Adapted to a specific target (robot, middleware and operating system) We propose some Specifications from classical Roboticians to Software Designers to integrate their knowhow in a framework SIMPAR 2014, Bergamo

Component Roboticians get used to manipulate “components”  Component based framework COMPONENT Input ports and out ports to interconnect them  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 SIMPAR 2014, Bergamo

Separations inside the Component 3 parts for each components I NPUT C OMPONENT O M ANAGEMENT C ORE ALGO M U NIT U NIT U 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 SIMPAR 2014, Bergamo

Input Management Unit data consumption How to consume input data FIFO LIFO CYFO Clr ∞ 5 9 Buffer in each input port (in the component )  data consumption policy for each component FIFO, LIFO and CYFO buffers + Clear older values option  Choose the sampling stragegie SIMPAR 2014, Bergamo

Input Management Unit Trigger How to trigg the core (algorithm) SYNCHRONOUS OPERATOR (n trigger effect) ASYNCHRONOUS OPERATOR ADD OPERATOR CYCLE OPERATOR OR OPERATOR LAG OPERATOR  Selection of the trigger IMU IMU FIFO LIFO Input 1 10 4 CYFO ∞ Cycle (100) Lag(50, Input 2) TRIGGER TRIGGER Separate from the Data Consumption Policy SIMPAR 2014, Bergamo

The entire Component A Parser fits the data in the good format for the CCU. The Component Core Unit : only process inputs and delivers output. The Output Management Unit : only fits data in the good format IMU CCU OMU LIFO D D Input 1 A A Output 1 4 T T A A CYFO P P ALGORITHM Input 2 A A ∞ R R Output 2 S S FIFO E E Input 3 R R 5 Input 2 x Input3 TRIGGER The Component Core Unit : do not manage its own trigg  Reuse do not manage the consumption policy do not manage the data format SIMPAR 2014, Bergamo

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

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

Pro / Cons 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 IMU and OMU formalism allows to exchange “easily” a component  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)  No algo change (same CCU) XML format of data flow  time/weight of transmition Broadcast output data  Catch data on the fly 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. This formalism must integrate ‘big’ shared data (like maps) Validate it thru a strong link with SD researchers SIMPAR 2014, Bergamo

Thank You SIMPAR 2014, Bergamo

SIMPAR 2014, Bergamo

Design a robotic application Plan / Hardware Software Architecture Expecting Behavior (?) Simulator Mission / Scenario Robotician Development Robot SIMPAR 2014, Bergamo