Création d'un head tracker
- Thread starter dje8269
- Start date
Ce serait une erreur : manifestement, votre façon de voir les choses est bien mieux comprise que la mienne.
Je vous laisse donc volontier la place, et je reconnais que ce fut une erreur de compenser ce magnétomètre, même sommairement, au moyen d'un Picaxe, alors que manifestement ce processeur ne permet pas de le faire.
Moi qui voulais vous rabibocher , je vais faire perdre a tout le monde des expert comme vous ;
PieM, tu ne peux pas arrêter, tu es un pilier de ce forum, et sans toi il est certainement destiné a mouru ! ou du moins ne sera plus aussi actif qu'avant . ce n'est pas une question de compliqué car sur ce coup , je préfère la tienne, plus proche de ma logique( même si j'ai compris le focntionnemetn j'aurais jamais pus faire un truc comme ca aussi simplement) Si tu avais vu mon programme qu is'approche du tiens il faisait au bas mot 50 lignes et 4 ou 5 variables de plus .
BESQUEUT vous avez réussis l'exploit de compenser un magnétomètre avec un picaxe , qui apparemment ne se prêtait pas du tout a ce genre d'exercice . Moi je dis chapeau l'artiste ;
Je vais essayer de pas vous décevoir , et je vais travailler pour vous faire une vidéo, des que j'aurais fais ma mise a l'échelle, tant pis pour le film de ce soir .
J'ai encore tellement de chose a apprendre avec vous ! Ce serait vraiment gacher votre savoir en arrêtant le forum, pensez a toutes ces personnes qui comptent sur vous . ( moi le premier) . Sans vous je serais encore a faire mon chenillard paint ball avec des bascules et des registres à decalage.
Faut-il que j'arrete de poster pour que vous restiez ? Je le ferais avec tritesse, mais ne quittez pas le forum a cause de mon post .
PieM, tu ne peux pas arrêter, tu es un pilier de ce forum, et sans toi il est certainement destiné a mouru ! ou du moins ne sera plus aussi actif qu'avant . ce n'est pas une question de compliqué car sur ce coup , je préfère la tienne, plus proche de ma logique( même si j'ai compris le focntionnemetn j'aurais jamais pus faire un truc comme ca aussi simplement) Si tu avais vu mon programme qu is'approche du tiens il faisait au bas mot 50 lignes et 4 ou 5 variables de plus .
BESQUEUT vous avez réussis l'exploit de compenser un magnétomètre avec un picaxe , qui apparemment ne se prêtait pas du tout a ce genre d'exercice . Moi je dis chapeau l'artiste ;
Je vais essayer de pas vous décevoir , et je vais travailler pour vous faire une vidéo, des que j'aurais fais ma mise a l'échelle, tant pis pour le film de ce soir .
J'ai encore tellement de chose a apprendre avec vous ! Ce serait vraiment gacher votre savoir en arrêtant le forum, pensez a toutes ces personnes qui comptent sur vous . ( moi le premier) . Sans vous je serais encore a faire mon chenillard paint ball avec des bascules et des registres à decalage.
Faut-il que j'arrete de poster pour que vous restiez ? Je le ferais avec tritesse, mais ne quittez pas le forum a cause de mon post .
PieM
Senior Member
Et bien expliquez mieux votre méthode simple pour qu'un novice puisse s'en sortir.
vous êtes trop bon. Mais je décline, et j'ignorai que l'on prenait "la place" de quelqu'un sur un forum.
Je ne vois pas le rapport.
J'ai vainement tenté. Plus simple que C=A+B je ne sais pas faire. J'ai aussi proposé un programme.
Je pense qu'il est préférable qu'il n'y ait qu'une seule approche sur ces sujets de façon à ne pas entraîner de confusion pour les lecteurs.
Manifestement, l'usage d'entiers relatifs est inaproprié. Et comme la compensation en fait un gros usage, ça ne peux que troubler encore plus les lecteurs.
Et comme je ne me sens pas de ré-écrire tout ça en vérifiant à chaque addition le signe des opérandes, je pense qu'il est préférable que vous continuez à proposer des solutions qui ont le mérite d'être comprises par tous.
Croyez bien qu'il n'y a aucune animosité dans mes propos. J'essaie de faire au mieux pour les passionés de Picaxe qui nous lisent et que je respecte profondément pour leur enthousiasme.
Je pense qu'il est préférable qu'il n'y ait qu'une seule approche sur ces sujets de façon à ne pas entraîner de confusion pour les lecteurs.
Manifestement, l'usage d'entiers relatifs est inaproprié. Et comme la compensation en fait un gros usage, ça ne peux que troubler encore plus les lecteurs.
Et comme je ne me sens pas de ré-écrire tout ça en vérifiant à chaque addition le signe des opérandes, je pense qu'il est préférable que vous continuez à proposer des solutions qui ont le mérite d'être comprises par tous.
Croyez bien qu'il n'y a aucune animosité dans mes propos. J'essaie de faire au mieux pour les passionés de Picaxe qui nous lisent et que je respecte profondément pour leur enthousiasme.
Oui : c'est pour laisser dans q sa valeur de départ sans changer son signe.
On aurait aussi pu utiliser une variable auxiliaire :
Temp=-q
sertxd("-",#Temp)
Mais le nombre de variables est assez limité, ça en fait une de moins.
A mon tour , voici la chose promise .
C'est fait un peu a l'arrache, mais bon, je n'avais pas trop le temps, de faire mieux .
Merci BESQUEUT pour ces paroles , qui font, je dois bien l'avoué , un grand plaisir ! Nous avons ré-inventé la stabilité gyroscopique . malheureusement le servo est alimenté avec l'alim picaxe, y'as des petit sursauts. Peu faire un effet sympa , j'ai mis le sens de rotation inversé, ainsi on as l'impression d'une stabilisation gyroscopique .
H-S : j'ai faillis vous demander si avec des picaxe on pouvait faire une nacelle avec stabilisation gyroscopique . mais je pense en acheter une toute faite car c'est tres pechu quand même .
Il n'y as pas de moyennage , car ça provoque de la latence ; je re-essayerais en version final ; sinon je ne suis pas contre tester votre methode BESQUEUT de ralentissement ; si c'est pas trop compliqué .
[video=dailymotion;x2h9uaj]http://www.dailymotion.com/video/x2h9uaj_magnetometre-compense-avec-picaxe_tech[/video]
lien vers vidéo plein ecran
@BESQUEUT : peut etre puis je enlevé certaines parties dans votre programme comme le S/prog affichage ?
C'est fait un peu a l'arrache, mais bon, je n'avais pas trop le temps, de faire mieux .
Merci BESQUEUT pour ces paroles , qui font, je dois bien l'avoué , un grand plaisir ! Nous avons ré-inventé la stabilité gyroscopique . malheureusement le servo est alimenté avec l'alim picaxe, y'as des petit sursauts. Peu faire un effet sympa , j'ai mis le sens de rotation inversé, ainsi on as l'impression d'une stabilisation gyroscopique .
H-S : j'ai faillis vous demander si avec des picaxe on pouvait faire une nacelle avec stabilisation gyroscopique . mais je pense en acheter une toute faite car c'est tres pechu quand même .
Il n'y as pas de moyennage , car ça provoque de la latence ; je re-essayerais en version final ; sinon je ne suis pas contre tester votre methode BESQUEUT de ralentissement ; si c'est pas trop compliqué .
Code:
' HeadTracker v11 2014_02_11 JYB (compense)
'
' Conventions de nommage suivant AN3192 STMicroelectronic
'
#picaxe 20X2
#no_table
{'Definition des symboles
symbol I=b1
symbol Ax=w1 ' b2_b3 valeurs brutes de l'accelerometre
symbol Ay=w2 ' b4_b5
symbol Az=w3 ' b6_b7
Symbol Pitch=w4
Symbol Roll=w5
Symbol pan = b12
symbol Mx=w7 ' b14_b15 valeurs brutes du magnetometre
symbol My=w8 ' b16_b17
symbol Mz=w9 ' b18_b19
symbol Cx=w10 ' X Compense
symbol Cy=w11 ' Y compense
symbol Angle = w20
symbol P=w21 ' variable temporaire
symbol R=w22 ' parametre pour multiplications et divisions
symbol Xm=w23 ' parametres de ATAN2
symbol Ym=w24
symbol A0=w25 ' Angle de reference pour le Heading
symbol Alpha=w26 ' retour de ATAN2 et de ASIN
symbol Q=w27 ' variable temporaire pour ATAN2 et autres
}
{'Definition des macros
#MACRO ATAN2(dx,dy) ' resultat retourne dans Alpha
Xm=dx
Ym=dy
gosub ATAN2_Function
#ENDMACRO
' ATTENTION
' Ne pas mettre beaucoup de code dans une macro, (sauf optimisation draconiene)
' En effet, ce code est recopie autant de fois que la macro est appelee...
' ici, on ne recopie que le GOSUB, pas ATAN2_Function...
#MACRO Quadrant(Qxm,Qym) ' Result ==> Alpha
if Xm>Ym then
gosub ATAN_Xm
Alpha=Qxm
else ' Xm < Ym
gosub ATAN_Ym
Alpha=Qym
endif
#ENDMACRO
#MACRO Affiche(Val)
Q=Val
gosub Affiche_Sub
#ENDMACRO
#MACRO Cosinus(Val)
Q=Val
gosub Cosinus_Function
#ENDMACRO
#MACRO Sinus(Val)
Q=Val
gosub Sinus_Function
#ENDMACRO
#MACRO Multipl(Val) ' multiplie Q par R
R=Val
gosub Multipl_Function
#ENDMACRO
}
{' Initialisations
setfreq m8 'frequence
servo B.1,150
{'************ initialisation accelerometre *******************
hi2csetup i2cmaster ,%00110000, i2cfast_8, i2cbyte
hi2cout $20,($27) 'activation
hi2cout $23,($00) 'mode 2g
b24=1
}
{'************ initialisation magnetometre *******************
hi2csetup i2cmaster ,%00111100, i2cfast_8, i2cbyte
hi2cout $02,($00) 'mode conversion continu
}
pause 100
}
hi2csetup i2cmaster ,%00110000, i2cfast_8, i2cbyte
hi2cin $A8, (b2,b3,b4,b5,b6,b7) ' lecture Accelerometre
hi2csetup i2cmaster ,%00111100, i2cfast_8, i2cbyte
for i=1 to 5
hi2cin $03, (b15,b14,b19,b18,b17,b16)' lecture des valeurs magnet X , Z et Y
next i
gosub Compense
ATAN2(cX,cY)
A0=Alpha
'================================================= =====================
'|||||||||||||||||||||| Programme principal |||||||||||||||||||||||||||
'================================================= =====================
do
hi2csetup i2cmaster ,%00110000, i2cfast_8, i2cbyte
hi2cin $A8, (b2,b3,b4,b5,b6,b7) ' lecture Accelerometre
hi2csetup i2cmaster ,%00111100, i2cfast_8, i2cbyte
hi2cin $03, (b15,b14,b19,b18,b17,b16) ' lecture Magnetometre
gosub Compense
ATAN2(cX,cY)
'sertxd ("alpha=",#Alpha," A0=",#A0)
if Alpha > A0 then
bit0 = 0 'sens cw
angle = Alpha - A0
else
bit0 = 1 'sens ccw
angle = A0 - Alpha
endif
if Angle > 180 then 'on prend le supplement et on inverse le sens
angle = 360 - angle
bit0 = not bit0
endif
angle = angle max 90
Affiche(Roll)
if bit0 = 1 then
pan = angle / 2 + 150
else
angle = angle /2
pan = 150 - angle
end if
servopos B.1,pan
'sertxd (" sens: ",#bit0," angle: ",#angle," pan: ",#pan,cr)
loop
'================================================= =====================
'|||||||||||||||||||||| Programme secondaire ||||||||||||||||||||||||||
'================================================= =====================
{ ' Sous programme de calcul de cX et cY compens?s
Compense:
' X Y Z
' maxi 542 688 187
' mini -452 -408 -835
'delta 994 1096 1022
'delta/2 497 548 511
' -45 140 324
mx=mx-45 ' etalonnage
my=my-140
mz=mz+324
gosub Pitch_Roll
Cosinus(pitch) ' resultat dans Q
Multipl(mX) ' Q=Q*Mx
cX=Q
Sinus(Pitch)
Multipl(mZ)
cX=cX-Q ' Xc=Xe * cos(Pich)- Ze *sin(Pitch)
Sinus(Roll)
Multipl(mX)
cY=Q
Sinus(Pitch)
Multipl(cY)
cY=Q ' Xe * Sin(Roll) * Sin(Pitch)
Cosinus(Roll)
Multipl(mY)
cY=cY+Q ' + Ye * Cos(Roll)
Sinus(Roll)
Multipl(mZ)
P=Q
Cosinus(Pitch)
Multipl(P)
cY=cY+Q ' + Ze * Sin(Roll) * Cos(Pitch)
Return
}
{ ' Affichage des nombre sign?s
Affiche_Sub:
if q<32768 then
else
q=-q
q=-q
endif
return
}
{'ATAN2
ATAN2_Function:
' Input Xm & Ym are 2 complement encoded
' Xm and YM can be anything from -32767 to + 32767
' So you can use Xm=X1-X2
' even if X2 greater than X1
'
if Ym <32768 then ' Ym > 0
if Xm<32768 then ' Xm > 0
Quadrant(Alpha,90-Alpha)
else ' Xm < 0
Xm=-Xm
Quadrant(180-Alpha,90+Alpha)
endif
else ' Ym < 0
Ym=-Ym
if Xm<32768 then ' Xm > 0
Quadrant(360-Alpha,270+Alpha)
else ' Xm < 0
Xm=-Xm
Quadrant(180+Alpha,270-Alpha)
endif
endif
RETURN
}
{ 'Reduction des nombres trop grands et calcul de l'arc Tangente
ATAN_Xm:
select case Ym ' Ym < Xm
case < 655 ' Ym < 655
Alpha=100*Ym/Xm
case < 6553 ' 655 < Ym < 6553 donc Xm > 655
Q=Xm/10
Alpha=10*Ym/Q
else ' 6553 < Ym donc Xm > 6553
Q=Xm/100
Alpha=Ym/Q
end select
Alpha=ATAN Alpha
RETURN
ATAN_Ym:
select case Xm ' Xm < Ym
case < 655 ' Xm < 655
Alpha=100*Xm/Ym
case < 6553 ' 655 < Xm < 6553
Q=Ym/10
Alpha=10*Xm/Q
else ' 6553 < Xm
Q=Ym/100
Alpha=Xm/Q
end select
Alpha=ATAN Alpha
RETURN
}
{' Calcule Pitch et Roll
Pitch_Roll:
if Ax<32768 then
Alpha=Ax/16
gosub ASIN_P
Q=cos Alpha
Pitch=-alpha '180-Alpha
else
Alpha=-Ax/16
gosub ASIN_P
Q=Cos Alpha
Pitch=alpha '180+Alpha
endif
if Ay<32768 then
Alpha=Ay/16*100/Q
gosub ASIN_P '180+Alpha
Roll=alpha
else
Alpha=-Ay/16*100/Q
gosub ASIN_P '180-Alpha
Roll=-alpha
endif
return
ASIN_P: ' sin(90?)=1050
select case Alpha
case <750:Alpha=Alpha+8/17
case <960:Alpha=Alpha-750/10+45
case <1040:Alpha=Alpha-960/4+66
else:Alpha=90
endselect
return
Cosinus_Function:
if Q>32767 then
q=-q
endif
Q=cos q
return
Sinus_Function:
if Q<32768 then
Q=sin q
else
q=-q
q=sin q
q=-q
endif
return
Multipl_Function: ' resultat dans Q
if Q<32768 then
if R<32768 then
Q=R/2*Q+25/50
else
R=-R
Q=R/2*Q+25/50
Q=-Q
endif
else
Q=-Q
if R<32768 then
Q=R/2*Q+25/50
Q=-Q
else
R=-R
Q=R/2*Q+25/50
endif
endif
return
}lien vers vidéo plein ecran
@BESQUEUT : peut etre puis je enlevé certaines parties dans votre programme comme le S/prog affichage ?
Code:
{ ' Affichage des nombre sign?s
Affiche_Sub:
if q<32768 then
else
q=-q
q=-q
endif
return
}Affiche_Sub et la macro qui va avec ne servent qu'à afficher des nombres relatifs (sertxd ne sait pas faire).
Vous pouvez l'enlever si vous n'avez pas besoin d'afficher de nombres relatifs.
Comme prévu, c'est assez calculatoire. Je pense qu'il est possible d'optimiser un peu le code.
Une autre solution "force brute" est de mettre le Picaxe à fond...
Et on peut faire une moyenne mobile sur 3 ou 4 valeurs sans consommer beaucoup de CPU et sans trop changer la réactivité.
Merci pour la vidéo.
Vous pouvez l'enlever si vous n'avez pas besoin d'afficher de nombres relatifs.
Comme prévu, c'est assez calculatoire. Je pense qu'il est possible d'optimiser un peu le code.
Une autre solution "force brute" est de mettre le Picaxe à fond...
Et on peut faire une moyenne mobile sur 3 ou 4 valeurs sans consommer beaucoup de CPU et sans trop changer la réactivité.
Merci pour la vidéo.
Je ferais un test avec l'analyseur logique, pour voir le temps que ça prends par curiosité .
Pour le picaxe à fond, je sais pas trop comment m'y prendre , mais comme me la préconisé PieM, je pense dédié un 20X2, rien que pour le head tracker. Cela sera plus simple et surtout que je suis à la recherche de rapidité pour l'émission. Ou alors pourquoi pas un 08M2 si j'ai pas besoin de passer en esclave.
Dans la version final il n'y aura pas de commande servo, mais une inscription dans le scratchpad pour que je puisse récupérer les valeurs avec le bus
Pour le picaxe à fond, je sais pas trop comment m'y prendre , mais comme me la préconisé PieM, je pense dédié un 20X2, rien que pour le head tracker. Cela sera plus simple et surtout que je suis à la recherche de rapidité pour l'émission. Ou alors pourquoi pas un 08M2 si j'ai pas besoin de passer en esclave.
Dans la version final il n'y aura pas de commande servo, mais une inscription dans le scratchpad pour que je puisse récupérer les valeurs avec le bus
Jacques ROBERT
Senior Member
Bonsoir tardif mais je ne veux pas attendre demain pour réagir : je ne suis pas souvent intervenu dans le forum,mais à chaque fois j'ai été remis sur le bon chemin par PieM et j'ai
progressé grâce à Lui ,alors je vous demande PieM : ne nous abandonnez pas,personnellement j'aime votre pédagogie et bien d'autres doivent penser comme moi et ont besoin de vous
pour continuer à avancer . Continuez PieM.MERCI.
progressé grâce à Lui ,alors je vous demande PieM : ne nous abandonnez pas,personnellement j'aime votre pédagogie et bien d'autres doivent penser comme moi et ont besoin de vous
pour continuer à avancer . Continuez PieM.MERCI.
@ BESQUEUT : pourquoi lire 5 fois de suite les valeurs du magnétomètre ? une raison particulière, car j'essaye de comprendre
Je viens d'effectuer le test avec l'analyseur logique. je crois qu'il est effectivement indispensable de faire mouliner le picaxe a fond les gamelles ; Le temps de calcul fait 91ms . le temps d'ecrire en strachpad de 910µs. Il faudrait tomber en dessous de 40ms pour avoir au moins , une MAJ par envoie RF .
Dédié un picaxe 20X2 en le mettant a 64Mhz je vais essayer
Ok , ca roule je viens de mettre a 64Mhz le 20X2 avant les calculs , et le temps d'exécution tombe à 15ms .
est ce que ça vaut le coup de moyenner sur 2 valeurs seulement avant de mettre la valeur dans le scratchpad?
Code:
for i=1 to 5
hi2cin $03, (b15,b14,b19,b18,b17,b16)' lecture des valeurs magnet X , Z et Y
next iDédié un picaxe 20X2 en le mettant a 64Mhz je vais essayer
Ok , ca roule je viens de mettre a 64Mhz le 20X2 avant les calculs , et le temps d'exécution tombe à 15ms .
est ce que ça vaut le coup de moyenner sur 2 valeurs seulement avant de mettre la valeur dans le scratchpad?
Last edited:
Pour l'init : non rien de concret ; c'est à la limite juste une temporisation.
Je voulais juste voir si ces valeurs étaient immédiatement stables ou s'il fallait attendre un peu mais je ne suis pas allé au bout de l'idée.
Pour la moyenne mobile : pas d'avis à priori. Il faudrait essayer sur les jeux d'essais disponibles et voir ce que ça donne.
Bonjour ,
Après avoir travaillé sur le hard, je me plonge dans le boitier du HT .
J'avoue hésiter sur la bonne façon de m'y prendre ; Mais le hard reste le hard, et je crois qu'il va m'obliger a faire ainsi . je voudrais votre avis, Si vous voulez bien me le donner . M'étant déjà frotter un multi-maitre en i2C, je pense que ce ne sera pas possible .
Dédié un 20X2, pour la boussole, ne sera malheureusement pas possible . tout simplement car le 20X2 dédié , devras être maitre, pour lire la boussole , mais sur le BUS il y a déjà un maitre, c'est celui qui émet les infos ( solution multimaitre) .
Donc du coup ça fonctionne pas .
Du coup je pensais faire gérer les calculs par mon 28X2 ( celui des TOR), mais même problématique, il doit être esclave car c'est le 20M2 émission le maitre dans l'histoire ( multi maitre).
Il me reste qu'une seule solution le faire gérer par le 20M2 . en changeant d'esclave ( un coup le 28X2 pour lire les TOR et si l'inter du HT est activé, on intégré la lecture de la boussole dans une boucle).
Quel serait les avantages ? et les inconvénients ?
déjà , pendant que l'on pilote la camera, la voiture est arrête , donc déjà pas besoin de gérer les infos des joysticks .
Le 20M2 mouline déjà à 32Mhz , donc ça c'est un point positif car le temps de calcul sera bien réduit ( 15ms) .
Ca me pète quand même la réactivité, peut être que ce n'est pas trop gênant, car le VHL est arrêté .
Voila , que vous faudrait-il pour avoir une vision de la chose , afin de m'aider . programme ? schéma ? je voulais pas tout poster , alors demandez moi , et je fournis.
Après avoir travaillé sur le hard, je me plonge dans le boitier du HT .
J'avoue hésiter sur la bonne façon de m'y prendre ; Mais le hard reste le hard, et je crois qu'il va m'obliger a faire ainsi . je voudrais votre avis, Si vous voulez bien me le donner . M'étant déjà frotter un multi-maitre en i2C, je pense que ce ne sera pas possible .
Dédié un 20X2, pour la boussole, ne sera malheureusement pas possible . tout simplement car le 20X2 dédié , devras être maitre, pour lire la boussole , mais sur le BUS il y a déjà un maitre, c'est celui qui émet les infos ( solution multimaitre) .
Donc du coup ça fonctionne pas .
Du coup je pensais faire gérer les calculs par mon 28X2 ( celui des TOR), mais même problématique, il doit être esclave car c'est le 20M2 émission le maitre dans l'histoire ( multi maitre).
Il me reste qu'une seule solution le faire gérer par le 20M2 . en changeant d'esclave ( un coup le 28X2 pour lire les TOR et si l'inter du HT est activé, on intégré la lecture de la boussole dans une boucle).
Quel serait les avantages ? et les inconvénients ?
déjà , pendant que l'on pilote la camera, la voiture est arrête , donc déjà pas besoin de gérer les infos des joysticks .
Le 20M2 mouline déjà à 32Mhz , donc ça c'est un point positif car le temps de calcul sera bien réduit ( 15ms) .
Ca me pète quand même la réactivité, peut être que ce n'est pas trop gênant, car le VHL est arrêté .
Voila , que vous faudrait-il pour avoir une vision de la chose , afin de m'aider . programme ? schéma ? je voulais pas tout poster , alors demandez moi , et je fournis.
Voir Tome 2, Appendix 4
Autrement dit, ça peut marcher, mais ça peut aussi merder...
C'est pour ça que j'ai parlé de communications "fiables"
Un handshake est un dialogue entre deux périphériques qui doivent communiquer entre eux pour s'assurer que l'un est prêt à envoyer les données et l'autre prêt à les recevoir.
Voir flow_control ou rts--cts-hardware-flow-control-
On peut faire ça en soft (par exemple avec des XON, XOFF)
mais sur un Picaxe, il me semble plus performant de faire ça en hard, c'est à dire au moyen d'au moins une ligne supplémentaire.
Si ce protocole est correctement mis en place, il n'est pas nécessaire d'utiliser les fonctions "background" puisqu'on s'est mis d'accord pour être disponibles pour faire le travail.
Par exemple :
Quand le M2 est prêt à recevoir des données, il envoie une impulsion sur la ligne de handshake, puis se met en réception pour quelques ms.
Coté X2, c'est relié à une interruption, laquelle envoie le dernier Heading et le dernier Pitch sous forme de 2 octets.
Si les interruptions coté X2 perturbent le I2C (oui c'est aussi incompatible...), on utilise deux lignes de handshake :
"prêt à émettre" et "prêt à recevoir"
Dans ce cas, le M2 ne se met en réception que si le "prêt à émettre" est monté
La mise au point du bidule n'est pas triviale. Prévoir une maquette avec un émetteur de paquets numérotés pour valider le protocole.
Une fois au point, c'est à la fois fiable et très réactif.
Code:
Possible Conflicting Commands
Internal Interrupt Driven Event Tasks
Task: Internal Interrupt: Command:
Background serial receive Serial interrupt hsersetup
Background I2C slave mode I2C interrupt hi2csetup
...
Frequency Dependent Internal Background Tasks
Task: Internal Module: Commands:
PWM Timer 2 & pwm pwmout / hpwm
Background serial receive Serial receive hsersetup
Background I2C slave mode I2C receive hi2csetup
Servo Timer 1 & 2 servo
Timer Timer 1 settimer
Timer 3 Timer 3 tmr3setupC'est pour ça que j'ai parlé de communications "fiables"
Un handshake est un dialogue entre deux périphériques qui doivent communiquer entre eux pour s'assurer que l'un est prêt à envoyer les données et l'autre prêt à les recevoir.
Voir flow_control ou rts--cts-hardware-flow-control-
On peut faire ça en soft (par exemple avec des XON, XOFF)
mais sur un Picaxe, il me semble plus performant de faire ça en hard, c'est à dire au moyen d'au moins une ligne supplémentaire.
Si ce protocole est correctement mis en place, il n'est pas nécessaire d'utiliser les fonctions "background" puisqu'on s'est mis d'accord pour être disponibles pour faire le travail.
Par exemple :
Quand le M2 est prêt à recevoir des données, il envoie une impulsion sur la ligne de handshake, puis se met en réception pour quelques ms.
Coté X2, c'est relié à une interruption, laquelle envoie le dernier Heading et le dernier Pitch sous forme de 2 octets.
Si les interruptions coté X2 perturbent le I2C (oui c'est aussi incompatible...), on utilise deux lignes de handshake :
"prêt à émettre" et "prêt à recevoir"
Dans ce cas, le M2 ne se met en réception que si le "prêt à émettre" est monté
La mise au point du bidule n'est pas triviale. Prévoir une maquette avec un émetteur de paquets numérotés pour valider le protocole.
Une fois au point, c'est à la fois fiable et très réactif.
Last edited:
Surtout qu'il faut peut etre prendre en compte la longueur du câble dans cette histoire non ? quelle est la com la plus adéquat pour transiter dans disons 80cm de câble ?.
On n'est peut etre pas obligé de passer un background receive . mais une liaison serie normal ? j'avoue ne pas encore d'expérience sur les différentes com possible
On n'est peut etre pas obligé de passer un background receive . mais une liaison serie normal ? j'avoue ne pas encore d'expérience sur les différentes com possible
Sans Garantie Du Gouvernement...
Le X2 envoie les données quand ça lui chante, (disons 3 octets, plus une balise genre 255 impossible pour les 3 autres, disons à la fin)
Le M2 va voir de temps en temps ce qu'il y a dans son tampon mémoire.
Vu qu'il n'y a pas de synchronisation, il peut y avoir n'importe quoi :
- rien du tout (pas grave : on continue)
- 4 octets ou plus dont une balise après le 3ième octet : on cherche la balise, on prends les 3 octets précédents, et on vide le tampon de ce qu'on a pris.
- moins de 4 octets ou pas de balise ou pas assez de caractères avant la balise : on attends le prochain tour.
Impossible de prédire le taux de paquets reçus altérés; ni le taux d'émission foireuses parce que le timing a été perturbé par la réception d'un paquet "en background"
vous verrez bien...
Le X2 envoie les données quand ça lui chante, (disons 3 octets, plus une balise genre 255 impossible pour les 3 autres, disons à la fin)
Le M2 va voir de temps en temps ce qu'il y a dans son tampon mémoire.
Vu qu'il n'y a pas de synchronisation, il peut y avoir n'importe quoi :
- rien du tout (pas grave : on continue)
- 4 octets ou plus dont une balise après le 3ième octet : on cherche la balise, on prends les 3 octets précédents, et on vide le tampon de ce qu'on a pris.
- moins de 4 octets ou pas de balise ou pas assez de caractères avant la balise : on attends le prochain tour.
Impossible de prédire le taux de paquets reçus altérés; ni le taux d'émission foireuses parce que le timing a été perturbé par la réception d'un paquet "en background"
vous verrez bien...
Last edited:
Après réflexion et étude de mes schémas ,votre méthode me parait la meilleur approche . Pourquoi est ce que je dis ca !
Car en fait on se retrouve exactement dans la même position que sur le récepteur du drone . En effet lui aussi possède son maitre ( 20X2) qui a en esclave le SD-20( pour les servos) . et même temps il reçoit les infos venant du 28X2 en RF , en background serial . Et pour le moment ça fonctionne parfaitement bien !
donc en gros mon 20X2 communique avec mon 20M2 en hserin/hserout . Je pense que ce coup ci c'est la bonne ! . il faut donc , que je démonte ma télécommande et strap la communication hserin/hserout , sur mon connecteur .
La distance est elle problématique avec la liaison série ? surtout a cote de l'alim ?
Car en fait on se retrouve exactement dans la même position que sur le récepteur du drone . En effet lui aussi possède son maitre ( 20X2) qui a en esclave le SD-20( pour les servos) . et même temps il reçoit les infos venant du 28X2 en RF , en background serial . Et pour le moment ça fonctionne parfaitement bien !
donc en gros mon 20X2 communique avec mon 20M2 en hserin/hserout . Je pense que ce coup ci c'est la bonne ! . il faut donc , que je démonte ma télécommande et strap la communication hserin/hserout , sur mon connecteur .
La distance est elle problématique avec la liaison série ? surtout a cote de l'alim ?
Ça dépends de la vitesse et de la qualité du câble. Avec un câble blindé :
Débit (bit/s) Longueur (m)
2400 60
4800 30
9600 15
19200 7,6
38400 3,7
56000 2,6
A 19200, voire 9600 vous êtes "tranquille"
Excellent merci pour cette bonne nouvelle .
Question Hard ca risque d'être très compliqué . En effet la broche Hserin ( B.6) du 20M2 est déjà prise pour la lecture d'un joystick . pas de chance ! j'abandonne donc cette idée , vu le temps que j'ai passé a faire la télécommande , je me sent pas le courage de tout refaire .
Je vais me rabattre et tester la solution , plus simple niveau hard , et peut être pas si gênant que ca .
Il s'agirait de rester en i2C, avec un risque de perte de réactivité . car plutôt que de faire un envoie tout les 40ms j'en ferais un toute les 40+15= 55ms . pas si grave, surtout que la voiture sera arrêté.
Désolé de tout ces changements, mais bon j'essaye de voir les problèmes au fur et a mesure
Question Hard ca risque d'être très compliqué . En effet la broche Hserin ( B.6) du 20M2 est déjà prise pour la lecture d'un joystick . pas de chance ! j'abandonne donc cette idée , vu le temps que j'ai passé a faire la télécommande , je me sent pas le courage de tout refaire .
Je vais me rabattre et tester la solution , plus simple niveau hard , et peut être pas si gênant que ca .
Il s'agirait de rester en i2C, avec un risque de perte de réactivité . car plutôt que de faire un envoie tout les 40ms j'en ferais un toute les 40+15= 55ms . pas si grave, surtout que la voiture sera arrêté.
Désolé de tout ces changements, mais bon j'essaye de voir les problèmes au fur et a mesure
Ca tombe bien j'en ai besoin que de deux !
C'est sur , j'aurais pus aussi mettre un pentium 7 . j'avais ouvert un post pour savoir comment m'y prendre sur l'architecture.
Le head-tracker est arrivé après ; alors faut s'adapter ; J'ai la flemme d'aller relire le post pour verifier si on en avait parler ou non
Mais balancer des phrases, pour me ridiculiser, ne fait pas avancer le schimlblick ,et je commence à saturer . Je sais bien que je fais tout mal , je sais bien que je suis un bon a rien, et que sans vous j'arriverais a rien . Mais est ce nécessaire de me rabaisser à chaque fois que j'ai un problème, ou que je fais une erreur.
J'apprends encore de ma connerie certes ; mais y'as que ceux qui font rien, qui n'en font pas ! . Et comme je fais plein de chose , ben j'en fais plein .
Si tu as une autre solution que de faire ça en i2C avec un multi-esclave , je suis tout ouïe .
2 octets : ça reste jouable en tassant bien.
Et ça m'a même l'air plutôt bien car directement issu du hardware, donc non susceptible d'interférer avec d'autres commandes.
Reste à trouver une astuce pour ne pas confondre le heading et le pitch, et on peut même avoir 2 fois le pitch ou deux fois le heading...
Vraiment pas moyen de mettre un petit strap pour prendre le joystick ailleurs ?
Last edited:
Oui mais sur cette façon c'est le hard qui coince ! Pour le moment j'ai vraiment pas le gout a refaire toute la télécommande ; Et avec la puissance HF je ne prefére pas mettre de straps sur la lecture analogique ; J'ai déjà tellement galérer a faire cohabiter tout ça dans une télécommande du commerce .
Je pense que c'est plus jouable en i2c
je vous tiendrais au courant bien entendu, ne serait ce que par respect envers tout le travail que vous savez fait; Pour le moment je vais garder mes problèmes pour moi, je viendrais quand même avant de lancer mon projet par la fenêtre .
et si y'as pas de HT ben tant pis pour moi après tout ;
PieM
Senior Member
post 256
et il me semble qu'il était question dans un post très récent de recevoir 4 octets dans le buffer d'un M2....
Et je ridiculise quoi ?
Désolé de t'avoir donné des idées dès le départ que tu n'as pas jugé utile d'approfondir pour te fixer sur ton multi maître.
Je te promets de ne plus intervenir sur tes réalisations.
C'est tout de même pas moi qui en ai parlé !dje said:
et il me semble qu'il était question dans un post très récent de recevoir 4 octets dans le buffer d'un M2....
Et je ridiculise quoi ?
Désolé de t'avoir donné des idées dès le départ que tu n'as pas jugé utile d'approfondir pour te fixer sur ton multi maître.
Je te promets de ne plus intervenir sur tes réalisations.
En effet un 28X2 serait passé, car il possède la fonction rfout. J'avais oublié.
Ça ne me dis rien . Pour moi, à première vue seul , le pitch et le heading doivent être envoyer, les calculs se faisant à l’arrivée.
moi.
J'en suis fort triste. Car j'avais encore plein projet. Je suis dégoûté pour moi et pour ce forum.
C'est moi qui ait envisagé ça dans un premier temps :
7 bits pour chaque direction en valeur absolue, plus un bit à zéro pour faire un octet.
1 octet pour les bits de signe, 5 bits de checksum et un zéro final.
1 octet de balisage $FF pour repérer la fin de transmission.
Le protocole est fiable mais trop riche.
Désolé : je ne connaissais pas les limites de la série M2.
Comme indiqué, le M2 a l'avantage de gérer 2 octet en hard, donc sans aucune incompatibilité avec d'autres commandes.
J'ai donc fait une proposition pour faire passer tout ça dans 2 octets, mais c'est encore incomplet car il faudrait pouvoir identifier chaque octet, donc n'utiliser que 7 bits dans chaque direction.
boussole-miniature-compensee
a un tarif presque raisonnable.
a un tarif presque raisonnable.
Bonjour,
Toujours en congé paternité, alors je profite de mon petit bout de choux, avant de ré attaqué le boulot.
Sachez que vous allez très vite me revoir sévir , sur le forum.
Vos 2 références sont tous elles équivalentes ? Et conviendrait elle a mon application? Car sur la dernière c'était aussi marquée compensée dessus, et pourtant c'était mensonger.
J'aurais plus de faciliter avec celle de chez gotronic, car j'ai fais ouvrir une ligne de compte dessus.
Si vous me dites que ce serait adéquate, j'en prendrais quelques une lors d'une prochaine commande
Merci en tout cas et à très bientôt
Toujours en congé paternité, alors je profite de mon petit bout de choux, avant de ré attaqué le boulot.
Sachez que vous allez très vite me revoir sévir , sur le forum.
Vos 2 références sont tous elles équivalentes ? Et conviendrait elle a mon application? Car sur la dernière c'était aussi marquée compensée dessus, et pourtant c'était mensonger.
J'aurais plus de faciliter avec celle de chez gotronic, car j'ai fais ouvrir une ligne de compte dessus.
Si vous me dites que ce serait adéquate, j'en prendrais quelques une lors d'une prochaine commande
Merci en tout cas et à très bientôt
PieM
Senior Member
Ben ce sont les mêmes puisque Gotro revend ce produit Robot Shop.
Dans le LSM303, il ne pouvait pas y avoir de compensation, car il était non pourvu d'un µC pour faire les calculs.
J'ai déjà dit précédemment que c'est une amélioration du CMPS09 compensé (6 DOF) que j'utilisais il y a quelques années.
voir doc http://www.robot-electronics.co.uk/htm/cmps11doc.htm.
Last edited:
Oui c'est la même chose. Pas vraiment mensonger, mais ambigu. Comme dit par PieM, ce module mets à disposition les données brutes, mais calcule en plus l'angle compensé. Voir en particulier les commandes 0x12, 0x13 et 0x23
http://www.robot-electronics.co.uk/htm/cmps11ser.htm
C'est pour ça que j'ai indiqué ce nouveau référencement.
Demain commande du module chez gotronic.
Avec d'autre bricole http://www.gotronic.fr/art-capteur-d-empreinte-digitale-ada751-19580.htm, pour verrouiller mon établi . Car rien de plus désagréable de ne pas retrouvé ces outils quand on s'absente.
Avec d'autre bricole http://www.gotronic.fr/art-capteur-d-empreinte-digitale-ada751-19580.htm, pour verrouiller mon établi . Car rien de plus désagréable de ne pas retrouvé ces outils quand on s'absente.