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.

Oui ça coûte un bras.

Ce n'est pas vraiment destiné aux amateurs, mais plutôt aux université et aux industriels.

 

Voici une description plus détaillée (en anglais) de la bête:

https://click.intel....opment-kit.html

Je l'ai directement acheté a intel, ce qui fait avec frais de port et frais de douane plus de 450E.

 

La profondeur de détection est donnée pour un range de 50cm à 3m, avec des angles de 60° horizontal et vertical

La caméra RGB est HD, avec des angles de 70° en horizontal et 40° en vertical

La caméra fisheye est juste en VGA, avec des angles de 133° en horizontal et 100° en vertical.

 

Les caméra et la détection de profondeur semble plutôt bien fonctionner en exterieur aussi, ce qui rend le GPS intégré un peu plus utile

 

Pour la consommation, elle est donnée à 5W en nominal ( pas sur de ce que ca veut dire), mais je pense que c'est très lié à l'utilisation de l'Atom.

Le kit contient un micro-ventilateur intégré, et lorsque les scenartio d'analyse d'image sont en routes, on l'entend tourner régulièrement.

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.

Mes robots sont pour l instant des robots pour apprendre, donc une fois 'termine' je prends des photos, je sauvegarde le code puis je demonte.

Effectivement avec des encodeurs ton robot, une fois qu'il saura se balancer pourra en plus tenter de se ballader, mais ce n'est pas obligatoire, c'est plutot une deuxieme phase.

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.

Je ne pense pas que les moteurs ont besoin d'une si grande reactivité, c'est peut-etre plus facile de rattraper des erreurs, mais ca crée aussi des grosses surcompensations, qui sont assez difficiles à contenir.
Un conseil, met le centre de gravité plutôt vers le haut, c'est plus facile. (typiquement batterie en haut).

Je suis en train d'écrire un tutoriel pour l'ensemble arduino/raspberry/PC.
C'est assez long à écrire donc j'ai fait une sauvegarde en copier/collant le contenu de ma page en cours de construction dans un fichier pour plus tard.

Je voulais voir s'il y avait une méthode plus simple, en soumettant le tutoriel 'en cours', pour pouvoir l'éditer plus tard, avant de dire qu'il est pret pour publication ?
J'ai pas oser appuyer sur 'soumettre' de peur de pas pouvoir édtier, ou qu'il soit visible en l'état.

L'entrée de l'algorithme est simplement l'ecart par rapport à la vertical ( donnée par le capteur gyroscope/acceléromètre)

La sortie est la puissance et la direction a donnée au moteur.

 

Pour l'accumulation d'erreur, effectivement le controleur cherche a réduire l'erreur, mais parfois il ne le fait pas assez vite. Dans le self-balancing, en regle generale le coefficient pour l'accumulation est tres faible, il permet juste de compenser l'imprecision de ton capteur.

 

Je n'ai regardé si la logique floue était pertinente ou pas, et comment, si le sujet t'intéresse, je t'invite a te lancer, faire un robot self-balancing est relativement simple, 2 moteurs et un capteur gyroscope/acceleromètre et c'est parti.

Il y a sur le robot un gyroscope et un accelerometre, un MPU6050 connecte en I2C pour etre precis.

Sinon c'est effectivement impossible de faire tenir le robot debout.

 

Le probleme du self-balancing, c'est comment tu commandes les moteurs en fonction de l'etat actuel ( et passe) de l'angle du robot par rapport a la vertical.

Une simple commande de type "moteur = error*Kp" ne suffit pas , c'est pour ca qu'on utilise un controlleur PID, proportionnel, integral et derivatif, ou tu calcules les commandes moteurs a partir de l'erreur actuelle, l'accumulation des erreurs depuis le debut, et la difference avec l'erreur precedente :  "moteur = error*Kp+ cumError*Ki + diffError*kD", mais encore faut il trouver les bonnes valeurs des coefficient Kp, Ki et Kd.
Et dans Crabeel j'avais choisie une approche genetique pour trouver les meilleurs valeur de coefficient, et c'est ca que l'on voit dans l'evolution des generations.

Je m'etais inscrit pour voir les pieces du future turtlebot 3 actuellement developpe par Robotis pour la ROS fundation. Mais je ne l'ai pas pratique, n'en ayant pas encore eu le besoin.

Ca a l'air a un mix interressant  avec une interface 100% online, une database consequente d'objet existant.

Quand l'arduino est connecte en USB a un raspberry PI, pour compiler en ligne de commande on peut aussi  utiliser  'platformio' (http://platformio.org).

C'est probablement un peu plus complique que le tutoriel de Path, mais c'est une outil  qui marche pour d'autre platforme que arduino.

 

Si cette approche interesse des gens je pourrai faire une petit tuto.

Oui tu as raison c'est souvent un module a part.

J'ai regardé pour les carte PC du type Raspberry, et elles n'incluent pas de module RTC (visiblement pour des raisons de prix). Il y a quand même un timer sur le SoC, mais sa précision est faible, par exemple ca va dériver avec la température.. C'est souvent largement suffisant pour faire des timestamps. Par contre ca ne l'ai pas pour faire un calcul avec des données GPS par exemple.

 

Après si le robot à une connection internet il est toujours possible de synchroniser son horloge interne avec une horloge standard de haute précision grace au protocol NTP.

Faire une animation de 'feu' pour les soirees d'hiver

Bonjour,

 

Un "Timestamp" c'est un identificateur de temps. En règle générale dans une puce éléctronique complexe, il y a toujours un module 'timer' dans un coin, justement fait pour la gestion d'un temps. Et l'OS peut l'utiliser pour tout ce qui est lié au temps.

Donc si le robot tourne un OS de type linux, il y aura un timestamp associé, après la question c'est de pouvoir y accéder, et cela dépend du robot et du kit de développement associé.

Concernant le nombre, il y  a un temps principal sous linux, celui qui t'ai répondu quand tu fais 'uptime' par exemple, mais sur les puces éléctronique il peut y avoir plusieurs 'timer' qui peuvent être accessibles, mais de manière moins directe.

Je crois que le fondateur de SofBank, Masayoshi Son est un 'fanatique' de robotique et c'est lui qui a provoqué le rachat d'Aldebaran, j'imagine qu'il est aussi à l'origine du rachat de Boston Dynamics.

L'évolution d'Aldebaran n'a pas été grandiose après son rachat, j'espère que ce sera meilleur pour Boston Dynamics.

Voici 5 videos du cours  "ColumbiaX: CSMM.103x Robotics" que je suis sur edx.org (https://www.edx.org/...mbiax-csmm-103x)

C'est en anglais malheureusement.

 

Ca explique la notation D.H et son utilisation pour faire de la forward Kinematic :

 

Forward Kinematic D.H Example:

 

D.H Notation example : 2-link planar robot

 

D.H Notation example : SCARA Robot

 

Kinematic example : 6 DOF and 7 DOF robots :

 

 

Effectivement je ne l'avais pas vu, et même après que tu m'as montré son existence, j'ai cherché avant de le trouvé en repartant de la page principale (dans le footer).

 

Merci !

Petite idée.

Quand on est sur la boutique, j'aurai aimé voir une rubrique "dernier ajouts", qui permette de trouver facilement les (10,20?) dernier produits ajouté dans la boutique.
Parfois on cherche quelquechose de précis, mais dans mon cas je "flane" souvent et voir ce qui est recemment ajouté peut me donner des idées. En parcourant les rubriques j'ai vu des nouvelles choses par rapport a mon dernier passage je pense, genre le kit de seed-studio de nouvelles entrées dans l'alimentation.

 

A prendre ou à laisser bien sur

Pour les bases du machines learning et ceux qui parlent anglais le cours de Andrew Ng est une référence :

https://www.coursera...achine-learning

On y apprend les differentes catégories de problèmes et les premiers algorithmes de machine learning que sont les régressions linéaires, puis les reseau de neurones muti-couches. C'est une bonne base pour ensuite attaquer le deep-learning.