| |
| Auteur |
Message |
|
|
philopat
|
Publié: Mer 22 Avr 2009, 00:00 |
|
|
Roboticien initiéInscrit le: Mer 5 Nov 2008, 00:19Messages: 1074Localisation: Paris - Chevreuse |
bonjour à toutes ..bonjour à tous ! et surtout je pense aux spécialistes j'ai pu à certaines occasion faire constat que parmi nous il y aurait , comment dire, quelques experts, ou quelques expertes, de microcontrolleurs PICs et de bus en tout genre. alors , dans ma petite tête, je me suis demandé, mais que font ils, que font elles? car je n'ai pas encore, ou peut etre pas su trouver, un debut d'elan, ou comme on dit , une ombre d'action... ne le prenez pas sur ce ton, non, non, ce n'est pas un compliment! ahaa, en fait, je tourne autour du pot, parce que à un moment donné, c'est qu'on va fichtremet avoir besoin de vous , quoi! prenons un debut , l'intitulé serait "réseau nerveux artificiel " il faut controller 80 DOF (degres of freedom) c'est à dire 80 moteurs.... les capteurs de positions ou de tension associés, une centrale inertielle, les entrees/sorties video et audio, plus des petits extras de derniere minute qui se feront connaitre à la... dernière minute! alors qui peut faire un joli dessin d'un réseau comme ça? il faut que les messages d'ordre et les infos de retour soient en permanence en train de se renouveler, sans se mélanger les pieds dans les pédales. autrement dit, sans rien y connaitre , je préconise l'emploi des bus CAN ( http://uuu.enseirb.fr/~kadionik/formation/canbus/canbus_enseirb.pdf ) pourquoi? parce que je fais confiance à un fin connaisseur qui en parlait ailleurs... (un roboticien , qui plus est! ) on a quelques mois devant nous, (pas mal en fait) , mais un de ces 4 , ce serait tellement formidable d'avoir un p*t*n de super reseau vivant , gerant les flux de millions de de données à la minute, permettant la marche en meme tant que le dialogue, le controle video, et la saisie d'objets, etc.... le principe que j'imagine d'ors et dejà , c'est un principe de remplissage progressif de précision comme une image GIF. c'est à dire que la courbe de fonctionnement est transmise dans sa totalité dès la premiere couche, mais avec 4 vortex par exemple, puis on transmets les 3 autres pour doubler la précision, puis à une énième couche, enfin le moteur aura vu une courbe "chiadée" de 255 vortex ! (pour déplacer un bras dans un environnement complexe avec mouvements relatifs du torse pendant les hauts et les bas de la marche en ligne courbe! ) ce qui permettrait au bras de partir tant que faire se peut pour voi ensuite se préciser son mouvement... il faut des cycles de reconnaissance de phase (tempo de simultanéité , etc...) mais peut etre que le protocole CAN en dispose déjà (je n'ai meme pas encore lu ce que je vous ai mis en lien) en revanche, si une année passe pour avoir un tel réseau opérationnel, ce serait chouette d'avoir un dessin en peu de chose. une premiere ebauche, puis un petit coin détaillé, etc... qu'en pensez vous ? quelques uns parmi vous seraient ils interessés par mettre la main à la pâte? amicalement, Phil
_________________ ce qui voit , se voit dans les yeux de ceux qui nous regardent... |
|
|
Haut
|
|
|
adrien8255
|
Publié: Jeu 23 Avr 2009, 08:08 |
|
|
| CurieuxInscrit le: Ven 20 Mar 2009, 21:12Messages: 6 |
J' avais déjà pensé à un truc du genre : déléguer les taches très bas niveau à des PICs qui serait eux-mêmes commander par un autre PIC ou PC servant de cerveau. Cela présente certains avantages : le programme principale serait, du fait plus simple, on aurait juste à envoyer l'ordre "avancer" au PIC(s) qui gère(nt) les jambes ou les roues pour avancer via un bus CAN par exemple. Ainsi, l'UC principale serait libre pour d'autre taches et les PICs "esclaves" gèreraient les collisions, déplacement et tout le reste. On pourrait ainsi implémenter le réflexe au sens propre : le PIC gère la situation d'urgence rapidement et envoie un rapport à l'UC sur l'ordre qui vient d'être reçu : "Action annulé : Surface trop chaude". Et puis contrôler 80 degrés de liberté via une seule unité de commande, ça doit vraiment être le gros bordel. Une tel architecture serait carrément un réseau, et le deboguage pourrait être un vrai calvaire  .
|
|
Haut
|
|
|
Calibanproject
|
Publié: Jeu 23 Avr 2009, 08:28 |
|
|
Roboticien initiéInscrit le: Jeu 23 Oct 2008, 14:27Messages: 1017Localisation: Saint-Ouen |
adrien8255 a écrit: J' avais déjà pensé à un truc du genre : déléguer les taches très bas niveau à des PICs qui serait eux-mêmes commander par un autre PIC ou PC servant de cerveau. Cela présente certains avantages : le programme principale serait, du fait plus simple, on aurait juste à envoyer l'ordre "avancer" au PIC(s) qui gère(nt) les jambes ou les roues pour avancer via un bus CAN par exemple. Ainsi, l'UC principale serait libre pour d'autre taches et les PICs "esclaves" gèreraient les collisions, déplacement et tout le reste. On pourrait ainsi implémenter le réflexe au sens propre : le PIC gère la situation d'urgence rapidement et envoie un rapport à l'UC sur l'ordre qui vient d'être reçu : "Action annulé : Surface trop chaude". Et puis contrôler 80 degrés de liberté via une seule unité de commande, ça doit vraiment être le gros bordel. Une tel architecture serait carrément un réseau, et le deboguage pourrait être un vrai calvaire  . En même temps, il est possible de faire aussi des programmes annexe de controle dans des thread indépendant qui se chargeraient des même tâches que les PICS (et serait aussi simple à mettre en place), de façon indépendante au programme maitre. OK ca consome du CPU mais dans ce cas là il suffit de surdimensionner la puissance de calcul ce qui, contrairement à une armée de PICS et autres controleurs, ne demande pas nécessairement d'embarquer plus de "masse" pour le traitement (cartes, Pics, batteries pour combler la hausse de conso...etc). Personellement, je ne suis pas super fan d'une architecture exploitant des controleurs physiques "off-shore" car je n'arrive pas a cerner son avantage sur des appli en thread. Mais je ne demande qu'a apprendre
_________________

Languages : Delphi, Pascal, C#, RPL, SQL, PL-SQL, Français, Anglais |
|
|
Haut
|
|
|
adrien8255
|
Publié: Jeu 23 Avr 2009, 09:31 |
|
|
| CurieuxInscrit le: Ven 20 Mar 2009, 21:12Messages: 6 |
Ben l'avantage comme je l'ai dit, c'est de ne pas avoir 80 fils arrivé à l'interface de ton UC,
Avec une architecture en réseau, tu as juste le bus qui se ballade dans le corps du robot.
Un autre avantage se verrait aussi dans le cas on ton UC plante dans un bipède : le PIC qui gère l'équilibre serait toujours online et le robot, toujours debout.
|
|
Haut
|
|
|
Calibanproject
|
Publié: Jeu 23 Avr 2009, 09:44 |
|
|
Roboticien initiéInscrit le: Jeu 23 Oct 2008, 14:27Messages: 1017Localisation: Saint-Ouen |
Un autre avantage se verrait aussi dans le cas on ton UC plante dans un bipède : le PIC qui gère l'équilibre serait toujours online et le robot, toujours debout. Ca pour le coup, je pense qu'effectivement c'est un trés trés gros avantage qui m'avait échappé jusqu'à present
_________________

Languages : Delphi, Pascal, C#, RPL, SQL, PL-SQL, Français, Anglais |
|
|
Haut
|
|
|
philopat
|
Publié: Jeu 23 Avr 2009, 22:06 |
|
|
Roboticien initiéInscrit le: Mer 5 Nov 2008, 00:19Messages: 1074Localisation: Paris - Chevreuse |
salut les gars! et les filles aussi  on est en phase adrien, en reponse à Calib, je dirais que je pense qu'une armée de pics ne pose pas specialement de probleme, si on a un meme pogramme embarqué avec une meme carte electronique qui le gere. ce qui serait different ne serait ce que la donnée d'entrée et le feedback local. on multiplie un truc qui marche bien , et qui s'adapte bien à sa mission locale. la donnée d'entrée serait en 3 composantes : - la position de reference (le referentiel qui sert au bazars à se demander si il a fait son boulot pour maitenir l'equilibre entre son feedback local et ldit referentiel , - les petits contre-ordres ou alterations en provenance de partout et qui perfectionne le rendu, c'est à dire pour la precision du geste en tenant compte de tout ce qui echappe à la pu-puce en question. -et le mode de fonctionnement (en mode superuser, pas à pas, lent, rapide, urgence, pour la compèt, etc..., force maxi, puissance maxi, mouvements artistiques, etc...) -toutefois, en plus de l'action sur le ou les moteurs qu'il controle , ce brave petit Pic doit envoyer l'info au cerveau et accompagné des caracteristiques associées du genre courant consommé par le dispositif controlé, les conditions de fonction, tension , temperature etc..., bref une carte postale! - pour le feeback local aussi, je pensais que les capteurs serait ratachables à un Pic tout pareil. et le but de maintien de l'equilibre est qu'il envoi un ordre à tous ceux qui controlent les moteurs permettant de faire varier le resultat lu, mais aussi bien entendu au cerveau, accessoirement, au cas, ou la conscience voudrait y mettre sa participation... -Phil-
_________________ ce qui voit , se voit dans les yeux de ceux qui nous regardent... |
|
|
Haut
|
|
|
Calibanproject
|
Publié: Jeu 23 Avr 2009, 23:54 |
|
|
Roboticien initiéInscrit le: Jeu 23 Oct 2008, 14:27Messages: 1017Localisation: Saint-Ouen |
philopat a écrit: salut les gars! et les filles aussi  on est en phase adrien, en reponse à Calib, je dirais que je pense qu'une armée de pics ne pose pas specialement de probleme, si on a un meme pogramme embarqué avec une meme carte electronique qui le gere. ce qui serait different ne serait ce que la donnée d'entrée et le feedback local. on multiplie un truc qui marche bien , et qui s'adapte bien à sa mission locale. la donnée d'entrée serait en 3 composantes : - la position de reference (le referentiel qui sert au bazars à se demander si il a fait son boulot pour maitenir l'equilibre entre son feedback local et ldit referentiel , - les petits contre-ordres ou alterations en provenance de partout et qui perfectionne le rendu, c'est à dire pour la precision du geste en tenant compte de tout ce qui echappe à la pu-puce en question. -et le mode de fonctionnement (en mode superuser, pas à pas, lent, rapide, urgence, pour la compèt, etc..., force maxi, puissance maxi, mouvements artistiques, etc...) -toutefois, en plus de l'action sur le ou les moteurs qu'il controle , ce brave petit Pic doit envoyer l'info au cerveau et accompagné des caracteristiques associées du genre courant consommé par le dispositif controlé, les conditions de fonction, tension , temperature etc..., bref une carte postale! - pour le feeback local aussi, je pensais que les capteurs serait ratachables à un Pic tout pareil. et le but de maintien de l'equilibre est qu'il envoi un ordre à tous ceux qui controlent les moteurs permettant de faire varier le resultat lu, mais aussi bien entendu au cerveau, accessoirement, au cas, ou la conscience voudrait y mettre sa participation... -Phil- En fait, je pense qu'un feedback de TIERRY8000 sur ce sujet serait trés interressant car il bosse depuis de longues années sur ce genre de problématique  Le seul hic est que je sais que, d'aprés nos echange par mails, il est trés peu dispo en ce moment car il est beaucoup de garde à l'hopital  Thierry, si tu nous lit, ce serait cool de nous éclairer de tes lumières
_________________

Languages : Delphi, Pascal, C#, RPL, SQL, PL-SQL, Français, Anglais |
|
|
Haut
|
|
|
philopat
|
Publié: Sam 25 Avr 2009, 22:53 |
|
|
Roboticien initiéInscrit le: Mer 5 Nov 2008, 00:19Messages: 1074Localisation: Paris - Chevreuse |
bonsoir , en faisant un petit tour dans la rubrique energie, http://forum.caliban-web.com/energie/construire-reseau-energetique-solution-intermediaire-t216.html#p1748ça m'a rappelé qu'il serait sage de penser aussi au controle des batteries locales près des moteurs. soit une batterie pour un moteur.. (ou presque) ça veut dire que le circuit de recharge ou d'inversion pour secours au cerveau , devrait etre géré d'une même maniere par un Pic, peut-être le meme que celui du moteur, mais là je dois dire, que sans vraiment connaitre, je suis sec. --- par rapport à la participation de T8000, je pense en effet que serait bien car je vois déjà l'interêt d'exploiter à bon escient son idée de simulation de trajectoire avant réalisation. c'est à dire pour detecter les collisions suite à l'apport des autres traitements en temps réel , et ainsi transmettre en temps réel les correctifs de trajectoire. (bon ok , le temps réel c'est relatif..) mais que tout autre passionné désireux d'entreprendre ce genre de chose n'hesite pas à se manifester, car il est n'est pas utile de stresser une personne qui voudrait participer meme au maximum, tant bien que mal, sans forcément pouvoir seule parvenir au but, en final. alors aidons nous les uns les autres, sans attendre forcément que l'un ai des difficultés pour qu'un autre prenne le relais. on peut participer à toutes les échelles de participation. Phil
_________________ ce qui voit , se voit dans les yeux de ceux qui nous regardent... |
|
|
Haut
|
|
|
|
Heures au format UTC
Utilisateurs parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité
|
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
|
|
|