Ceux qui sont à l’affût de la meilleure manière de tirer parti des kits Mindstorms avaient déjà repéré la carte d’extension pour Raspberry nommée PiStorms. Il s’agit d’un produit développé par la société Mindsensors, bien connue pour ses capteurs et extensions diverses pour NXT et EV3.
Cette carte permet de transformer une Raspberry Pi en équivalent de la brique programmable LEGO, en proposant :
- des ports pour connecter capteurs et moteurs compatibles Mindstorms
- un écran LCD couleur tactile
- deux LEDs RGB contrôlables
J’avais déjà fait l’acquisition à sa sortie du premier modèle (le rouge). Mindsensors en a sorti récemment une nouvelle version (beige). Nos amis de Génération Robots m’en ont gentiment offert un exemplaire afin que je l’évalue et que je vous fasse part de mes impressions.
Déballage et montage
Le kit envoyé est le "base kit" qui se différencie du "starter kit" par le fait que ce dernier contient une carte SD préchargée avec Raspbian et les extensions PiStorms. A part cette petite différence,on trouve dans les deux kits :
- la carte PiStorms (c’est la moindre des choses)
- une frame pour son montage sur une structure LEGO, faite de 3 pièces réalisées en impression 3D
- un stylet pour l’écran tactile, car il s’agit d’un modèle résistif
Le montage de la frame se fait par simple emboîtage des 3 parties, et la RasPi vient se fixer à l’aide de 2 vis fournies. C’est l’affaire de 5 minutes grand maximum.
Le résultat final est très semblable à l’ancienne version, comme en témoignent les photos ci-après.
Mindsensors a un peu modifié la frame par rapport à la v1, comme en témoigne la photo ci-dessous, la v2 étant à droite.
On note que la carte n’est maintenant fixée que par deux vis, l’autre extrémité venant se glisser dans des logements de maintien. Des emplacements pour caler correctement les différents connecteurs de l’extension ont été ajoutés, pour une meilleure tenue de l’assemblage lors des connexions et déconnexions des câbles des capteurs et moteurs.
Mindsensors a corrigé quelques défauts de conception de la v1, qui nécessitaient de petites retouches au cutter, par exemple pour laisser la place au connecteur micro-USB d’alimentation de la RasPi.
L’extension PiStorms vient se relier sur le connecteur GPIO, mais attention :
- pensez à préparer la carte SD et à l’insérer dans le slot avant, car après ce n’est plus vraiment possible : le slot est accessible, mais les embases de connexion des moteurs empêchent la sortie complète de la carte
- ne pas monter de radiateur sur le processeur, car il y a 3 condensateurs soudés sous le module PiStorms, dont un qui vient au niveau du CPU. J’avais par chance utilisé un modèle low profile sur la RasPi de test, mais du coup le module ne peut pas être totalement enfoncé sur le connecteur car le condensateur en question vient buter sur le radiateur.
Les pins non utilisées du connecteur GPIO de la Raspberry restent accessibles une fois la PiStorms connectée, ce qui permet d’en faire usage pour des besoins spécifiques. Il en est de même pour le connecteur CSI, même s’il se trouve en limite sous le module.Il faudra peut-être connecter le câble avant d’enfichier le PiStorms.
Un point à revoir
Il y a un petit bémol pour la solidité mécanique du module, plus précisément au niveau de la qualité de l’assemblage entre la façade et le circuit imprimé.
Dans l’ancienne version, la façade rouge était une plaque de quelques millimètres d’épaisseur, découpée pour l’écran et collée assez fermement sur le circuit imprimé. Tout cela présentait une solidité correcte. Dans cette version, c’est une pièce en plastique moulée, assemblée au PCB par quelques plots de ce qui ressemble à du mastic silicone.
Ce collage n’offre pas de réelle résistance. Il a lâché dès que j’ai voulu déconnecter le module, car il faut alors exercer une traction importante pour débrancher le connecteur. Ca m’a fait craindre pour l’écran, car il n’est pas fixé et il se baladait donc au bout de sa nappe. J’ai ajouté un petit bout d’adhésif double-face pour le maintenir en place sur une de ses deux entretoises afin d’éviter une rupture de la nappe au cas où.
Il a également fallu retirer totalement les résidus de mastic, car impossible de remettre la façade correctement en place ensuite, ce qui posait quelques problèmes de fonctionnement du bouton GO. Je n’ai pour l’instant pas recollé la façade, des fois que, mais ce sera indispensable car elle se détache pour un oui ou pour un non maintenant.
Mindsensors devra donc revoir sa copie au niveau de la fixation de la façade, car je ne donne pas cher de l’assemblage une fois mis entre les mains de jeunes roboticiens pleins de fougue.
Un petit conseil [EDIT 18/12/2016]
Il est très difficile de déconnecter la PiStorm de la Raspberry, du fait du grand nombre de connexions de son connecteur, et par conséquent de l’effort de traction nécessaire. Au-delà du problème de fixation de la façade signalé ici, les contraintes mécaniques exercées sur les différentes parties risquent d’avoir des effets destructeurs si on n’est pas assez soigneux.
Pour éviter cela, je conseille de ne pas enfoncer à fond le connecteur lors du montage, de manière à laisser un interstice permettant de glisser la lame d’un petit tournevis plat entre la base du connecteur de la RPi et le boîtier noir de la partie femelle sur la PiStorms. La photo ci-dessous sera sans doute plus explicite.
En se servant du tournevis comme levier (en le faisant tourner sur lui-même) on pourra écarter progressivement les deux connecteurs, jusqu’à ce qu’ils soient suffisamment désengagés pour que la traction à effectuer pour finir la séparation soit raisonnable.
Alimenter PiStorms
Un bornier à vis est présent sur la carte pour y connecter une source d’énergie. La documentation précise qu’il ne faut pas dépasser 9V, ce qui veut donc dire que vous pouvez oublier le bloc d’alimentation LEGO (en 10V). A ce jour deux options sont disponibles, toutes deux faites pour s’intégrer dans la frame de montage :
- le boitier de piles,
- le pack LiPo.
Le prix du pack LiPo est tout ce qu’il y a de plus raisonnable quand on le compare à celui de l’EV3, qui vaut 100 Euros à peu de choses près. Même à 25% de capacité supplémentaire, ça fait une grosse différence. Ceci étant, ne vous attendez pas à une autonomie similaire à celle de l’EV3, car la Raspberry consomme bien plus que l’EV3. N’ayant pas ce pack LiPo pour l’instant, je ne peux valider cette hypothèse, mais elle a 99.99 % de chances de se vérifier sur la base des calculs sur le papier.
Pour ce qui est de la mise sous tension, il suffit d’appuyer sur le bouton GO. Idem pour l’arrêt, en maintenant ce bouton une petite dizaine de secondes, jusqu’à ce que les deux LEDs RGB commencent leur farandole colorée. A noter un très bon point ici : la séquence de power off ne se limite pas à mettre le système en halt, mais coupe réellement l’alimentation de la RasPi (extinction de sa LED). Pas certain cependant qu’une éventuelle batterie connectée au PiStorms ne continue pas à être déchargée lentement du fait de la surveillance du bouton GO.
Côté logiciel
L’installation de l’environnement PiStorms sur la RasPi est très bien décrite sur le site de Mindsensors.
Deux options sont possibles :
- récupérer l’image complète de la carte SD (basée sur Raspbian Jessie),
- ne récupérer que l’extension PiStorms
Cette deuxième option est à choisir si on veut installer l’environnement sur une carte déjà installée en Raspbian. C’est celle que j’avais utilisée en premier lieu, car habitué à faire tourner mes RasPi en Raspbian Jessie Lite, c’est à dire sans environnement graphique (elles sont toutes embarquées dans des systèmes headless).
Je ne vous la conseille cependant pas en date de rédaction, car la procédure d’installation semble souffrir de certains défauts. Par exemple à un moment, une copie de fichiers échoue car le répertoire de destination n’existe pas. De plus un fois tout installé, il semble que le tableau de bord qui permet de contrôler le PiStorms et de naviguer dans son contenu ne se lance pas, car l’écran reste noir. Ce sera certainement corrigé prochainement, mais pour l’instant utilisez l’image complète, même si elle va vous ramener des tas de choses inutiles, comme VNC si vous n’avez pas l’intention d’utiliser le bureau graphique de la RasPi depuis votre machine (en ce qui me concerne, je fais tout sous ssh 🙂 ).
Que trouve-t-on de base ?
Plein de choses.
Pour les plus jeunes (ou les grands débutants), deux environnements de programmation graphiques sont fournis :
- Scratch
- Blockly
Le premier est bien connu, et fait maintenant parti de l’arsenal choisi par l’Education Nationale pour "apprendre le code" (sic) aux plus jeunes.
__0__
Petite parenthèse (et billet d’humeur) : il faudrait que les personnes publiques qui décident au plus haut niveau de l’Etat prennent un jour la peine de commencer par se former suffisamment sur les domaines dont on leur confie la responsabilité afin de pallier leur ignorance. Surtout lorsqu’il s’agit de domaines à connotation technologique ou scientifique. On veut leur faire apprendre quel code à nos jeunes ? Le code de la route ? Le code pénal ? Mort de rire :’-))
On l’aura compris, l’idée était d’apprendre la programmation, ou l’algorithmique. Pas le code bien entendu, l’auteur de cette phrase ayant sans doute pensé "apprendre le codage".
Excusez-moi pour cette petite digression, mais ça fait du bien de se lâcher parfois 🙂
__0__
Retour à nos moutons, à savoir le PiStorms, Scratch, Blockly et consorts.
Blockly est plus récent et est issu de chez Google. Rassurez-vous, il ne va pas espionner vos pérégrinations Internet, mais vous mettre à disposition quelque chose de semblable à Scratch dans l’esprit, mais tournant dans votre navigateur Web préféré, et donc sans installer une quelconque application plus ou moins compatible avec votre système favori, que ce soit une fenêtre, une pomme ou un manchot. Il a donc ma préférence, et c’est d’ailleurs l’option que j’ai retenue pour un de nos projets récents. Pour voir la tête que ça fait sur le PiStorms, allez faire un tour sur le site de Mindsensors.
Le deuxième effet Kiss Cool de l’option Blockly est qu’il n’y a pas besoin de se connecter à l’environnement graphique de la RasPi via VNC ou similaire, mais de pointer simplement votre navigateur Web vers le serveur HTTP qui tourne sur la RasPi. Reportez-vous à l’article référencé juste avant pour en avoir une illustration avec le projet Youpi.
Dans les deux cas de figure, on se retrouve dans un environnement qui permet de programmer le robot d’une manière similaire à celle proposée par l’environnement graphique Mindstorms pour ses briques NXT et EV3.
Et pour les plus grands ?
Ou plus exactement, pour les plus avancés en termes de connaissances informatiques.
Là c’est le pied, car vous allez pouvoir programmer votre robot avec mon langage de prédilection : Python. Je ne vais pas recopier ici le contenu d’autres sites, et si vous voulez vous faire une petite idée de ce à quoi ressemble un programme Python qui contrôle la PiStorms, le mieux est d’étudier le tutoriel Mindsensors.
Rien de bien terrible comme vous pouvez le constater. Tout passe en fait par la classe PiStorms qui regroupe les accès aux différentes ressources : capteurs, moteurs, écran tactile, bouton. Et si vous vous posez la question de l’origine des acronymes bizarres utilisés pour accéder aux capteurs, sachez que les ports d’entrée et de sortie du PiStorms sont réparties sur deux banks, A et B. BAS signifie sans doute "Bank A Sensor" et comme vous l’aurez déduit par vous-même, BBS signifie "Bank B Sensor".
Une exception pour les capteurs I2C qui sont eux gérés directement à l’aide de classes fournies dans le module mindsensors.py
. A noter qu’il ne faut pas oublier d’activer le mode I2C custom pour le port concerné en appelant sa méthode activateCustomSensorI2C
. Illustration pour un capteur connecté sur le port BAS1 :
from PiStorms import PiStorms
psm = PiStorms()
psm.BAS1.activateCustomSensorI2C()
Merci à Deepak Patil du staff Mindsensors pour m’avoir donné cette information qui m’a permis de mener à bien les tests du capteur LineLeader. La réactivité du support est vraiment au top, car j’ai eu les premières réponses de leur part quelques heures à peine après avoir posté mon problème sur le forum.
Pour vous mettre l’eau à la bouche concernant les possibilités qui s’ouvrent alors à vous, visionnez juste cette vidéo et les autres du même auteur.
Bon, il faut cependant être honnête : la bibliothèque Python est loin d’être aboutie. Le code est dans un état que je qualifierais de "ni fait, ni à faire". Il y a pas mal de choses déjà opérationnelles, mais on sent que c’est du travail en cours, car il y a pas mal de lignes de code commenté, ainsi que des bugs manifestes tels que lignes identiques dans différentes branches de if résultat évident d’un copier-coller non finalisé. Le code est assez souvent de piètre qualité, et a quasi certainement été écrit par un non-Pythoniste. Ce sent le Java traduit mot à moi, à commencer par la capitalisation, à continuer par les parenthèses autour des expressions de test dans les if, sans parler de construction totalement inefficaces et relevant souvent d’une méconnaissance flagrante des particularités et points forts de Python. Autant dire qu’une réécriture totale s’impose quasiment.
Premier galop
J’ai monté la PiStorms fraîchement reçue sur une RasPi3, l’exemplaire précédent étant lui monté sur une RasPi2, le modèle 3 n’existant pas encore au moment de son acquisition. Ca aura peut-être (sans doute ?) son importance dans d’éventuels comparatifs de performances entre les deux versions.
Commençons par le commencement : le temps de démarrage, à savoir depuis la mise sous tension jusqu’au moment où on récupère le contrôle du bestiau. Voici le verdict :
EV3 | 31 s |
RPi3 + PiStorms | 20 s |
Avantage très net à la PiStorms. On peut d’ailleurs faire mieux en configurant la RasPi pour ne pas démarrer l’environnement graphique. Le temps de démarrage tombe alors à 18 secondes, soit 10% de mieux. Ce qui est plus intéressant est que le nombre de process passe de 184 à 136. C’est bien mieux car ça ne sert à rien de gaspiller mémoire et CPU à animer des fenêtres si notre RasPi est dans un robot autonome. D’aucuns pourraient rétorquer que ça peut être intéressant d’avoir un affichage graphique utilisable via VNC ou X, mais c’est un peu faible comme contre-argument car il est beaucoup plus efficace d’utiliser une appli Web pour arriver à ce résultat la plupart du temps, voire une appli spécifique côté PC avec un protocole ad-hoc comme ici.
Et pour l’arrêt :
EV3 | 43 s |
RPi3 + PiStorms | 12 s |
Là ça fait mal pour l’EV3, sachant qu’en général les minots sont pressés de partir en récré à la fin du cours, et attendre 40 secondes parait alors une éternité :)
Vous allez me dire qu’on s’en fiche un peu car on ne passe pas son temps à allumer et éteindre les briques, ce qui est vrai, mais il fallait quand même bien le dire. De toute manière il n’y a rien de bien surprenant dans tout cela, car les deux systèmes tournent sous Linux (et non pas avec une environnement bare metal), et que les processeurs respectifs ne jouent pas dans la même cour : un quad-core à 1GHz pour l’un et un ARM9 single core à 300MHz pour l’autre.
Essais capteurs
Au lieu de recopier ici des programmes du genre "hello world" avec les capteurs, que vous pouvez trouver par vous-même soit dans ce qui est installé par défait, soit via un ou deux Google par ci par là, j’ai préféré tester un par un les différents capteurs dont je dispose et vous dire comment ils se sont comportés avec notre PiStorms.
Etant donné que la bibliothèque de blocs Blockly n’est pas complète concernant les produits non-LEGO, les essais qui suivent ont été programmées directement en Python. J’ai utilisé pour cela les exemples déjà présents dans l’environnement, qu’on peut exécuter directement en navigant grâce au tableau de bord.
Pour une liste détaillée des compatibilités de capteurs (et moteurs aussi) avec PiStorms, consultez cette page.
Capteur de contact EV3 et NXT
Les deux fonctionnent sans réserve, mais ne se gèrent pas du tout de la même manière au niveau logiciel.
Le capteur EV3 est représenté par une classe à part entière (LegoDevices.EV3TouchSensor
) alors que le capteur NXT est lu via la méthode isTouchedNXT
de la propriété du port (BASx ou BBSx) de la classe PiStorms.
Peut-être la méthode d’accès sera-t-il unifiée dans une version future de manière à exposer une approche analogue pour les deux familles de capteurs. Tel que c’est actuellement, c’est un peu déroutant pour le débutant.
Capteur de couleur EV3
Le capteur peut être utilisé selon deux modes :
- luminosité ambiante et réfléchie, idéal pour du suivi de ligne
- détection de couleur
Les réponses fournies par le capteur sont conformes à ce qu’on attend, et la code est très réactif (pas de latence notable à l’appel des fonctions de lecture).
Capteur de distance à infra-rouge EV3
Il fonctionne sans problème, si tant est qu’on n’interprète pas la valeur retournée comme étant la distance à l’obstacle lorsqu’il est en mode télémètre.
Ca donne l’impression d’être ça (et c’est peut-être censé l’être), mais le compte n’y est pas. L’évolution de la valeur n’est pas linéaire, et on ne peut donc pas se contenter d’un décalage de l’origine. Il faudra étalonner en fonction de la nature des obstacles si on veut une vraie valeur de la distance.
Si le besoin se limite à la détection d’un obstacle, c’est par contre tout à fait utilisable.
Le mode balise fonctionne très bien en conjugaison avec la petite télécommande. Là encore il ne faut pas interpréter la prétendue distance comme une mesure fiable. Tout au plus une indication de proximité.
Attention, ces reproches ne sont en aucun cas à imputer au PiStorms, mais sont des défauts intrinsèques du capteur lui-même. L’environnement PiStorms ne fait que publier les valeurs qu’il fournit.
Et c’est d’ailleurs là tout l’intérêt du PiStorms par rapport à l’EV3 : on peut enrichir à loisir le code de base pour par exemple introduire des mécanismes de correction des défauts des capteurs. C’est tout l’intérêt d’un code ouvert.
Capteur de distance à ultra-sons EV3
Il fonctionne parfaitement, et la valeur retournée est relativement fiable, car évoluant correctement avec la distance. C’est bien entendu lié à la forme de la surface de l’obstacle, en l’occurrence la petite boite en carton du PiStorms ici.
En tout cas ça semble tout à fait utilisable pour une mesure de distance.
Gyroscope LEGO EV3
Aucun problème avec les deux modes du gyro (angle et vitesse de rotation), les valeurs reflétant parfaitement la piètre qualité de ce capteur dont la dérive chronique a rapidement fait le tour de la planète Mindstorms. Pour donner un ordre d’idée, un aller-retour gentil entre les deux branches d’une équerre se solde par une erreur de 5° lorsqu’on est revenu à la position de départ.
Et là peu d’espoir de pouvoir corriger cela par soft malheureusement :’-(.
Capteur de distance à ultra-sons NXT
Il n’y a pas de bloc fourni pour ce capteur, qui par ailleurs est un peu spécial. Pour autant que je me souvienne, il fait quelques entorses au protocole I2C. On ne trouve pas sa trace non plus dans les sources Python (module LegoDevices.py
), le seul ultrasonic sensor supporté étant celui de l’EV3. Et pourtant plusieurs capteurs NXT sont implémentés dans ce module.
J’ai bien peur qu’il ne faille oublier cet ancêtre avec notre PiStorms.
Capteurs spéciaux
Mon stock contient quelques spécimens Mindsensors, tels que le LineLeader (version 1, avec PID intégré ;), le SumoEyes, et autres goodies. Ces produits apparaissent dans le module mindsensors.py
mais il n’ont pas de bloc Blockly actuellement.
Voici le résultat des courses (en temps réel) :
Modèle | Testé ? | Résultat | Classe support | Remarques |
NXTLineLeader-v1 | oui | OK | mindsensors.LINELEADER |
à ne pas confondre avec le Line Detector Array, qui se présente de la même manière mais n’est qu’une série de 8 capteurs, sans le PID intégré pour le suivi de ligne |
NXTSumoEyes | non | PiStormsCom.SumoEyes |
||
NXTServo | non | mindsensors.NXTSERVO |
||
NXTCam-v3 | non | mindsensors.NXTCAM |
||
NXTIRDist | non | mindsensors.DIST |
||
IMU | non | mindsensors.ABSIMU |
Note : ayant préféré publier l’article rapidement plutôt que d’attendre une hypothétique date de complétude, tous les tests n’étaient pas encore faits en date de rédaction, d’où la série de "non" dans la colonne "Testé". Ce sera mis à jour au fur et à mesure du temps libre... Revenez faire un tour ici de temps en temps pour venir aux nouvelles.
Essais moteurs
Même tour de piste avec les moteurs cette fois-ci.
Le comportement est identique quel que soit le type de moteur utilisé, que ce soit les deux moteurs EV3 ou le moteur NXT. Bonne nouvelle pour ceux qui ont du stock d’anciens modèles.
En se basant sur les exemples Blockly, le contrôle semble précis. D’ailleurs, on a aussi accès aux paramètres du PID pour ceux qui voudraient affiner les réglages.
Programmer PiStorms
Je vous ai parlé de Scratch, de Blockly, de Python... Du coup ça doit être un peu confus dans votre tête. Comment utiliser l’une ou l’autre de ces options ? Doit-on se connecter sur le PiStorms en ssh pour faire du Python ?
Eh bien il faut tirer un coup de chapeau aux développeurs de chez Mindsensors, car ils ont réussi à proposer tout cela de manière très accessible via votre navigateur Web préféré. Il suffit pour cela de le faire pointer sur l’IP du PiStorms (qu’on peut trouver en cliquant "About me" sur l’écran principal du tableau de bord) et on arrive sur cette page d’accueil :
Cerise sur le gâteau : c’est du responsive design, c’est à dire que ça s’ajuste au mieux à la taille du device. Autrement dit, vous pouvez l’utiliser également depuis une tablette, voire un mobile (mais là il faut être un poil masochiste quand même).
Cliquez maintenant sur "Programs" en marge gauche, et vous obtiendrez le navigateur de fichier, à la racine de l’espace de stockage de programmes, que ce soit du Python ou du Blockly.
Si vous cliquez sur un fichier Python, un éditeur de code s’affiche avec le programme concerné chargé, prêt à être modifié :
Si vous naviguez dans le dossier BlocklyDemos
et que vous sélectionnez l’un des programmes, c’est maintenant l’éditeur Blockly qui s’affiche :
Pour ce qui est de Scratch, rien de tout ceci, car Scratch est une application graphique qui tourne sur la Raspberry, qu’il faudra donc démarrer avec l’environnement graphique et sur laquelle il faudra se connecter avec VNC pour accéder au bureau graphique.
Personnellement, ce mode d’utilisation ne me branche pas vraiment, car je trouve que c’est du gaspillage de ressources que de faire tourner un environnement graphique sur un système embarqué, juste pour pouvoir utiliser un outil de programmation graphique. De plus la solution Scratch est un peu lourde sur le plan architecture, car le programme est exécuté par l’application Scratch, qui communique via un socket avec le programme Python Scratch_PiStorms.
, contenu à la racine de l’espace "Programs", et qui doit s’exécuter en même temps pour assurer la traduction des messages Scratch en appels de l’API PiStorms. Pas hyper efficace comme infrastructure.
J’ai donc mis Scratch de côté, car il offre somme toute un intérêt limité ici du fait de l’alternative Blockly, beaucoup plus légère de mise en oeuvre. De plus, le résultat est plus efficace, car votre programme Blockly est traduit en son équivalent Python lorsque vous le sauvez, et c’est ce programme Python qui va être exécuté directement (ce sont les fichiers en .py
qu’on peut voir dans le répertoire BlocklyDemos
).
Un autre argument en faveur de Blockly est qu’il ouvre la voie à une démarche pédagogique d’apprentissage de la programmation en Python. En effet, on peut commercer en utilisant la programmation graphique, puis étudier le code Python qui a été généré, et poursuivre directement en Python.
Remarque : je n’ai pas (encore) trouvé comment on peut ouvrir avec l’éditeur de code un fichier Python généré par un programme Blockly, et il faut se connecter sur la RasPi pour aller voir le contenu du fichier généré.
Les autres fonctions du tableau de bord
Télécommande
Outre les outils de programmation, le tableau de bord fournit une petite télécommande, permettant de piloter via un joystick graphique deux moteurs connectés classiquement en B et C. Il est aussi possible de contrôler les deux LEDs RGB.
Capture d’écran
Cet outil est très pratique et sauvegarde une image de l’écran du PiStorms à chaque modification de son contenu. En voici un exemple :
Et en plus c’est joli, ils ont ajouté la reproduction de l’ensemble de la face avant.
Ils ont d’ailleurs pensé à ceux qui utilisent cette fonction pour faire des tutoriaux, car lors de la capture on peut activer une option d’enregistrement de l’emplacement de l’action sur l’écran. En plus du fichier reproduisant l’affichage, un autre fichier est produit avec juste un point rouge à l’emplacement correspondant, et le reste en transparent. Ce fichier est destiné à être superposé à l’image écran, pour réaliser une animation illustrant la dynamique du déroulement. Un très grand bravo pour cette idée, qui démontre le souci des concepteurs à apporter des outils aux utilisateurs à profil éducation.
Autres fonctions
Tout a été pensé pour aider l’utilisateur quel que soit son profil, car le tableau de bord permet l’accès direct au sections du site Web Mindsensors dédiées au blog et au forum.
Last but not least, un formulaire de soumission de bug est intégré au logiciel. On aimerait trouver cela dans d’autres logiciels, payants et propriétaires... suivez mon regard. Quoi que je m’en moque un peu en fin de compte, car je n’utilise pas ces logiciels 😉
D’ailleurs ça tombe bien, car voici ci-après quelques défauts constatés.
Les bugs et points à corriger
Où est la fonction "renommer" ?
Je n’ai trouvé nulle part comment on peut modifier le nom d’un dossier ou d’un fichier. Ca ne serait pas trop grave (bien que gênant) si... les blancs dans les noms causent une erreur 512 au lancement des programmes. OK, des blancs dans un nom de fichier ou de dossier sont le mal absolu pour les informaticiens, mais les utilisateurs standard s’y sont habitués, alors difficile de ne pas les gérer correctement.
Gestion des blancs dans les noms de fichiers ou dossiers
Il faudrait soit les accepter et les traiter correctement, soit les interdire à la saisie. Aucun message n’évoque ce point au moment de la création d’un nouveau dossier ou fichier.
Il y a un bug dans... la fonction "Submit a bug"
Si on essaye de soumettre deux bugs d’affilée, l’appel de la commande pour le deuxième affiche à nouveau le message de confirmation de soumission du premier au lieu du dialogue de saisie. Pour contourner le problème, il faut sélectionner n’importe quelle autre commande auparavant avant d’invoquer le commande.
La qualité très décevante du code Python
Comme évoqué plus haut, le code contenu dans le répertoire
Par ailleurs, la bibliothèque de blocs Blocky devrait être complétée de manière à supporter au minimum les produits Mindsensors.
Un choix technique discutable
L’application Web du tableau de bord est écrite en PHP et le serveur est Apache. Outch 😡. Dans le genre scaphandrier aux chaussures lestées, on peut difficilement faire pire 😄 Pourquoi ne pas avoir utilisé quelque chose de plus léger et adapté au contexte de la Raspberry, comme par exemple l’excellent Tornado ? C’est d’autant plus surprenant, qu’il y a en réalité deux serveurs HTTP qui tournent, le deuxième étant développé en Python/Flask, et fournissant une API sous forme de Web services. Unifier le tout dans une unique application Flask permettrait de réaliser une grosse économie de ressources systèmes, et éviterait un patchwork de technos disparates, difficile à maintenir de manière cohérente. Il est clair que la communauté open-source doit se mobiliser sur ce sujet, et je vais essayer d’y contribuer à la mesure de mes moyens.
Conclusion
Nous voici arrivé au terme de ce très long article qui n’est pourtant qu’un très court aperçu du PiStorms.
J’ai personnellement beaucoup aimé le bestiau et ce pour plusieurs aspects :
- convivialité
- multiplicité des modes de programmations
- qualité de l’application Web tableau de bord
- ouverture grâce à l’accès libre aux sources sur GitHub.
Je l’aime beaucoup moins cependant pour les heures de sommeil qu’il va me coûter en bon geek que je suis 😄 Naaan, je blague, je pense que je vais bien m’amuser avec.
Le framework logiciel est de toute évidence dans l’état work in progress en date de rédaction. Préparez vous à pas mal d’investigations personnelles pour arriver à vos fins, et espérons que suffisamment de contributeurs pourront prêter main forte à Mindsensors pour l’amener à maturité. Votre serviteur en aurait bien l’envie, mais il faut du tems pour cela.
Pour finir, je vous conseille donc l’achat de ce produit. Même avec toutes les options (la Raspberry Pi, le bloc batterie, le bloc secteur et une carte SD) le budget est moins élevé que celui de la brique EV3, de sa batterie et de son bloc secteur. Vous aurez en prime :
- une puissance de calcul infiniment supérieure,
- un éventail de choix plus large quant à la programmation,
- le Wifi intégré si vous utilisez une Raspberry 3.
Bon, ok, vous perdez le haut parleur intégré, mais ce n’est pas l’accessoire le plus indispensable des briques Mindstorms.
Attention cependant : si l’usage prévu est dans un cadre scolaire ou similaire, l’ensemble est un peu plus vulnérable que la brique EV3. A réserver donc aux plus grands, ou en tout cas aux plus soigneux.
Si vous craquez et avez déjà la carte bancaire entre les mains, vous pouvez vous procurer la PiStorms v2 ici... ainsi que bien d’autres produits (y compris des robots dont le prix est à 5 chiffres ;) ).
Vos commentaires
# Le 7 décembre 2016 à 14:01, par Vanessa Mazzari En réponse à : PiStorms v2
Un bon article ! Merci, c’est très complet ! :) Longue vie au PiStorms
Répondre à ce message