2019 - Evolutek<<

Partagez votre expérience en expliquant comment vous travailler sur votre robot.
Share your experience by explaining how you work on your robot.
Post Reply
User avatar
kmikaz
Posts: 11
Joined: Wed 19 Sep 2018, 09:38

2019 - Evolutek<<

Post by kmikaz » Fri 25 Oct 2019, 02:22

Bonjour à tous,

Vaut mieux tard que jamais comme on dit XD.

Pour ceux qui nous connaissent pas, voici une petite présentation:
Evolutek<< est l'association de robotique des écoles Epita, Epitech, Ipsa et Sup'Biotech.
Nous participons à la coupe de France depuis 1997 et nous sommes surtout connus pour notre barbecue gratuit chaque année.
De plus, nos anciens ont aussi une équipe plutôt connue: Coffee Machine.

Nous avons fini 24 ème malgré des problèmes méca tout au long de la coupe (https://www.youtube.com/watch?v=KLkzqG9DutY).

----- Mécanique -----

Toute la mécanique est réalisée sur Catia.
Nous réutilisons souvent les solutions des années précédentes:
- Bloc moteur: Au centre du robot, un bloc contenant deux maxons pour la propulsion du robot que nous devons renouveler par manque de moteurs.
- Sur les côtés: Deux roues folles montées sur des codeurs Kubler comme odométrie que nous devons aussi renouveler à cause d'un jeu sur la glissière.
- Une structure en profilés 20mm depuis 2018.
- Des Ax12 en actionneurs.

L'année dernière, nous avons conçu deux robots.

Image

Le gros alias PAL:

Il a pour but de ramasser 3 palets par 3 avec ses bras munis de ventouses, d'en stocker 9 et de les déposer dans l'accélérateur de particules.
La rampe bascule pour mettre les palets dans le bon sens et un bras sur crémaillère les pousse.
Le bras central a une ventouse en plus pour attraper le goldenium.

Image

Malheureusement, à cause de notre odométrie qui avait un sacré décalage (qui n'a été réglé qu'à la coupe d'Île-de-France), nous n'arrivions pas à déposer les palets dans l'accélérateur.

Le petit alias PMI:

Il a pour but de récupérer la zone chaos et de la pousser via la rampe dans la balance.

Image

Ce robot a été fabriqué, codé et homologué en 3-4 jours mais comme il n'est pas stable, il arrive pas à monter la rampe. Nous avons préféré ne pas l'utiliser pendant les matchs car le code n'était pas super au point.

Balise Wifi/Lidar:

Cette balise nous sert à détecter la position des adversaires grâce à un Lidar mais aussi à héberger le routeur Wifi et notre Serveur RPC (vous en saurez plus après).

Image

----- Electronique -----

Pour l'électronique, nous réutilisons les mêmes cartes depuis 5-6 ans voir plus:
- Une carte d'alimentation qui génére du 12V et 5V.
- Une carte moteurs avec des ponts en H faits de MOSFET et un DSPIC pour asservir en position le robot.
- Une Raspberry Pi 2 ou 3 avec un shield IO pour avoir des connecteurs JST pour l'intelligence du robot.

Image

Carte d'alimentation:

Image

Carte moteurs:

Image

La Raspberry avec son shield IO:

Image

Nous avons pas mal de soucis:
- Le BAU sert de bouton ON/OFF
- La carte moteurs se fait vielle
- La Raspberry Pi n'a pas assez de GPIO
- Le bus 12V n'a que 6A, trop faible pour les Ax12
- Trop de câbles entre les différentes cartes

Nous bossons sur une nouvelle architecture avec un module Phycore IMX7 de notre sponsor Phytec (https://www.phytec.fr/produit/modules-s ... ore-imx-7/).

----- Informatique -----

Pour la partie asservissement sur le DSPIC, nous avons du code C qui gére tout l'asservissement de position du robot et qui reçoit les ordres de déplacement depuis une liaison Serial.
Nous avons même une détection de collision (https://www.youtube.com/watch?v=mid3QFePVV8).

Pour les Ax12, nous utilisons un USB2AX (https://www.trossenrobotics.com/usb2ax) avec une bibliothèque sur la RaspberryPi.

Alors, nous allons surement choquer beaucoup de gens ici mais, notre code ne tourne pas 100% sur nos robots XD.
Nous avons développé il y a quelques années un serveur RPC appelé Cellaserv codé en Go (https://www.youtube.com/watch?v=zV1a-kmO1BU).

Les sources sont ici: https://bitbucket.org/account/user/evolutek/projects/CS.

Le serveur tourne sur une Raspberry dans notre balise Wifi/Lidar et nous lançons des services qui communiquent en TCP/IP via le Wifi depuis les différents appareils (balise, robots).
Les services sont en Python mais nous pouvons faire ce que nous voulons selon les clients disponibles (actuellement Python et C++).

Voici l'architecture des services de 2019:

Image

En soi, l'IA peut tourner sur un de nos PCs (c'est le cas quand nous débuggons) mais à la coupe, tout le code tourne sur les robots ou les balises.

Le souci majeur de cette architecture est que nous devons passer par le serveur (donc faire des allé-retours) dès qu'on s'adresse à un service.

Nous avons aussi dev un Dashboard, un utilitaire et un Shell pour pouvoir contrôller l'ensemble facilement. Par exemple nous avons un shell WASD pour faire bouger le robot ...

Pour la détection des adversaires, nous avons deux systèmes:
- Le système d'urgence avec des capteurs de proximité de chez Sick (https://www.sick.com/fr/fr/capteurs-pho ... /p/p246945) qui arrête le robot en cas d'obstacles imprévus sur le chemin du robot.
- Un Lidar de chez Sick pour calculer la position des robots précisement (https://www.sick.com/fr/fr/solutions-de ... /p/p369446). Nous nous-en servons pour recalculer les trajectoires du robot.

Les capteurs de proximité étant du tout ou rien, et surtout un rayon simple et pas un cône de détection, nous avons du mal à voir certains robots vides mais ce système a fait ses preuves plusieurs fois comme avec le robot de l'ESEO que nous avons bully (en toute amitiée) à la précoupe de Da Vinci Bot: https://www.youtube.com/watch?v=bhKQYf5Enl8.

L'IA est une machine à états qui choisit les objectifs à faire selon la situation. nous n'avons pas encore eu le temps de dev la solution pour choisir les actions donc nous avons juste une liste d'objectifs.
La stratégie est dans un fichier JSON que l'IA load au démarrage.

Image

Pour le pathfinding: https://www.planete-sciences.org/forums ... 30#p167687.

Les nouveautés de cette année arriveront dans un autre post.

Pour plus d'infos:
- https://www.youtube.com/watch?v=p4qXxmP_h34&t=338s
- https://www.youtube.com/watch?v=9kYd1uzYyro
- https://www.youtube.com/watch?v=MchOJBbPgB4

En bonus: notre robot qui chill avant le début de la coupe de Belgique.
Image
--
EPITA 2020
Président Evolutek<<

antoine_cvra
Posts: 455
Joined: Mon 27 Aug 2007, 18:05
Location: Suisse

Re: 2019 - Evolutek<<

Post by antoine_cvra » Sat 26 Oct 2019, 18:22

Intéressant le système de RPC qui tourne sur la balise, mais ca me fait me poser plein de questions :D Désolé si certaines sont déjà répondues dans un lien que vous avez posté.
  • Est-ce que vous avez eu des soucis de packet drop sur votre lien Wifi ? TCP peut vite ajouter des méga latence en cas de perte de packet.
  • Dans la même veine, pourquoi pas en UDP en utilisant des RPC qui peuvent être envoyées plusieurs fois ?
  • Vu que vous avez un raspberry pi, vous auriez pu faire tourner l'ensemble de vos services en local sur le rpbot, avec les mêmes avantages mais moins de dépendances au Wifi et moins de latence non ?
  • Est-ce qu'il y a une raison d'avoir fait votre propre framework de RPC plutôt que d'utiliser un pré-existant ? Vous avez pas spécialement de contrainte à ce niveau là du coup gRPC/ZeroMQ/whatever aurait fait le travail en plus vite développé non ?
En tout cas on voit l'influence des softeux dans votre équipe :D Mais c'est nice de voir que des gens font d'autre architectures software et recherchent un peu de nouvelles idées à la coupe.

halfr
Posts: 1
Joined: Mon 28 Oct 2019, 11:23
Location: Zurich

Re: 2019 - Evolutek<<

Post by halfr » Thu 31 Oct 2019, 16:25

Salut Antoine !
Est-ce que vous avez eu des soucis de packet drop sur votre lien Wifi ? TCP peut vite ajouter des méga latence en cas de perte de packet.
Oui c’est vrai c’est un risque qu’on prend, heureusement on a pas eu de soucis avec le Wifi, ou bien on ne s’en est jamais rendu compte. Pour avoir plus d’information à ce sujet, on a commencé à rajouter du monitoring dans le serveur de RPC, et une des premières mesures est la latence de chaque RPC.
Dans la même veine, pourquoi pas en UDP en utilisant des RPC qui peuvent être envoyées plusieurs fois ?
On a besoin pour certains RPCs de s’assurer de l’ordre d’arrivée des commandes, et même si certains messages n’ont pas cette contrainte, par exemple la télémétrie qui est envoyée périodiquement, on a préféré un setup réseau simple (=tout TCP) à un système plus complexe (tantôt TCP tantôt UDP) marginalement plus efficace.
Vu que vous avez un raspberry pi, vous auriez pu faire tourner l'ensemble de vos services en local sur le rpbot, avec les mêmes avantages mais moins de dépendances au Wifi et moins de latence non ?
C’est ce qu’on a fait pendant quelques coupes, mais avoir le serveur de RPC sur la balise permet de travailler sur le robot secondaire même si le robot principal est éteint.
Est-ce qu'il y a une raison d'avoir fait votre propre framework de RPC plutôt que d'utiliser un pré-existant ? Vous avez pas spécialement de contrainte à ce niveau là du coup gRPC/ZeroMQ/whatever aurait fait le travail en plus vite développé non ?
En fait, le cœur du framework RPC a été codé en quelques jours et depuis on le modifie petit à petit en fonction des besoins ou des contraintes. On voulait initialement réduire le nombre de dépendances et simplifier l’architecture logicielle tout en ajoutant des fonctionnalités qu’on ne trouvait pas ailleurs.

Côté fonctionnalités, on a besoin de rien qu’un autre système, comme ZeroMQ, apporterait. On est pas forcément les plus efficaces, mais pour ce qu’on veut faire ce n’est pas un problème. Un avantage majeur est qu’on a une forte cohérence de notre stack logicielle, autrement dit : elle ne fait que ce dont on a besoin et s’il y a quelque chose qui ne nous plaît pas, on peut la changer du jour au lendemain. Par exemple si on trouve que la latence due au wifi est trop élevée, on pourra sans soucis rajouter un concept de serveur RPC “relais” pour éviter la latence de aller retour vers le serveur distant. Je pense d’ailleurs qu’il y eu autant de fonctionnalités ajoutées qu’enlevées depuis le début du projet et à vrai dire la version 3 actuelle n’a absolument rien en commun avec la version 1 !

En outre, notre système de RPC correspond à la façon dont on développe les robots en pratique, à un niveau d’abstraction qui nous convient, sans nous contraindre à utiliser des concepts trop génériques ou juste pas adaptés. Avec ça on peut expliquer l’intégralité du système en quelques minutes à un nouveau membre de l’association sans qu’ils aient à de se plonger dans un pavé de documentation pas forcément pertinente. Voilà quelques exemples de fonctionnalités spéciales Evolutek :
  • Avoir tout en TCP/Wifi permet de développer depuis n’importe quel PC, du moment qu’il est connecté sur le même réseau que les robots.
  • Toutes les communications passent par un serveur RPC central, de sorte que lorsqu’on développe les robots on a juste besoin de se connecter à lui pour avoir accès à tout, par exemple les logs de services (qui passent par le RPC), où juste envoyer de commandes RPC à n’importe quel service depuis notre PC.
  • On peut lancer un service alors qu’un service avec le même nom existe déjà, de façon transparente. Cela permet entre autre de remplacer un service “en prod” qui tourne sur le robot par un service de dev sur un PC. On a aussi des services de simulation pour faire des testes sans avoir à utiliser un robot complet.
Bref, comme tu l’as vu, on a essayé d’avoir un software sympa avec un bon compromis simplicité/performance. Je pense aussi qu’on a pas fini d’améliorer ce système, on a pas mal d’opportunités pour le rendre plus utile (plus d’introspection dans les services, meilleure visibilité sur l’état du robot, etc.) et si on s'y prend bien il pourrait peut être même réutilisé dans d'autres contextes que la coupe de robotique.

Post Reply