Salut Léon,

super boulot que tu fait là, et tu en avances à un bon rythme à ce que je vois (j'ai toujours quelques problèmes à rester motivé face à certain problèmes qui me bloquaient dans mes projets, je respecte d'autant plus ceux qui arrivent à fournir un travail constant à leur projet).

Pour le poids de la bête je dit respect : faut le faire pour tout faire tenir dedans, et plus en ce souciant des problèmes de centre de gravité...

J'ai vu que tu utilisais Matlab pour afficher tes données et faire des tests. J'utilise aussi Matlab, ça fait gagner pas mal de temps pour faire du débug, mais je me demandais comment tu fait pour transmettre tes données à Matlab en temps réel ? il y a des boites à outils pour ça peut être ? Comme je suis en train de travailler sur l'asservissement de mon robot en ce moment ça pourrait m'être très pratique

en tout cas bonne continuation pour ton projet

Salut Léon,

beau boulot que tu nous a fait là ! BOB4 a volé de ses propres ailes
J'admire ta persévérance pour avancer à cette allure sur un tel projet perso.
Encore bravo et bonne continuation

Salut Léon,

ça avance toujours bien à ce que je vois. C'est un gros morceau la reconstitution de la position 3D de ton bestiau par rapport à toutes tes mesures capteurs mais je vois que tu t'accroches ^^
Tu pourrais indiquer une estimation du temps que tu passes sur ton projet si ça te dérange pas ? c'est que quand on arrive sur un forum on voit beaucoup de projets, et souvent on ne regarde que le résultat et on se dit "ah ben tient c'est cool ça j'aimerais bien faire pareil" mais sans trop se rendre compte de tout le boulot qu'il y a à fournir derrière.

Mais les sonars dans tout ça? Eh bien à chaque fois qu'on a une mesure sonar crédible, on s'en sert pour recaler vitesse et position dans la direction de la mesure. Déjà, on ne recale pas de 100%, mais de ~30% de l'erreur constatée, pour être robuste aux petites erreurs. Avec 30%, ça converge bien rapidement, sans introduire trop de bruit. Si on corrigait de 100%, ça créerait trop d'oscillations, de bruit.
Qu'est-ce qu'une mesure crédible? Une mesure qui est faite avec un mur (ou plancher) à peu près perpendiculaire (tolérance de 17° dans les 2 directions par rapport à ce plan), pas trop faible ni trop élevée (=impossible), cohérente avec l'estimation de position actuelle.

Pour résumer, tout se passe comme si j'utilisais les accéléro pour renseigner la partie "haute fréquence" des déplacements, et les sonars pour les basses fréquences. Les sonars permettent une estimation de position précise, mais peu souvent actualisée, surtout quand on doit "rejeter" de nombreuses mesures inexploitables (orientation pas bonne, objet devant le sonar). A l'opposé, les accéléros permettent une bonne estimation du mouvement sur de courtes durées (2 secondes maxi), mais ça n'est pas du tout précis sur le long terme. Il faut donc "fusionner" plusieurs sources d'informations de qualité différentes.

Par rapport à la localisation avec tes capteurs US, tu dit que tu les utilise pour corriger la position et la vitesse : j'imagine que ton drone n'a pas pas de carte de ton logement avec les dimensions précises, donc je suppose que tu déduis la vitesse avec deux mesures US et l'heure de chaque mesure et que tu intègre ensuite pour la position. La tolérance de 17° tu l'applique par rapport à l'orientation de ton hélico calculée avec tes gyros ?

C'est marrant pour les auto pilots d'avion ou autres drones d'extérieur c'est le même principe que celui que tu utilises, à la seule différence que c'est un GPS qui permet de recalculer la position "basse fréquence".

Par contre, j'ai encore énormément de problèmes avec le capteur magnétique, il est trop perturbé. Il faut impérativement que je trouve une solution.

J'imagine que c'est le moteur brushless qui pourrit les mesures ? Surtout que vu la proximité de l'ensemble ça va pas être évident...

Salut Léon,

Quelques news.

Tout d'abod, l'astuce du jour: pour voir comment se comportait l'estimation d'angle en vol, j'ai tout d'abord essayé de piloter l'engin tout en regardant l'écran du PC... très scabreux comme exercice, j'en ai conclu que c'était impossible (ou alors que je n'étais pas doué, ce qui revient au même). Le cerveau est tiraillé entre piloter un truc virtuel qu'on voit sur l'écran et piloter le drone réel. Bref, c'est le crach quasi assuré!
Comment faire? Et bien regardez la vidéo ci dessous: je filme mon drone avec une webcam, et je capture avec CAMSTUDIO les 2 vues: la vue de la webcam et la vue Matlab. Comme ça, je n'ai pas besoin de regarder l'écran du PC quand je pilote le drone; je peux rejouer calmement le truc, voir comment ça s'est comporté.

http://heli.bot.free.fr/demo_screencapture.avi
(aussi sur Dailymotion pour Néo et les autres, mais la qualité est vraiment merdique: )

pas mal ta technique ! effectivement ça a l'air bien pratique, et puis comme tu le dit ça te laisse le temps après d'étudier minutieusement la vidéo pour faire du débug. Tu utilises toujours ta toolbox Matlab qui recupère des données par le port série ? comme tu m'avais dit que c'était plutôt lent, et que le temps de réaction dans la vidéo a l'air tout a fait correct je me demandais si c'était le même outil.
D'ailleurs BOB4 a l'air assez péchu ^^ même avec son packetage ont voit qu'il reste réactif !

Ensuite, j'ai testé et retesté les gyro en vol, et contrairement à ce que je disais plus haut, je ne me suis pas contenté du résultat obtenu initialement (post du 25 juillet): ça oscille beaucoup, ça dérive. Oui, j'en suis encore à l'interprétation des gyro, alors qu'il me reste aussi à traiter les accéléro, les capteurs magnétiques, les sonars... bref, ça risque d'être long.

En fait, en vol, il y a beaucoup de vibrations, les mesures sont très bruitées. J'ai donc du filtrer un maximum dans le logiciel. Comment faire? Tout d'abord, il faut multiplier la fréquence des mesures. J'arrive à faire 120 mesures accéléro et gyro par seconde (6 données à mesurer à chaque fois) comtre 50 initialement et 60 mesures de capteur magnétique par seconde. Pas mal, non? Je filtre toutes ces mesures avec des filtre passe bas (1° ordre) de temps de réponse ~100ms. C'est le filtre numérique le plus simple possible. Une fois filtrées, les informations sont beaucoup plus exploitables, moins bruitées, et conservent une dynamique suffisante pour suivre les mouvements du drone.

Mais la puissance de calcul est insuffisante pour traiter 120 fois par seconde tous les calculs de trigo (et compagnie) nécessaire à la détermination des angles. Alors je ne fait ces calculs gourmands que 20 fois par seconde à partir des infos filtrées, ce qui est bien suffisant.
Avec ces modifs, le résultat en vol est désormais satisfaisant, la preuve sur la vidéo.

Je dois désormais m'attaquer (à nouveau) à la boussole 3D, ce qui n'est pas non plus une mince affaire.

Toutes les mesures que tu effectues (120x par seconde pour les gyro et accelero, 60x par seconde pour magneto, etc...) sont effectuées par la même carte, ta carte embedded master module ? ou par les modules capteurs directement ?
A l'occasion si tu as un moment je serais intéressé par un retour d'expérience sur cette carte embarquant un .NET micro framework. J'avoue que je suis assez sceptique sur le C# pour réaliser de telles applications, mais n'ayant jamais eu l'occasion de tester...
Tu penses que cette carte suffira pour piloter ton drone entièrement, et ce de manière autonome ?

Je crois que c'est tout pour les questions ^^, en tout cas bonne continuation et merci pour tout ces détails qui pourront être utiles à plus d'un je pense.

Une question: Comment peut on initialiser le 0° du servo moteur à une de ses extrémités, car moi le 0° de mon servo ne par pas exactement de l'une de ses extrémité (j'espère que j'ai été clair... )????

Ce n'est pas possible. Ton servomoteur à un débattement nominal de 180° mais pour des raisons pratiques à toujours un peu plus de débattement mécaniquement. Il y a des moyens de tricher un peu en sortant des spécifications nominales des signaux à envoyer au servomoteur mais c'est pas forcément extraordinaire. Faut essayer de se débrouiller avec les 180° disponibles

" Pour l'alimentation de mes 8 servomoteurs, à partir de la carte Arduino, j'avais pensé à une plaque d'essais, mais j'ai peur que sa prenne de la place sur le robot, voyez vous un autre moyen ou la plaque d'essais est une bonne solution???

La plaque d'essai c'est bien pour te mettre au point au début. Mais c'est sûr que par la suite sa va pas aller ton robot ne va pas se trimballer la carte comme ça ^^, c'est trop gros. Le meilleur moyen (mais pas le plus simple) à mon avis et surtout pour un bipède serai de te faire un arduino shield avec des connecteurs pour seromoteur et une alim externe (ton arduino n'est pas prévue pour alimenter 8 servomoteurs).

Car pour le moment je teste avec un servomoteur qui avait une prise femelle et j'ai modifier en cassant la prise femelle, séparé les fil et j'ai branché à l'arrache les fil dans les broches de la carte Arduino, mais sa à du mal à rentré et à tenir, existe-t-il des embouts adaptable pour la carte arduino??? "

C'est vrai que c'est galère à brancher quand on a pas les bons connecteurs. Il existe des barettes de connecteurs males qui vont parfaitement bien avec ces prises là comme celles de l'arduino ou des servo : Barette sécable ça ce trouve dans n'importe quel magasin revendeur d'électronique. Moyennant un peu de soudure et quelques bouts de nappe tu peux facilement faire des connecteurs mâle / mâle pour relier tes servos à l'arduino. Le plus embêtant ce sont les alims de tout tes servos.

Il te faudrait une carte venant se "ficher" sur l'arduino ayant un schéma similaire à sa :

Merci pour tes liens qui mon était utile!

Mais qu'est ce que t'appelle IDE (sans jouer l'inculte)?????

Avec plaisir. Un IDE c'est un environnement de développement. C'est ce qui te permet de faire tes programmes et de les télécharger sur l'arduino sans trop de soucier de ce qu'il y a derrière (bibliothèques, compilateur, programmateur etc)

L'arduino IDE ressemble à ça :
Arduino IDE image

Et oui, sa m'intéresserais bien ton programme que ta fait, mais il fonctionne qu'avec AVR-GCC????

Oui il ne fonctionne qu'avec AVR-GCC. Je n'ai pas fait attention mais si tu dit que tu est débutant en programmation je t'ai peut être mal conseillé. Essaye de tester la solution de galactus qui a la mérite de fonctionner sur l'IDE. Ce n'est pas que je veuille pas te passer mon code, mais si tu n'as pas de bases de programmation sous linux en C ça va pas mal te compliquer la vie. Pour commencer c'est bien d'aller au plus simple

Tiens nous au courant de tes avancées.

Merci, sa marche nikel!

Mais j'aimerais pour débuter faire un enchainement de séquence comme suit:

1 - le servo s'initialise à 0 degré.

2 - puis il va à 90°, il se stabilise 3 secondes.

3 - puis il va à 180°, il se stabilise 3 secondes.

4 - puis il retourne à 90°, stabilise 3 secondes.

5 - enfin retourne à 0° est là séquence s'arrête, car ça j arrive pas à arrêter un programme, sa me fais toujours des boucles.

En plus si possible pouvoir régler la vitesse du servo pendant cette séquence???

merci d'avance!

Ah ben post croisé ^^

Pour faire ton enchainement de séquence essaye de bien comprendre le code que t'as passé Galactus. La fonction servo pulse s'occupe de générer une impulsion de la bonne forme pour contrôler ton servomoteur branché sur "servoPin" et le faire se déplacer à l'angle "myAngle". Donc a chaque fois que tu appelera la fonction servoPulse(3,x) ton servo branché sur la patte 3 se positionnera à l'angle x. Du coup il va te falloir faire un enchainement de servoPulse pour gérer ton déplacement. Ensuite pour régler la vitesse plutot que de lui dire va à cet angle en une seule fois, tu peux lui dire d'aller à un certain angle puis à un autre puis à un autre... mais de manière rapprochée.

C'est ce qui est fait ici :

for (myAngle=0; myAngle<=180; myAngle++) {
    servoPulse(servoPin, myAngle);

Le servo va à tout les angles entre 0 et 180 (soit 0, 1 ,2 ... 178, 179, 180). Pour gérer la vitesse d'avancement tu peux changer le pas de la boucle au lieu de myAngle++ mettre myAngle = myAngle+2 par exemple, ça ira deux fois plus vite(les angles seront 0,2,4,6,8...) .. etc. Pour un déplacement élémentaire le myAngle=0 correspond à l'angle de départ du mouvement (ici 0°) et le myangle<=180 signifie que ton servo va se déplacer jusqu'à atteindre l'angle voulu (ici 180). et bien sur tu peux intercaller des delay pour ralentir tout ça !
Si tu veux faire un déplacement avec un angle dégréssif la forme change un peu :

Exemple pour aller de 180 à 90°

for (myAngle=180; myAngle>90; myAngle--) {
    servoPulse(servoPin, myAngle);

Je te laisse essayer de faire ça par toi même, de toute façon on est toujours dans le coin pour te filer un coup de main ou un conseil si besoin.
Bonne chance

Salut,

c'est un bon petit projet en effet que tu veux faire, ce n'est pas évident les humanoides ^^(je ne dit pas ça pour te casser la motivation hein).
Coté Arduino il y a une bibliothèque toute faite permettant de facilement contrôler des servomoteurs (en utilisant leur IDE) cf Arduino Reference
J'imagine que tu as déjà lu cette page mais il me semble que tout les éléments nécessaires pour comprendre le fonctionnement y sont. D'un autre coté il me semble que j'avais eu des soucis moi aussi quand j'avais voulu faire fonctionner cette librairie. Comme c'était au moment ou je suis passé à programmer mon arduino avec AVR-GCC (sans passer par leur IDE) j'ai pas trop cherché, et je me suis développé un petit programme permettant de contrôler 8 servo avec l'arduino. Si ça t'intéresse je peux toujours te le passer, ça peut te servir de base (ne fonctionnera pas si tu utilise juste leur IDE).

Une autre adresse qui peut être utile : Arduino motor/stepper/servo controll Tout semble expliqué.

Pour ce qui est des drones à base d'avion (il faudrait ouvrir un nouveau sujet si tu veux développer ), il y a une belle communauté ici, qui partage pas mal de choses. Plusieurs bases "opensource" ont apparemment été développées.
http://www.diydrones.com/

Merci pour le lien je connaissais pas ce site. Je suis toujours tenté par un projet de drone à base d'avion mais pour l'instant je suis sur un autre projet de robot, alors on verra plus tard pour le moment.

Désolé, mais je n'ai pas compris ton propos.

Si tu connais un peu l'aéromodélisme, tu dois savoir qu'un hélico ne se comporte pas du tout comme un avion. Un hélico bi-rotor se comporte quasiment comme un quadri: la dynamique que tu peux avoir en latéral est quasiment la même que celle que tu peux avoir en longitudinal. Ca sera particulièrement vrai si j'enlève la queue de l'hélico, et que l'inertie et la prise au vent selon les axes longi et latéral se ressemblent. S'il fonce sur un mur, il "suffira" de freiner, pas besoin de tourner, que ce soit un quadri-rotor ou un bi-rotor coaxiaux. Et puis quand tu parles de 'rayon de rotation de l'hélico', je ne comprends pas là non plus: tous les hélicos peuvent tourner sur place, avec un rayon de rotation nul.

Un quadri se commande avec les 4 mêmes voies qu'un bi-rotor (tangage, roulis, lacet, vertical). En terme de commande, je ne vois pas trop de différence entre les 2. C'est avant tout la stabilité qui est différente.

Je n'ai pas du être assez clair, mais ce que je disais se base sur le fait que pour moi l'hélico bi-rotor avait une dynamique largement inférieure en latéral. Comme je n'ai jamais piloté de "vrai" (pas les petits jouets 2 voies) hélico RC je ne pensais pas que ça pouvait être aussi maniable. Je me basais aussi sur le fait que tu garderais la queue de l'hélico et que tu le controlerai "un peu" comme un avion, d'où de "rayon de rotation". Autant pour moi C'est vrai que maintenant que tu le dit j'ai raisonné comme si tu utilisais un hélico 2 voies, ce qui n'est pas le cas.
Après je suis d'accord avec toi que niveau commande il n'y aura pas trop trop de différence, et que ce sera forcément plus simple à asservir un bi-rotor.

Inounx

Salut Léon,

super intéressant ton projet, mais de longue haleine ! J'ai lu un petit peu toutes les infos qui ont circulé sur ce post et sa fait vraiment envie J'ai moi aussi eu l'idée de faire quelque chose de ce genre mais plus orienté avion RC (j'ai fait de l'aeromodelisme avion donc j'avais déja le matos qu'il fallait) mais c'est vraiment complexe et je pense que pour l'instant j'ai pas les compétences pour tout ce qui est asservissement 3D et toute la couche logicielle qui vient par dessus faire la génération des lois de commande et autre...

Pour en revenir à la question que tu posais tout a l'heure : "Pourquoi un drone quadrirotor, c'est mieux en apparence qu'un bi-rotor ?"
je dirait à première vue c'est la façon de le commander. Par exemple imaginons que tu ai un quadri rotor, tes asservissements sont faits (bien qu'ils soient complexes) mais juste les asservissements. Tu veux maintenant développer "une logique" qui va permettre à ton bestiau d'éviter les murs (condition mini de ton projet) Ton quadri-rotor en vol détecte un mur, pour l'éviter (dans le principe) tu diminue la vitesse d'un ou deux rotor pour faire "reculer" ou tourner le drone et il peut continuer facilement sa route. Dans le cas d'un birotor, je trouve ça de suite plus complexe à gérer : ton helico va donc détecter mur mais pour l'éviter il va falloir effectuer des manoeuvres. Quand je pense à ces contraintes, il me vient à l'esprit l'exemple d'un robot roulant non-holonome et je pense que c'est pour cela que les quadrirotors sont plus utilisés. Les manoeuvres à effectuer ne sont pas forcément complexes mais il faut prévoir, si on est face au mur qu'il est impossible (selon le rayon de rotation de l'helico) de faire demi tour sur place, ou alors il faut gérer de reculer et ensuite d'amorcer le virage. Je ne dit pas non plus que c'est impossible mais peut être plus complexe à mettre en oeuvre. ça peut réduire les possibilités d'évolutions de ton hélico dans un environnement "restreint".

en tout cas bonne chance pour ton projet

Inounx

Salut SeeB,

bienvenue sur le forum

je ne connais pas tout les moyen de faire des études en robotique, mais je peux te citer mon parcours : j'ai fait une seconde ISI ISP, de là j'ai fait un bac STI génie électrotechnique (eh non il ne faut pas OBLIGATOIREMENT faire leur foutu bac S pour réussir sa vie). Mon bac en poche je suis rentré à l'IUT GEII (Génie Electrique et Informatique Industrielle) et j'ai pris l'option Automatismes et Systèmes en 2ème année. On y fait pas mal d'électronique, d'automatique aussi, un peu d'info entre autres. C'est une bonne formation qui donne les bases pour continuer vers la robotique. Je ne pense pas qu'une formation robotique telle quelle existe directement après le bac, étant donné que la robotique est multi disciplinaire : il faut de la mécanique, de l'électronique et de l'informatique pour faire un robot. Après l'IUT j'ai intégré l'IUP Systèmes Intelligents, dans lequel je suis encore en Master 1. La formation est très orientée robotique : IA, microcontroleur, vision, robotique mobile, bras robotisés, automatique, etc.

Si tu as des questions n'hésites pas.

Pour mon cas, j'ai fait une seconde générale section S (désolé Inounx )

Personne n'est parfait

Bienvenue à toi Ghelle,

c'est bien un projet de drone comme ça C'est de mieux en mieux ce forum : on commence à avoir quelques projets sympatiques qui se profilent...
Reste plus qu'à espérer que toutes les réflexions seront bien retrancrites ça peut servir à ceux qui voudront s'y lancer aussi.

Sinon une question qui est peut être bête mais que je me pose : j'ai juste fait du java sur PC "normal" mais même si c'est un language puissant, j'ai toujours trouvé sa plus ou moins lourd par rapport à un language comme le C++ ou ce style là. Je ne sais pas ce qu'il en est au niveau embarqué mais ça ne risque pas de pomper pas mal (trop ?) de ressources ou d'être trop lent, surtout si ton programme est beaucoup solicité pour maintenir la stabilité de l'engin ?

Salut shyhack,

perso j'ai une colone proxxon et comme toi j'ai le même problème. Quand je descend la perceuse elle se décale légèrement vers la manette. ça doit être un problème sur ce genre de petites colonnes qui ne sont pas de grande qualité. (Ce genre d'outil coute cher en général) Après moi comme je m'en sers exclusivement pour percer des circuits imprimés je fait pas des trous profonds et sa me pose pas trop de problème mais c'est vrai que c'est pas génial...

Un gars qui a eu le meme problème sur la proxxon :
http://www.rcgroups.com/forums/showthread.php?t=608804

Enfin juste pour dire que ce n'est pas que dremel...

Beau boulot que tu as fait là, ça te fait une bonne station de perçage / fraisage.
par curiosité quand tu dis que tu veux faire des pièces en série, c'est pour un robot quelconque ou rien à voir ?

Je suis toujours sur mon projet de quadrupède, le 4ème de sa génération (détail dans réalisation et projet), ainsi j'avais concocté une bonne idée de châssis pour supporter les servos des pattes afin qu'il ne rendent pas mon quadrupède haut sur patte (du moins pas trop grand), le prototype de châssis d'une patte était parfait mais a pris beaucoup de temps à réaliser (du fait des tests fait dessus), j'ai ainsi par la suite voulu faire les autres pattes en m'aidant de la colonne de perçage DREMEL qui m'aurait permis d'aller un peu plus vite, en fait pas du tout, j'ai plus passé du temps à réparer cette colonne qu'à réaliser mon robot
En fait depuis le début je suis toujours freiné par une question mécanique, les plans, la théorie, tout est plus ou moins au point, mais je bloque sur la construction du châssis

En réalité cette 4ème génération est très particulière, elle utilise 2 nouvelles trouvailles, la première sont des pattes arrières permettant quand j'aurais suffisamment la bête en main que le robot puisse courir et même sauter, la seconde est liée puisqu'elle consiste à fabriquer une colonne vertébrale à 3 segment qui permettrait au robot d'utiliser son propre poids dans la course ou le saut et ainsi de bénéficier de l'effet "pendule" de son train arrière pour ramener ses pattes arrière vers l'avant. (mais ça c'est juste un projet à long terme un ! )

Un quadrupède qui saute et qui court ? intéressant ^^ j'ai hate de voir ce que ça peut donner . On a plus l'habitude des quadrupèdes qui avancent pas bien vite...

Je ne compte pas faire tout sur le même robot en même tant (sinon moi j'ai pas fini !) mais je tient à faire une version qui me permettrait par le suite de l'améliorer sans pour autant tout démonter.

Voila quoi, je ne tient surtout pas à faire un quadrupède juste comme ça, pour le fun, j'y travail et ça me passionne, c'est pour moi une manière de m'impliquer dans quelque chose et d'y travailler comme dans le métier dans lequel je souhaiterais travailler.

désolé si la réponse est longue mais ça fait longtemps que quelqu'un ne m'a pas posé de question sur l'avancé de mon projet .

Je dirais que le forum est fait pour ça ^^ et puis même si on te pose pas de questions tu peux quand meme nous tenir au courant de tes avancées, je suis sûr qu'il y a plein de monde que sa interesse ^^

on attends la suite, maintenant que ta dremel est opérationnelle

Salut denis, (Bienvenue sur le forum au fait)

j'ai acheté une Roboard il y a quelques temps déjà donc je peux te fournir quelques informations complémentaires si besoin.
J'ai essayé d'y installer une debian (4 ou 5 je ne me rappelle plus), il y a des docs qui existent et sa ce fait très bien (on crée une clé usb bootable et on installe à partir de ça une debian classique light avec un noyau spécial pour ce processeur là), le seul souci est que c'est assez lent à booter. Environ 50s ou qq chose dans le genre.
Par contre le fabriquant de la Roboard fourni un petit linux minimal (XLinux) qui permet de faire beaucoup de choses (bien qu'un peu limité au niveau drivers) qui boote en 14s a peu près, ce qui est déjà largement mieux.

Comme toi j'ai eu besoin d'une carte graphique pour faire du débug, ça tombe bien il en proposent une au format mini-pci avec la roboard, et ya rien à dire c'est vraiment pratique (Tu peux aussi utiliser un port RS232 pour faire rediriger la sortie console si tu n'as pas d'interface graphique). Après je me suis monté une carte wifi à la place pour avoir plus de possibilités.

Coté consommation c'est bien ce qu'ils annoncent sur le site, dans les 2-3W. ça varie bien sur en fonction de l'utilisation du processeur et des pariphériques comme les cartes wifi ou les pariphériques USB un peu gourmands en énergie.

Si tu trouves d'autres équivalents, je suis intéressé, ne serait-ce que pour être informé de ce qui ce fait.

a+

Voici quelques news du petit Robert je n'ai pas trop le temps de m'en occuper en ce moment avec mon stage et mon rapport à finir mais j'essaye de m'y tenir.

Coté odométrie le problème est réglé, cela venais du fait que les entrées des capteurs sur le CPLD n'étaient pas synchrones avec l'horloge du CPLD ( 50Mhz), je pense que vu que c'est un composant hyper sensible avec les moteurs en marche il devait "attraper" tout les parasites qui trainaient, d'où les fausses valeurs.

J'ai essayé de mettre en place des PID sur chaque moteur, un à gauche et un à droite ça fonctionne nickel. Pour l'asservissement delta - alpha c'est pas encore ça par contre, j'ai du mal à bien régler les coefficients. J'ai aussi essayé de mettre les PID delta et alpha commandant les PID droite et gauche, je ne sais pas si cela vient du fait que la boucle d'asservissement est faite sur le même retour capteur mais le système devient très rapidement instable (oscillations dans les plages de régime permanent).

En plus c'est vrai que devoir reprogrammer l'arduino à chaque fois que je fait un changement de coeff c'est vraiment pas pratique. J'évite de faire des saisies console, les fscanf (et aussi les fprintf) sa prend 3 tonnes de place dans la mémoire et les 16ko de l'atmega168 se remplissent vite. J'ai donc décidé de prendre un peu d'avance sur ce que j'avais prévu de faire. J'ai rajouté la roboard sur le robot afin de pouvoir commander l'arduino via la connexion série.

Le protocole de communication que j'utilise est simple : on envoi un premier caractère de début de trame (j'ai choisi 0x80, mais peut être n'importe quoi d'autre) ensuite on envoi la taille de la trame sans compter les caractères de début et fin de trame. En suivant un code 8 bits est envoyé représentant l'ID de la commande (pourra être étendu à 16 bits si 255 commandes ne suffisent pas) suivent ensuite tout les octets de la commande et pour finir le caractère de fin de trame (0x90). La longueur de la trame permet d'effectuer une vérification sur la trame et évite de confondre le caractère de fin avec un octet de donnée. Ce qui donne en résumé :
START - LENGTH - ID - D1 - D2 - ... - Dn - STOP

Les commandes permettront donc de commander entièrement le bas niveau du robot (les PID, les commandes moteurs brutes, les capteurs, etc). tout le mécanisme de réception et déserialisation des commande est codé sur l'arduino mais pas encore testé. J'ai remis en marche la roboard et je me suis débattu quelques temps afin de faire fonctionner correctement le wifi. J'arrive à me connecter à mon routeur wifi pour l'instant ce qui me suffit même si à terme l'intéret serais de se connecter à un réseau connu si existant ou sinon créer un réseau ad-hoc. Il me reste encore à coder une petite application permettant d'envoyer des commande à l'arduino, ce qui va simplifier la mise au point de l'asservissement. Le but est de soit faire une application avec socket pour communiquer à travers le réseau et donc commander le robot à distance, soit faire une page web avec un script CGI. Je n'ai pas encore choisi ce que j'implémenterai même si il y a des chances que je fasse les deux.

J'avais aussi mis en place tout un système de TTS (Text To Speech) pour le faire parler, ce qui pourrait être marrant, mais je ne me rappelle plus comment je l'utilisais je vais essayer de retrouver ça.

Si j'ai bien compris, tu as essayé de bidouiller des asservissements PID imbriqués.

C'est tout a fait ça oui. Comme j'ai vu que certains robots de coupe de france utilisaient cette technique je me suis dit "Pourquoi pas essayer ?" Par contre les robots de coupe on de bonnes raisons de l'utiliser puisque qu'ils réalisent l'asservissement des moteurs avec les codeurs qui sont fixés sur les moteurs et l'asservissement polaire avec des codeurs "libres" qui mesurent l'avancement sur le sol.
J'ai mis ces asserivessements en place surtout pour compenser la non linéarité de la commande sur mes moteurs (Commande PWM sur 8bits mais les moteurs n'avancent réellement que vers 150 / 255. Pour régler ça sans PID j'ai mis un offset tout bête dans la commande).

Premièrement, ça n'est pas indispensable: tu peux utiliser directement un asservissement "avancement/angle" (que tu appelles delta alpha), qui commande directement les moteurs. C'est en général ce que font les roboticiens.

Effectivement tu n'est pas le premier qui me dit ça.

Ensuite, si tu veux vraiment faire des asservissements imbriqués, il faut que le temps de convergence de l'asservissement "bas niveau" (ici le PID sur l'avancement des roues) soit très faible par rapport aux constantes de temps de ton asservissement "haut niveau". Sinon, tu peux très bien avoir des phénomènes de divergence.

Là pour le coup je me sens terriblement bête ça ma pas posé de problème quand j'ai codé mes asservissements de les mettre dans la même boucle de rafraîchissement. Rha ! tu m'étonnes que ça marchait pas... Bon au moins je crois que je m'en souviendrais pour le coup ^^ Le pire c'est que je l'ai déjà vu en cours, chose qu'on a du nous répéter X fois. Comme quoi rien de mieux qu'un peu de pratique !

En tout cas merci bien pour les conseils Léon

J'ai eu le temps aujourd'hui de faire une petite vidéo : video youtube
Désolé pour le format vidéo qui est pas génial mais j'ai pas d'APN digne de ce nom sous la main.

L'évitement d'obstacle marche plutôt bien sauf dans certain cas comme les angles morts entre 2 capteurs, ou les angles bien fins.

Pour reprendre la discussion qui a commencé dans le post de ma présentation :

J'ai quelques idées pour la mise en oeuvre de l'asservissement de mon coté, yaurais quelques changement par rapport à l'idée de départ. Un pote ma donné l'idée d'utiliser le couple uC / FPGA et je pense que ça peut simplifier pas mal les choses pour certains traitements qui doivent être rapides, comme le décodage des signaux en quadrature, le comptage des impulsions, la mesure de leur durée etc on pourrai le faire très facilement. (et en plus faires d'autres choses à l'occaz). ça permettrait de décharger un peu le uC et de lui laisser gérer tout les capteurs en même temps. Je t'en reparlerais plus en détail, c'est ptetre pas le meilleur endroit que le sujet ou je me présente

C'est intéressant, votre histoire de Robert... Alors pourquoi ne pas ouvrir un sujet dédié?

Plusieurs remarques:
1) pour la mesure par plusieurs télémètres ultra-sons, il est apparemment possible d'émettre sur plusieurs sonars en même temps et de mesurer la réponse en retour de chaque capteur. Je ne pourrais malheureusement pas tester ça sur BOB3, car je suis limité par le PICBASIC qui ne sait pas faire ce genre de choses. Par contre, pour le robot suivant, ça serait à tester.

2) Pour le FPGA, est-ce que ça n'est pas trop "usine à gaz"? Est-ce que tu sais déjà programmer un FPGA?

Bref, si vous voulez en discuter plus longuement, je vous propose d'ouvrir un autre post.

Leon.

Ah bon ? il me semblait justement qu'il n'était pas possible d'émettre sur plusieurs en même temps pour des raisons de perturbations entre capteurs justement. Sauf peut être si on s'arrange pour travailler sur des fréquences sonores différentes. Enfin si tu as plus d'info je suis preneur.


Quand je dit FPGA, c'est cette famille de composant, ici on a en stock des CPLD Xilynx donc on fera avec ça si on valide la faisabilité et la comodité . Après Usine à gaz, d'un coté oui, d'un coté non. Comme un CPLD ou FPGA ce n'est ni plus ni moins qu'un réseau logique qu'on peut programmer comme on veut et ce sur une puce minuscule (1cm* 1cm a peu près pour ceux que j'ai). L'avantage ici c'est que tout le bloc décodage comptage peut etre facilement programmé à l'intérieur et modifiable à souhait. Il suffit de se fixer l'interface avec le uC. Cela peut aussi permettre de coder des fonctions de décodage "hardware" pour des capteurs ou autre je n'y ai pas encore trop réfléchi. Je sais tout a fait programmer ces bestioles en vhdl oui, j'ai fait ça quand j'étais à l'IUT et maintenant à l'IUP : j'ai pas forcément une maîtrise extrême de la chose mais comme tu l'as si bien dit, on est aussi la pour apprendre

Apparemment, si tu envoies les pulses EXACTEMENT en même temps, les capteurs ne se perturbent pas. Ils inhibent en effet la réception lors de l'émission de leur propre pulse. Après, pour la réception, les capteurs sont suffisamment directifs pour ne pas recevoir le pulse du voisin. J'essaye de retrouver des infos, et je compte bien tester ça également.

Leon.

Perso j'y crois pas trop au système d'émettre les US en même temps :/
D'abord parce que vu le % de tolérance sur les composant +-20% pour un condo par exemple il risque d'y avoir des décalages entre les émissions de chaque émetteur, sans compter les multiples réfractions possibles qui sont déphasées (en temps donc) à la réception.

Le mieux comme je l'ai conseillé dans un autre sujet, ce serait de moduler l'émission d'un US avec une basse fréquence genre 1 Khz pour le premier émetteur, 5 khz pour le second, 10 pour le troisième et 15 Khz pour le 4ème.
Avec un filtre passe-bande sélectif et basse-fréquence après la réception sur chaque capteur US.

Electron, je rappelle que nous ne faisons qu'utiliser des modules télémètres à ultra-sons tout fait du commerce, de marque "Devantech". Donc impossible, dans ces conditions, de bricoler une quelconque modulation. Seule solution : réaliser un module de A à Z.

Personnellement, je pense que ça fonctionne. Je ferais l'essai en temps et en heure, et je vous dirais bien évidemment si ça fonctionne ou non. Pourquoi je pense qua ça fonctionne? D'abord, parce que la génération du pulse est réalisée en software, donc quand on dit que c'est émis exactement en même temps, c'est vraiment très précis: delta inférieur à la microseconde. Ensuite, pour les réflexions multiples, il faut que l'angle de réception soit précis (à +/-30°), ce qui limite sacrément le risque. J'ai du mal à me représenter un schéma géométrique de rebond multiple qui arriverai AVANT le rebond principal d'un capteur, et dans un cône de 30°. Mais bon, je suis preneur de toute démonstration géométrique que ça peut exister.

Pour ce qui est d'une modulation basse fréquence, je vois mal comment interpréter le truc: En software? En hardware? Si tu reçois 2 signaux en même temps, mais avec des amplitudes et des modulations différentes, ça nécessite quand même du traitement du signal (DSP?) pour déterminer l'instant précis de début de réception d'un des 2 signaux. Si tu as des idées (software ou hardware) pour réaliser ça de manière simple et précise, je suis preneur. Un filtre hard sera difficile à mettre en oeuvre, à mon avis, car l'instant de détection "ça y est, j'ai reçu le signal 5kHz" va peut-être dépendre de l'amplitude du signal reçu. Une période de 5kHz fait quand même 6cm de longueur d'onde. On a besoin d'une précision bien meilleure que 6cm.

Leon.

Ok OK comme tu veux

Sinon pour ce qui est de la modulation BF, c'est juste un oscillateur qui va direct sur l'entrée modulation d'un oscillateur US
La modulation BF est générée juste pour une durée de temps de ms, ce qui envoie donc une onde US modulée en BF pendant ce temps-là quoi^^

Les deux oscillateurs (BF et US) peuvent se faire juste avec deux portes "nand" par oscillateur.
Puisque le circuit intégré à portes "nand" tel que le CD4011 comporte quatre portes "nand", tu as ainsi tes deux oscillateurs avec un seul circuit intégré "nand".

Quand aux capteurs US ce sont des US modulés qu'ils reçoivent et non de la BF donc la longueur d'onde reçue est trés petite (US) et non 6 cm^^

Mais bon j'ai donné une idée après faites comme vous voulez, cela ne me regarde plus

Ca m'intéresse, mais tu n'as pas répondu à ma question: comment veux-tu faire pour démoduler, ou plutôt détecter le bon signal avec un bon timing, sans être dépendant de l'amplitude? Je n'y connais pas grand chose, mais ça ne me parait pas simple. Le plus gros problème me semble bien être côté réception, et non côté émission.

Leon.

Pour la RoBoard, c'est un joli cerveau. Tu vas pouvoir en faire des choses avec ça.

Tu parles en parallèle de FPGA et d'Arduino... Est-ce que tu veux mettre les 2 dans un même robot, en plus de la RoBoard?Ca fait un peu beaucoup, non?

C'est une idée oui. En fait vu comme ça, ça fait peut être beaucoup mais c'est le plus simple je pense. Je partais sur le principe de diviser en deux l'électronique : une partie "bas niveau" composée donc de l'arduino, avec un CPLD (surtout là pour traiter les signaux en quadrature), tout ça pour gérer les capteurs, la tension batterie, l'asservissement "bas niveau" et peut être d'autre chose. La deuxième partie serait donc l'électronique "haut niveau"(la Roboard, ou la Fox pour Aquanum) plus orientée prise de décision et "gros" calculs. Le lien entre les 2 niveaux pourrait être une liaison série entre arduino et Roboard en RS232 par exemple.

Pour l'asservissement, comment comptes-tu asservir ton robot? Pourquoi as-tu choisi de faire l'asservissement dans une Arduino, alors que tu as de la puissance de calcul à revendre dans ta RoBoard?

L'asservissement est en 3 niveaux : un asservissement type PID pour la vitesse, l'acceleration et la position, et une partie génération de consigne (évolution des consignes au cours du temps sur une période à temps fini), et pour finir une partie génération de trajectoire (position du robot au cours du temps). Le principe serait donc vu la position du robot et celle à atteindre de générer une trajectoire, avec cette trajectoire de générer les courbes de consignes et de transmettre aux asservissements. Facile à dire mais pas autant à coder

L'arduino s'occuperai des asservissements, et la Roboard de la génération de trajectoire et des consignes. Je ne fait pas tout directement avec la Roboard parce que je n'ai pas un linux temps réel installé dessus et je ne contrôle donc pas les temps. ça peut devenir assez génant surtout que l'asservissement doit être rafraichi un minimum de fois par seconde. Dernière raison je réservai surtout la Roboard pour les calculs comme le calcul de trajectoire, la génération de la carte, et plus dans le futur un peu de traitement d'image.

Pour l'instant ce ne sont que des idées il faut voir si j'arrive à coder tout l'asservissement ce qui ne sera pas une mince affaire à mon avis. On le dit tout le temps mais faire la correspondance entre la théorie que l'on voit en cours et la pratique c'est pas évident ^^.

Salut à tous,

maintenant que j'ai un peu plus de temps pour travailler sur le robot, j'ai pu finir avec un ami la carte à CPLD qui sert à décoder et à compter les informations des codeurs optiques. J'ai mis en place un asservissement tout simple en théta-alpha (asservissement polaire). étant donné que c'est la première fois que je me lance dans la pratique pour un asservissement (en dehors des cours mais c'est là qu'on s'aperçoit que quand on fait marcher une manip toute faite et en étant guidé cela n'a rien à voir avec le faire "en vrai") je me heurte fatalement à des petit problèmes. J'ai donc quelques petites questions pour ceux qui passerons dans le coin :

- Dans le principe mon asservissement fonctionne (plus ou moins il faut régler les coefs) mais assez régulièrement (et je ne sais pas pourquoi) je fait des lectures fausse de valeurs. Du coup quand j'ai une consigne de 30tick / dT par exemple de temps en temps je me retrouve avec une valeur -1500 ou 400. Comme vous pouvez vous en douter sa donne des à-coups sur la commande et sa fausse complètement le positionnement. Est ce que certains d'entre vous ont déjà été confrontés à ce problème là ? je pensais filtrer les mesures mais après c'est génant dans le fait où je suis limité en dynamique du système, même si dans l'absolu mon robot n'a pas besoin d'être très dynamique. Je me demandais si cela venait pas des moteurs qui perturbent la lecture à certain moments, parce que dans le doute j'ai incriminé la carte à CPLD. Comme il y a un registre qui me permet de commander des pattes en sortie du CPLD j'ai fait un programme qui réalise en boucle des cycles de lecture écriture avec des valeurs différentes. Et résultat du test : aucune erreur sur des millions de lectures / écritures. Je me suis aussi aperçu qu'il y avait moins d'erreurs de lecture quand je faisait une première lecture bidon puis les "vraies" lectures ensuite. (Il faut encore que je fasse d'autres tests de lecture sur le CPLD dans des conditions différentes, je crois que c'est trop sensibles ces bestioles là)
J'utilise pour l'instant un quartz 50mhz pour toute la partie synchrone du CPLD mais je pense diminuer un peu pour limiter les problème (vers 20/30Mhz). Autre chose que j'ai failli oublier mon CPLD est alimenté en 3.3V (5V compliant sur les entrées) et je me demandais si ça pouvais jouer sur les erreurs de lecture par le uC (même si en théorie le seuil logique est à 2V équelques il me semble pour du 5V)

- Par la liaison série de l'arduino je renvoie les valeurs de mes codeurs et les valeurs des commandes générées par les PID. J'affiche ensuite tout ça avec matlab. C'est là qu'on se rend compte que la moteur gauche est très bien positionné par rapport à sa consigne (sans tenir compte des erreurs de lecture) alors que le moteur droit oscille autour de sa consigne. Comme l'asservissement est effectué sur les deux moteurs à la fois et non sur chaque moteur séparément je me demandais si c'était vraiment normal. Je joint deux captures d'écran Matlab : la première montre un essais de consigne de 90°/s sur 3s, la deuxième montre la même chose mais avec une lecture bidon effectuée avant les vraies lectures.
Légende : pour les odomètres courbe bleue = valeur lue, rouge = consigne.
Pour les les commandes courbe rouge = commande brute calculée par les PID, en bleu la même commande seuillée entre 255 et -255 (255 pas de PWM avec avant ou arrière).
Le delta de temps est de 1/61s (calcul des PID à 61Hz). Les unités des courbes de odomètres sont en ticks sur l'axe Y et en secondes sur l'axe X. Pour les courbes des commandes sur Y il n'y a pas d'unité ce sont des "pas de PWM" et sur X toujours le temps en secondes.

Merci j'aurais appris que le PID virtuel existe
Je constate que je ne te serais d'aucun secours pour tes erreurs aléatoires de lecture :/
Bizarre quand même que ces erreurs n'existent pas lorsque tu utilise un programme de test en boucle, ça veut dire que ces erreurs n'existent que lors de leur lecture réelle et donc que le système de lecture entraine la venue de ces erreurs.
Le circuit de lecture n'est-il pas sensible à quelques parasites ? est-il bien cablé de la meilleure façon ? voilà j'essaie d'orienter un peu les recherches

C'est toujours bien d'avoir un point de vue différent, ça permet souvent de progresser ^^
J'avais fait des tests de cette carte CPLD quand le CPLD était cadencé à 24mhz et meme avec les moteurs qui tournaient pendant le prog de test en boucle j'avais pas d'erreur non plus. Depuis j'ai passé le CPLD à 50Mhz pour pouvoir augmenter la vitesse de transmission des données (et pour qu'il puisse suivre la cadence de l'arduino@16Mhz) mais c'est peut être ça qui le perturbe. Il faut dire aussi qu'un CPLD c'est hyper sensible par nature, alors le 3.3V et du 50Mhz sa doit pas plaider en ma faveur... Je vais essayer de faire des tests sur la lecture des codeurs directement plutot que sur le registre que j'ai à coté. Si je désactive ma remise à zéro automatique des compteurs, sans faire bouger les codeurs, je peux réaliser pleins de lectures de la meme valeur et voir si il y a des fausses lectures.
Pour ce qui est du cablage, peut être pas de la meileure façon qui soit mais tout mes fils sont torsadés pour réduire les parasites, mon alim est filtrée et chaque carte a des condensateurs de découplage. Les fils sont les plus courts possibles. La liaison avec l'arduino se fait avec un cable de 10 cm de long composé de 3 fils torsadés, sa devrait marcher nickel.

Je vais essayer de faire quelques tests de plus, mais si il y en a qui passent par là et qui ont des idées je prends toujours ^^(pas que pour le problème des erreurs de lecture, mais aussi pour l'oscillation sur la voie droite)