Portail des Équipes

Coupe de France de Robotique - Eurobot

Sommaire

Premiers points !

Voilà nous sommes fin novembre et nous avons le plaisir de réaliser nos premiers points !

Ce samedi a été consacré à l'achat de planches pour la table et ses bordures. Bien que nous ayons de quoi faire une table complète, nous n'avons fait qu'une demi table primitive, composée de deux planches légèrement bombées...

Ce soir, nous avons passé un peu de temps à initier le code pour la stratégie 2022, puis dessiné nos deux premières trajectoires. Nous mettons le plan du règlement à l'échelle 1mm : 1 px, dessinons les trajectoires et recopions les coordonnées des points des courbes de Bézier dans notre code.


2022 - premières trajectoires

C'est fait à la Rache, les contacteurs pour s'assurer que le robot est en position ne sont pas utilisés mais ça marche, au mois 3 fois sur 4 !


La vidéo est disponible en 720p ici (Ogg - 10 Mo)

Les travaux de cet été 2021 (1/2) - La supervision

Le contexte

Quand j'ai choisi de re-participer à Eurobot, nous étions à quelques jours des finales. Alors j'ai choisi de re-travailler sur notre robot précédent. Deux points me chagrinaient, le premier étant les capacités de supervision du robot.

La supervision

Ce qu'on peut faire avec une liaison série, un peu de python et de Qt.

Les servomoteurs

Chaque année, le réglage des positions des servomoteurs se fait en entrant une valeur au hasard, compilant le code et testant. Il faut une petite quinzaine d'itérations pour affiner chaque position. Alors qu'il suffit de pas grand chose pour lier une commande de la liaison série à la commande d'un servomoteur.

Donc voilà, nous définissons une trame simple, qui permet de forcer la position d'une servomoteur. La trame est la suivante :
"Sxpppp"

  • S pour Servo
  • x pour le numéro du servomoteur à pilote
  • pppp pour la position à atteindre, en hexadécimal.

Sur l'interface graphique, 6 boutons, 3 pour avancer d'un petit pas, d'un pas moyen ou d'un grand pas, 3 pour reculer. Ces boutons sont un peu rigides, alors je rajoute un curseur horizontal (QSlider) qui permet d'atteindre une position approximative très rapidement. Enfin, un champ texte affiche la position actuelle.

Un dernier bouton permet de récupérer la position actuelle de tous les servomoteurs.


Supervision - servomoteurs

La surveillance

Vient ensuite le problème du robot, très fréquent, du "mais qu'est-ce qu'il lui a pris de faire ça ?". Vous avez généralement le choix, pour comprendre ce qu'il se passe.

Soit vous banchez un débogueur sur votre robot, mais chez nous, ça ne marche pas génial. Les broches de debug sont utilisées pour autre chose, le débogueur Microchip n'aime pas trop les interruptions et rapidement, nous n'arrivons même pas à reproduire le bug avec le débogueur branché (alors que sans, c'était 100% reproductible).

Soit vous émettez un signal en fonction des états de votre programme (comme allumer une LED). C'est une solution simple, qui a le mérite de bien marcher dans des cas simples.

Avec la surveillance, le robot émet sur la liaison série toute une série de valeurs correspondant aux états du robot (position, orientation, distances des obstacles, etc...) à intervalles réguliers. Comme le robot émet un entête descriptif de ce qu'il va envoyer, nous pouvons modifier l'ordre des valeurs, en enlever ou en rajouter sans toucher au code de la supervision.

L'interface n'est pas très soignée, mais nous avons quand même deux panneaux.

Le premier affiche les valeurs actuelles :


Supervision - état actuel

Le second un graphique pour la valeur sélectionnée. Généralement en fonction du temps, mais afficher la position Y en fonction de la position X est tellement parlant que nous ne nous en sommes pas privé :


Supervision - graphique

La communication

Enfin, toujours pour aider au debug, nous renvoyons sur la liaison série ce qui transite sur la liaison I2C. Soyons clair, ce ne serait pas adapté à de gros débit de communication. Mais dans notre cas ça marche !


Supervision - communication

Les bonus

La sauvegarde

Analyser à chaud, c'est bien. Pouvoir reprendre les logs précédents pour revoir un détail qui nous aurait échapper, c'est mieux. Chaque acquisition est enregistrée et peut être rechargée.

Le Python

Le programme est développé en Python, avec PyCharm. PyCharm est puissant mais parfois un peu lent à lancer. Alors lorsque nous avons voulu lancer notre programme sans ouvrir PyCharm, nous avons rencontré deux erreurs :

$ python Supervision.py ... SyntaxError: invalid syntax

Sous Debian, notre Python est Python 2.7. Essayons avec Python3 :

$ python3 Supervision.py ... ModuleNotFoundError: No module named 'PyQt5'

Et pourtant, ça marche avec PyCharm.

Le secret réside dans les environnement virtuels. PyCharm utilise venv.

Activation $ source venv/bin/activate

Et là, un simple :
$ python3 Supervision.py
lance l'application.

Pour quitter l'environnement virtuel, utilisez la commande suivante :

Désactivation $ desactivate

Plus de détail sur les environnements virtuels pour le Python, je vous conseille cet article de Linuxfr.

Avancement mi-novembre 2021

Quoi de neuf ?

La reproduction du terrain

Nous ne ferons pas un terrain complet. Pas avant plusieurs mois en tout cas. Mais nous réalisons l'angle qui accueille la statuette ainsi que les échantillons qui se trouvent dessus.


Angle du terrain 2022

Le robot

Nous avons dépouillé notre ancien robot, il ne lui restait que la planche de base, les moteurs, le gyroscope et la carte électronique.


Robot tout nu

Nous nous faisons un petit plaisir, nous construisons un support mobile pour la carte électronique. La carte sera en position verticale pour un match, mais son support peut se mettre en position horizontale pour faciliter les branchements et les mesures.


Robot 2022 - carte électronique pliée

Robot 2022 - carte électronique dépliée

L'inconvénient, c'est que nous devons refaire tous nos câbles en plus longs. Et ça, ça va nous occuper un petit moment.


Robot 2022 - support carte électronique

Côté actionneurs, nous en avons commencés deux. Le premier pour attraper la statuette, le second pour déposer la réplique.

Actionneur de la statuette

Nous comptons sur du velcro pour attraper la statuette. Notre bras n'utilisera qu'un servomoteur pour attraper et déposer la statuette. Le bras est construit, mais il faut encore le fixer sur le robot.


Actionneur de la statuette

Actionneur de la réplique

Pour l'instant, nous n'avons mis en place que les deux contacteurs qui nous indiqueront le bon positionnement du robot. Avec deux contacteurs, si le robot n'est pas bien positionné, il est possible de savoir de quel côté il doit se décaler. Nous avions utilisé un système similaire en 2012 pour accoster les totems qui contenaient les lingots.

Et la suite ?

Tout d'abord, nous devons finir nos câbles puis l'actionneur de la réplique. Ce sera probablement l'occasion pour le robot de faire quelques tours de roues, pour s'assurer que nous arrivons à déposer la réplique.

Ensuite, il faudra positionner l'actionneur de la statuette.

Ce qu'on se garde pour plus tard

Et oui, nous sommes loin d'avoir fini. Voici, en vrac, ce qu'il nous faudra réaliser :

  • Le positionnement des capteurs d'évitement.
  • la réalisation de la vitrine
  • le mat balise
  • le bras latéral pour retourner les carrés de fouille
  • tester, tester, et ... tester !

Bref, ce n'est pas fini, loin de là !

Eurobot 2022

Règlement officiel

Ça y est, le règlement officiel est sorti ! Vous pouvez le trouver sur le site de coupederobotique.fr, plus précisément ici.

Le forum pour discuter du règlement, voir les questions posées sur la version bêta est là.

Enfin, le forum pour discuter de la compétitions, présenter l'avancement des robots et autres se trouve ici.

Portail des équipes

Nous relançons le portail des équipes, disponible ici : http://poivron-robotique.fr/planet. Vous souhaitez apparaitre sur le portail, envoyez-nous un message !

Notre participation

De notre côte, même si tout n'est pas réglé, nous devrions participer à l'édition de cette année.

Nous avons reproduit quelques éléments de jeux et un petit bout de terrain.

Nous avons défini notre stratégie, avec un seul robot pour l'instant. Nous nous concentrons sur les actions simples et ferons un second robot si c'est trop facile (mais nous en doutons fortement).

Pour l'instant, notre stratégie est la suivante :

  1. Faire tomber les deux échantillons de l'abri de chantier et les pousser sous l'abri
  2. Prendre la statuette
  3. Déposer la réplique
  4. Déposer la statuette dans la vitrine
  5. Découvrir les carrés de fouille
  6. Rentrer dans la zone de départ

Si nous tenons notre contrat, nous devrions faire un bon paquet de point, mais clairement sans viser les premières places.

Le Wiki

Enfin, Planète Sciences/Eurobot a tenté de mettre un wiki à disposition des équipes. Nous avons apporté notre part et continuerons probablement d'y contribuer un peu au cours de l'année. Vous le trouverez à cette adresse : https://www.eurobot.org/wiki/fr/home. N'hésitez pas à le compléter !

How we reached our current architecture

Background & History

In order to understand the current design, I think one must understand where we are coming from. The club experimented with different platforms over the years, and every time outgrew those. Every time we switch to a new platform, we must throw out everything and start again from scratch. To avoid this waste, the “obvious” solution is to design a system that we will never outgrow, but such a design is unlikely to succeed as technology and requirements always evolve.

When I joined the club (2008) it was using a board with a single microcontroller, a fixed number of I/Os and channels for 3 motors with position feedback and PID control. The architecture was quite rigid, but the motherboard allowed a bit of customization of the input/output, and when we needed functionality that could not be implemented on this platform, we built dedicated boards with small microcontrollers on them, communicating via ad-hoc protocols, generally over UART or GPIOs. This approach served us well for several years, but started to show its age (the PID controllers were 20 year old when we moved away!).

In 2010, we decided to switch to another system. In particular, we wanted to do polar control of the wheelbase (rather than per-wheel), which the existing system could not do as it relied on dedicated hardware for PID control. We also wanted to experiment with onboarding a computer in the robot for computer vision. The result was made of two parts: a custom board and a Linux computer. The board had an ATMega as its core. It could control three motors like the old board, but the PID was done in software, meaning we could do polar control. The Linux computer was communicating with the board over USB, sending it orders such as “go to this point”. The system worked well enough, but was not very modular: adding functionality for additional actuators required a lot of code changes. We were also not too convinced by the platform the computer was using (URBI, a now-dead programming language for robots).

In 2011, we built our first Debra, the name of our robots with SCARA arms. This was a massive increase in the number of motors we had to control: we went from 2 PIDs to 12, and they needed coordination. It was clear that our current approach did not scale to those requirements. The ATmega had to go, and was only used for one year. Realizing this was wasteful, we committed to a more modular solution, which we could adapt to each year’s requirements. We turned to FPGAs, as they provide the ultimate modularity: you can change what the hardware is doing simply by reflashing the FPGA! We still had a computer onboard for tasks like computer vision, but it never really got used.

The FPGA setup served us well, but it was a nightmare to develop for. FPGAs are programmed very differently from conventional platforms. To make things worse, we have to use tools provided by the FPGA vendors, which are pretty bad, non standard and had some bugs. We stuck with it for a few years, fixing bugs and in 2014, this platform had us win the Swiss championships! However, we needed a change for several reasons:

  • The FPGAs were too complicated to program1,
  • The platform was pretty expensive, meaning we only had three setups (two in robots, and one redundant). Developing outside of the robots was impossible.
  • The bugs of the platform made it challenging for reliability,
  • The boards were quite big, which made it mechanically challenging to integrate.

We started brainstorming for a new solution in 2015, and this document presents the current architecture, which is what we have running for now.

Objective

Provide a platform that can be extended indefinitely to match the requirements of the robot. Give developers flexibility in choosing the best platform for the subsystem they are working on.

Requirements

  • Can drive more than 12 DC motors, since this is what we are replacing
  • Compact
  • Real time requirements
  • Can be used for “10 years” because rebuilding PCBs cost time and money.

Overview

Unlike previous systems, which were relatively centralized, the new architecture is made of many systems collaborating to control the robots. While in the past our robot typically had 2-3 microcontrollers, the new design has ~15!

Linking each microcontroller to each other via a dedicated UART link like we used to do in the past would be infeasible just by the number of wires and UART interfaces required. Instead, this design uses a field bus shared by all the nodes: a single physical interface is enough for each node to talk to every other node.

Each microcontroller exposes a very high interface to the rest of the robot. This is very important to make the system easy to test and reason about: compare telling a board “turn on pump #3” to “please set register #4 to 0xfe”.

Detailed design

The robot’s network is based on the CAN (Controller Area Network) protocol. CAN was originally designed for the automotive industry, where it is used to communicate between different parts of an engine and/or a car’s interior. It was designed for robustness (safety critical systems depend on it), electrical resilience (a car emits a lot of electrical noise) as well as wiring simplicity (wires weigh a lot). CAN transmit data over a differential pair, with the two signals named CANH and CANL.

By itself, CAN is a very simple protocol: it can transmit messages up to 8 bytes, which are tagged with a 29-bit identifier. Any node on the bus can send and all the nodes will receive all the messages. Therefore, it is common to add higher level protocols on top of CAN, which provide longer messages, addressing and message serialization2. We chose UAVCAN for this, which is an emerging standard aimed at small drones and robots, an application close to ours. It proposes a nice set of features, and has a good quality reference implementation. Note that UAVCAN has two versions: the one we use, v0, is deprecated, and v1, currently in development.

CAN, like most low-level protocols, does not guarantee delivery of messages: messages can be lost, for example if two different nodes send a message at the same time. This lead to the introduction of two different message types in UAVCAN: broadcast and service calls. The first one is simply a node sending a message to everyone on the network, without expecting a response or a way to find if a message was dropped. It is well suited for things like sensors or a motor’s current position, where it does not matter if we drop a single message. The second one is used when we want to have a response, or we want to know if the message was dropped. We use it mostly for setting parameters on board (PID gains, board modes and so on). This mode does not guarantee message delivery, but triggers an error if a response was not received in a given time.

To simplify development, UAVCAN can automatically generate code to switch between human-readable formats and representation on the CAN bus. Messages are described in a special language (example), and C++ or Python code is generated from that.

When working with a large number of devices, software update becomes a challenge. We used to do that by connecting a JTAG probe to the target microcontroller, but this would become intractable with so many microcontrollers, some of which were not reachable without disassembly. We decided to develop an in-band method of programming, which uses the same CAN network that we used in normal operation to download updates. When powering up the robot, boards wait for software update messages for 10 seconds before proceeding to normal operations. The detailed design can be found in cvra/can-bootloader.

Available modules

The first type of board we designed, and still the most commonly used one is the motor control board (2015). It allows the control of a single DC motor, with control loops for controlling in torque, speed or position. It has inputs for two different quadrature encoders for position sensing. Originally we wanted to be able to use it as an alternative means of controlling RC servos, but this turned out to be unnecessary. It was also re-used with a different firmware for our opponent detection beacon. The API of the board is simple: you send it a position (or speed, or torque), and it will go there.

The sensor board (2016) contains three optical sensors: a laser range finder (10 cm range), a color sensor and an ambient light sensor. It can be used for object detection around the robot, for example to check that a game object was correctly handled. It simply publishes periodic readings on the CAN bus, for anyone interested.

The IO board (2016) has no definite purpose: by default it is simply 4 digital input / output + 4 PWMs. The original goal was to control a few industrial sensors or custom electronics. We used it for many different tasks over the years by reprogramming them to add features. Two generations of this board exist, with the only difference being the size of the module.

The UWB beacon (2017) is still a work in progress. The long term goal is to provide a system to find the position of all robots on the playing field by measuring distances with radio (similar to how GPS receivers work). Antoine is working on them at the moment.

The actuator board (2020) is the latest addition to the list (2020). Its goal is to be able to control a small actuator made with RC servos, vacuum pumps and valves. It has vacuum sensors to check if an object was picked, and has a digital input.

Our Pi shield (2020) allows one to connect a Raspberry Pi to the bus and to send and receive UAVCAN messages from Linux. It also allows us to connect a touchscreen placed on the front of the robot.

We have a custom USB to CAN adapter (2015), which has the correct connectors for our robot. It can also optionally power on the bus (only for a few devices). It is automatically recognized, and can be set up to be used as a native CAN interface on Linux. Two generations exist: micro-USB and USB-C. If you are working on the club’s projects, you should probably ask to have one.

Alternatives considered

When we started looking for what was used as a field bus, we identified big contenders based on the bandwidth and general availability: I2C3, CAN, and Ethernet-based platforms (IP, ModBus, Ethercat). We removed I2C as it operates in a master-slave configuration: we wanted the ability for any board to send messages on the bus. Ethernet-based solutions were the most advanced ones, but required a lot of circuitry while CAN only required compact single-chip transceivers.

Originally we had a split master design, where the realtime parts of the master firmware would be running on a large STM32, while the non-realtime parts would be written in Python on a PC. The two parts would communicate over Ethernet. This was extremely complicated and unreliable, so in 2016 we switched to an architecture with only one master firmware running on STM32. It served us well, but we were spending a lot of time dealing with low level work, as well as optimizing to not use too much RAM. This led us to switching back the code to run on Linux again, but this time including the realtime part as well, with everything written in C++. You can read more about this switch there.

We experimented with ROS for one year in 2016, using an architecture pretty similar to the one presented here. The biggest downside of this approach is that the build tools for ROS are not very nice to use and don’t support cross compilation, which makes building software really slow. The ROS navigation stack was very CPU hungry, which did not help with our limited CPU resources. It could certainly be interesting to come back to it now that ROS2 is available. You can read more about this approach here.

Future work

Communication between robots

The work presented in this article solves the issue of communicating inside the robot pretty well. However, the rules are moving more and more in the direction of requiring collaboration between the two robots. In order to do that in an efficient and safe manner, the two robots need to be able to communicate with each other.

Several technologies can be used here. Since the two master firmwares are running on Linux, we can use the normal networking stack to communicate between the two, either using Wifi, or by reprogramming the UWB boards. Theoretically, we could even use the two transports in order to provide a redundant link, however further study is needed.

The higher level protocol is also still an open question. Should we use UDP, in order to have real time behavior, or TCP to have reliable transmission? Do we handle errors at the application layer? Do we have something in-between for reliable ordering of messages (à la Paxos)?

  1. The software landscape for FPGA has since changed, and it might be easier now thanks to projects like Yosys and Chisel

  2. Serialization is the process of taking a high level structure and translating it to bits on the wire. 

  3. I2C is typically not considered a fieldbus and was never designed for inter-board communication. However it is commonly used in Eurobot due to its relative simplicity. 

Coupe Ile de France de Robotique 2021

Ce week end a eu lieu a l’Electrolab une coupe amicale de robotique. Nous avons pu faire rejouer notre robot et se tester face à 9 autres équipes. Le niveau de cette compétition été assez relevé avec plusieurs équipes réalisant plus de 100 points.

Nous avons perdu en 1/4 de finale contre les gagnants de la coupe : RCVA

Merci a tous pour ces bons moments.

Video des matchs :

Initiation aux médias de la vulgarisation

Initiation aux média de la vulgarisation

Radio, Vidéo et bien d’autres !

Vous passez votre temps sur Youtube à regarder des vidéos de vulgarisation ? Pourquoi pas vous lancer ?

Participez à notre initiation aux médias de la vulgarisation, en vidéo ou en radio, avec le labo des savoirs.

Prochain Atelier

Le prochain atelier découverte est organisé le :

Mercredi 29 Septembre
Salle PIXA (BU Sciences)
Accès libre de 12h30 à 14h

Inscription sous le liens ci-dessous :

Atelier cosplay

Atelier Cosplay

Un temps pour se familiariser avec les différentes techniques impliquées dans le cosplay au sein d’un même projet.

Le cosplay ?

Le cosplay, c’est la création du costume d’un personnage fictif, issu de la pop culture, impliquant différentes techniques de l’artisanat ou des travaux manuels.

Derrière la création du costume, le cosplay comporte une part d’incarnation du personnage réalisé, et le port avec fierté de sa réalisation.

La démarche du cosplay est donc une création complète, tant physique qu’intellectuelle d’un personnage de fiction.

Techniques et méthodes du cosplay

La pratique du cosplay implique de nombreuses techniques issues des artisanats traditionnels et des pratiques des travaux manuels.

  • La couture et les arts textiles
  • La coiffure et la chapellerie
  • Le modélisme et le craft
  • La peinture et les art décoratifs
  • Électronique
  • etc.

Compétences impliquées

Plannification

La création d’un cosplay est un projet complet qui implique des compétences de planification. Chacun à sa façon de faire, découvrez et développez votre propre méthode !

Artisanat

La richesse des personnages de fiction amène à pratiquer une grande diversité de techniques. La pratique du cosplay est un apprentissage constant de techniques.

Acting

L’interprétation des personnages de fiction, dont le port du costume, amène à mobiliser des compétence dans les art dramatiques propres à incarner le personnage choisi.

Média

La pratique du cosplay implique une part de médiation, qui mobilise des compétences en photographie, en vidéo et en community management sur les réseaux sociaux.

Participez à notre atelier collectif

L’association organise un atelier de pratique collective pour découvir le cosplay, ou travailler sur vos réalisation en compagnie de cosplayeurs plus expérimentés :

Tous les mercredi de 17h à 19h30
Local de l’association (bat 13)

N’hésitez pas à passer les rencontrer !

Voir la vie en bleu avec le cyanotype

Atelier Cyanotype

Atelier de découverte

Procédé historique de tirage photographique, le cyanotype joue avec la lumière et le bleu de prusse pour vous faire voir la vie en bleu.
Venez le découvrir !

Le cyanotype ?

Le cyanotype est un procédé photographique monochrome utilisant le bleu de Prusse. Cette technique a été mise au point en 1842 par le scientifique et astronome anglais John Herschel.

Prochain Atelier

Le prochain atelier cyanotype est organisé le :

Pas encore prévu !
Mais peut-être bientôt

Documenter ses cartes électroniques

J'ai eu l'occasion de réveiller un vieux projet et de me heurter à un certain nombre de problèmes liés à l'obsolescence. J'en détaillerai probablement une partie prochainement.

Quand on ressort une vieille carte électronique, arrive rapidement la question du brochage des différents connecteurs. Je viens justement de trouver Pinion. C'est un outil qui permet de documenter les carte électroniques avec un rendu web impressionnant.

Je détaille l'utilisation de Pinion dans un article dédié que vous trouverez ici.

En attendant, voici le résultat obtenu après une petite journée de prise en main.