Je reviens par ici, j'ai vu un sujet sur l'IA, je me doutais de ce qui se passerait. J'ai lu le début, survolé le reste, bizarrement je n'ai pas été surpris du tour de la discussion. Tous les fils que j'ai vu, sur tous les forums où M. Delespinay intervient pour parler de son système finissent en M. Delespinay qui part offensé par les remarques et critiques (souvent curieuses et polis, mais pas toujours, disons-le). Et qui dit que tant que personne ne voudra collaborer pour tester son IA sur un robot, il n'y a pas de discussion possible.

Après toutes ces années et ces refus, je m'étonne que vous soyiez toujours dans le même scénario : si tout le monde vous dit systématiquement que vos systèmes sont sympas sans plus, pointent qu'ils sont désuets, mentionnent les méthodes récentes d'IA, d'apprentissage, à un moment il faudrait voir à écouter la critique ! Mais non, nous sommes tous des informaticiens bornés qui ne connaissent rien à l'IA. Vous avez la chacne de pouvoir venir présenter votre travail dans des communautés ouvertes à la discussion ; vu le manque de respect dont vous faites preuve à chaque fois, je suis étonné qu'on vous y laisse encore poster.

Bref, avec l'énergie perdue en débats stériles, vous auriez eu 5 fois le temps d'apprendre à fabriquer des robots et à vous passer de tous ces gens qui ne croient pas en votre système.

Est-ce qu'il n'est pas possible de blinder l'électronique ? De mes souvenirs de cours (houlà c'est loin), ça ressemble typiquement à un problème de CEM (compatibilité électromagnétique). De mémoire, il faut placer des éléments bloquants entre la source du bruit et les cartes/câbles, dans ton cas mettre les moteurs dans une boîte hermétique aux champs magnétiques/électromagnétiques.

Logiciellement, je ne suis pas sûr de ce qu'il est possible de faire, mais si tu blindes ; ça devrait bien réduire tes problèmes.

(Un peu de HS, mais j'ai aperçu dans la vidéo un robot Qbo, tu pourrais nous faire un retour d'expérience dans un autre sujet si tu as du temps ?)

Est-ce que le package Gmapping et les stack de navigation inclues dans ROS ne te suffisent pas ? Ça n'utilise que des capteurs embarqués (laser + odométrie), c'est plutôt éprouvé. En créant une carte en avance et avec une bonne odométrie, la localisation est plutôt bonne. En intérieur, j'ai eu de bons résultats.

Je confirme, OBS fonctionne bien et offre l'opportunité d'arranger plusieurs vues du bureau/d'applis comme tu le veux, très pratique. Et gratuit !

ROS facilite beaucoup d'aspects de la programmation de robots, et un aspect important est la modularité du logiciel : pouvoir remplacer l'algorithme de navigation N1 par N2 juste en démarrant un programme (noeud) différent, c'est vraiment pratique. Le fait d'avoir des mécanismes "faciles" à mettre en œuvre pour faire communiquer des programmes entre eux permet de se concentrer sur le développement des algorithmes. Pas besoin de réécrire ces interfaces à chaque fois. Le parallélisme est effectivement important (avoir l'évitement d'obstacles qui tourne toujours pendant que le robot planifie comment aller d'un point A à mais sans GPU, ça reste du faux parallélisme (corrigez-moi si j'ai tord -- les programmes sont appelés en série, sur des fenêtres de temps suffisamment faibles pour que ça ressemble à une exécution parallèle).

Pour ton code, poste-le (peut-être dans un autre fil de discussion, on dérive un peu dans celui-ci) et je jetterai un oeil.

ROS Serial te mâche le travail de communication, mais au prix de certaines limitations : http://wiki.ros.org/rosserialToutes les plateformes ne sont pas supportées. Selon le hardware, tu peux vouloir contrôler les trames plus précisément que ce que ne permet les messages ROS.

En termes d'exemples, tu peux regarder ce tuto : http://wiki.ros.org/rosserial_arduino/Tutorials/Blinkpour une version très simple de l'utilisation de ROS Serial. Si tu veux faire sans ROS, il faut gentiment invoquer Oliver qui a passé du temps sur ce sujet.

J'ai lu la discussion très rapidement, mais à propos de ROS et du microcontrôleur : il n'y a a priori pas de contrainte tant que tu peux faire communiquer ton MC et ton ordi. Tu as plusieurs designs avec ROS qui doivent théoriquement marcher :

- Un noeud d'interface qui tourne sur l'ordi (RPi dans ton cas). Ce noeud (qui est un programme C++, Python,etc. utilisant le framework ROS) est chargé de faire la communication avec le microcontrôleur (en utilisant un port série en général). Ça signifie que tu dois écrire le code de communication, mais le firmware du microcontrôleur est indépendant de ROS.

- tu utilises ROS serial, qui est un package ROS fait pour utiliser les topics avec un microcontrôleur. Ça marche bien avec Arduino, il y a sûrement d'autres MC supportés. Le firmware du MC utilise donc la logique de ROs (les topics) pour envoyer des infos vers l'ordi, donc pas besoin de faire tourner de noeud d'interface sur l'ordi, tu peux lire directement les infos.

Mode Modérateur ON.

Merci de recentrer la discussion et de rester poli quelque soit votre opinion des propos de l'autre. On est une petite communauté et ça serait bien d'y garder une bonne atmosphère (pensez toujours que votre ton ironique ou blagueur n'est pas forcément retransmis à l'écrit et un lecteur peut mal interpréter vos propos).

Par ailleurs, le débat plus d'anglais/moins d'anglais n'a, à mon avis, pas de solution. Il y a un ensemble de raisons qui justifient l'un ou l'autre (le public visé étant important dans la décision finale). On peut éventuellement ouvrir un topic séparé (gosh, un anglicisme!) pour discuter de la question (bien que ça soit probablement un peu hors du sujet de la robotique). Dans tous les cas, on ne s'insulte pas et on se met à la place de l'autre pour savoir si les blagues seront bien reçues.

Sinon, I'm gonna kick your butt* !

(*je viendrais vous administrer une correction sévère dont votre arrière-train se souviendra longtemps !)

Mode Modérateur OFF.

Pas sûr que ma réponse t'aide beaucoup, mais mon département utilise Riot + Matrix.org comme système de chat interne.

Pour bien comprendre ta problématique: contrôle des bâtiments = domotique ? Et tu parles d'un ensemble de bâtiments contrôlés depuis un point central ?

D'un point de vue robotique, on construit autant que possible des systèmes informatiques hiérarchiques : ma boucle de contrôle bas-niveau tourne sur le hardware embarqué (connexion capteurs-actuateurs) et peut fonctionner en l'absence de commande de plus haut niveau / connexion au réseau (e.g. il y a un évitement d'obstacle réactif en local). La commande de direction globale vient d'un autre programme sur le robot (e.g. un planificateur ou un système de décision réactif -- je vois du rouge je vais à droite, je vois du vert, je vais à gauche, ...). Si ce programme crashe pour une raison quelconque, ma boucle bas-niveau tourne toujours et assure la sécurité minimum de l'évitement d'obstacles. S'il y a un système plus complexe qui a besoin de ressources non disponibles sur le robot (un gros traitement d'images ou du raisonnement symbolique), les systèmes inférieurs doivent pouvoir fonctionner indépendamment. La fréquence de communication baisse au fur et à mesure qu'on monte dans la hierarchie : la boucle de contrôle est en général au kHz, un système réactif de l'ordre du Hz, un planificateur symbolique de l'ordre du mHz (pifométriquement, hein).

Y'a une mode des structures de ce genre en ce moment !

C'est utilisé en robotique aussi d'ailleurs (c'est tout en anglais, désolé) :

https://ntrs.nasa.go...20140010029.pdf

https://ti.arc.nasa....y/superballbot/

À propos de la localisation, un thread twitter (en anglais, désolé, mais les anims sont plutôt claires) sur les filtres particulaires (Particle Filters) : https://twitter.com/...559073913704448

Bon j'ai des vacances la semaine prochaine, j'espère avancer sur Marcel !

Mais c'est qu'il pourrait rouler dans l'été ce robot !

Ça fait plaisir de voir que ça avance

Suffisait de demander : https://ec.europa.eu...ws/robots-dream

EDIT : le site officiel est là http://dream.isir.upmc.fr/

Pour compléter ce que dit Sandro, il est important de faire des tests simples de tes fonctionnalités. Si tu veux mesurer une distance à partir de ton capteur, écris un code qui ne fait que ça, et teste ton code avec seulement le capteur branché sur ton Arduino. Quand tu as validé que ce code marche, tu peux créer une/des fonctions dont tu sais qu'elles font ce que tu veux comme tu le veux. En créant un ensemble de briques de code comme cela, tu simplifies le développement de ton projet et tu rends le code plus clair, ce qui te permet d'identifier les sources d'erreur plus facilement.

Pour ma part, j'ai eu du bonne expérience avec des cartes Micro:Bit (https://microbit.org/) et des enfants de 8-12 ans. En leur expliquant les bases de l'électronique pour les capteurs et les moteurs, et en les aidant pour la programmation de la carte, ils ont réussi à faire des robots qui roulent en une douzaine d'heure. On est parti au début sur du carton pour les bases, puis on a fait des versions "propres" en plexi (sur la découpeuse laser du fablab).

En gros, il existe beaucoup de kit d'éducation et de cartes "simplifiées" pour permettre aux enfants d'apprendre les bases de la robotique. L'intérêt de cette approche par rapport à des kits avec des chassis, c'est que ça ne coûte quasi-rien et c'est personnalisable à l'envie. Ça demande juste un peu plus de travail, mais ça se fait bien en compagnie d'un adulte.

Bravo !

Pour ajouter quelques détails:

- python est un langage interprété (donc il n'y a pas d'étape de compilation en fichiers exécutables ; on "exécute" le script). Le développement est relativement rapide (le langage est un peu moins contraignant que, par exemple, C ou C++ ; pas besoin d'attendre la compilation) et il est facile de transcrire un algorithme en python (par exemple parce que python ne demande pas à l'utilisateur de faire la gestion de la mémoire utilisée par son programme).

- IDLE, ipython, jupyter notebook sont des outils qui permettent d'exécuter du code python (en ligne de commande pour les deux premiers, dans une page web pour le dernier).

- pip est un utilitaire de gestion de paquets pour python ; La commande "pip install nomdupackage" permet d'installer nomdupackage. Il y a des différences entre installer nomdupackage avec pip, avec apt sous Linux (sudo apt install python-nomdupackage), conda, etc. que j'avoue n'avoir jamais creusé personnellement. Entre apt et pip, les packages de pip sont en général plus récents que ceux disponibles par apt (attention aux conflits !).

- python dispose d'un nombre immense de modules pour faire plein de choses. Parmi ceux que j'utilise : numpy/matplotlib/pandas/seaborn pour le traitement des données et la visualisation ; scikit-learn/tensorflow pour le machine learning ; wxPython pour créer des interfaces graphiques ; et j'en passe.

- beaucoup de libraries offrent une interface python, parce que le langage est facile à apprendre et accessible, donc très utilisé. Le nom est souvent affublé d'un "py" pour representer ça : Bullet -> pyBullet ; ROS -> rospy ; torch -> pyTorch ; etc.

Pour ce qui est de faire naviguer un robot dans un environnement, il y a deux approches:

- la version réactive (par exemple les roomba) : une stratégie de déplacement pseudo-aléatoire dans un environnement contraint (une pièce) permet en général de couvrir la majorité de l'espace en un temps long (théoriquement infini). L'intérêt, c'est qu'elle demande peut de capteur/peu de qualité dans la mesure. L'inconvénient, c'est qu'elle prend du temps.

- la version modèle : en construisant/ayant à disposition un modèle de l'environnement (une carte dans ton cas), tu peux faire du SLAM, en combinant l'odométrie et une correction basée sur des amers distants (un peu comme l'idée des poteaux que suggère Oracid).

Globalement, je recommande ce cours sur la navigation qui est très bien fait : ROB312 https://perso.ensta-...rses/index.html

https://www.ebay.fr/...GEAAOSw3mdZcysB

Ça a l'air d'être la première édition de 2008, la deuxième édition de 2016 est celle pointée par Ludovic.

En pratique, pour un cours de base de robotique, ça me semble un peu overkill (après, c'est un bouquin qui sert bien pendant les 10 années suivantes - jusqu'à l'édition d'après). Avant de considérer l'acheter, je te conseille effectivement de le consulter en bibliothèque ou en pdf.

Le "Elements of Robotics" est déjà une bonne base (bien que clairement moins complet) et il est gratuit en pdf : https://link.springe...8-3-319-62533-1

Si tu te trouves limité par ce bouquin, tu pourras envisager de dépenser 300 USD dans "La Bible de la Robotique"

Non mais ça il ne fallait pas le dire, pour tenir mes délais et le faire rouler dans l'été ce sera comme ça : j'ai dit "il roulera dans l'été", sans préciser dans quelles conditions .

En capteurs il n'y aura que la télémétrie le pilote (moi) ne doit pas se planter !

En fait j'ai du temps, comme beaucoup de monde, donc en sachant ce que je vais utiliser comme carte je peux prévoir les emplacement et supports.

Ben go Arduino, drivers, moteurs, 5m de câble et les boutons que je mentionnais. Dans tous les cas, si cette partie marche, tu peux développer le code de l'Arduino pour couvrir plus de besoin (wifi, etc), ou connecter une RPi à l'Arduino si cette dernière est trop limitée. L'expérience que tu acquiers en faisant fonctionner ton système te dira si tes plans marchent ou s'il faut les modifier.

Après, si tu veux juste qu'il roule, tu l'amènes dans une pente, une pichenette et paf, c'est parti

(en vrai, j'attends avec impatience de voir ton robot rouler de manière legit )

J'aurais tendance à réfléchir en termes de capteurs et d'actionneurs : la première étape, ça devrait être (à mon avis) de valider que tes moteurs peuvent faire bouger ta machine. Donc un montage super simple avec ton driver + moteurs + une Uno pour générer du PWM en fonction de deux potentiomètres/boutons (vitesse avant arrière, vitesse de rotation) pour commencer.

Selon ce que ça donne, tu peux faire le test suivant avec la motorisation de ta nacelle (donc ajouter les drivers/moteurs correspondants).

Pour ce qui est des capteurs, tu as les codeurs des moteurs, probablement une caméra, un laser ou des ultrasons (pour détecter les obstacles et éviter les collisions si le pilote se foire) ... À ce niveau, ça peut valoir le coup d'intégrer un PC portable et un routeur wifi, selon le nombre d'entrées nécessaires et la puissance de calcul nécessaire. Je pense que tu n'as pas trop de problème de place pour ça .

De mémoire, sur une plateforme Robulab, on avait intégré un accéléromètre + Arduino connecté au PC du robot, donc l'organisation de ton robot est assez libre.

Arf, violent !

Tu as une idée de ce qui a provoqué le problème ?

L'interface d'Atom est sympa mais il est lourd et rame.

Sinon il y a VSCodium qui sont les sources de VSCode et a priori vient sans les trackers de crosoft: https://github.com/VSCodium/vscodium

Remarque bête : si tu réduis la taille des pièces que tu dessines pour les imprimer en 3D vite, avec des modèles des composants (genre un cylindre pour les moteurs), et-ce que ça te ne permettrait pas d'éviter ce genre d'erreur à moindre coût ? Mieux vaut jeter  500g de plastique à 20€ le filo que 10kg d'alu à je sais pas quel prix (après j'ai pas suivi l'état de tes imprimantes, me semble que t'avais eu des problèmes ?).