R.Ian est un robot simple à fabriquer, extensible et économique. C’est en tous cas l’objectif dans la conception de ce robot. Comment s’assurer de tout cela? Je vais vous présenter dans ce billet mes solutions pour répondre à ces problèmes.
You are browsing archives for
Catégorie : électronique
Caméra Raspberry pi waterproof : présentation.
Dans le cadre de mon projet SauronPi, je développe une caméra autonome et waterproof capable de rester un moment dans la nature pour photographier ou filmer pendant de longues périodes sans intervention. Ceci est un sous-projet du projet SauronPi, pour lequel je développe des systèmes vidéo/photo basés sur le Raspberry Pi et son module caméra. L’objectif de ce billet est de vous présenter le projet et ses objectifs.
Boitier de contrôle de Rlieh, contrôleur automatique d’aquarium
Dans un précédent billet, nous avons décrit le modèle 3D du panneau de commande de Rlieh. J’ai maintenant imprimé le boîtier, et je vais vous présenter le résultat, qui me sert de boîtier de contrôle de rlieh, mon système de gestion automatique d’aquarium.
Boitier de rlieh imprimé en PLA
Le boîtier a été imprimé en PLA. Il s’agit de la façade présentée dans le précédent billet, avec trois trous pour les boutons, et un grand rectangle pour l’écran LCD.
L’écran est fixé par l’arrière, avec 4 vis, et le tout est prévu pour que l’écran soit tout juste au niveau de la façade. Le fichier scad peut toutefois être modifié pour changer cela, si l’on souhaite par exemple que l’écran dépasse pour qu’il soit au niveau d’une autre plaque. Tous les fichiers sont disponibles sur le github du projet Rlieh.
Les boutons se fixent par l’avant, avec un écrou à l’arrière. Sur la version imprimée, les trous étaient un peu juste, je les ai donc élargis, mais sur ceci à été mis à jour, et la taille des trous permet maintenant une installation facile de boutons de 16mm standards.
Écran et boutons installés sur le module de contrôle de Rlieh
Sur la photo précédente, vous pouvez voir le rendu lorsque l’écran et les boutons sont en place. Sur la droite, une carte SD et un Raspberry pi zero à titre de comparaison pour la taille.
boîtier de contrôle de Rlieh de face, en fonctionnement.
Pour connecter le tout, il suffit de brancher quatre fils pour l’écran I2C : le vcc (5v), la masse, et les broches sca et scl. Il faut deux câbles supplémentaires pour chaque bouton.
Pour l’instant, seul le bouton du haut est utilisé : il allume ou éteint l’éclairage. Toutefois, puisqu’il s’agit d’un contrôleur automatique, il n’allume pas simplement de façon instantanée et continue l’éclairage. En effet, celui ci s’allume et s’éteint automatiquement selon l’heure. L’éclairage s’allume également progressivement, comme illustré dans cette vidéo :
L’extinction est également toujours progressive.
Si l’on appuie sur le bouton alors que l’éclairage est allumé, alors l’éclairage s’allumera (progressivement), mais pour une durée (réglable) de 5 minutes, avant de s’éteindre progressivement. Dans l’autre sens, si l’éclairage est allumé, alors un appui sur le bouton l’éteindra progressivement pour 5 minutes avant de le rallumer. Ce comportement sera bientôt changé, en effet, si quelqu’un éteint l’éclairage, c’est sans doute pour avoir de l’obscurité (par exemple pour dormir). Du coup dans la prochaine version du code, l’éclairage restera éteint jusqu’au prochain cycle d’allumage programmé.
Dans mon cas, l’éclairage s’allume a 11h et s’éteint à 23h, sur une période de plusieurs minutes.
façade du module de commande de rlieh en fonction
Sur l’écran, la première ligne sert à afficher l’état des lumières (on ou off). La seconde affiche quelque chose si l’on est en train d’allumer ou d’éteindre (pendant les transitions). Ces messages sont surtout utiles pour le développement et le débogage, ils seront sans doute remplacés par autre chose plus tard.
La troisième ligne affiche la température de l’air, et la température de l’eau. Enfin, sur la dernière ligne, on affiche l’heure courante et la date.
Une version ultérieure affichera le temps restant avant le prochain allumage/la prochaine extinction, ainsi que d’autres indications utiles.
R.Ian : démo rapide (robot Arduino à 35€)
Salut à tous. Dans un précédent billet, je vous présentais R.Ian, mon nouveau projet de robot économique, simple et extensible. J’ai crée une page détaillée sur R.Ian, et maintenant, voici une petite démonstration d’un programme de base, s’exécutant sur une version encore en développement du robot.
Pour cela, j’ai tourné une petite vidéo que vous pouvez retrouver sur ma chaîne Youtube, ou consulter directement ici :
Si l’intégration de la vidéo devait ne pas fonctionner, voici le lien vers la vidéo :
Démonstration rapide d’évitement d’obstacles par R.Ian en utilisant les capteurs de contact.
A bientôt pour plus de développements!
Présentation de R.Ian : un robot économique pour apprendre à programmer.
R.Ian est mon nouveau robot, simple, économique, presque entièrement imprimé en 3D (roues et pneus inclus), pensé pour l’enseignement de la programmation, mais également pour ceux qui voudraient se lancer dans la robotique pour moins de 50€, tout en ayant une machine extensible. J’ai donc créé une page de présentation de R.Ian, et divers articles suivront sur ce robot pendant les étapes de sa création et de son évolution. Je vous invite donc à suivre ce lien pour plus de détails : R.Ian : un robot économique pour apprendre à programmer. Après la balise suite, retrouvez quelques photos du robot au moment de l’écriture de ce billet.
REA – contrôle des moteurs, PWM et choix du composant adapté
Dans le cadre du programme REA, nous développons un rover. Nous avons tout d’abord décidé du mode de déplacement du robot, avant de nous pencher sur le type de moteurs à utiliser, puis au choix des roues ou chenilles pour la propulsion. Nous disposons maintenant d’un groupe moto-propulseur, qu’il convient de s’intéresser au contrôle des moteurs pour gérer précisément les déplacements du rover. Nous nous pencherons maintenant sur cette problématique.
REA – energie, alimentation électrique : batteries pour rover
Dans le cadre du programme REA, nous développons un rover. Nous avons tout d’abord décidé du mode de déplacement du robot, avant de nous pencher sur le type de moteurs à utiliser, puis au choix des roues ou chenilles pour la propulsion. Pour que notre rover soit autonome, il nous faut une source d’énergie, et comme nous avons opté pour des moteurs électriques, il nous faut une alimentation électrique pour l’ensemble. Voyons cette problématique en nous penchant principalement sur les batteries pour rover.
REA – roues ou chenilles : transmission de la puissance
Pour notre programme REA, nous développons un Rover d’Exploration Autonome. Dans les précédents billets, nous avons discuté du mode de déplacement du robot, puis des divers types de motorisation exploitables. Maintenant que nous avons sélectionné un type de moteurs, il nous faut un moyen de transformer le mouvement de rotation de l’axe moteur en un mouvement linéaire du robot. On s’appuiera pour cela sur des roues ou chenilles, utilisées dans plusieurs configurations :
- deux roues motrices et une roue libre omnidirectionnelle;
- quatre roues motrices (ou N paires de roues motrices);
- deux roues entraînant des chenilles.
Voyons en détail ces solutions.
Deux roues motrices et une roue libre omnidirectionnelle
Robot à deux roues motrices et une roue omnidirectionnelle. cc Jiuguang Wang, Wikimedia commons
Si nous avons deux roues motrices, alors il nous faut un troisième point de contact avec le sol pour que le robot reste en équilibre. Il existe des robots capables de se contenter de deux roues, en s’équilibrant automatiquement, mais cette approche est plus complexe, et posera d’autres problèmes, sans forcément apporter grand chose à notre rover. Nous devons donc trouver un moyen d’avoir un troisième point de contact qui génère aussi peu de frottement que possible. Pour cela, nous utiliserons une roue omnidirectionnelle. Il s’agit d’une roue capable de rouler dans tous les sens sur sur le plan. Pour cela, il y a deux approches communes :
- les billes ou “ballcaster“;
- les roues sur un pivot.
Le ballcaster, ou bille
ballcaster en plastique, cc Bomazi, wikimedia commons.
Pour la première solution, on utilise une bille métallique ou en plastique enfermée dans une base ajourée dans sa partie basse. La bille ne peut s’échapper de cette base, mais est libre de tourner dans tous les sens. On fixe alors l’ensemble sur le châssis du robot, et on obtient notre troisième point de contact. Cette solution est peu coûteuse, facile à mettre en œuvre, et on trouvera une grande variété de ballcasters. En contrepartie, on aura davantage de frottement qu’avec une roue classique, et une hauteur de franchissement d’obstacle plus faible, à moins de trouver un ballcaster de très grande taille, ce qui est plus rare.
La roue sur pivot
La roue sur pivot est une roue classique, fixée sur un support rotatif, qui fait que celle ci peut tourner normalement comme une roue classique, mais également de gauche à droite facilement. On s’en servira de façon totalement passive : les roues motrices feront tourner le robot dans un sens, et la roue libre s’alignera avec le sens de déplacement du robot. On peut toutefois concevoir d’utiliser ce système avec un servomoteur pour tourner cette roue libre, et ainsi avoir une direction par ce biais plutôt que par les roues motrices. C’est une solution plutôt performante, avec peu de frottements. Cependant, il est parfois difficile de trouver de petites roues de ce genre, en dessous d’une certaine taille, on ne trouvera que des ballcasters.
Dans les deux cas, cette solution limite la capacité de franchissement d’obstacle du rover en fonction de la taille de cette roue omnidirectionnelle. Plus elle est petite, plus on sera arrêtés par de petits obstacles. Pour un sol relativement lisse, c’est donc une bonne solution, en milieu accidenté, on sera en revanche plus limités.
Quatre roues motrices (ou 2N roues motrices)
robot K10 – image NASA
Pour cette approche, nous aurons 4 roues motrices (ou plus), donc chacune avec un moteur. Cette solution fournira un couple plus important, en contrepartie d’une consommation supérieure. On aura également une bonne capacité de franchissement, avec potentiellement la possibilité de franchir des obstacles plus grands que les roues, si la garde au sol est assez importante. On réduit le risque d’être embourbé, ensablé, ou bloqué à cause d’une roue dans le vide.
Les points négatifs sont qu’il faut 4 moteurs, qui consommeront davantage (en théorie!), et qu’il faudra synchroniser les moteurs pour des performances optimales. Petit point sur la consommation toutefois. Si l’on prend un robot d’une masse donnée équipé de deux moteurs. Les moteurs devront chacun fournir un couple de X g/cm pour faire avancer le robot. Pour toutes autres choses égales par ailleurs, si l’on passe à 4 roues motrices, chaque moteur devra fournir X/2 g/cm de couple pour faire avancer le robot de façon identique. De ce fait on a plus de moteurs, mais chacun sera moins sollicité, donc consommera moins.
En pratique, on aura des pertes, donc il est difficile de donner une règle générale. On peut cependant s’attendre à ce qu’à priori, 4 moteurs consomment un peu plus que 2 sur un robot , mais pas forcément le double, à moins que tous les moteurs ne soient poussés au maximum de leurs capacités.
3 générations de rovers martiens à 6 roues. Domaine public (source Nasa)
Il est à noter qu’on peut utiliser 6, 8 ou 2N roues motrices si on le souhaite. Tous les rovers envoyés sur Mars par la NASA comportent 6 roues (sojourner, spirit et oportunity, et curiosity)
.
Le premier rover à rouler sur un autre astre que la terre : lunokhod
Le Lunokhod 3 de profil (domaine public)
Le premier robot de l’histoire de l’humanité à se déplacer à la surface d’un autre corps céleste fut le rover Lunokhod,ou le marcheur lunaire, en 1970, ouvrant la voie à l’exploration spatiale robotique. Des chercheurs de l’équipe de Sergueï Korolev, au cœur du programme spatial russe, furent par la suite (après le changement de régime russe en 1989) contactés et recrutés pour le développement du programme de rovers de la NASA. Ces technologies sont donc bien plus anciennes que ce que l’on imagine!
Les Lunokhod avaient quand à eux 8 roues.
Deux roues entraînant une chenille
.jpg)
Robot GROVER, en Islande – image NASA
Une autre solution est d’utiliser des chenilles. Celles ci possèdent en effet de nombreux avantages, avec par exemple une très grande surface de contact avec le sol. Il en découle une excellente adhérence, et une faible pression par unité de surface sur le sol.
Cette technologie réduit donc le risque d’enlisement ou d’ensablement. Du fait de son excellente adhérence, elle permet en outre d’aborder des pentes importantes, pourvu que les moteurs fournissent la puissance nécessaire. Enfin, cette solution permet un franchissement d’obstacle excellent, pouvant dépasser la hauteur de l’engin. Conclusions sur la transmission de la puissance
En effet, si les chenilles dépassent de l’avant du rover, elles pourront agripper l’obstacle, et l’avant se soulèvera pour le franchir. Si les chenilles sont aussi longues que le rover, il n’y aura pas de “zone morte” au milieu. On ne pourra donc pas se retrouver bloqué sur un obstacle entre deux jeux de roues. En revanche, la chenille sera aussi solide que le plus faible de ses maillons. Si la chenille casse, alors il y a peu de chances que le rover puisse se déplacer. Pour de longues missions, il conviendra de choisir des chenilles solides. La seconde contrepartie, c’est que les chenilles génèrent plus de résistance au mouvement, et donc une consommation énergétique supérieure. Selon leur taille et leur qualité, on trouvera diverses gammes de prix pour ces chenilles.
Malgré ces petits inconvénients, les chenilles restent une solution très intéressante, et simple à mettre en œuvre.
Il est à noter que l’on peut très bien utiliser 4 roues motrices entraînant les chenilles, pourvu qu’on synchronise les roues de chaque chenille. C’est en effet un bon moyen d’augmenter le couple disponible, et ainsi la capacité de franchissement du rover. Du fait de la très grande surface de contact entre le sol et la chenille, ce système bénéficiera d’autant plus efficacement de la puissance apportée par des paires de moteurs supplémentaires.
Conclusions sur la transmission de la puissance : roues ou chenilles ?
Dans le contexte d’un rover devant affronter un terrain accidenté, la solution la moins à même de franchir les obstacles sera celle des deux roues motrices avec une roue omnidirectionnelle. Toutefois, puisque la gestion des moteurs et l’algorithme de conduite seront identique à celui des deux roues entraînant des chenilles, et très proches de la version 4 roues motrices (ou plus), nous pourrons utiliser ce système pour des prototypes, ou pour des missions en terrain relativement lisse. On pourra toutefois utiliser deux roues libres non omnidirectionnelles à la place d’une roue omnidirectionnelle, et cela nous permettra une meilleure capacité de franchissement, et une meilleure stabilité, au prix d’un peu plus de frottement, et donc d’une efficacité énergétique plus faible. Cette configuration peut en outre facilement être convertie en une configuration à chenilles, et vice-versa.
Les autres solutions sont toutes deux très intéressantes, la solution des 2N roues motrices étant plus coûteuse en moteurs et en énergie (potentiellement), mais très efficace. Sur un terrain très accidenté ou difficile, la solution la plus efficace sera celle des chenilles. Sur un terrain moins difficile, les 2N roues motrices peuvent fournir une meilleure efficacité énergétique, une vitesse de pointe plus élevée, tout en conservant une bonne capacité de franchissement, mais pour un coût plus élevés, non seulement pour les moteurs, mais aussi pour les capteurs nécessaires pour chaque moteur.
Dans le contexte d’un petit rover, afin de maintenir des coûts acceptables, et une bonne versatilité de l’ensemble, le système final embarquera probablement des chenilles entraînées par deux moteurs.
Maintenant que nous avons déterminé l’architecture globale du système de propulsion du rover, il nous faut nous intéresser à la source d’énergie de celui ci. Nous nous penchons sur ce sujet dans le billet suivant.
REA – motorisation : choix des composants
Pour notre programme REA, nous développons un Rover d’Exploration Autonome. A la précédente étude, nous avons étudié les modes de déplacement accessibles, avant d’opter pour un système basé sur des roues/chenilles, avec un système de conduite différentielle.
L’objectif sera d’utiliser une source d’énergie quelconque pour générer un mouvement de rotation pour entraîner les roues. Puisque nous avons choisi la conduite différentielle, il nous faudra deux moteurs (ou N paires).
Étudions maintenant les solutions de motorisation qui nous sont accessibles.
REA – mode de propulsion du robot
Pour notre programme REA, nous développons un Rover d’Exploration Autonome.
Si nous souhaitons avoir un robot autonome qui ne soit pas une sonde immobile, il lui faut être capable de se déplacer. Nous nous intéressons ici aux robots terrestres, et nous pencherons sur les modes de déplacement utilisables pour nos robots. Nous verrons donc dans cet article chaque mode de propulsion utilisable simplement pour notre robot autonome, en expliquant leur fonctionnement, et en comparant leurs avantages et inconvénient. Le but de cette étude théorique est de dresser un panorama des solutions existantes afin de pouvoir choisir la plus adaptée à un problème donné.
Programme REA : Rover d’Exploration Autonome – introduction
J’ai construit divers robots “comme ça”, sans planifier grand chose, pour apprendre, comme R.Cerda,pour lequel j’ai fait un tuto, ou encore mon projet de robot à haute autonomie. Aujourd’hui, je me dis que je peux progresser de façon plus structurée, plus scientifique, un peu comme un programme de recherche (c’est mon métier après tout 
).
Je démarre donc mon programme REA, pour Rover d’Exploration Autonome. Le but est de faire un rover capable de se déplacer seul dans un environnement donné de façon autonome. J’ai déja réalisé certains des objectifs de ce programme dans quelques uns de mes projets précédents. Cependant, je souhaite pour ce projet tout reprendre depuis le début, et mener les évolutions comme un projet de recherche classique (en m’inspirant, sans bien sur prétendre approcher ce niveau, du programme MER –Mars Exploration Rover— de la NASA).
J’aborde ce projet sous deux axes :
- L’axe scientifique;
- L’axe pédagogique.
Débuter avec les esp8266 : connexion esp2866 série USB
Dans ce billet, nous verrons comment connecter un module esp8266 à un ordinateur pour pouvoir le configurer et lui envoyer des commandes. Cela nous permettra de vérifier que le module est fonctionnel, mais également de pouvoir le paramétrer. Nous utiliserons également ce schéma de connexion ultérieurement pour pouvoir mettre à jour le firmware (nouvelle version ou alors un firmware alternatif tel que nodemcu).
Alitest : écran LCD 10 pouces HDMI 1280×800 IPS
Le Raspberry pi est capable d’utiliser des écrans HDMI variés, du moniteur d’ordinateur à la télévision de salon. Toutefois, pour certains projets, on peut souhaiter utiliser un écran plus compact, sans se ruiner. Dans cet article, nous testerons un écran LCD 10 pouces HDMI 1280×800 IPS acheté sur Aliexpress. aux alentours de 60€. Il existe des écrans moins chers pour cette diagonale, mais celui ci à l’avantage d’avoir une définition de 1280×800, donc compatible avec le 720p (les modèles moins chers sont plutôt en 1024×600), et également d’être vendu comme ayant une dalle IPS. Nous verrons donc ce que vaut cet écran en pratique, ce que l’on reçoit, et comment assembler le tout (très simple), et nous vérifierons qu’il s’agit bien d’un IPS.
DS3231 Raspberry pi RTC : ajouter une horloge temps réel I2C – Alitest
Le Raspberry pi ne dispose pas de module RTC (Real Time Clock, horloge en temps réel), et ne peut donc pas garder une trace précise du temps écoulé sans avoir recours à une synchronisation sur un serveur de temps (NTP). Cela n’est pas toujours possible, notamment pour des projets ou le Raspberry Pi n’est pas connecté au réseau. Pour remédier à cela, il est possible d’ajouter un module RTC tel que le DS3231, économique, compact et précis. Nous verrons dans ce tutoriel comment réaliser cela.
DS18B20 Raspberry pi – Mesurer la température avec une sonde numérique
Pour mesurer la température, il est possible d’utiliser divers capteurs, tels que le TMP36, le DHT11/DH22, ou encore le DS18B20. C’est à cette dernière sonde que nous nous intéresserons aujourd’hui. Il s’agit d’une sonde numérique (pas besoin de convertisseur analogique-numérique tel que le MCP3008) qui est assez précise (±0.5°C sur la plage -10°C – 85°C), raisonnablement facile à utiliser, et consommant peu. Par rapport à une sonde analogique, c’est un peu plus complexe, puisqu’il faut utiliser le protocole dallas 1-wire, mais nous verrons qu’il y a déjà les outils nécessaires pour exploiter tout cela.
Alitest : WS2812 chinoises – led adressables type neopixels
Aujourd’hui, nous allons tester des leds adressables, les WS2812 et WS2812B, en provenance de Aliexpress. Ces leds sont similaires à ce qu’Adafruit appelle les NeoPixels. En pratique, il s’agit de LED RGB, donc capable de produire toutes les couleurs que vous souhaitez utiliser, et adressables, c’est à dire qu’on peut contrôler chaque LED individuellement. Ces LED sont chainées, ce qui fait qu’on utilise un seul GPIO pour contrôler l’ensemble, et on peut placer plusieurs ensembles les uns à la suite des autres. On a généralement 3 câbles : l’alimentation 5V, la masse, et le câble de signal. Que valent ces exemplaires achetés sur Aliexpress? C’est ce que je vous propose de découvrir aujourd’hui, avec deux modèles :