Pleading for open modular architectures - Lirmm

More documents

Recommendations

Info

First National Workshop on Control Architectures of Robots - April 6,7 2006 - Montpellier o liability : because this is for use in fine by military force for strategic operations eliminating the possibility for any error, o modular : because the kit must be adapted and fitted for different platforms and components must be replaced or added easily o open : because the final objective is to find the right architecture and set of sensors so many tests must be done, the task of implementation must be eased as much as possible, o adaptive : because as a prototype, several configurations and improvements or modifications must be done in a short time to make it usable. To find the right compromise between all of these constraints has been the objective of the study phase, as well in terms of forecasting what will be needed in the next future as in terms of ease of use for pilots, not specialists in using computers and a powerful but complicated MMI. The results are shown in the next paragraphs. B. Command & Control architecture Components The command & control architecture is composed of several subsystems : � the Command & Control system (C²S) i.e. the place from which the operator is giving the orders or supervising what’s happening. This subsystem is then subdivided into mobility & mission dedicated work stations. Further details on this will come in the next chapter. � the on-board layers : a cPCI computer architecture is used to provide all services needed from the interpreter to the physical command of the actuators, it is divided into the following components : o a communication interface that deals with transmission protocol between C²S and low level on-board calculator. Thus, a change in the protocol from cyclic to acyclic transmission, or change in the delivery rate of cyclic packets will result only in a change in this layer (and the same in C²S of course), o a supervisor (SUP), in charge of all security aspects managements and arbitration of possible conflicts between the components. o a low level controller (LLC), whose role is the management of all automatons for remote operation, meaning placing the commands in correct…. o a platform controller (PFC), that acts as an abstraction layer between the platform and low level orders. This layer has the responsibility to provide the link from orders to physical command of the actuators through the various installed boards (analog and digital I/O, counters, serial links, …). This is the only specific part of the architecture, platform dependent, that need to be adapted for each different type of vehicle (apart from specific transmission). o a high level controller (HLC) who can communicate with the LLC to get information from the platform to run value-added algorithms and give back orders to the LLC for driving the robot or simply give feedback to the user via the MMI through the SUP to help in the driving or alert if an automatic obstacle detection is activated for example. To prevent any malfunction caused by a high level function and also maximizing the calculation power needed for the algorithms, a physical calculator is provided for high level functions to ensure in case of hang up of a function or a module, or in case of severe software failure, the low level will so be still alive and allow the user to keep control of the platform. 92
The following scheme sums up the interaction between all components of the system. Automatons First National Workshop on Control Architectures of Robots - April 6,7 2006 - Montpellier Low level Controller Automatons management State info Command Control System TC Communication interface Security Commands Filtered commands InfoSys Supervisor Components exchanges management Security / liability Platform Controller TM System Commands States + PF Commands Vehicle specific command management Directions Alerts/Malfunctions States + assisted commands Measures Actuators/ Sensors Drivers Picture 2 : the Command & Control architecture High levelController Autonomy modules Driving help After identification, the functions have been analyzed to elaborate the state machines. Below is an example of such an automaton, showing the interactions and data exchange between components. 93
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:
Page 42 and 43: • Three Petri nets model level 3:
Page 44 and 45: First National Workshop on Control
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?