Positron libre     EasyRobotics     Robot-passion     Assoc-Caliban     AMF     NaoForge     MbRobot 
Auteur Message

Index du forum <  Projets et études techniques  ~  réseau d'as de pic

MessagePublié: Mer 22 Avr 2009, 00:00
Avatar de l’utilisateurRoboticien 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! :lol:
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! :lol:

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. :8):
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...
Hors-ligne Profil
MessagePublié: 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 :peur: .


Hors-ligne Profil
MessagePublié: Jeu 23 Avr 2009, 08:28
Avatar de l’utilisateurRoboticien 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 :peur: .


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 ;)



_________________
Image

Languages : Delphi, Pascal, C#, RPL, SQL, PL-SQL, Français, Anglais
Hors-ligne Profil
MessagePublié: 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.


Hors-ligne Profil
MessagePublié: Jeu 23 Avr 2009, 09:44
Avatar de l’utilisateurRoboticien 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 :D



_________________
Image

Languages : Delphi, Pascal, C#, RPL, SQL, PL-SQL, Français, Anglais
Hors-ligne Profil
MessagePublié: Jeu 23 Avr 2009, 22:06
Avatar de l’utilisateurRoboticien 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...
Hors-ligne Profil
MessagePublié: Jeu 23 Avr 2009, 23:54
Avatar de l’utilisateurRoboticien 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 :o 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 :twisted: Thierry, si tu nous lit, ce serait cool de nous éclairer de tes lumières ;)



_________________
Image

Languages : Delphi, Pascal, C#, RPL, SQL, PL-SQL, Français, Anglais
Hors-ligne Profil
MessagePublié: Sam 25 Avr 2009, 22:53
Avatar de l’utilisateurRoboticien 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...
Hors-ligne Profil

Afficher les messages depuis:  Trier par:

Heures au format UTC
Page 1 sur 1
8 messages
Utilisateurs parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité
Rechercher pour:
Publier un nouveau sujet  Répondre au sujet
Sauter vers:  
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
cron