Bobox

Il peut y avoir un  interet à avoir des microcontrolleurs multiple dans une même application, et pas seulement pour des problèmes de localisation.

C'est pour séparer les problèmes, comme en language objet, quand tu commences a faire des classes séparés. Le micro-controlleur dédié à l'analyse des encodeurs, au calcul de vitesse et évaluation de position tu peux décider de le séparer comme ça plus besoin de reccompiler, et les modifications sur les autres microcontroleur ne peuvent pas baver sur celui-là.

D'ailleurs la majorité des gros capteurs ( par exemple le BNO055 ), viennent avec leur microcontrolleur dédié, pour masquer le détail de la conversion du signal analogique des capteurs en des données digitales un peu plus haut niveau.

 

Après, dans nos réalisation personelles où l'on concoit pas des cartes, mais plutôt assemble des composants, les micro-controlleurs sont 'gros', car ils viennent avec beaucoup de feature inutile une fois mis en place. ( programmeteur par exemple, port USB etc..).

Ceci étant, un arduino nano, c'est assze petit, et parfois séparer certains problèmes matériel en deux pourrait faciliter le développement.

Pas de probleme pour mettre des updates, au contraire, comme ca la communaute peut suivre, commenter si elle en a envie, et en plus souvent ca garde la motivation pour celui qui post.

 

Tu as l'air d'avoir une idee en tete qui te semble raisonnable, je te conseille de la mettre en oeuvre. Peut-etre qu'elle ne marchera pas parfaitement, voir pas vraiment, mais parfois il faut affronter quelques aleas pour avancer, pour se faire une idee des contraintes ou problemes qu'on avait pas imagine. C'est un premier prototype !

Je trouve que le format audio correspond bien a ce que tu es en train de demarrer. La video c'est tres complique a monter, surtout pour des formats de 10 min ou plus, c est aussi tres contraignant pour les intervenants.

Personnelement je suis partant pour aider a animer une emission, je suis plus a l aise pour repondre, commenter, rebondir que vraiment pour ´leader' une emission. J'aime bien l'idee de reprendre des sujets du forum (avec autorisation de l'auteur initial) et d'en extraire les parties interressantes, et de les discuter en live, avec nos connaissances/meconnaissances respectives. Pour les questions de debutants, a defaut de trouver des personnes pour poser leur questions en live, ou de les poser sur le repondeur, on peut peut etre aussi reprendre des questions simples poser sur le forum (avec autorisations).
On peut aussi imaginer une petite section ´nouvelle du monde la robotique ´ ou l' on reprend une/deux info d'actualite sur la robotique et on commente un peu. Ca mixerai du contenu technique avec un peu de contenu d actualite.

Je préférerai commencer en bi-mensuel, parce que j'aime bien preparer, et si ca devient trop contaignant a mon gout je risque de lacher en route un peu sans prevenir. Quitte a passer en hebdomadaire quand j'ai trouver mon rythme et ma zone de confort.

Double vote !

 

 

Ca ressemble beaucoup à la vidéo précédente, mais maintenant c'est mon propre code qui analyse le nuage de point du capteur de profondeur et choisit la direction à aller. Dans la première vidéo j'utilisais le firmware fournit par Intel (sans source ).

 

Dans la visualisation Rviz on voit :

• En haut à gauche, le widget perso (plugin rViz) pour activer/desactiver les moteurs sur l'arduino. Ca passe part un appel de service ROS.
• En blanc, le nuage de point filtré, c'est à dire après l'avoir 'Voxelisé' ( ou 'pixelisé') et nettoyé des artefacts.
• Les points rouge sont les analyses de distance à gauche, en face et à droite du robot. Basé sur le nuage de point filtré.
• Le point violet est l'objectif de déplacement, qui sera ensuite transformé en commande moteur par le noeud de commande sur l'arduino.

J'ai teste differentes versions de chez Anker, dont des versions supportant l'USB 3.

Voici mes remarques:

 

++ :

• 5V parfaitement regule, avec amperage suffisant pour un raspberry PI 3.
• Electronique interne de regulation, Indicateur de charge. Pas de risque d'abimer la batterie par mauvaise utilisation. (s'eteint toute seul si elle est trop dechargee).
• Un tres bon rapport poids/volume/mAH.

--:

• Courant de decharge probablement 1C, ce qui veut dire qu'on ne peut pas depasser l'amperage indiquer.
  S'il y a un appel de courant trop grand la batterie s'eteint, et ne se reallumera pas sans action utilisateur (peut-etre different avec d'autres marques)
  C'est inutilisable avec quasiment n'importe quel servo moteur. (sauf peut-etre les plus petits, et pas trop a la fois)
• Dans les model anker, je ne sais pas si c'est vrai sur les autres, la batterie se coupe au bout d'un moment s'il n'y a pas de demande de jus, et souvent ne se ralume pas d'elle meme ensuite.
  Donc ca ne marche pas bien pour alimenter seulement des moteurs ou des servo-moteur
• La prise USB ca prend de la place, qu'il faut prendre en compte dans la taille de batterie, car elle ne peut pas etre reorientee.

 

Donc, dans mon experience, c'est nickel pour faire une alimentation independante pour l'electronique d'un robot, processeurs et capteurs, mais c'est inutilisable pour les actionneurs.

Comme mes robots sont plutot petit pour l'instant, j'ai un jeu de batterie unique pour  l'electronique et les actionneurs, donc j'utilise des piles ou des lipo, mais des que je ferai des robots plus gros, ou avoir deux jeux de batterie est pertinent alors je reprendrais mes batteries USB externes pour l'electronique.

Non mais maintenant je me force a cliquer sur la boutique de temps en temps et a regarder la liste des nouveaux produits. Et j'ai vu les ajouts recents avant ce poste.

 

La je commentais pour dire que c'etait cool d'avoir les T-shirt sur la boutique.

Cool le T-shirt sur la boutique !

Va falloir que je repasse commande a la boutique alors.

L'Euclid et le Raspberry PI ont tous les deux ROS qui tourne.

ROS supporte nativement des noeuds repartis sur plusieurs ressources.

 

Ils communiquent entre eux via l'intermediaire de mon WIFI perso. L'Euclid peut faire hotspot wifi ( peut-etre le raspberry pi aussi), donc j'aurais une config disponible pour faire fonctionner hors de chez moi.

 

 

 

Sur l'euclid tourne tous les noeuds bas niveau des cameras : analyse des images, du nuage de point.

Sur le raspberryPI tourne les noeuds de control des moteurs, en liaison serie avec l'arduino.

 

Les noeuds de plus haut niveau, comme celui qui convertit la distance aux obstables en un objectif de deplacement, tourne sur l'euclid, mais pourrait etre sur le raspberry en fonction de l'occupation des deux systemes.

 

En bonus mon laptop perso tourne aussi ROS et est connecte a l'ensemble pour faire le debug et la visualisation.

Sur la video avec les differentes vue camera, la vue nuage de point tourne sur mon laptop et est un peu en retard par rapport aux vue camera, qui sont plus direct.

Voici une petite video montrant ce que peut voir le robot :

 

 

• En haut à gauche, c'est la caméra RBG.
• En bas à gauche, c'est la caméra fisheye
• En haut à droite, c'est le rendu, sous forme d'image, du capteur de profondeur
• En bas à droite, c'est la visualisation dans ROS, de la sortie du capteur de profondeur, c'est un nuage de point en 3D, chaque point correspondant à un 'obstacle', bien évidemment avec du bruit et des zones 'mortes'.

 

En pratique pour l'évitement d'obstacle,  il n'utilise que la vue 'nuage de point' en bas a droite, pour définir la position des points les plus proches  et choisir une 'meilleur' direction pour tourner ( ou rester droit s'il n'y a pas d'obstacles).

Voilà mon nouveau projet éducatif, pour m'éduquer moi, surtout :

 

 

 

 

Le robot se compose :

• D'un kit de développement Intel Euclid :
  C'est un kit tout en un, incluant un module realsense ( perception de profondeur, comme la kinect), deux caméra, un mini-PC, une batterie, et de multiple capteurs, dont un gyroscope/accéléromètre
   
• Une carte Makeblock MegaPi
  Elle est compatible Arduino Mega, et inclu entre autres des driveurs moteurs.
   
• Une raspberry PI 3
   
• De la mécanique Makeblock
   
• Les moteurs du magasin robot-maker (lien).
  J'ai cassé un des moteurs du kit , mais ceux du magasin sont compatibles juste en créant un connecteur pour remappé les fils correctement.

 

Mes objectifs principaux avec ce robot sont d'apprendre et mettre en oeuvre toutes les techniques de mapping et localisation, type SLAM, et de mettre en oeuvre des algorithmes videos, type reconnaissance d'objet, de personne.

C'est aussi l'occasion de continuer à me plonger dans l'univers ROS, l'Euclid étant fournis avec de nombreux 'noeux' ROS pour les différents éléments. 

 

Le robot lui-même risque de se transformer en robot 'joueur', par exemple je vais essayer de me faire ramener une balle que j'ai lancer. (il me manque quelques actionneurs bien sur).

 

Voilà une première démonstration, elle utilise une partie des noeuds ROS fournis avec l'Euclid pour faire de la détection d'obstacle avec le capteur de profondeur, ainsi que leur algorithme d'évitement. Seul les noeuds ROS pour actionner les moteurs sont codé maison, en utilisant rosserial pour accéder a l'Arduino.

 

 

Toutes les sources du projet :  https://github.com/Bobox214/Dovlo

A mince, j'ai fait une edition car les listes numeriques ne s'affichent pas correctement, je les ai changees en des bullets, mais du cout il refaut une validation.

 

@Mike118 : Une petite validation ?

Si vous avez des remarques/commentaires/manquement ajouts  n'hesitez pas a les faire dans ce post, ou celui du tutoriel.

Pendant que c'est chaud je vais l'updater comme necessaire.

J'ai l'impression que je ne suis pas le seul, mais ma principale intéraction avec le site robotmaker consiste à cliquer sur 'nouveau contenu' dans le forum.

De ce fait je n'ai vu aucun des 5 posts sur le blog qui sont arrivés cette semaine, je n'aurai pas vu l'ajout d'un robot dans le robotscope ou l'ajout d'un tutoriel, ou l'ajout de nouveaux produits dans la boutique.

 

Je clique sur 'nouveau contenu' parce qu'alors ca me filtre le forum pour ce me montrer que les nouveautés. Je ne clique pas chaque jour sur 'blog' et pour me poser la question si en haut c'est un post que j'ai pas vu. etc..

 

Je me demandais donc s'il n'était pas possible d'automatiser un liens entre le forum et les autres parties de la boutique. Une catégorie du forum "Nouveauté robotmaker.com" où de manière automatique un post est crée à chaque nouveau billet sur le blog, avec juste le titre du billet et un lien vers le billet.  Ce post du forum étant directement fermé, sans possibilité de commentaire.

Si c'est possible on pourrait étendre çà aux nouveau tutorials, aux ajouts dans le robotscope, meme peut-etre avoir un résumé hebdomadaire des ajouts dans la boutique s'il y en a eu cette semaine là ?

 

Ca permet aux habitués ( où à moi en tout cas) de ne pas rater ce qui se passe ailleurs sur le site, sans à chaque fois devoir cliquer à 6 endroits différents pour voir s'il y a qqch de nouveau ( sachant que 90% du temps y a rien de nouveau).

 

Voilà, c'était une idée en passant.

Cela va toujours plus lentement que ce qui était prévu initialement, pour tout le monde, même les gens expérimentés.
Donc c'est normal et personne ici ne va s'en étonner, le plus important c'est de continuer régulièrement.