Ceci n’est pas un problème d’asservissement.

6 mars 2023

Sur la vidéo suivante, le robot ne se comporte pas comme demandé. Nous verrons pourquoi nous considérons que ceci n’est pas un problème d’asservissement.

Avance et tourne ! (480p - 5 Mo | 720p - 10 Mo).

Ce que l’on voit sur la vidéo, c’est que la rotation du robot sur lui-même n’est pas fluide. Elle devrait progresser en même temps que le mouvement.
Pour comprendre ce qui se passe, notre premier réflexe est de comparer la rotation du robot avec sa consigne de rotation.

Orientation du robot et sa consigne

En zoomant sur la courbe, ça ressemble vraiment à un asservissement mal réglé (à un ou deux détails près).

Détail de l’orientation

Dans la première partie, l’orientation suit bien sa consigne puis elle décroche et dépasse sa consigne lorsqu’elle est proche de sa valeur finale. C’est assez semblable au comportement d’un correcteur intégrale mal réglé.

Notre premier réflexe a été d’ouvrir le code de notre asservissement en rotation pour aller modifier le gain de notre correcteur intégral sur notre orientation. Et là, nous réalisons que nous n’avons jamais mis de gain intégral sur notre correcteur en orientation. Le seul gain intégral que nous ayons est sur l’asservissement des moteurs. Nous observons alors le comportement des moteurs

Vitesse moteur A et sa consigne

Vitesse moteur B et sa consigne

Vitesse moteur C et sa consigne

Sur le dernier graphique, celui du moteur C, le moteur n’atteint pas sa consigne à plusieurs reprises dans le cycle. Plus en détail, il semble décrocher quand la consigne dépasse les 500 mm/s alors que la consigne va grimper jusqu’à 1 500 mm/s (probablement sous l’influence du terme intégral).

Ceci arrive lorsque le robot atteint 60° d’orientation. À ce moment-là, tandis que toutes les roues assurent la rotation du robot, la roue C commence à être la seule à faire avancer le robot (selon le vecteur vert sur le schéma) alors que les deux autres roues, dans leur rôle de faire tourner le robot, participent à diminuer sa vitesse.

Projetez les vitesses sur l’axe Y, vous verrez !

Robot ayant tourné de 60°

Nous demandons au robot une consigne qu’il ne peut pas atteindre, car ses moteurs ne sont pas assez puissants.

Si cette théorie est bonne, alors le robot devrait pouvoir réaliser la même trajectoire, mais moins vite.

Ce qui se voit sur la vidéo et les graphiques ci-dessous, où la vitesse maximale a été diminuée de 1 000 mm/s à 300 mm/s.

Avance et tourne ! (3 Mo).

Tant pour l’orientation qui suit sa consigne :

Orientation du robot et sa consigne (lent)

Que pour les moteurs :

Ceci n’est donc pas un problème d’asservissement.

C’est un problème de consigne ! La consigne doit être atteignable. C’est une notion qui est importante, car nous aurions pu perdre beaucoup de temps à corriger nos gains sans obtenir de résultats. De là à considérer que si la consigne (ou l’erreur) sort de certaines valeurs il faut couper l’asservissement et sortir en erreur, il n’y a qu’un pas. Ce n’est pas notre priorité pour l’instant, car il faut ensuite gérer le cas où l’asservissement se "bloque", mais c’est une piste pour améliorer la fiabilité du robot.

Bien sûr, le doute peut persister, est-ce qu’un asservissement un peu plus violent nous permettrait de réaliser le même mouvement plus vite ? Probablement, mais nous pensons que l’effet serait plutôt marginal.

Note du 8/3/2023 : Si l’article s’attarde sur le problème de vitesse des moteurs, c’est parce que la vitesse est la donnée la plus facilement observable. En réalité, le problème se situe au niveau du couple moteur disponible à une certaine vitesse, donc à un problème de puissance des moteurs !

0 commentaire

Contacteurs et détection de l’adversaire

23 février 2023

 Inscription à la Coupe de France

Cette année, nous participons à la coupe de France de Robotique dans la catégorie "Legends" nouvellement créée. Une des conditions est de fournir un projet scientifique et un plan de communication. Voici le nôtre.

 Aspiration des balles

Le dernier prototype nous avait donné satisfaction, voici la vidéo.

Aspiration des balles avec le prototype (1 Mo).

Voici quelques photos de la construction de la version finale. Nous l’avons bien montée une fois sur le robot mais démontée presque aussi tôt pour s’occuper des contacteurs.

Aspiration cerises : démontée

Aspiration cerises : vue de face

Une autre raison pour laquelle nous avons démonté le système, c’est que lors de nos essais la turbine était maintenue à la main et que nous l’avons bousillée. Attention, les pâles de turbines sont vraiment dangereuses pour les yeux !

Turbine HS

Nous avons reçu les nouvelles turbines, mais nous ne les avons pas encore installées.

 Installation des contacteurs

Les contraintes de place sont assez fortes au niveau des contacteurs. Surtout que ceux-ci doivent être protégés car nous comptons sur eux pour longer des murs. Nous avons finalement un modèle qui nous satisfait. Voici le prototype :

Contacteur désassemblé

Contacteur assemblé

Surface en PTFE pour les frottements

L’intégration nous a quand même demandé un peu de temps. Mais les contacteurs sont maintenant câblés et raccordés à la carte électronique.

Contacteur "fin de course"

Contacteurs pour longer les murs

 Détection de l’adversaire

Nous avons fini la conception de nos cartes, commandé et reçu nos cartes de détection de l’adversaire.

Nous les avons aussi partiellement soudées. Nous avons commandé les mauvaises référence de LED, nous attendons la nouvelle commande. Nous n’avons pas encore soudé tous les capteurs. Nous attendons de valider un minimum le code avant de tous les souder.

Détection - dessus

Détection - dessous

Les quelques lignes de code montrent que la carte se comporte comme prévu, avec la possibilité de désactiver les capteurs un par un.

 Déplacement

Nous arrivons enfin à finaliser un mouvement qui nous tenait à cœur : avancer droit en faisant tourner le robot sur lui-même.
C’est probablement l’un des mouvements le plus complexe que le robot aura à faire et donc un bon moyen de valider notre architecture.

Avance et tourne ! (3 Mo).

Bref, la joie du robot holonome !

 Avancement

Du côté de nos tâches :

• Reprendre les tests avec la turbine
  • Aspiration : nous avons enfin un prototype concluant
  • Soufflage : abandon, nous allons tenter de propulser les cerises avec des roues.
• Placer des contacteurs sur le robot pour détecter les bordures : Fait !
• Longer les bordures
• Transformer la base roulante en robot :
  • Installer le mat balise
  • Intégrer la turbine : réalisation à 90%
• Améliorer la détection de l’adversaire
  • Électronique : carte reçue et partiellement soudée et testée
  • Programmation : sélection des capteurs opérationnelle

0 commentaire

Carte Holonome 2023 - La doc !

13 novembre 2022

Après plusieurs essais, nous avons enfin la documentation de notre carte.

La bibliothèque Pinion, que nous utilisons, ne se porte pas très bien. Les différentes briques logicielles semblent avoir évolué séparément et la dernière version Pinion ne semble pas compatible avec les dernières versions de ses dépendances pcbdraw et pcbnewTransition.

À l’heure actuelle, la dernière version livrée est la 0.2.0. Pour l’utiliser, il faut installer manuellement pcbdraw en version 0.8.0 et pcbnewTransition en version 0.1.0 :

pip3 install pinion==0.2.0
pip3 install pcbdraw==0.8.0
pip3 install pcbnewTransition==0.1.0

Pour construire cette visualisation de la carte nous avons suivi notre article sauf que nous avons modifié cette ligne dans le fichier template.py :

template.py # p.insert(0, "name", f"{footprint.GetReference()}.{pad.GetName()}") p.insert(0, "name", f"{pad.GetNetname()}")

Ainsi, la configuration générée lie les broches du même signal entre elles.

0 commentaire

Journal - 3 novembre 2022 - Aspiration et Gyroscope

3 novembre 2022

Deux semaines qui n’ont pas été des plus fructueuses, mais nous avons quand même quelques avancées à présenter...

 Le gyroscope et le Rpi Pico

Nous sommes passés à l’ADXRS453, censé être plus stable. Nous avons eu du mal à obtenir nos premières valeurs et les premières mesures n’ont pas montré de différences significatives avec notre L3DG20H.

En statique, la vitesse renvoyée varie de +/- 0,01°/s sur les deux modèles.

L’ADXRS453 a quand même plusieurs points pour lui, notamment une compensation de la température intégrée. Les résultats en intégrant la vitesse sur 90s sont entre corrects et bons.

 Côté mécanique - Aspiration des balles

C’est l’aspiration des balles qui nous fait transpirer en ce moment. Notre premier prototype en papier et carton montrait que la turbine avait une puissance d’aspiration suffisante pour attraper les balles.

Notre second prototype avait pour mission de :

1. Montrer la faisabilité technique d’utiliser du papier mâché
2. Valider les grands principes de fonctionnement : avoir un tuyau large pour limiter les pertes de charge du flux d’air et utiliser un guide à l’intérieur du "tuyau" pour dévier les balles du flux initial.

Réalisé en papier mâché, il a fallu le découper dans la longueur pour extraire le "moyeu". Notons l’astuce du papier d’aluminium pour éviter que le papier mâché colle à la forme !

Ce qui permet d’installer les guides, ici en fil de cuivre, pour dévier la balle du flux d’air.

En recollant les deux morceaux, nous obtenons notre pièce terminée.

Les résultats ne valident pas intégralement la solution. Le système attrape les balles/cerises mais dès que le tuyau s’élargit, l’aspiration n’est pas suffisante pour continuer de soulever les balles, de les projeter contre le guide (qui est au-dessus des balles) et les sortir du flux. Par contre, l’utilisation du papier mâché donne des résultats satisfaisants. Il se découpe et recolle bien ! Ce qui nous incite à réaliser une nouvelle pièce qui pourrait être la pièce finale. Il sera possible de la couper et recoller sans tout refaire de zéro.

Nous partons sur un conduit fin 26mm de diamètre, sur une séparation des balles du flux d’air sur une section relativement horizontale avec le flux d’air allant vers le haut, la balle vers le bas. Nous agrandissons aussi la section à cet endroit pour que la balle ne soit plus aspirée par le flux d’air. Et bien sûr, nous installerons le guide en fil de cuivre. Voilà le plan !

 Le chant du signe de Capsicum

Capsicum, notre robot 2022 fera sa - probablement - dernière sortie dans 2 semaines. Nous avons l’occasion de présenter nos activités de robotique. Si vous passez dans le coin, venez nous retrouver à la médiathèque de Riom, le samedi 19 novembre 2022.

Est-ce que ceci nous motivera pour écrire une page de présentation pour Capsicum ? Peut-être...

0 commentaire

Règlement 2023 et notre programme

16 septembre 2022

Le brouillon du règlement de la coupe est disponible, sur le site de la coupe de France de robotique. Cela fait donc une semaine que nous réfléchissons activement au règlement.

C’est un règlement à l’opposée de celui de l’an dernier, avec une table presque sans obstacle qui incite à avoir des robots qui se déplace bien, voire très bien sur le terrain !

Alors, en attendant la version finale du règlement - la FAQ peut vous indiquer dans quel sens évolue le règlement - nous ébauchons nos robots.

Cette année nous sommes très tentés d’avoir deux robots. Le premier sera basé sur notre architecture de 2014 et sera chargé de marquer les points avec les gâteaux. Le second robot sera bien différent du premier et s’occupera des cerises. Voici ce que nous avons en tête avec les principales étapes du projet.

 Robot des gâteaux

Basé sur le robot historique, nous réutiliserons les roues, les moteurs, le gyroscope et notre magnifique carte électronique maison. Il embarquera les 10 cerises du départ, devra pousser et tirer les gâteaux dans les assiettes et leur déposer une cerise dessus. Voici notre programme (pas forcément dans l’ordre) :

• Programmation : gérer les accélérations et décélération au niveau des trajectoires
• Programmation : Arrêt de l’asservissement en cas d’erreur trop grande
• Mécanique : actionneur pour prendre une cerise du réservoir du robot et la déposer sur un gâteau
• Mécanique : refaire le châssis, diminuer le périmètre non-déployé
• Programmation - optionnel : Gérer la stratégie haut niveau avec le Raspberry Pi

 Robot des cerises

Nous partons de zéro pour ce robot. Pour la localisation, nous tentons de rester sur l’architecture qui nous a si bien réussi : des codeurs sur les moteurs. Pour le reste, l’objectif est de changer un peu des technologies utilisées depuis 2014 sur nos robots. Ce sera donc un robot holonome, d’un diamètre modeste (nous visons 25cm). Le cœur de l’électronique sera un Raspberry Pi Pico et pour le pilotage des moteurs, nous hésitons entre des LMD18200 ou des modules de type Pololu. Sur ce robot, notre programme est très chargé :

• Mécanique : base roulante holonome
• Mécanique : intégration de l’électronique
• Mécanique : intégration de la batterie
• Électronique : prototypage sur plaque de test pour valider les capteurs/actionneurs
• Électronique : conception de la carte
• Programmation : lecture du gyroscope à partir du RPI Pico
• Programmation : lecture des capteurs de couleur à partir du RPI Pico
• Programmation : lecture des codeurs à partir du RPI Pico
• Programmation : portage du code des servomoteurs (ou utilisation des PWM ?)
• Programmation : portage des codes de déplacement sur RPI Pico (asservissement, construction des trajectoires, accélération et décélération, arrêt sur erreur trop grande)
• Divers : système de préhension et de dépose des cerises
• Divers : système d’évitement.

 En gros

Un programme bien (trop ?) chargé. Alors nous essayons de ne pas trop traîner, nous avançons bien côté shopping. Nous espérons avoir fini de commander les composants nécessaire à la nouvelle roulante ce week-end. Ensuite, nous nous focaliserons sur le RPI Pico...

0 commentaire