Menu
Systèmes de sécurité 2004
Vérification du robot avant le match
Détection des problèmes en cours de match
Reboot / segfault
Bug soft
Le programme du robot doit être très robuste. Il ne doit pas planter... et le robot ne doit jamais rester bloqué (en général les stratégies offensives rapportent plus de point que les stratégies défensives). Le robot doit donc vérifier en permanence qu'il fonctionne correctement et si ce n'est pas le cas il ne doit plus tenir compte des capteurs qui fonctionnent mal.
Vérification du robot avant le match
Avant le début du match le robot vérifie que toutes les cartes sont bien connectées et les capteurs sont dans un état correct (voir la fonction src/main/strategyInit.cpp Strategy::waitStart()).
- On vérifie que toutes les cartes nécessaires au robot s'identifient bien pendant le ping sur l'UART. Si ce n'est pas le cas, L'utilisateur est prévu par l'afficheur LCD et un son et on utilise le composant en mode simulé (c'est à dire qu'il ne fait rien).
- On vérifie que tous les bumpers sont dans un état correct (en général non enfoncé). Si ce n'est pas le cas, l'utilisateur est prévenu et il peut désactiver le capteur. L'évenement (EVENTS_BUMP_XXX) sera alors désactivé, c'est à dire qu'un changement d'état du capteur ne reveillera pas la fonction EVENTS->wait
- On vérifie que les odomètres fonctionnent correctement en poussant le robot sur une certaine distance. Si les codeurs des roues motrices, les codeurs des roues non motrices et la distance théorique concordent, tout va bien. Si ce n'est pas le cas, on décide de n'utiliser que les codeurs des roues motrices pour calculer la position du robot.
- Enfin des procédures de test sont lancées sur certaines cartes (comme la carte catapulte) pour vérifier que tous les capteurs sont dans un état correct.
- On vérifie aussi que l'arret d'urgence n'est pas enfoncé! puis on attend la jack de départ.
Vérification en cours de match
En cours de match le robot vérifie régulièrement qu'il n'y a pas de problème mécanique ou de communication avec les cartes critiques (comme les odomètres).
- La carte odomètre étant censée envoyer des données régulièrement au PC, si le programme n'a rien recu pendant un certain temps, il considère que la carte ne fonctionne plus et utilise les codeurs des roues motrices pour calculer sa position. (voir src/move/robotPosition.cpp RobotPosition::periodicTask()).
- Si la consigne envoyée aux moteurs des roues (Motor::getPwm) sature pendant un certain temps, cela signifie que les roues sont bloquées. Dans ce cas on reset les moteurs des roues et on déclenche l'évenement EVENTS_PWM_ALERT qui est interprété comme une collision. Le robot change donc automatiquement de direction (voir src/motor/motor.cpp Motor::periodicTask).
- Si la position calculée à partir des roues motrices diffère fortement de la position calculée par les odomètres, cela signifie que le robot patine ou à décolé. Par conséquent on déclenche l'évenement EVENTS_PWM_ALERT qui est interprété comme une collision. Le robot change donc automatiquement de direction (voir src/move/robotPosition.cpp RobotPosition::periodicTask()).
- Les capteurs infrarouges étant souvent perturbés par l'éclairage à la coupe, on essaye le plus souvent possible de faire de la redondance de capteurs. On compare la valeurs de plusieurs capteurs qui sont censés voir la même chose et on en déduit si on a mesuré du bruit ou si l'information est pertinente. Dans le cas de la détection des cocotiers, on n'avait qu'un seul capteur mais on effectuait une moyenne sur les N dernières estimation de la position des cocotiers en enlevant les valeurs extrèmes (voir src/main/match/matchTools.cpp MatchBase::setCoconut()).
- Pour ne pas être induit en erreur par un bumper qui resterait enfoncé, on ne détecte les collisions et la plus part des évènements que sur des changements d'état des capteurs.
Reboot - segfault
Le robot devant à tout prix bouger (il devait traverser la moitié du terrain cette année pour ne pas être forfait), il est important d'avoir un système qui détecte que le PC a rebooté ou que le programme à fait segfault et de repartir dans un mode "dégradé" permettant d'accomplir un minimum de chose en utilisant le moins de capteurs possibles.
Au départ l'idée était d'utiliser une shared memory pour savegarder l'état du robot et le rétablir en relancant le programme après avoir fait segfault.
Finalement nous avons utilisé un système plus simple: un interrupteur indique si le robot est en train de jouer un match ou non. Juste avant de mettre la jack de départ on positionne cet interrupteur en mode match. Quand le programme du robot est lancé, il commence par vérifier l'état de cet interrupteur. S'il est en mode match, le robot lance la stratégie "StrategyDegraded" qui démarre sans attendre la jack de départ et ou le robot se déplace aléatoirement. Un gère les crash du programme de la même manière en lancant le programme principal en boucle dans un script shell. Si le programme crash, il est relancé et on détecte que l'on est en mode match grace à l'interrupteur et on lance la stratégie dégradée.
Bug soft
Pour éviter les bugs soft, toutes les classes composant du robot sont des singletons. De plus on évite au maximum les allocations dynamiques. Le programme a également été vérifier avec "valgrind" pour détecter les problèmes mémoires.
Pour éviter les problèmes de boucles infinies, toutes les boucles "while" ont été équipées d'un compteur qui vérifie qu'on ne boucle pas trop et fait sortie de la boucle si c'est le cas.
Pour éviter de rester coincer dans un coin du terrain, chaque calcul de trajectorie vérifie que la nouvelle trajectoire est différente de la précédente et que le point de départ de la trajectoire est assew éloigné du précédent point de départ utilisé lors du calcul de trajectoire précédent. Si ce n'est pas le cas, on génère une trajectoire vers un point aléatoire du terrain assez loin du point de départ.
Coupe e=m6 2004 - "Sophia
Team" : ISIA-ESSI-ESINSA-EK