Règlement
Règlement 2015 : c2015_reglement_fr_final.pdf
Mécanique
Voici quelques photos de nos robots.
Montage de la carcasse :
Electronique
Nos robots :
L’électronique de nos deux robots repose sur nos cartes PLVL et carte moteurs.
carte PLVL
carte moteurs
Le hardware étant au point, il s’agit exactement des mêmes cartes que les deux années passées.
Cette année nous utilisons un jeu de deux cartes PLVL dans chaque robot (plus une carte moteur dans le robot 1). La 1er carte PLVL est dédiée à l’ordonnancement des taches stratégiques et d’automatismes alors que la seconde se charge des calculs d’asservissement du robot.
Ainsi ce jeu de cartes nous permettait de gérer, sur le robot 2 :
– 9 servomoteurs ax12
– 3 moteurs
– 1 pompe à vide
– 2 encodeurs
– 14 capteurs
– 2 encodeurs
– 14 capteurs
– 1 inclinomètre
– 1 accéléromètre/gyroscope
sur le robot 1, avec l’aide d’une carte moteur en plus :
– 9 servomoteurs ax12
– 4 moteurs
– 1 pompe à vide
– 2 turbines
– 4 encodeurs
– 17 capteursUne liaison I2C permet d’établir une communication entre toutes les cartes.
Si vous souhaitez plus d’informations au sujet de nos cartes électroniques, je vous invite à visiter les pages de nos robots précédent.
– 4 encodeurs
– 17 capteursUne liaison I2C permet d’établir une communication entre toutes les cartes.
Si vous souhaitez plus d’informations au sujet de nos cartes électroniques, je vous invite à visiter les pages de nos robots précédent.
La particularité de cette année était la montée des marches pour notre électronique.
Notre système de chenille devait se déployer avant la montée et se ranger le plus rapidement en haut afin d’éviter un basculement violent de notre robot, pouvant aller jusqu’a la chute :/
Pour avoir la réactivité nécessaire, nous avons utilisé un accéléromètre et un gyroscope, qui , à l’aide d’un filtre complémentaire nous assuraient de pouvoir agir rapidement.
Cependant nous avons tout de même ajouté de la redondance sur le système d’inclinaison. Je vous laisse comprendre notre choix avec la vidéo ci-dessous :
Un inclinomètre de 17° a été ainsi ajouté afin de se prémunir d’éventuel problème de calibration de notre centrale inertielle, les conséquences pouvant être désastreuses…
Nos balises :
Cette année, Sick et roboPeak nous ont sponsorisé un de leur LIDAR respectif.
Pour Sick, le LIDAR est un TIM561 :
Un excellent Lidar avec une fréquence de rotation de 15Hz et une acquisition tous les 0.3°.
Au niveau perturbation, rien à dire non plus, nous n’avons pas eu le moindre soucis!
A noter qu’un premier niveau de filtrage peut être effectué par le TIM afin de supprimer les points isolés. Ce type de fonctionnalité est toujours apprécié par les softeux en manque puissance CPU :p
Exemple d’acquisition avec le TIM561
Ce dernier était embarqué dans une balise de terrain et avait pour role de localiser tous les robots adverses présent sur l’aire de jeu.
La balise était donc équipée d’une carte RaspberryPI version B 1er génération afin de :
– faire l’acquisition des données renvoyées par le Lidar
– calculer la position des robots adverses
– renvoyer les positions à nos robots via notre réseau Wifi
Par la suite nos robots utilisaient ces informations afin d’améliorer le contournement d’obstacles statique et dynamique.
Par ailleurs un système de mise à niveau deux axes (X,Y) était présent dans la balise afin de maintenir le Lidar parfaitement horizontal.
Malheureusement nous pensions pouvoir gérer cela avec la Raspberry mais ça n’a pas été possible. Le jitter était tellement important que les servomoteurs étaient incapable de garder une position précise. Par manque de temps et de matériel, la solution manuelle a été choisie, à l’aide de bonne vieille cales en PVC^^
Notre Balise avec le TIM
Pour RoboPeak il s’agit du RPLIDAR :
Le RPLIDAR pour sa part, est un Lidar low cost. Sa fréquence de rotation est de 5.5Hz, avec une précision de l’ordre d’1°.
Il n’a donc pas la précision et la rapidité du TIM, mais je dois dire que j’ai été tout de même agréablement surpris au vu des performances!
En effet, RoboPeak se défend bien :
Exemple d’acquisition avec le RPLIDAR
RoboPeak fournit tout ce qu’il faut pour faire fonctionner le lidar, cependant pour une question de place nous avons développé notre propre carte d’adaptation pour récupérer les données :
Notre Balise avec le Lidar RoboPeak
Concrètement, nous devions détecter des cylindres de 6cm de diamètre. Jusqu’a 2500mm, que se soit le TIM ou le RPLidar, nous n’avions aucune différence après traitement. A plus grande distance, la detection n’était plus forcement assurée par le RPLIDAR car nous ne détections plus qu’un ou deux points du cylindre.
Alors que le TIM était utilisé pour notre système d’évitement adversaire, nous avons décidé d’utiliser le RPLIDAR pour « surveiller » l’adversaire afin de connaitre ses zones stratégiques (déposes, récupération d’éléments,…). Cette partie moins critique était tout de même importante, afin que nos robots ne perdent pas de temps à aller faire des actions inutiles.
Ainsi nous avons su trouver l’utilisation adaptée de chaque Lidar et en tirer le meilleur partie.
Encore merci à Sick et RoboPeak pour ces très bon Lidar!
Logiciel
Hormis notre nouveau logiciel LidarGui, pas grand chose de neuf cette année de ce coté.
Nucleus:
Ce système maison (rien à voir avec l’OS 😉 est une sorte de shell tournant sur nos Dspic. Il permet de contrôler l’ensemble des I/O de nos cartes, les réglages de l’asservissement, des automs,… depuis un PC/Mac. Il a été grandement amélioré et supporte à présent la communication via le wifi. Fini le robot qui se prend dans les câbles!
L’ensemble des logiciels présentés ci-dessous repose sur Nucleus.
Nucleus Server:
L’ensemble de nos logiciels (et vous allez constater qu’il y en a pas mal 🙂 ) fonctionnent tous en synergie à l’aide d’un serveur qui dispatch les informations souhaitées. Son role est de rediriger l’ensemble des données provenant des cartes électroniques vers les clients que nous allons vous présenter.
Interface avec Nucleus Server
AversiveConfigurator:
Afin de faciliter les réglages de l’asservissement, nous avons développé une interface graphique permettant de visualiser l’ensemble des paramètres actuellement utilisés par le robot. Nous pouvons ainsi peaufiner les réglages de l’odométrie et de l’asservissement plus facilement.
Ecran de réglages d’AversiveConfigurator
Ecran des courbes d’asservissement en live… là c’était avant les réglages^^
AvoidGui:
Un système d’évitement adversaire et d’obstacles a été développé cette année.
Son role est double :
– gérer l’activation des US avant/arrière en fonction de la position du robot sur le terrain, de son angle et du sens de déplacement
– trouver une trajectoire alternative en cas de rencontre inopinée
Le principe est assez simple pour le contournement : nous avons 5 méthodes de contournement d’obstacles, le module logiciel d’évitement les tests les une après les autres, de la plus optimisée en distance à la moins optimisée, jusqu’à trouver une solution. Pour avoir un aperçu visuel, une interface a été codé. Cette dernière récupère les données retournées par chaque traitement et les affiches. Les résultats à la coupe ont été assez encourageant, malgré quelques collision avec les baguettes en bois (un détail je vous dis, un détail :p ).
Visualisation du contournement retenu en vert et des US actif à droite
StrategyManagerGUI:
Depuis deux ans maintenant, nos robots sont capables de choisir leur stratégie de façon dynamique, en fonction de plusieurs paramètres : priorité, temps de match, points, dépendance entre taches…
Afin de valider ce module, rien de mieux qu’une petite interface graphique bien évidement 🙂
L’interface de validation
RtiGUI:
C’est une interface permettant de visualiser les déplacements du robot sur le terrain. L’intérêt est de confronter visuellement les déplacements vu par l’asservissement et vu en vrai par nos yeux émerveillés. Cela nous permet ainsi de voir clairement si un décalage de position est causé par des problèmes d’odomètries ou par des mauvaises coordonnées lors d’un contournement ou autre.
LidarGui :
La voici, la voila, la nouveauté 🙂
Afin d’avoir un retour graphique des acquisitions des Lidars, nous avons développé une application. Cette dernière gérait à la fois les données du TIM561 et du RPLIDAR.