Pleading for open modular architectures - Lirmm

More documents

Recommendations

Info

First National Workshop on Control Architectures of Robots - April 6,7 2006 - Montpellier propose, appears to be very well adapted to robotics software development and, moreover, bring a very interesting modular concept. With iCORE approach, modularity is twofold. First, relying on SynDEx methodology, iCORE provides users with hardware modularity. This means that once an application is written for a given architecture (composed with a set of cb555, PC and CAN buses), it is able to run on an extension of this architecture without any modification. Hence, extending the computing capabilities of a robotics platform is totally effortless: application is automatically redistributed in order to handle the new architecture resources. Secondly, iCORE approach also provides user with software modularity. As shown on figure 1, in our context, an application is designed as a block diagram. Each block contains either a basic feature (from iCORE kernels) or another set of blocks implementing a more complex feature. Thus, iCORE approach make software part be easily reusable: simply by copying and pasting blocks subsets. Fig. 6: Example of possible platform modularity Figure 6 gives a striking illustration of possibilities offered by iCORE modularity. On the left side, a four-wheeled platform is shown, composed with two pods. Each pod is driven by the same piece of control software (running on its own cb555). Hence, programming control for a six-wheeled version (with three pods) is nothing but duplicating a diagram subset and adding a new cb555 into architecture graph. Code distribution and execution will require no other step. The same way, assuming a 6-DOF robot arm control has been previously realized using iCORE approach, adding such an arm to the 6-wheeled platform is nothing but merging the two application diagrams together and modifying the architecture description in order to fit the right set of cb555 boards and PC. Conclusion Relying on this flexible and reliable development methodology, the iCORE approach, we present here, bring an efficient help to users and researchers, interested in overriding application implementations complexity. Thanks to his own experience, Robosoft has adapted robotic solutions for the field of automatic transportation of people and goods, leading to a dedicated product range: rugged hardware components (cb555 and various types of embedded PC), as well as a set of realtime software components (control loops, I/O primitives, laser and wire guidance, obstacle detection, ...). As shown over the given examples, iCORE approach allow user to easily implement and customize transportation applications. Finally, making use of programming methodology introduced by SynDEx, iCORE guarantee applications executions integrity during risky interventions. References [1] E. Bianchi, L. Dozio, P. Mantegazza. DIAPM RTAI Dipartimento di Ingegneria Aerospaziale - Politecnico di Milano Real Time Application Interface. [2] RTLinux The Realtime Linux. [3] Thierry Grandpierre, Christophe Lavarenne, Yves Sorel. Modèle d'exécutif distribué temps réel pour SynDEx. 1998.. [4] MOTOROLA SEMICONDUCTOR TECHNICAL DATA. MPC555 Product Preview PowerPC TM Microcontroller, MOTOROLA INC., 1998. 90
First National Workshop on Control Architectures of Robots - April 6,7 2006 - Montpellier Remote operation kit with modular conception and open architecture : the SUMMER concept L. WALLE, Defence R&D & Europe business manager ECA – Defence & Offshore, Land systems Bât Apollo 4 r Rene Razel 91892 ORSAY CEDEX, � lw@eca.fr � http://www.eca.fr Abstract The article presents an original command and control architecture, realized for French MoD (DGA), aiming at operating any robot through a low level controller acting as an abstraction layer between actuators and high level orders, whilst ensuring liability of the remotely operated system as well as allowing high level mechanisms to help the operator in assisted mode or to plan semi or fully autonomous mobility actions while the operator concentrates on its inspection or observation mission, with the ability to keep the control of the machine in any case. The Man Machine Interface has also been a big achievement for this project since profile settings allow all controls to be fully configurable and being instantly modified, adjusted, new functions added. Lastly, a brief description of the company is provided to know more about ECA. A. Reasons for modularity : the Summer concept aim Cybernetix company has been developing since years several prototypes aiming at inspecting and observing the suburb region as well as operating remotely in case of harsh or hostile environments. One of our current realizations concerns a global solution for French MoD (DGA/ETAS) able to remote operate different types of vehicles with the same command & control architecture and the readiness and mechanisms to implement autonomy functions as well as testing new MMI configurations. The following pictures show the variety of vehicles to be adapted. All photos courtesy of DGA Picture 1 : Summer vehicles The problem therefore is of different kind : o size : because the range of vehicles goes from a truck pillar to a quad, solution has to be compact, o ruggedness : because it must operate in all-terrain, 91
Page 4 and 5:
Organization This first national wo
Page 6 and 7:
Contents Organization…………
Page 8 and 9:
Program April 6, 2006 8:30-9:00 Rec
Page 10 and 11:
First National Workshop on Control
Page 12 and 13:
Page 14 and 15:
1 User requirements defined 2 Syste
Page 16 and 17:
Page 18 and 19:
Page 20 and 21:
Page 22 and 23:
Page 24 and 25:
Page 26 and 27:
Page 28 and 29:
Figure 6. Interface for local map (
Page 30 and 31:
Figure 8. Map and robot trajectory
Page 32 and 33:
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Decision Planning Navigation Guidan
Page 40 and 41: First National Workshop on Control
Page 42 and 43: • Three Petri nets model level 3:
Page 48 and 49: Abstract First National Workshop on
Page 50 and 51: eginning of the next one. A guidanc
Page 52 and 53: Figure 5 - Supervision interface Fi
Page 54 and 55: On-going tests First National Works
Page 76 and 77: DES (Data Exchange System), a publi
Page 94 and 95: Pilote Expérimenté:Télépilote F
Page 100 and 101: A multi-level architecture controll
Page 106 and 107: The autonomous parts Basic levels F
Page 110 and 111: cluster of the perception part of t
Page 118 and 119: An ultrasound probe of a sonographe
Page 120 and 121: Abstract First National Workshop on
Page 126 and 127: nombre de branches dans le parallé
Page 132 and 133: 2 The Orccad architecture 2.1 Basic
Page 140 and 141:
5.3 Real-time structures At compile
Page 142 and 143:
From a software engineering perspec
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 154 and 155:
Page 156 and 157:
Page 158 and 159:
Page 160 and 161:
Page 162 and 163:
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Page 178 and 179:
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
Stopped destination reached destina
Page 188 and 189:
� ��
Page 190 and 191:
Page 192 and 193:
Abstract Horocol language and Hardw
Page 194 and 195:
Page 196 and 197:
• langage.xml which describe the
Page 198 and 199:
Coordination programming in Horocol
Page 200 and 201:
[F8] resume [F9] restart [F10] reev
Page 202 and 203:
References First National Workshop
Page 204 and 205:
Page 206 and 207:
TABLE I PROBABILITY VALUES FOR PERC
Page 208 and 209:
show all

Pleading for open modular architectures - Lirmm

Create successful ePaper yourself

Delete template?

Save as template?