Journal Un ami a la carte

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
42
26
déc.
2020

Cher journal,

Ça fait longtemps que je ne t'ai plus écrit. Je vais réparer cette absence aujourd'hui.
L'année a été compliquée pour tout le monde et je suis content de pouvoir envisager celle qui suit de manière plus sereine. Je te l'ai déjà dit, mais je ne serai plus jamais seul. Cette fois je le pense.

Comme de nombreux lecteurs, j'ai eu beaucoup de mal à ma nouvelle vie depuis mars dernier. Durant de longs mois dans mon appartement, j'étais perdu, paumé, j'errais du salon à la chambre sans savoir où aller. Je me nourrissais de crasses sans trouver la sortie. J'étais dans un état d'égarement profond, sans repère. Cette situation a duré plusieurs mois, je ne trouvais même plus la direction de la salle de bain. Je te passe les détails. Puis un jour, alors que je regardais par la fenêtre, paralysé sans espoir de sortie de ma prison j'ai eu le déclic. Pour m'en sortir, il me fallait les outils adaptés. C'est pourquoi j'ai ressorti mon Lidar RPLidar A1M8. Il me fallait une carte avec à la clé, la porte de sortie ! Effrayé à l'idée de m'éloigner de la fenêtre moi-même j'ai eu l'idée d'envoyer un ami en exploration. C'est alors que j'ai recommencé à travailler sur mon robot. Non pas Johnny 5, ni R1D1 qui ne me donne plus autant satisfaction mais R1D3 (nom de code: Agayon) !

J'avais commencé à travailler sur R1D3 dans l'ancien monde. Avec l'aide d'anciens collègues électroniciens et mécaniciens, je l'avais doté d'un châssis en bois issus d'une caisse de vin, d'engrenages véritables, de courroies de transmission et de deux belles roues de tondeuse. Il a de la gueule mon Agayon. Comme il est plus gros et plus costaud que R1D1, je mets plein de trucs dedans et ça rentre même si rien n'est optimisé.

courrois
chassis
Entrailles

  • A: R1D3 n'est pas un manchot puisqu'il fonctionne au courant continu 12V alimenté par une batterie au plomb d'UPS 7200 mAh. C'est lourd, mais ça va bien.
  • B: Arduino Mega, le cervelet de l'opération. Une liaison série interagit avec le Raspberry PI et l'autre sert aux mises à jour, au debug, etc.
  • C: Lignes d'alimentation de 12 et 5V pour les moteurs, des capteurs, des boutons, etc.
  • D: Raspberry PI4, 4Go RAM, le cerveau. Il est relié à l'Arduino par un adaptateur USB vers port série.
  • E: Des LEDs qui seront utilisées à l'avenir pour informer des états, du mode engagé etc. Elles sont fonctionnelles, mais pas encore réellement programmées.
  • F: Des Les boutons (voir ci-dessous)

Voici une vue du haut datant d'avant la mise en place du Lidar et de la caméra.
Vue du haut

Je lui donne des boutons mais on s'entend bien.

  • Lance roquette: démarrage
  • Champignon rouge: coupure de l'Arduino et des moteurs
  • Rectangulaire blanc: à l'avenir il déclenchera l'enregistrement vidéo
  • Leviers: un des deux servira probablement à lancer un mode démo, à voir

Pas mal de chemin a été fait depuis les débuts de Johnny 5. J'ai notamment pu éviter de justesse la singularité technologique, en codant sur le PI en python et puis Arduino quoi. Le problème est qu'en mode autonome, l'Agayon se déplace dans les pièces comme un Rumba en manque d'aspiration. Il a l'air un peu bourré aussi. Il se cogne parfois dans les meubles. Il a cinq capteurs ultrasons, mais il reste des angles morts et le Lidar ne l'avertit pas encore des catastrophes imminentes. Du coup, le plus simple est de le piloter à distances. Mais comme j'avais toujours aussi peur de m'égarer une fois de plus, je lui ai mis une webcam et une interface web pour le piloter via un navigateur web.

Interface web

Quand Dillo ne suffit plus, je peux le contrôler en bluetooth avec une manette de console. C'est plus réactif et c'est bien pratique pour ramener des bières.

Voilà cher journal je voulais t'écrire pour te dire qu'à partir de maintenant tout va bien aller. Le robot est sorti il y a 20 minutes, il a commencé à scanner mon appartement et j'espère pouvoir sortir très vite. Il reviendra d'un instant à l'autre avec plein de données tout va s'arranger, il va revenir. Il faut qu'il revienne !

Sa batterie est vide…

Liens

Pour ceux qui se poseraient la question, l'article ne mentionne pas R1D2. R1D2 est une abomination qui gît quelque part. Il n'était pas viable, cette monstruosité est maintenant un lointain souvenir qui sert de réserve de pièce détachées. Paix à son programme central.

  • # Barré

    Posté par  (site web personnel) . Évalué à 7. Dernière modification le 26 décembre 2020 à 18:29.

    C'est barré, ce virus atteint aussi le cerveau, visiblement. ;)

    J'avoue que j'ai un peu de mal à saisir le but du jeu, mais vu que "Un agayon désigne en wallon un objet dont l'utilité n'est pas connue ou comprise", je me sens moins con.

    Mettre un Raspberry Pi4 sur batterie, c'est osé au regard de sa consommation électrique.
    Pour un robot avec caméra, je serais parti sur un ESP32-CAM qui consomme 20 fois moins (et coûte aussi 20 fois moins cher), quitte aussi à le coupler à un Arduino si les entrées/sorties manquent (vu que la caméra en phagocyte déjà un paquet).

    N'empêche que c'est fun, et c'est bien le plus important.

    • [^] # Re: Barré

      Posté par  (site web personnel) . Évalué à 3.

      Effectivement, "Agayon" est un mot wallon qui désigne un outil, un bidule, un truc qui sert à faire quelque chose de flou. C'est hyper vague et on s'en sert de manière familière.

      Je m'étais senti limité pour effectuer les même tâches dans un Raspberry PI 2 alors quand le 4 est sorti, je me suis dis autant y aller à fond. J'utilise un boîtier avec ventilateur actif et je surveille les logs noyau à la recherche des "Under Voltage detected". Quand ils s’accumulent, ça sent mauvais et je coupe.

      J'ai lu un article sur les ESP32-CAM dans le magasine "Hackable" n°33 d'avril/mai/juin 2020 mais il me sembait limité. L'article détaillait comment faire de la détection de visage et utiliser un petit serveur web intégré. C'était fonctionnel et un super projet mais pas vraiment compatible avec mes objectifs. Comme j'ai envie d'appliquer différentes transformation avec OpenCV, de joindre le robot par XMPP, de faire du SLAM, d'expérimenter et de tester plein de choses, avoir un OS complet dans robot surdimensionné est bien pratique.

      J'espère jouer à l'avenir avec ESP32-CAM mais ce sera pour un projet plus ciblé, bien défini.

  • # direction

    Posté par  (Mastodon) . Évalué à 6.

    Je n'ai pas bien compris comment ton robot se dirige étant donné que les deux grandes roues ne semblent pas être indépendantes et les petites semblent totalement libres.

    Un peu d'explication?

    • [^] # Re: direction

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Pareil !

      Je suppose qu'une des deux roues est libre par rapport à l'axe ?

      J'ai plus qu'une balle

    • [^] # Re: direction

      Posté par  (site web personnel) . Évalué à 3.

      Il n'y a pas l'air d'avoir de roulement à billes au niveau du maintien de l'axe, il doit donc probablement être fixe, et chaque roue semble avoir un roulement au niveau de l'engrenage. Les roues sont donc indépendantes et chacune à son moteur.

      C'est pour aller tout droit que ça doit demander un réglage fin, dans ce genre de config, il y a toujours une roue qui tourne un chouia plus vite que l'autre.

      • [^] # Re: direction

        Posté par  (site web personnel) . Évalué à 5.

        C'est ça, Les deux roues sont reliées par un axes mais elles peuvent tourner librement indépendamment. Chaque grande roue est reliée à un moteur 12V par la corroi. Je fais varier la vitesse et la direction du moteur à l'aide de l'Arduino. J'ai été aidé pour cette partie par un ancien collègue mécanicien qui m'a permis d'avoir cette base solide.

        Il est vrai qu'il est compliqué d'aller tout droit, plus à cause des petites roues qui ne s’alignent pas instantanément. Malheureusement, je n'ai pas de réponse idéale compte tenu de mes contraintes de poids et de stabilité. Un système 4 roues motrices aurait été peut-être plus facile à diriger (mais pas à concevoir). Ça limite l'utilisation du SLAM qui est vite désynchronisé mais je pourrai peut-être corriger avec l'accéléromètre/magnétomètre que j'ai intégré.

        • [^] # Re: direction

          Posté par  . Évalué à 4. Dernière modification le 27 décembre 2020 à 21:42.

          Pour avoir souvent démonté les voitures télécommandées de mon fils, j'aime bien leur solution pour la direction :

          • Un moteur pour la propulsion
          • Un moteur pour la direction : les 2 roues avant sont liées par un axe pour toujours être parallèles, et un petit ressort sert à les remettre droites quand le petit moteur n'est pas actionné. Avec une butée pour limiter l'angle de rotation.

          Je n'ai aucune idée de la difficulté que ça représente sur un engin de la taille de R1D3 mais sur ces jouets je trouve ça simple et efficace.

          Je ne sais pas si je suis clair, voilà une vidéo qui montre ce dont je parle ( on voit mieux vers la 3e minute) https://www.dailymotion.com/video/x6fhp9g

          [EDIT] Et merci pour ton journal, je rêve de robotique la nuit mais n'ai toujours pas eu le temps courage de m'y mettre. Je suis fan de ces expériences DIY.

          • [^] # Re: direction

            Posté par  (Mastodon) . Évalué à 5.

            Sur ta vidéo, c'est une direction à crémaillère. En général c'est plus intelligent de la relier à un servo qu'à un moteur.

            • [^] # Re: direction

              Posté par  (site web personnel) . Évalué à 3.

              Le concept est en effet bien meilleurs que mes roues de caddies mais il faudrait un sacré servo pour assurer la rotation sans forcer. Ça fait partir des pistes à explorer.

            • [^] # Re: direction

              Posté par  . Évalué à 3. Dernière modification le 28 décembre 2020 à 17:34.

              Ouais, c'est pas faux.
              (Je n'y connais rien, rien de rien. Pas même la différence entre un moteur et un servo-moteur, enfin pas avant d'avoir lu ton commentaire puis cherché la différence. Donc j'ai vu une dynamo (appellation abusive d'après Wikipedia), un truc qui "fait tourner", donc j'ai dit "moteur"). Milles excuses.

        • [^] # Re: direction

          Posté par  (Mastodon) . Évalué à 4. Dernière modification le 28 décembre 2020 à 10:57.

          Je n'avais pas compris qu'il y avait 2 moteurs et 2 courroies.

          Ce serait plus simple et plus stable avec les deux grosses roues avant motrices supportant le max de poids et une unique roue libre sur pivot à l'arrière (quoique avant/arrière on s'en branle un peu dans le cas d'un robot).

          • [^] # Re: direction

            Posté par  (site web personnel) . Évalué à 3.

            C'est le design de R1D1. J'avais envie de changer ici et vu les dimensions du châssis (rectangle relativement large), j'avais peur qu'avec uniquement trois points, le risque de basculer soit trop important.

            • [^] # Re: direction

              Posté par  (Mastodon) . Évalué à 3.

              Sans relief ça doit être stable (au moins autant qu'une reliant robin!) tu peux imaginer mettre des patins sur les côtés (genre bloqueurs de porte) juste pour qu'il revienne en position normal s'il se penche trop.

        • [^] # Re: direction

          Posté par  . Évalué à 5.

          Ça limite l'utilisation du SLAM qui est vite désynchronisé

          Tu peux utiliser un anneau codé en code Gray (ou binaire réfléchi) à deux pistes sur chaque roue : tu pourras en déduire la vitesse exacte de rotation de chaque roue, et donc d'asservir les moteurs pour maintenir une vitesse de rotation identique sur chaque roue.

          Cf. la section sur les souris mécaniques. La page en anglais est (comme souvent) bien plus détaillée.

          Ensuite, les deux roues n'ont pas exactement le même diamètre, et donc même si elles tournent à la même vitesse, leurs vitesses linéaires vont être légèrement différentes et ton robot va dévier. Il te faudra mesurer cette déviation pour introduire un facteur correctif dans ton asservissement pour maintenir la ligne droite.

          • [^] # Re: direction

            Posté par  (site web personnel) . Évalué à 5.

            Les moteurs sont équipés d'encodeurs. L'information est déjà remontée à l'Arduino via des interruptions. Je n'en fais pas encore une utilisation optimale mais c'est déjà disponible.

            Les roues de tondeuse sont suffisamment similaires par rapport à mon besoin. Elles sont neuves et usinées à grande échelle. Le soucis n'est pas là. Le problème est que les roues libres ne s'alignent pas instantanément et lorsque le robot redémarre après avoir tourné, elles ne sont pas forcément alignées de manière parallèles et dans l'axe longitudinal. Les quelques dizaines de centimètres nécessaires pour les aligner induisent une trajectoire courbe au robot même si les roues motrices tournent de manière synchronisées.

            • [^] # Re: direction

              Posté par  . Évalué à 4.

              merci pour ton journal, je ne connaissais pas les lidar pas chère, j'en rêvais !

            • [^] # Re: direction

              Posté par  . Évalué à 7.

              Le problème est que les roues libres ne s'alignent pas instantanément […]

              OK, je vois. Du coup, pourquoi ne pas mettre des boules plutôt que des roulettes, par exemple ?

              Je suis sûr qu'on peut trouver de bien meilleurs produits dans des boutiques spécialisées dans les robots…

  • # R2D2 c'est pour quand ?

    Posté par  . Évalué à 3.

    Je vais suivre tes aventures pour savoir quand R2D2 serra en construction. :)

    Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.