Episode à fréquence variable

Mike118, R1D1 et moi partageons nos expériences sur nos robots en cours. Je vous laisse découvrir.

Liens cité dans l’émission :

http://www.sitedunxt.fr/articles/articles-4-21-1+vehicules-de-braitenberg-1-et-2.php

http://wiki.t-o-f.info/BEAM/V%C3%A9hiculesDeBraitenberg

 

Donovan – Imprimante 3D et bras robotisé

Avec Donovan nous faisons un détour dans l’est de la France. Il nous présente son imprimante, ses évolutions et il nous explique tout de son fonctionnement. Nous avons aussi abordé son projet de bras robotisé lui même imprimé. C’est le projet open source BNC3D. Je veux le remercier de sa sympathie à partager tout cela avec nous. Je voudrais pitcher cette interview avec cette phrase : une imprimante 3D c’est comme un pistolet à colle automatique qui peut même faire de la musique.

L’imprimante core XY

Sa prusa i3 V1 et V2

Toutes les infos sur le bras imprimé BNC3D. Le cours de cinématique dont parles Donovan est sur le premier post.

Pour retrouver le générique de fin 🙂

Arobasseb – Webmaster, bipède, domotique et guirlandes

J’ai eu le plaisir d’enregistrer le très sympathique Arobasseb, webmaster Robot-Maker.com. Il nous présente ses projets de bipède, de domotique et sa guirlande. Il a une manière très méthodique d’aborder ses projets. Il nous rappelle les différentes étapes qu’il a déjà partagé sur le forum et qui constituent ses projets. Cet interview nous éclair sur ses futur publications.

Rod le bipod

Tuto Registre à décalage 74HC595

Tuto Utilisation du module RTC DS1307

Émission 0 – Le pilote

Bobox (Boris), R1D1 (Erwan), Mike118 et moi (Path / Loïc) vous proposons ce nouveau périodique à une fréquence approximative de 771nHz. Il va s’agir d’actualité généraliste, de l’actualité du forum robot-maker.com et de sujets plus approfondis. Pour ce pilote, Pascal (Serveurperso) était notre guest-star.

Ce numéro zéro est notre pilote. Nous vous le proposons pour avoir vos retours. Nous serons attentifs à toutes vos remarques et suggestions.

Les liens cités dans l’émission :

Cette émission a été enregistrée le 16 aout 2017.

Podcasteur le punk de la radio

C’est le moment de faire un petit point d’étape.

L’histoire remonte au mois d’avril où, dans les coulisses du forum robot-maker.com, on cherchait à créer du contenu. J’ai parlé d’interviews. Je pensais d’abord aux acteurs connus comme le professeur Jacques Gangloff et ses cours en video, le youtubeur James Bruton et d’autres. Mais je n’ai eu que des dédicaces par mail. Bien mais pas très profond. Pour ce type de contenu, j’ai testé l’audio avec certains d’entre nous. En plus de mieux connaître mes interlocuteurs, de partager encore plus, de faire de très bonne rencontres, j’ai obtenu de la matière pour tester le matériel, le montage me roder. Et je trouve ça concluant, ça me donne envie de continuer. C’est encore très perfectible mais je trouve ça top !! Merci encore à ceux qui sont venus !!

A propos du format audio

Je le trouve tout à fait adapté à une utilisation annexe. Comme la radio, on l’écoute pendant qu’on continue à ses occupations. En voiture, en transport, à pieds, pendant qu’on bosse sur son robot ^^. Comparé à la video, d’un coté cela limite l’aspect didactique, de l’autre coté c’est plus facile à produire. Et on a l’écrit sur le forum pour l’aspect didactique. Je trouve aussi que le dialogue direct à l’oral rapproche, renforce l’esprit communautaire et démystifie la complexité de la robotique. Et c’est bien là le but.

A propos de la diffusion

Les gens qui viennent sur youtube cherchent du contenu video. On le voit dans les chiffre donnés par youtube, les gens ne lisent que 10% des interviews que j’ai posté sur ce support. Je vais continuer de diffuser sur youtube mais uniquement pour la « visibilité ». La cible des podcasts c’est itunes, podcloud, mon rss et twitter. Soundcloud n’est pas super en forme. Ils licencient … Sur les supports dédiés aux podcasts, on ne peut pas mesurer la durée de l’écoute. C’est un mp3 qu’on télécharge. Mais on se donne toutes les chances que ça le soit :)

On est au tout début de l’histoire. On va continuer les interviews bien sûr. A coté de cela, on va explorer d’autres voies avec une émission périodique. Affaire à suivre donc.

A propos du podcast

On a aucun objectif de chiffre, aucune pression. Ça sort quand ça sort :) On le fait dans la bonne humeur et sérieusement on le fait à la cool. La préparation du conducteur doit être très limitée. Nous n’avons besoin que de notre passion. On fait du contenu qui est diffusé en se marrant.

C’est quand je veux, si je veux, indépendant des media et des autres podcasts, liberté de format, liberté de ton, un espace pas encore très réglementé, très peu de moyens …  Bref, une radio pirate moderne en quelque sorte.

Discussion sur le forum.

Etat du studio

De quoi s’amuser un bon moment.

  • Un micro XLR.
  • Un enregistreur numérique.
  • Un serveur mumble.
  • Des cartes son externes pour brancher un téléphone et un ordi pour le mumble.
  • Un mixeur analogique et le câblage mix-minus pour que tout le monde se parle.
  • Un répondeur et une ligne téléphonique (ligne SIP gratuite).
  • Un serveur icecast2 et un raspberry pour diffuser le master audio brut en direct sur une page web, avec une image prise toutes les minutes pour illustrer.
  • un site web pour porter ces infos et le RSS de diffusion.

Multitâches avec arduino

C’est une petite réflexion sur le multitâche dans arduino. C’est mon quart d’heure pensée profonde de l’été. C’est de l’apologie assumée du non-bloquant. Je mettais mes idées en ordre avant de me remettre sur Emile.

 

Le concept selon wikipedia :
« La simultanéité apparente est le résultat de l’alternance rapide d’exécution des processus présents en mémoire. Le passage de l’exécution d’un processus à un autre est appelé commutation de contexte. Ces commutations peuvent être initiées par les programmes eux-mêmes (multitâche coopératif) ou par le système d’exploitation lors d’événements externes (multitâche préemptif). »

 

Cool !! Dans la procédure loop(), quand on appelle différentes librairies les unes après les autres, on fait du multitâches peut-être sans le savoir. Le mot « apparente » dans la définition est importante. Notre arduino favori ne fera qu’une seule chose à la fois. Mais tellement vite que cela semble être fait simultanément.

 

Piloter le driver de moteurs, compter les ticks des roues codeuses, afficher un message, commander et lire un capteur, envoyer et recevoir sur un port série, exécuter la logique de décision du robot … On ne met pas un arduino pour chacune de ces fonctions mais on peut vouloir dédier un arduino pour la lecture des ticks des roues codeuses. Car on le fait avec des interruptions. A chacune des interruptions, Arduino sauvegarde l’état des registres du programme principale, exécute la procédure de l’interruption, rétabli les registres et reprend le programme principale. On voit bien qu’il va être difficile pour l’arduino de capter un 2e ticks qui arriverait pendant une interruption. C’est pour cela que les interruptions doivent être très courtes. C’est une manière de faire du multitâches avec arduino en mode préemptif. C’est très pratique mais on voit apparaître une limite. A partir d’une certaine fréquence d’interruption, l’arduino ne pourra plus les exécuter toutes. Avant d’atteindre sa limite, il ne fera plus que traiter ces interruptions. On peut choisir d’ignorer les interruptions pendant un temps dans le programme principale mais pas plus. C’est pour cela qu’on dédie un arduino, pour maximiser le nombre de ces lectures. Malgrés la limite, c’est le meilleur moyen de lire des évènements déclenchés par un composant du robot extérieur à l’arduino.

 

De là à dire qu’il faut 2 arduino dans un robot, j’en suis pas loin. C’est un moyen radicale de faire du multitâche.

 

L’autre manière de faire du multitâches, c’est le mode coopératif. Il ne règle pas le problème qu’on vient de voir. On est toujours dans les limites de fonctionnement d’un micro contrôleur. Il permet de faire du multi tâches en le gérant soit même dans le programme. On le fait quand on est pas dépendant d’évènements extérieur et quand on a pas de contraintes de mesure de temps. Il consiste à faire des sous-programmes avec des fonctions ou des classes. À réserver des variables à chaque sous programmes. Et à appeler ces sous programmes dans la procédure loop(). C’est le même concept que l’interruption quand arduino sauvegarde les registres et les restaure après l’interruption. L’arduino a besoin de remplacer ses variables (ou registres) pour laisser la place aux données de l’interruption. Quand on le fait soit-même dans un programme, on ne va pas remplacer, on va avoir plusieurs variables, autant qu’il en faut pour chacun des sous programmes.

 

Pour illustrer, je vais expliquer pourquoi il faut se passer de la procédure delay(). Et comment ? En faisant du multitâche coopératif. Admettons qu’on veuille piloter la vitesse de rotation d’un servo moteur. Sans pilotage particulier, le servo ira à la position demandée aussi vite qu’il peut. Là, on veut qu’il aille à 10° par secondes. On est dans loop(). On a une variable qui contient la position courante. On commence à 0°, on place le servo à 0°, on attend 1 seconde avec delay(), on avance de 10° et ainsi de suite. Le résultat est un peu saccadé. On se dit qu’on va faire mieux en avançant de 1° à la fois avec des attentes de 100 ms. On est bien à la vitesse voulu et c’est pas saccadé. Génial !! On a réussi. Maintenant, on va placer un 2e servo. À la suite du programme, dans loop(), je vais piloter mon 2e moteur avec le même principe. Je déplace le moteur 1 de 1°, j’attend 100ms, je déplace le moteur 2 de 1°, j’attend 100ms et ainsi de suite. Ça fonctionne mais la vitesse est divisée par 2. Le temps d’attente est maintenant de 200ms. Je réfléchi 5 min et je décide de diviser par 2 les valeurs dans le delay(). Tout fonctionne bien.

 

Pour mon humanoïde avec 13 dof, je vais diviser par 13 pour conserver ma vitesse … J’arrête là ce raisonnement. Tous les moteurs ne fonctionnent pas en même temps et pas tous à la même vitesse. Je n’ai pas envie de calculer chaque valeur de delay() pour mes 13 servo. La solution consiste à ne pas attendre, a ne pas utiliser de fonction bloquante et laisser la boucle loop() s’exécuter aussi vite qu’elle peut. Indépendamment de la période de calcul des servo. Pour utiliser le temps d’attente du delay() et pour laisser le temps aux autres calculs. Il n’y a pas que la vitesse des moteurs à calculer. Alors comment on fait ? Le principe : je connais la position courante et la vitesse que doit avoir chacun des moteurs. A chaque passage dans loop(), je regarde l’heure qu’il est (toujours en ms). Et pour chaque moteur, je calcul la position où il doit être pour cette heure de passage dans loop(). On ne maîtrise pas le délai entre 2 passages dans loop() mais on le mesure et on en déduit la position.

 

Pour y arriver, on va dire que le calcul de la position d’un servo est un sous programme. Chaque servo doit avoir ses propres variables : vitesse, heure de départ, position de départ et position d’arrivée. Faire une classe Servo est tout indiqué. On va utiliser la fonction map().

La durée du parcours est donnée par la formule : vitesse = abs((position d’arrivée – position de départ)) / durée du parcours.

L’heure d’arrivée est donnée par l’heure de départ + durée du parcours.

Et chaque moteur est piloté par la fonction suivante.

long position courante = map(heure qu’il est, heure de départ, heure d’arrivée, position de départ, position d’arrivée);

 

Pour boucler la boucle, il y a le cas du capteur ultrason HC-SR04. Pour avoir une lecture de la distance, la fonction pulseIn va mesurer le temps qu’un pin du module ultrason reste à l’état haut. L’enjeu consiste à détecter avec précision les changements d’état. PulseIn est une instruction bloquante. Le temps d’attente est dépendant de la distance. Pendant ce temps, on voudrait que l’arduino fasse autre chose. Dans ce but, on pourrait avoir envie de mesurer le temps entre le front montant et le front descendant avec un code multitâches coopératif. Dans la boucle, je lis l’état du capteur. s’il passe à haut, je note l’heure (en ms). Je continue de lire à chaque passage de la boucle. S’il repasse à bas, je note aussi l’heure. La différence de temps entre ces 2 horaires maximise la largeur de l’impulsion. C’est possible mais on perd en précision. La précision serait dépendante de la longueur de la boucle. C’est à dire la quantité d’instruction qu’on a placé dans le procédure loop(). Même si la fonction pulseIn() ressemble à la procédure delay() par on caractère bloquant, on peut être tenté de l’utiliser. Parce que c’est simple à faire. Et si on veut en optimiser le résultat, on peut même ignorer les interruptions pendant qu’elle attend … Cela fonctionne très bien, mais là on coupe toute possibilité de multitâches !! Et si on a des roues codeuses à intercepter, soit on arrête le robot pendant qu’on utilise le capteur, soit on prend un 2e arduino. La bonne solution est de passer par les interruptions pour intercepter les changements d’état du capteur. Le seul inconvénient est qu’il faudra un arduino avec plus de 2 pin d’interruption si on souhaite les codeuses en même temps.

 

On en parle ici

Fabrication de la video avec l’onde sonore

La commande ffmpeg permet de créer une video avec une image de fond et d’un mp3. Elle permet aussi d’y ajouter des effets dont une représentation de l’onde sonore du mp3. La commande utilisée :

./ffmpeg -i MakerSecrets.mp3 -loop 1 -i YT_MBH.png -filter_complex \
"[0:a]showwaves=s=854x480:mode=p2p,format=rgba,colorkey=black[fg]; \
[1:v]scale=854:-1,crop=iw:480[bg]; \
[bg][fg]overlay=shortest=1,format=yuv420p[out]" \
-map "[out]" -map 0:a -c:v libx264 -preset fast -crf 18 -c:a libopus MakerSecrets.mkv

Source :

http://astuces.podcloud.fr/transformer-un-podcast-audio-en-video
https://ffmpeg.org/ffmpeg-filters.html

MakerSecrets – Le slow business

Le thème de cette émission est le slow business. Il repose sur la longévité, une bonne entente et le partage d’une vision commune. Avec le temps, Max et Alex, ces deux makers ont développé leur vision de leur activité et comment cela les distingue sur le marché de la robotique. Ils nous présentent leur activité et leurs ambitions en toute simplicité. Et je les en remercie chaleureusement. Cette interview est l’occasion d’une rencontre très sympathique ; faute d’être axée sur la technique, c’est une invitation au voyage !!!

https://makersecrets.thinkific.com/collections

http://www.makersecrets.com/

Fiction participative et à vivre

En ce début d’été Phil_Goud (PodCloud) nous propose de vivre une fake news. Un jeu de rôle participatif par message téléphonique. Le pitch est simple : un météore très inquiétant va heurter le nord de l’Europe. Sur le fil du podcast 163, nous suivons presque en direct la réaction de nombreux participants ou survivants. Certains organisent leur fuite, certains observent l’actualité. Moi je choisi de me planquer dans les catacombes de Paris.

http://163.lepodcast.fr/

Partager la conversation mumble avec un invité par téléphone

Pendant une conversation sur mumble, comment prendre un appel téléphonique et permettre à l’invité par téléphone de converser avec les personnes présentes sur le mumble.

J’utilise une table de mixage et je fais un mix-minus. Le principe : envoyer sur une sortie auxiliaire toutes les sources mixées sauf une. Par exemple, envoyer sur le téléphone tout le mix sauf le téléphone. Envoyer sur le mumble tout le mix sauf le mumble.

Par exemple, la Behringer 1204 possède 2 sortie auxiliaire. Elle permet de faire 2 mix-minus, un pour le mumble, un pour le téléphone.

Pour brancher le téléphone à la table de mixage, j’utilise la prise micro-casque. J’ai testé un séparateur Y sans succès. Il faut une interface comme le iRig2.

Pour brancher le mumble sur la table de mixage, j’utilise une carte son externe usb. Elle est reconnu automatiquement et directement. Il faut la sélectionner dans mumble et le tour est joué.