Les kits de petites voitures robotisées sont très bons pour les premières heures. On visse les moteurs, branche un capteur ultrason, charge un programme de suivi de ligne et, avec un peu de chance, quelque chose traverse enfin le salon sans se jeter immédiatement sous un meuble.
Puis vient le moment où le suivi de ligne ne suffit plus. On peut jeter la petite voiture de débutant pour reconstruire quelque chose de plus ambitieux ; Iulia choisit au contraire de faire évoluer la même machine sans repartir du châssis nu.
Le projet d'Iulia présenté par Arduino choisit la seconde voie. La base est un kit Elegoo d'entrée de gamme contrôlé par une Arduino UNO Rev3, avec son shield de moteurs et quelques capteurs. Elle retire la UNO Rev3, installe une UNO Q sur les mêmes headers, remet le shield, retrouve les moteurs et les fonctions d'origine, puis ajoute une webcam USB et le Face Tracking Brick d'App Lab.1
À la fin, le petit robot tourne pour garder un visage au centre de l'image puis avance vers lui. Le résultat est amusant. La méthode l'est davantage : chaque nouvelle capacité arrive au-dessus d'une couche qui fonctionne déjà.
Garder les roues
Un kit robotique réduit volontairement le nombre de problèmes à résoudre en même temps. Le châssis existe, les moteurs sont fixés, les roues tournent, le driver moteur a déjà ses connecteurs, et les programmes fournis prouvent que l'ensemble électrique peut avancer, reculer ou tourner.
Arduino décrit le kit utilisé par Iulia avec une UNO Rev3, un shield pour les moteurs et les connexions, plus quelques capteurs destinés au suivi de ligne et à l'évitement d'obstacles.1 La plateforme reste simple, avec l'avantage que le fabricant a déjà absorbé une bonne partie des erreurs mécaniques les plus ennuyeuses.
Pour l'apprentissage, ce périmètre déjà stabilisé change beaucoup de choses. Si le but du week-end est de comprendre comment une caméra devient une consigne de mouvement, passer d'abord quatre heures à choisir un rapport de réduction, imprimer un support de batterie et diagnostiquer une roue montée à l'envers n'ajoute pas forcément la bonne difficulté.
Le kit agit comme une hypothèse déjà vérifiée : on sait que cette chose peut rouler. La suite peut porter sur le logiciel et la perception.
Changer la carte
Le remplacement de la carte est rendu simple par une contrainte très ancienne de l'écosystème Arduino : les headers restent compatibles. Arduino souligne que la UNO Q reprend le format UNO et ses connecteurs, ce qui permet à Iulia de transférer directement le shield moteur utilisé avec la UNO Rev3.12
Au moment du swap, le premier objectif est beaucoup plus modeste : retrouver exactement le robot d'avant avec un autre contrôleur. Les commandes moteurs sont retrouvées avant d'ajouter quoi que ce soit.1
La séquence ressemble davantage à un diagnostic qu'à une démo : changer une variable, retrouver le comportement précédent, puis ouvrir la porte suivante.
UNO Q fournit précisément un niveau de calcul très différent tout en gardant cette enveloppe matérielle. La carte associe un microcontrôleur STM32U585 à un processeur Qualcomm Dragonwing QRB2210 capable d'exécuter Linux, avec une architecture où les deux mondes peuvent coopérer.2 Le microcontrôleur reste adapté au contact direct avec le hardware ; le processeur apporte les ressources d'un environnement Linux et de traitements plus lourds.
Ajouter les yeux
La puissance supplémentaire reste abstraite tant qu'aucune nouvelle donnée n'entre dans la carte. Iulia branche donc une webcam USB standard sur la UNO Q.1
La vidéo arrive ensuite dans App Lab. Arduino présente cet environnement comme une façon d'assembler des applications à partir de Bricks, des blocs logiciels réutilisables qui peuvent fournir une capacité, puis de connecter ces blocs au hardware et au reste de l'application.3
Dans ce projet, le Brick de suivi de visage fournit la position du visage détecté dans l'image.1 Ce n'est pas encore une commande moteur. Il manque une couche de traduction très ordinaire : si le visage est trop à gauche, tourner ; trop à droite, tourner dans l'autre sens ; proche du centre, avancer.
Pour débuter avec la vision, ce petit raccord entre coordonnées et moteurs est probablement la partie la plus instructive du montage. Le modèle de détection ne remplace pas la logique du robot. Il produit une observation, puis quelques règles transforment cette observation en action.
Le robot finit ainsi par « poursuivre » la personne détectée : il essaie de recentrer son visage puis avance dans sa direction.14 Arduino plaisante d'ailleurs sur le côté un peu agressif du comportement. C'est une démo, pas encore un système de navigation sûr.
Le modèle ne conduit pas
Le mot « intelligence » brouille vite les frontières utiles du montage. La caméra et le Face Tracking Brick ajoutent une capacité de perception, mais le robot n'a pas acquis une compréhension générale de son environnement.
Il ne sait pas, d'après la description publiée, planifier un trajet autour d'un obstacle tout en suivant une personne, raisonner sur la distance réelle d'un visage, ni décider s'il devrait s'arrêter devant un escalier. Les anciens capteurs du kit existent, mais le projet présenté par Arduino se concentre sur la boucle de poursuite visuelle.1
Cette limite aide justement à comprendre l'exemple. On peut voir exactement où finit chaque couche : le modèle détecte ; le code de contrôle interprète ; le shield pilote ; les moteurs bougent.
Lorsque tout est appelé « IA », cette séparation disparaît et l'apprentissage devient plus pauvre. Lorsque les responsabilités restent visibles, chaque comportement raté suggère un endroit à inspecter.
Le visage est bien détecté mais le robot tourne du mauvais côté ? Regarder la conversion des coordonnées en commandes. Le moteur ne répond plus après le changement de carte ? Revenir à la couche shield/contrôle. Le visage disparaît dans une lumière faible ? Le problème se situe plus haut, côté perception.
Une difficulté à la fois
Construire un robot complet depuis zéro reste un excellent exercice pour apprendre mécanique, alimentation, électronique de puissance et fabrication. Pour travailler la perception ou le contrôle, partir d'une base déjà roulante peut être plus efficace.
Le kit évolutif propose une progression beaucoup plus découpée : faire rouler une plateforme connue, remplacer son contrôleur sans perdre les roues, brancher une caméra, connecter une brique de vision, puis écrire une boucle de comportement. Chaque étape peut être testée séparément et chaque panne possède un voisinage plus petit.
C'est aussi une manière plus réaliste de travailler sur des objets existants. Dans un atelier ou un produit, on ne jette pas systématiquement la mécanique parce qu'un nouveau capteur devient disponible. Une bonne interface permet parfois de remplacer seulement la partie devenue limitante.
La compatibilité comme outil
Le détail décisif est presque banal : le shield de la vieille UNO peut être remis sur la nouvelle carte.1 Sans cette continuité, l'expérience aurait commencé par une migration électrique avant de pouvoir explorer quoi que ce soit de nouveau.
La compatibilité de format Arduino est souvent vendue comme le moyen pratique de réutiliser des shields. Ici, elle devient un outil pédagogique. Elle permet de conserver un système connu pendant que l'on introduit Linux, une caméra et un traitement de vision.
Cette logique dépasse évidemment ce kit précis. Quand un objet pédagogique devient trop simple, la meilleure mise à niveau n'est pas toujours un remplacement complet. Il peut être plus instructif de demander : quelle couche est devenue la limite, et peut-on ne changer qu'elle ?
Le petit robot d'Iulia ne devient pas intéressant parce qu'il poursuit un visage. Il le devient parce qu'il peut apprendre ce nouveau tour sans cesser d'être le robot qu'on savait déjà faire rouler.