Le quartier de la défense, je connais, j'y ai travaillé quelques années.

Mais j'avoue que je n'ai jamais songé à y habiter, ça n'est pas pour moi.

En tout cas, tu as un bel appartement de geek avec cet écran géant et ce robot! 

Leon.

C'est une chambre d'étudiant, chez toi?

Leon.

Essaye de programmer en C (pas en C++) comme tu programmerais en Basic, sans te soucier des objets, pointer, fuite mémoire etc.
Puis, quand tu y auras pris goût, tu pourras voir les concepts plus compliqués.

C'est ce que je fais depuis pas mal d'années : pour mes bidouilles, je dois coder en C# et en C++, mais dans ces 2 langages, je code exactement comme en C, langage que je maitrise beaucoup mieux (et qui ressemble beaucoup au basic).

Et c'est sans utiliser les trucs dont je n'ai pas besoin en C : allocation dynamique de mémoire entre autre.

J'utilise la syntaxe C++ et C# quasiment uniquement pour des appels de librairies faites pour du C# et C++, donc trois fois rien.

Je n'ai jamais vraiment compris les concepts qui se cachent derrière les langages orientés objet, et ça ne m'intéresse pas trop, tant que j'arrive à coder ce que je veux. Mais j'avoue que parfois, quand je dois me plonger dans du code déjà écrit en C# ou C++, j'ai vraiment du mal... Beaucoup de mal.

Donc il serait bien que je me donne un coup de pied au cul pour franchir le pas... un jour peut-être!

Leon.

Quelle idée de mettre un frigo (ou un distributeur de boisson) dans un atelier?

Franchement, ça ne me fait pas envie, mais alors pas du tout. L'important c'est ce que l'on fait, ce que l'on réalise. Pas la propreté de son atelier.

Attention, ceci n'est que mon avis, vous avez le droit de ne pas être d'accord.

Leon.

En regardant votre modélisation Anykode Marilou, je vois 6 articulations, mais je dois certainement me tromper quelque part. Je pensais notamment que tous les gros cylindres larges et plats étaient des articulations.

https://www.robot-ma...-1499518989.png

Leon.

Je compte 6 articulations par jambe, si je ne me trompe pas.

Vu que vous êtes à budget serré, ne pourriez-vous pas faire l'économie d'1 articulation sur chaque jambe?

Notamment, je ne comprends pas l'intérêt de la "double hanche". C'est comme si ce robot avait un fémur séparé en 2.

Il semble y avoir 2 articulations par jambe qui font à peu près la même chose : basculer la jambe d'avant en arrière selon un axe horizontal latéral.

Peux-tu stp nous expliquer l'intérêt de la chose?

Leon.

Je trouve très intéressante cette réflexion sur la nécessité de passer par une étape de simulation.

En industrie la question ne se pose pas mais en amateur c'est moins certain.

L'idée de la simulation est séduisante. Je suis bien tenté d'essayer et voir le temps que ça pourrait me prendre.

Vu le retour d'expérience d'Oracid, j'ai peur que pour arriver à un résultat il soit nécessaire de définir très précisément tous les aspects et donc d'y passer beaucoup de temps.

 

Est-ce que vous pouvez m'indiquer un exemple sur ce forum d'un projet réussi qui soit passé par une étape de simulation pour que je me fasse une idée ?

Pour l'instant sur ce forum j'ai le sentiment qu'il y a plus de "résultats" par une approche bidouille-empirique que par une méthode simulation-réalisation.

Je pense que ton équipe Yougo joue plutôt dans la cour des amateurs que dans la cour des industriels donc à voir ce qui est le plus efficace par rapport au temps que vous comptez y consacrer. En plus je pense qu'au bout d'un certain temps sans résultats intermédiaires vous risquez de perdre la motiv.

Sur BOB4, mon drone, j'avais fait une modélisation simplifiée. En fait 3 modélisations 1D séparées : 1 pour les mouvements verticaux, 1 pour les mouvements horizontaux, et une dernière pour les mouvements de lacets.

Ca m'avait permis de déverminer la chose, de pré-régler les asservissements, et vérifier leur robustesse (en injectant du bruit et/ou du retard dans les mesures). Ca m'a été très utile avant de lancer les asservissements sur le drone.

http://www.robot-maker.com/forum/topic/3447-bob4-drone/?p=18330

De manière générale, l'utilité d'une simulation ça dépend de la complexité de mise en oeuvre d'un essai, du risque de cet essai (destruction), du cout de l'essai, et de la complexité du système lui même. Un drone ou un bipède, ce sont des systèmes instables, ça ne fonctionne que si tout est bien réglé. Du coup, les faire fonctionner réellement pour la première fois, c'est juste très compliqué. La simu permet de déverminer.

De plus, ça n'est pas forcément facile de les faire fonctionner pendant très très longtemps pour tester, et encore tester:

* pour le drone, il faut des batteries chargées (j'avais 4 jeu de batteries, décharge en 6  minutes, recharge en 1h...), et de l'espace pour le faire voler.

* pour un bipède de plus de 1m très dynamique, il faut de l'espace, et il faut quelqu'un en permanence à côté pour surveiller ses mouvements, voire le suivre avec un portique

Bref, un bipède ou un drone, ça n'est pas comme un robot tout simple à 2 roues. Et la simulation est beaucoup plus utile pour un drone ou un bipède. La simulation va permettre de valider un concept, de déverminer un algorithme, ça va permettre de rejouer des centaines de fois une situation avec des réglages différents, etc...

Si un algorithme ne fonctionne pas en simulation, sur un robot bipède, il y a peu de chances qu'il fonctionne dans le monde réel.

Leon.

J'en ai déjà parlé, de mon côté, j'avais utilisé Anykode Marilou.

http://www.anykode.com/index.php

J'en parlais ici:

http://www.robot-maker.com/forum/topic/9118-anykode-marilou-simulateur-robotique/

http://www.robot-maker.com/forum/topic/9109-projet-de-bipede-marche-dynamique/

La version d'essai est renouvelable à l'infini (réellement, même pas besoin de tricher) et les limitations ne sont pas très contraignantes pour des robots simples.

J'étais plutôt satisfait : ça fait le job, et surtout, c'est pas trop complexe à utiliser. Les tutoriels sont bien faits, ça génère le code de départ en semi automatique.

C'est vraiment orienté robotique : ça simule des capteurs et des actionneurs.

En plus, c'est un logiciel français!

Par contre, je ne peux pas comparer à autre chose, car c'est le seul logiciel de simulation 3D que j'ai utilisé.

Ca utilise le même "moteur physique 3D" que beaucoup d'autres : ODE.

Leon.

Quelques remarques:

Donc avant de partir, NON on ne vas pas faire tout en simulation dès le début calmez vous, on va faire de la simulation, mais APRES avoir fait le robot, ou peut être de temps à autres pour vérifier des paramètres, mais il est hors de question de tout faire en simulation.

La simulation c'est surtout pour trouver les paramètres d'un réseau de neurone qu'on voulait le faire, on a vraiment pas le temps de tout faire en simulation.

A mon avis, c'est voué à l'échec. Un bipède est réellement un système très complexe.

Il y a 2 aspects très importants qui militent en faveur de l'utilisation d'une simulation:

* Pour tester et déverminer les algo à l'infini, sans avoir besoin de robot physique. Ca veut dire que n'importe qui peut n'importe où travailler dessus, juste avec un PC.

* Pour valider l'architecture mécanique du robot lui même. Est-ce que telle longueur de jambe améliore la stabilité? Et si on écartait la hanche de 5cm pour voir? Et la forme du pied? C'est hyper rapide à faire en simulation, alors que ça prend des jours à réaliser en réel. Car oui, c'est certain, la première idée ne sera forcément pas la bonne.

Sinon, ATTENTION : le modèle utilisé pour la simulation et le modèle utilisé pour la réalisation physique n'ont AUCUN intérêt à être les mêmes!

Dans l'industrie, on sépare ces 2 sujets, c'est obligatoire. Le modèle utilisé pour la simulation doit souvent être un modèle très simplifié de la définition détaillé, qui simule la cinématique, les inerties, la géométrie. Mais il ne doit pas forcément modéliser finement les formes, ça ne servirait à rien.

Sinon, je suis toujours aussi pessimiste sur les chances de réussite d'un tel projet, mais c'est un autre débat.

Leon.

Pourquoi ne pourrais-tu pas utiliser du C++?

Tu peux utiliser du C++ même si tu ne sais pas programmer en C++.

Globalement, tout ce que tu codes en C est compatible C++.

Il te suffira simplement d'utiliser les appels aux fonctions MODA de Marilou avec la syntaxe C++.

Il suffit de partir des exemples donnés, et de les enrichir avec du code en C.

De plus, as-tu bien remarqué que tu peux générer en automatique ton code de départ dans le langage de ton choix, à partir du modèle et donc des capteurs/actionneurs simulés? C'est juste hyper pratique.

Leon.

Une petite question vous utilisez quoi comme simulateur ?

Je ne sais pas à qui s'adresse cette question... A tout le monde?

De mon côté, pour mon bipède BOB5, j'utilisais Anykode Marilou. Voir les sujets suivants:

http://www.robot-maker.com/forum/topic/9118-anykode-marilou-simulateur-robotique/

http://www.robot-maker.com/forum/topic/9109-projet-de-bipede-marche-dynamique/

Attention : si tu veux discuter du sujet, il faut le faire ailleurs. Ici, on est sur le sujet qui parle de Walk-e.

Leon.

Salut à tous,

Je n'intervient que rarement sur ce forum, mais là, ça me semble nécessaire.

Tout le monde a l'air très enthousiaste autour de ce projet, et je ne vois que des retours positifs, c'est très bien, mais... je vais devoir faire mon rabat-joie, désolé (c'est souvent mon rôle). Je suis assez surpris que personne ne l'ait déjà fait.

Est-ce que vous avez conscience de la complexité d'un tel projet? C'est monstrueux.

Même si vous maitrisez la réalisation de pièces 3D, même si vous maitrisez la théorie des réseaux de neurone, même si vous savez utiliser des arduino et des capteurs de poids... passer à la réalisation d'un robot comme Cassie, c'est carrément autre chose, c'est d'un autre niveau.

C'est d'une difficulté que vous n'imaginez peut-être pas encore. A votre avis, combien de centaines d'homme-jour Cassie a nécessité en bureau d'étude?

Vous prenez exemple sur Cassie, qui est un magnifique robot. Mais avez-vous conscience que Cassie coute beaucoup plus de 3000€? Je parle bien sans compter les "couts d'étude". Cassie utilise beaucoup de métal usiné, de carbone. Faire la même chose avec de l'impression 3D, je n'y crois pas beaucoup.

Combien de versions de prototypes et combien d'années ont été nécessaire pour arriver à un résultat abouti pour Cassie?

Est-ce que vous partez de zéro? Ou alors est-ce que vous partez d'un concept "open-source" déjà dispo? Si oui, lequel? Je n'en connais pas et ça m'intéresse si ça existe.

Est-ce que vous avez déjà des expériences passées? Je veux dire de robots qui nécessitent une bonne dynamique, une structure rigide, des asservissements intelligents et temps réels?

Combien d'heures par semaines comptez-vous consacrer sur le projet? D'un point de vue planning, combien d'années de travail vous visez? Rester groupés et motivés pendant plusieurs années autour d'un projet commun, ça n'est pas facile.

Combien de versions de prototypes complets estimez vous nécessaire pour arriver à un résultat abouti? 3 versions? 4? 5?

Et en terme de budget total?

Il y a 3 ans, j'avais comme projet, de réaliser un bipède à marche dynamique. Je l'avais étudié en simulation, puis j'avais commencé à le construire en vrai.

http://www.robot-maker.com/forum/topic/9109-projet-de-bipede-marche-dynamique/?p=60671

http://www.robot-maker.com/forum/topic/9816-bob5-bipede-1m20/

Mais j'ai abandonné pour plusieurs raisons. Rien que la partie simulation m'avait pris pas mal de temps, mais j'étais tout seul.

N'hésitez pas à commencer par simuler votre robot pour déverminer vos algorithmes. On peut même simuler les imperfections des capteurs / actionneurs / électronique pour tester la robustesse des algos (temps de retard, jitter, imprécision, bruit, etc...).

Bon courage dans tous les cas. Je suivrais vos avancées avec intérêt.

Si vous avez d'aide sur les items suivants, n'hésitez pas à me solliciter par message privé (je consulte rarement le forum):

* électronique temps réel

* asservissements (classiques, complexes, mais pas réseau de neurone)

Leon.

Sinon j'ai tout configuré comme je le voulais. J'ai fait un test de précision. Impossible de manquer un trou avec ça.

20170519_210452.jpg

Joli, effectivement!

Pour la peinture, il faut faire attention : certaines peintures sont légèrement conductrices, je ne sais pas si tu as testé.

Le mieux c'est le verni dédié aux PCB, en spray. Certains vernis se volatilisent au niveau des pad de soudure quand on chauffe le pad avec un fer à souder. On peut aussi vernir le PCB (verni de tropicalisation) une fois que l'on a tout soudé et testé (en protégeant les connecteurs bien sur).

Sinon, tu n'aurais pas une vidéo de la machine en marche? Ca prend combien de temps de graver une telle platine?

Leon.

Pour un robot téléguidé, et c'est bien le cas ici, je ne vois pas l'intérêt de mettre des codeurs dans les roues.

Juste en modifiant la puissance entre droite et gauche, même sur un tel chassis articulé, ça doit pouvoir le faire.

Mais j'avoue que je n'ai pas trop compris pourquoi Levend pense que c'est potentiellement nécessaire avec un tel chassis articulé.

Est-ce qu'il y aura des "servos" au niveau des 2 articulations du chassis?

Leon.

J'ai découvert les FPGA il y a 2 ans, et je trouve ça vraiment puissant.

Mais même si c'est puissant et amusant, ça n'est utile que pour des applications assez spécifique. C'est en manipulant la bête que l'on comprend ce qu'un FPGA peut apporter.

Par contre, je suis du même avis que les autres : pour exploiter même un tout petit peu la puissance des FPGA, il vaut mieux rapidement apprendre le Verilog ou le VHDL. En quelques lignes de code, tu fais l'équivalent de choses très complexes représentées en "schématique".

Et puis, passer d'un langage classique © à un langage de description hardware, je trouve que c'est un bon exercice "intellectuel".

Leon.

Je suppose qu'il faut aussi une très bonne ventilation, pour évacuer les vapeurs inflammables et toxiques. Mais ça c'est de base indispensable en découpe laser de plastique/bois.

Et un bon extincteur à côté de la machine, au cas où...

Leon.

Je ne savais même pas qu'on pouvait découper du bois proprement avec un laser...

Comment on fait pour qu'il ne brule pas? Je précise que c'est une vraie question.

Leon.

Sinon, tu as déjà réussi un dessin complet? Je ne vois aucune photo d'ensemble d'un dessin complet, et ça serait vraiment chouette.

Si nécessaire avec une vue aérienne depuis un drone. Il y a forcément des volontaires équipés de drone dans ton coin, si tu n'en n'as pas un toi même!

Voire carrément une vidéo aérienne...

Côté navigateur, petit changement de stratégie. Du fait des imprécisions liées au système satellite, on fait appel à l'odomètre lorsque la distance à parcourir est inférieure à 1 mètre (à ajuster par essais) , au récepteur GNSS sinon, au compas dans tous les cas. En mode DEBUG ça ce passe bien (c'est un mode où je simule en live les données des capteurs par des informations que je maitrise avec des curseurs), à voir sur le terrain ce que ça donne.

Par rapport à ça, la meilleure stratégie reste la "fusion de données". N'utiliser qu'un seul jeu de données "position / orientation", qui est élaboré à partir de la fusion des données GNSS et odomètres.

Dans le principe : l'odomètre renseigne la partie "haute fréquence" du signal, et le GNSS la partie "basse fréquence".

Une méthode simple pour faire cette fusion de données :

1) tu mets à jour en temps réel la position avec l'odomètre. C'est précis sur les petits déplacements, et la précision de mesure est très bonne (quelques cm).

2) Mais en plus, tu recales lentement la position par rapport au satellite. Le lentement est super important. Par exemple, si tu as un signal GNSS toutes les secondes, tu ne recales (par exemple) que de 5% de l'écart entre la position estimée et la position GNSS chaque seconde. Ca fait que ça converge en ~20sec. la vitesse de recalage sera bien évidemment à affiner avec des tests sur le terrain.

Si ton robot fait des pauses ou roule à basse vitesse, pour éviter les "sauts" de l'estimation de position (à cause de la dérive GNSS), tu peux aussi choisir la vitesse de recalage en fonction de la vitesse réelle du robot: à l'arrêt, tu ne te recales pas du tout, et à haute vitesse tu te recales rapidement. Du coup, tu te recales de X% tous les mètres (non plus toutes les secondes).

Leon.

Un article mérité sur le célèbre blog Hackaday.

http://hackaday.com/2017/04/29/hackaday-prize-an-autonomous-beach-art-robot/

Ca doit faire un sacré coup de pub.

Bravo.

Leon.

Re,

 

je sais maintenant où me fournir en moteur. J'ai quelques questions sur les servomoteurs dont je ne trouve pas réponse sur le net, j'ignore si je peux les poser ici où dois-je recréer un nouveau sujet ? De votre expérience personnelle, le couple maximal du servomoteur indiqué était-il au moment où vous l'avez testé fidèle au couple annoncé ? Je vois supérieur à 66% parfois 70%, quel rendement puis-je attendre d'un servomoteur type ? Par rapport à la vitesse indiquée, souvent 60RPM, quelle est la plage des vitesses de rotation sur laquelle puis-je jouer ? Dernière question, en degré quelle précision un servomoteur type peut avoir ?

Les seules fois où j'ai testé le couple d'un servo (servo de qualité, entendons nous bien, pas servo à 3€) c'était à peu près conforme. Attention à bien mesurer ça à la bonne tension, ça varie énormément en fonction de la tension.

Mais attention : le couple annoncé, c'est le couple de blocage. Donc le couple résistant quand le servo ne bouge plus du tout car il force trop. Et un servo moyen de gamme ne peut tenir ce couple maxi que quelques secondes, pas plus.

Pareil pour la vitesse, c'est la vitesse à vide.

Du coup, je rappelle ce que j'expliquais ici : la puissance maxi est atteinte à la moitié du couple maxi et à la moitié de la vitesse maxi. Du coup, la puissance maxi est égal à 1/4 de vitesse_maxi x couple_maxi.

http://www.robot-maker.com/forum/topic/11192-openservo-ou-commande-cc-potar-encodeur/

C'est bien pour ça que je t'ai demandé plusieurs fois comment tu calculais la puissance de tes moteurs.

Tu as bien intégré ça?

Pour le rendement, je n'ai jamais mesuré, mais un servomoteur de modélisme n'est absolument pas conçu pour avoir un bon rendement!

Pour la vitesse, je n'ai pas compris ta question.

Leon.

Là, c'est à mon avis une vidéo pour rien. De la pure philosophie pour partager ses idées, mais ça n'est pas ce qu'attendent les gens qui le payent! Je pense que les gens veulent voir du concret, de l'avancement dans ses projets.

Est-ce qu'il a fait cette vidéo de manière sincère, croyant bien faire, ou alors est-ce qu'il était en manque d'argent? Lui seul le sait.

Encore une fois, la communication, c'est un exercice vraiment difficile.

Pour en revenir au sujet dans sa vidéo : le concepts d'agents dont il parle ne veut pas forcément dire d'éclater le contrôle de son robot en plein de modules électroniques différents. Je ne suis pas d'accord avec ce raccourci qu'il fait.

Dans plein de cas, on a tout intérêt à mettre plein "d'agents" dans des modules logiciels, mais qui sont tous hébergés à l'intérieur d'un seul processeur : communication ultra rapide entre ces modules sans nécessiter de réseau, mutualisation des ressources, réduction de la complexité. La multiplication des processeurs dans un système complexe (robot, voiture) est utile, surtout pour des contraintes "géographique" (éviter de faire transiter des gros faisceaux jusqu'à un calculateur central), mais ça n'est pas toujours une bonne idée.

Là aussi, c'est un métier... ça tombe bien, c'est le mien! Je veux dire mon vrai métier : architecte électronique système pour l'automobile.

Leon.

Ca alors!

Bienvenue pour ton retour à la maison, j'ai envie de dire.

Alors, ce drone-oiseau, il en est où? ;-)

Ca me fait plaisir de revoir des anciens (et anciennes)... Même si de mon côté je ne suis plus trop actif ici.

On a vu réapparaitre récemment :

* Oracid qui est devenu accro au forum

* Julkien

* Bernard (l'ancien admin) qui s'est transformé en "le mérovingien" (surnom donné par Bet@M@x à la belle époque, bien évidemment).

* JEF a fait son retour l'an dernier, mais on ne le voit plus

et j'en oublie certainement

Leon.

Du coup, la table est placée dans ton atelier? Ou alors dans ta maison?

Leon.

@Computer Mail : ceci est un avertissement de la part d'un modérateur.

Un forum est un lieu de partage.

Soit tu changes de comportement et tu partages des éléments concrets sur ton projet, pour nous montrer que tu ne nous racontes pas de conneries (sur ton IA et ton OS par exemple) soit je verrouille le sujet.

C'est non négociable, tu es prévenu.

Leon.

Bernard, c'est toi? L'ancien tenancier de la taverne?

Si oui, je pense que tu as le droit de revenir sur "ton" forum... Depuis le temps !

Leon.