Robots 2016

Règlement:  » The Beach Bots »

Règlement 2016 : c2016_reglement_fr_final.pdf
 terrain_2016

Mécanique:

Voici les robots pour l’édition 2016 de la coupe de France de robotique:

robot1

Le robot principal s’occupe de la construction de la muraille et des cabanes de plage.
Le robot secondaire s’occupe du moyen tas de sable et de la pêche au poissons.

La conception:

Afin d’optimiser au maximum l’agencement interne des robots nous les modélisation en 3D dans le logiciel CATIAV V5. Cette exercice nous permet de maximiser les encombrements des actionneurs et de l’électronique  :

Modèle 3D du robot principal:

 

Ci dessous le modèle 3D du bras 4 axes avec les 4 ventouses et les 4 capteurs infrarouges:

 

Modèle 3D du robot secondaire:

La réalisation:

Les robots sont construits à l’aide d’un assemblage de plaques PVC 6mm découpées avec une fraiseuse numérique:

Robot principal:

robot5

 

Bloc moteur 2016 du robot principal:

bloc2016n

 

Robot secondaire:

14102626_638798386289539_6301859898843844453_n

 

Vue arrière du robot:


13173956_589315904571121_1206226696387082466_n 13139327_588370827998962_6739629788109615617_n
 

Les robots en action sur le plateau de jeu:

FullSizeRender

Ci dessous une video de test de la fermeture des cabines de plage:

https://www.facebook.com/sussusinvaders/videos/579736115529100/

 

Électronique:

Nos robots : 

Cette année nous avons changé l’architecture électronique de nos robots. En effet, lors des précédentes coupes, l’électronique de nos deux robots reposait uniquement sur nos cartes PLVL et sur nos cartes moteurs.

carte PLVL
carte moteurs

Nous avons aussi utilisé ces cartes cette année, mais nous avons ajouté une RaspberryPi 2. L’idée est d’utiliser les cartes ainsi :

  • RaspberryPi 2 : gère l’ordonnancement des taches stratégiques, des automatismes et la gestion des obstacles
  • PLVL 1 : gère les calculs d’asservissement du robot
  • PLVL 2 : gère les actionneurs du robot (une sorte de carte IO)
  • Carte Moteurs (robot 1 uniquement) : gère les moteurs en plus 🙂

La RaspberryPi 2 est équipée d’un Linux (Distribution Poky générée à l’aide de Yocto). Ce choix a été motivé par une volonté d’efficacité  lors de la programmation du robot et du debug de notre logiciel. Le uC Dspic est long à programmer, nécessite de brancher le programmateur, de redémarrer le robot,… Maintenant la programmation se fait par wifi en quelques secondes! Le debug lui est beaucoup plus simple aussi.

Une 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.

 Ci-dessous un test d’asservissement en position du robot:
https://www.facebook.com/sussusinvaders/videos/573244422844936/
Nos balises :
L’année dernière, Sick nous a sponsorisé en nous donnant un LIDAR 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 é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

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é par nos soins.
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 :
Afin d’avoir un retour graphique des acquisitions du Lidar, nous avons développé une application.