Paradigme Réactif

GEF 447B Bring sample sensors Paradigme Réactif Capt. Vincent Roberge

Aperçue • Paradigme Réactif • Architecture Réactive ‘Subsumption’ • Exemple • Implémentation Réactive ‘Subsumption’

RobotPrimitives

Paradigme Réactif • réaction aux limites du Paradigme Hiérarchique • Introduit par Brooks (1987) • Beaucoup utilisé entre 1988 – 1992 • Depuis 1992, utilise surtout paradigme hybride • Deux facteurs causes de cette technologie • L’étude d’organisme simple (p.ex. fourmis, abeilles…) • Réduction coût des ordinateurs, et capteur Agir Capter

Paradigme Réactif Agir • Connecte directement Capter à Agir • N’utilise pas la primitive Planifier • Comportementest décrit par la relations capteur-actuateur • Plusieurs relationscapteur-actuateur peuventexistés. Capter

Paradigme Réactif • Crée suite aux problèmes du paradigme hiérarchique et d’après l’étude de comportement animaux. • Le paradigme hiérarchique était horizontal de nature

Paradigme Réactif • décomposition vertical • Débute avec comportement de survie • Couche supérieur peut • Utilisé couche inférieur • Inhibé couche inférieur • Créer couche parallèle exhibant nouveau comportement • Chaque couches ont un certain accès auxcapteurs & actuateur Prendre pomme verte

Paradigme Réactif • Toute action est effectuée par des comportements • Comportements sont des relationsdirects entre l’entrée des capteurs à un set de commande contrôlant l’action des moteurs • Arkin, Brooks et Payton ont étudié les mécanismes pour gérer la situation de comportements multiples simultanémentactifs.

Prochain Point • Paradigme Réactif • Architecture Réactive ‘Subsumption’ • Exemple • Implémentation Réactive ‘Subsumption’

Architecture Réactif :Deux Approches • Quand des comportements multiples sont actifs simultanément, de nouveaux comportements peuvent émerger • Subsumption : l’approche (orienté matériel) de Brooks (MIT) pour faire des robotsressemblant aux insectes • Champ de potentiel :l’approche deArkin et Payton applicable pour des implémentations logiciel

Architecture Subsumption • Modules groupés en couche de compétence. • Couche inférieur : but-orienté (p.ex. prise de la pomme) • Couche supérieur : basic (fonctions de survie). • Couche supérieur peut subsumer (override) l’inférieur • Tâche complétée en activant la couche appropriée, qui subsume les couches inférieures. :

Implémentation Subsumption : Exemple • Comportement d’un robot utilisant: • un petit microcontrôleur • un anneau de sonar • Démontre un objet proche du sonar 2 et 3.

Exemple: 1ère couche - Éviter Première couche éviter la collision avec objets: • “Sonar” est un module SW qui détermine distances • “Motors” est un pilote SW qui contrôle les moteurs • “Avoid” est un comportement réflexe de fuite • Si objet trop proche en avant du sonar: arrête déplacement. • Tourne robot jusqu’à ce que la plus petite distance soit lue par le sonar de derrière. • Avancer jusqu’à un seuil de détection (objet détecté)

Exemple: 2ème couche - Recharge Battery Level • Recharge: retour du robot à une station de recharge lorsque le voltage des piles sont basses • stationde recharge contiens une balise IR • Si “Dock” est activé, va envoyer des commandes aux moteurs pour aller se chargé tout en regardant pour des obstacle en route • D’autres couches peuvent être ajouté sans changer les couches inférieurs. Dock Motors IR Detector Sonar

Contention des comportements • Avoid et Dock peuvent vouloir contrôler les moteurs • Conflit résolu en utilisant un nœud de suppression “S” • Message passe à moins d’être ‘override’ par un signal valide des couches supérieurs

Nœud de suppression • Nœud de suppression laisse passer message du nœud inférieur à moins qu’un nœud supérieur a un message à passer. • Fonction Dock subsume la fonction Avoid

Couches additionnelles • Des couches additionnelles peuvent être ajoutées de façon à créer des comportements complexes et les couches de bases ne sont pas perdues. • Les calculs/temps d’exécution resteront petit.

Exemple 2: Section 9.3 du livre Mobile Robots

Implémentation - Défi • L’implémentation des comportements représente un défit important: • Design - sans-fouillis et facilement compréhensible; • Structure - suit les règles d’art de programmation • Temps – s’assurer que les comportement exécute à temps • Chaque comportement est un processus… • Qui doit être exécuté simultanément • c.-à-d. multitâche • Solution: Real-time processing (ou Pseudo)

Multitâche • Multitâche requière un ordonnanceur (scheduler) real-timepour coordonner les processus • idéalement l’ordonnanceur génèrera une interruption des tâches pour laisser une tâche plus importante être exécutée. • Multitâche préemptif • Nécessite un OSreal-time • Nous n’utilisons pas d’OS real-time • Notre solution est le multitâche coopératif

MultitâcheCoopératif (MC) • Les processus, au lieu du ordonnanceur, décide quand est-ce qu’il redonne contrôleà l’ordonnanceur . • En utilisant MC, il faut s’assurer qu’aucun processus ne monopolise le processeur. • Éviter les boucles laborieuses… exceptionnellement pour les tâches de grande priorité (main{}).

MultitâcheCoopératif - Ordonnanceur • appelle chaque processus tour-à-tour • Doit aussi utiliser une arbitration pour résoudre le conflit entre deux comportements compétitifs

Arbitre • Tous les comportements ont une connections à certains actuateurs • L’arbitre s’occupe de faire la bonne connections en adressant les comportements conflictuels • suppression des nœuds se fait par l’ordre des lignes de codes des comportements • behave1  actuator1 • behave2  actuator1 • behave3  actuator1

Flag de sortie valide • En utilisant un flag pour signifier que la sortie d’un comportement est valide, on a l’engrenage ordonnanceur /arbitre qui peut fonctionner • p.ex. • if ( behave1ValidFlag = = TRUE ) { • Connecter la sortie de behave1 à actuator1 } • if ( behave2ValidFlag = = TRUE ) { • Connecter la sortie de behave2 à actuator1 } • etc. • L’ordre peut être inversé, et utiliser “else if”

Implémentation en bref • dans main(); • Ordonnanceur appelle chaque fonction/comportement • set flag quand on a une sortie/donnée valide • déterminela sortie des comportements • Appel la fonction arbitre • Chaque comportement devrait avoir son flag et sa variable de sortie en variableglobal (ou ptr) • Arbitre doit utiliser les flags actifs pour choisir quelle sortie des comportements qui sera connectée aux actuateurs

En bref • Paradigme Réactif • Architecture Réactive Subsumption • Exemple • Implémentation Réactive Subsumption Questions?

Références • Images et contenus pris de: • Introduction to AI Robotics, R. Murphy, 2000 • Behavior-Based Robotics, R. Arkin, 1998 • Mobile Robots, Jones; Sections 9.4, 9.5

Paradigme Réactif