Télécommande RC

dje8269

Senior Member
Bonjour à tous ,

Pour des raisons de timing, je souhaite utilisé les Picaxes pour mon projet .( On m'a demandé d'avancer un peu plus vite)

Le cahier des charges; fabriquer une radio commande pour piloter un VHL à distance par voie radio .

Fort de mon expérience de la première voiture RC, je souhaite reproduire celle-ci avec disons un meilleur rendement ou réactivité , ou façon de faire . Avant de me lancer dans les schéma je souhaiterais voir avec vous la meilleure façon de s'y prendre, afin d'obtenir les meilleurs résultats possibles . Votre expertise dans tous les domaine me sera fort précieuse;

caracteristiaque de la radioCommande :
- Transmission radio par emetteur : emetteur
- Un barregraphe : barregraphe
- 2 joystick analogiques ( chacun deux voies) .
- 5 interrupteurs à bascule.
- 4 boutons poussoirs.

La télécommande (de récupération) est en construction : et bientôt finis pour la partie non électronique .

HPIM2462.jpg
HPIM2466.jpg



Voila vous avez une idée de la chose .

Ma plus grosse priorité c'est l'envoi d'information sûre et le plus rapidement possible .

Pour ce faire: je pensais dédié un Picaxe à l'émission radio un 14M2 par exemple avec le codage manchester . Son rôle serait de récupérer les valeurs des joysticks sur des entrées analogiques puis d'envoyer les datas . Les tors seront écrit dans son scratchpad dans b0 et b1 par liaison I2C.
Ainsi je pense que le 14M2 enverrais le plus rapidement possible les valeurs .

Pour gérer tous le contexte un 20X2 en mode master :
son rôle , récupérer les données des TOR ( certains devront être temporisés), recuperer les infos alimentation, gestion du barre-graphe , gestion du buzzer , envoie des infos sur le slave en mode I2C .

Voila , est ce que pour vous c'est une bonne idée, ou façon de faire ? avez vous des suggestions, des idées , des interrogations, des certitudes ?

Merci de m'avoir lu .
 

BESQUEUT

Senior Member
J'imagine qu'il y a aussi un cahier des charges pour le récepteur, en particulier poids et encombrement...
Si ce n'est pas indiscret (genre pilotage d'un drone au dessus d'un site sensible... :rolleyes:), pourquoi réinventer ce qui existe déjà ?
 

dje8269

Senior Member
pourquoi réinventer ce qui existe déjà ?
Ben justement car c'est n'existe pas ou peu, pour un vhl TERRESTRE . L'avantage d'un drone volant est que la liaison aussi bien radio que vidéo se fait en liaison direct , on s'affrranchit donc , de beaucoup d'obstacles et de perturbations , qui sont très très présente en liaison sol/sol .

Tout ce que j'ai pu trouvé sur les robots militaires en sol/sol ou autres industrie , ont une portée de quelques centaines de mètres , tout au plus .
 

PieM

Senior Member
fabriquer une radio commande pour piloter un VHL à distance par voie radio .
Quelles sont les fonction de ce "VHL" (c'est quoi ?) ? Car si il y a des contraintes de sécurité c'est avant tout le problème à prendre en compte !

Un 14M2 en émission c'est ce qui a été fait non ?
Les tors seront écrit dans son scratchpad dans b0 et b1 par liaison I2C.
Il n'y a pas de scratchpad sur un 14M2!
Pour gérer tous le contexte un 20X2 en mode master :
heu... en mode slave non ?

Je ne vois pas trop la différence avec ce qui a été déjà réalisé...
 

dje8269

Senior Member
Car si il y a des contraintes de sécurité c'est avant tout le problème à prendre en compte !
Il n'y as pas de problème de sécurité a proprement parlé , mais juste une sécurité pour éviter de faire une action par accident, Cette sécurité est faite en Hard par un interrupteur à bascule sécurisé,( qui doit être soulever pour pouvoir commuter).

Un 14M2 en émission c'est ce qui a été fait non ?
Sur la deuxième voiture c'est un 20M2 , mais c'est pareil dans le fonctionnement, rien de nouveau de ce cote la.

Il n'y a pas de scratchpad sur un 14M2!
Oups j'ai du utilisé le mauvais terme . je veux dire, que les TOR ne seront pas traités par le 14M2 , mais lui seront envoyés par une liaison I2C .

heu... en mode slave non ?
Non je crois pas, mais tu me mets le doute .

Je ne vois pas trop la différence avec ce qui a été déjà réalisé...
Effectivement y 'as une énorme ressemblance . Mais une importante pour moi . c'est le traitement de l'information .

Dans le proto les calculs sont effectué par le même µC que celui qui envoie les infos .la différence se situe en gros ici .

On as vu, dans le proto , que le temps entre deux émission était difficilement améliorable( voir pas du tout), du fait de la commande Rfout qui met 37ms pour envoyer ses 8 octets . Par contre Peut être et c'est la que votre expertise est précieuse, on peut en gagner un peu , en faisant tout les calculs en parallèle je pense .
Laissant ainsi le 14M2 seulement ou presque, faire un Rfout .
et aussi, peut être que j'avais pas fait les choses très "proprement" dans le proto ; et qui peuvent etre améliorés . Car ma vision des choses peu être tronquée par mon inexpérience, comme sur le calcul du temps dans le compte a rebours, qui l'a bien démontré.

Mais peut être qu'il n'y as rien a faire de plus ou de mieux .

je pense que le 14M2 emission devra etre esclave non ? car il recevra les infos des TOR du 20x2 DATA . et le 20X2 dATA doit pouvoir lire le 14M2, pour effectué les calculs sur la position des joysticks .
 

PieM

Senior Member
du fait de la commande Rfout qui met 37ms pour envoyer ses 8 octets
Le timing du RFOUT est incompressible. Quels calculs sont à faire ?
je pense que le 14M2 emission devra etre esclave non
Un 14M2 ne peut pas être esclave.
Ne connaissant pas le nombre d'infos à traiter ni les traitements à faire, difficile de définir une architecture.
 

dje8269

Senior Member
Quels calculs sont à faire ?
rien de bien méchants, le même calcul que sur le proto grossomodo , pour connaitre la position des joysticks . on fait l'addition de 3 valeurs analogiques et on les compares a une référence . cela dans le but de désactivé l'emeteur qaund on ne touche pas au joystick et/ou aux TORs ;

Un 14M2 ne peut pas être esclave.
C'est exact , je viens de m'en apercevoir . ce seras donc je pense deux 20X2 du coup .

Ne connaissant pas le nombre d'infos à traiter ni les traitements à faire, difficile de définir une architecture.
pas de soucis je peux vous donné les infos que je possède.
Les infos seront les même que sur le proto des TOR . Mais il m'en faudrait 9 pour le moment . ( je peux éventuellement descendre à 8 mais ça me complique le hard ) . la gestion de ces TOR devront être temporisé , je m'explique , pour passer les vitesses je souhaite que l'interrupteur puisse être pris en compte seulement après un moment après le basculement . dans le but de laisser le temps a la mécanique d'effectuer son travail ; et surtout a la réception de traiter les différentes mouvements a effectuer . Car le passage de vitesse doit s'accompagner d'un protocole pour ne pas abimer les pignons .
 

BESQUEUT

Senior Member
Tout ce que j'ai pu trouvé sur les robots militaires en sol/sol ou autres industrie , ont une portée de quelques centaines de mètres , tout au plus .
Quelle est la portée minimale envisagée, avec donc un très bon niveau de fiabilité ?
Si c'est ça le gap, il me semble judicieux de faire des essais de transmission fiabilisée avant même de monter le tout dans les boitiers, mais avec les antennes ad hoc...
 

PieM

Senior Member
Jeremy, Je le repéte :
Android, et GSM.
S'il te plait ...
Pas pratique en zone blanche....

@ Jeremy:

Il n'y as pas de problème de sécurité a proprement parlé , mais juste une sécurité pour éviter de faire une action par accident, Cette sécurité est faite en Hard par un interrupteur à bascule sécurisé,( qui doit être soulever pour pouvoir commuter).
ça c'est au niveau de l'émetteur.
Moi je parle au niveau de l'engin: ne sachant toujours pas ce que c'est et où il va circuler.
 

dje8269

Senior Member
Android, et GSM.

S'il te plait ...
J'aimerais Georges, crois moi, je pense que cela m'aurais bien simplifier la vie . Mais ce n'est pas possible de l'envisagé notamment,t pour les zones blanches et/ ou perturbés !

Moi je parle au niveau de l'engin: ne sachant toujours pas ce que c'est
Un véhicule de reconnaissance et d'écoute . rien de critique .

Quelle est la portée minimale envisagée, avec donc un très bon niveau de fiabilité ?
Ca c'était ma question permanente , qui n'as pas réussie à trouvé une réponse précise, la seul à retenir "le plus possible" . La fiabilité n'est pas la top priorité, même si elle est haute et tout dépend de ce qu'on entend par fiabilité . effectivement je ne peux pas me permettre que le VHL pête un câble et fonce tête baissé jusqu'à qu'il n'ai plus batterie .

d'après mes résultats avec le prototype, et le matériel monté dessus, je me suis engagé sur une communication de 500 M en zone peu perturbé et encombré a minima. j'ai bien spécifié qu'en terme de transmission et d'autant plus vidéo , il n'y avait jamais de règle garantis a 100% , et que personne ne peut garantir un fonctionnement correct et sans faille.
La Cohabitation des deux systèmes radio , fut le plus dur a réalisé . et je ne suis pas au bout de mes peines ; avec le nouveau matériel reçu , encore plus puissants.
 

dje8269

Senior Member
Pour être honnête à la base je voulais le faire avec des PICS ; pourquoi ! , pour pouvoir effectué des échantillonnage et moyennage sur les valeurs reçues . Ce qui impliquait bien évidemment un gros débit d'informations ( 64 kbps aurait été génial) .impossible à faire avec un picaxe ;

Mais les délais se raccourcissant et la pression augmentant, j'avais aussi pensé passé par des arduino , mais pareil le temps d'apprendre le langage, je partait un peu a l'inconnu et je ne pouvais pas donné de date .
j'avais encore pensé a une autre solution , mais je n'ai pas trouvé de "parrain" pour me suivre dans ce projet fou . j'aurais aimé faire seulement la transmission avec des PIC et profité de leur rapidité d'exécution pour le codage Manchester pour ensuite traité l'info avec un picaxe dont je commence a connaitre quelques trucs . Mais je ne suis pas assez calés pour connaitre la compatibilité des deux, et le même le pic recevoir les données et les envoyés , même si une bibliothèque Manchester existe .

Alors TOUT en picaxe.
 

PieM

Senior Member
des échantillonnage et moyennage sur les valeurs reçues
ça sert à quoi ?
et un gros débit n'est pas compatible avec une grande portée.

Un véhicule de reconnaissance et d'écoute . rien de critique .
Faudra m'expliquer ce qui est critique au niveau temps de réponse, car ce n'est tout de même pas une maquette de jet à réaction !

Avant de décider qu'il faut deux 20X2 (!?) pour faire 3 opérations, il faudrait faire la liste des infos, des traitements associés, de leur criticité en terme de timing, et en déduire un schéma bloc, et enfin le matériel adapté.
Si c'est pour commencer par les circuits imprimés, ça risque d'être galère !
 

dje8269

Senior Member
ça sert à quoi ?
hummmm ..... tu sais bien ou je veux en venir . Mais bon si tu veux me faire dire une bêtise la voila :
le fait de faire un moyennage , avec un grand panel d'échantillon, me permettrais d'éviter les erreurs de com . Ou plutôt de les lisser ; je m'explique je prends 10 valeurs / 100;100;100;100;100;100;100;0;100;100 .
La voiture pourrait faire une pause ou un accoup ( marche arriére) ce qui se passe avec le proto de temps en temps . l'exemple n'est pas flagrant hein ....

avec un moyennage . avant d'envoyer ces 10 valeurs sur le moteur , j'en ferais la moyenne ce qui donnerai 900/10 = 90 . j'enverrais donc 90 au lieu de 100 certes, mais je n'enverrai pas de 0 en tout cas ; Voila a quoi j'avais pensé . ca doit etre idiot comme résonnement .

Faudra m'expliquer ce qui est critique au niveau temps de réponse
as tu déjà piloter un véhicule commandé par wifi disons ? un temps de latence de 500 ou 600 ms , c'est juste énorme et bizarre a conduire il fau anticiper en permanence . la différence entre 100ms et 1 ms se ressent très facilement quand on pilote sur un écran , un VHl qui se déplace pas comme un avion certes, mais a 40kmh tout de même .

le timing c'est pour la conduite de la voiture, et sa réactivité .
le timing des boutons , c'est pour laisser le temps aux servo de passer les vitesses et autres blocage différentiel . les autres TOR allument et éteignent des périphériques;

la différence avec le proto n'est pas énorme , Je souhaiterais juste mieux le concevoir
 

PieM

Senior Member
Un grand panel d'échantillon, avec une moyenne glissante, c'est l'inverse de ce que tu cherches; cela réduit la réactivité.

40 km/h, soit 11m/s pour ce type d'engin ? Tu vas organiser des courses ?
 

dje8269

Senior Member
Un grand panel d'échantillon, avec une moyenne glissante, c'est l'inverse de ce que tu cherches; cela réduit la réactivité.
Pas forcement un grand panel . une base de 10 me parait un bon début .

tu dis que ca réduit ma réactivité , mais a l'heure actuelle , je fais 20 mesure secondes ; 50ms ( 37ms pour le codage et 13ms pour le programme et les calculs) .

maintenant si avec un PIC je fais des envois tous les 3 ms ( 2ms pour le codage et 1ms pour le programme si la gestion se fait par un autre) . Même en faisant 10 relevés j'obtiendrais une MAJ toutes les 30ms au lieu des 50 actuelle et ce avec une moyenne glissante ;

je te vois venir : oui les chiffres sont des estimations, je n'ai pas d'ordre d'idée précise et encore moins de test a l'appui c'est juste des infos que j'ai pus glanner ; peut etre que je me mets le doigt dans l'œil , c'est le but de cette conversation . me mettre sur le bon chemin , mais peut être que j'y étais, peut être qu'on ne peut pas améliorer les choses .

PS : la discussion n'as plus lieu d'être vu que je n'aurais pas le temps de tout étudier et tester
 

BESQUEUT

Senior Member
le fait de faire un moyennage , avec un grand panel d'échantillon, me permettrais d'éviter les erreurs de com . Ou plutôt de les lisser ; je m'explique je prends 10 valeurs / 100;100;100;100;100;100;100;0;100;100 .
La voiture pourrait faire une pause ou un accoup ( marche arriére) ce qui se passe avec le proto de temps en temps . l'exemple n'est pas flagrant hein ....
avec un moyennage . avant d'envoyer ces 10 valeurs sur le moteur , j'en ferais la moyenne ce qui donnerai 900/10 = 90 . j'enverrais donc 90 au lieu de 100 certes, mais je n'enverrai pas de 0 en tout cas ; Voila a quoi j'avais pensé . ca doit etre idiot comme résonnement .
Ce raisonnement ne me plait pas :
- comme dit par PieM ça augmente considérablement le flux à transmettre et donc ça diminue la réactivité,
- ça ne garanti rien : si le bidule reçoit 10 fois une connerie, il va faire une connerie...

Ma propre expérience, utilisée par les pompiers pour transmettre par radio les ordres de mission, ce qui implique un niveau de fiabilité connu :
- chaque message, aussi court que possible pour limiter la bande passante contient un checksum,
- le récepteur élimine systématiquement les paquets dont le checksum est invalide,
- soit la donnée est émise en continu et les paquets manquants sont remplacés par le paquet suivant,
- soit les paquets sont émis plusieurs fois pour avoir une bonne chance qu'au moins un paquet soit reçu,
- dans le cas des pompiers, le récepteur envoie un accusé de réception (pas utile dans votre cas)
Tout ceci nécessitte finalement assez peu de puissance d'un coté comme de l'autre. Mais, à titre de précaution, mieux vaut prévoir d'utiliser les plus rapides, genre 28X2 à 64Mhz. Attention : tous les Picaxes retombent à une fréquence standard pour certaines opérations. Donc la vitesse ne fait pas tout. Et même un PIC32 ne fera rien pour améliorer la bande passante,
sauf si on donne la possibilité de reconstituer les paquets endommagés à partir du checksum, comme celà se fait sur les lecteurs de DVD. Là oui, la puissance améliore les choses.
A mon avis, dans votre cas, c'est l'optimisation du protocole qui permettra d'obtenir à la fois fiabilité, réactivité et portée.

Après, plus la chaîne de transmission (émetteur, antennes, récepteur,...) sera performante, meilleures seront bande passante et fiabilité, mais on atteint vite des limites en termes de coût, d'encombrement et de puissance consommée.

Pouvez-vous donner le nombre d'octets utiles à transmettre à chaque paquet ?
Je verrais bien une maquette chargée d'envoyer des paquets standards de plus en plus vite et un récepteur permettant de mesurer le taux d'erreur en fonction de l'éloignement. Seul ce type de mesure objective permet de savoir si telle ou telle optimisation est pertinente ou pas.
 
Last edited:

PieM

Senior Member
Si RFOUT et RFIN sont utilisés outre le codage Manchester, un CRC est effectué. Donc en principe la validité de la trame de 8 octets est assurée.

Je pense que cette recherche à tout prix de la vitesse est le problème lié à un cahier des charges qui me semble mal défini.
Pour moi, un appareil destiné à de l'observation et de la reconnaissance et de "l'écoute" qui ne va pas fonctionner à vue directe, qui se déplace à 10m/s est un danger publique !
Si les appareils commerciaux ont une portée limitée et une vitesse bien inférieure, ce n'est pas un hasard. C'est le résultat d'une recherche de fiabilité.
 

dje8269

Senior Member
Bonjour ,

Je crois que je me suis mal fait comprendre, comme souvent lol, c'est ca quand on est pas un spécialiste .

comme dit par PieM ça augmente considérablement le flux à transmettre et donc ça diminue la réactivité,
J'ai démontre en #16 que c'était pas exact .

Entre recevoir un ordre toutes 50ms et en recevoir tout les 30ms , la réactivité est meilleur à 30 ms . il est nullement 'augmenter le flux , mais la vitesse de traitement de l'encodage et donc de l'envoi , l'émetteur est prévu pour 64kbps tandis que l'émulateur NKM du picaxe permet 5kbps .

ça ne garanti rien : si le bidule reçoit 10 fois une connerie, il va faire une connerie...
Ben non justement le but de la moyenne permet d'éviter de recevoir 10 fois une connerie . il faut faire ca comparativement . les dix valeurs reçues seront plus rapides qu'une seul .
sans moyenne et a 50ms si une erreur est reçue elle durera 50ms .
avec moyenne et a 30 ms si une erreur est reçue elle sera minimiser car moyenner avec 9 autres bonnes . et ne durera que 30ms . on aura donc une valeur dégradé mais pas trop fausse et plus courte ;


L'augmentation de la vitesse ne changeras rien au nombre d'envoi par seconde car la commande RFout est fixé a 4Mhz. Ca n'auras pour but que d'améliorer le temps entre deux envois . j'ai déjà testé ca . et donc de réduire les 14ms de temps de calcul.Mais PieM m'as déconseillé de faire mouliner le picaxe a fond les gamelles et je l'ai donc bien sur ecouté

Pouvez-vous donner le nombre d'octets utiles à transmettre à chaque paquet ?
Je pense qu'il en faut 5 . 2 octets pour les TOR ( b0 et b1) . et trois pour les valeurs analogiques .

qui se déplace à 10m/s est un danger publique !
Je suis entièrement d'accord, amis je n'ai jamais dis qu'il roulerai a cette vitesse . Car tout simplement ca ne serait pas pilotable. Mais c'est la vitesse indiqué qu'il peut atteindre . il va de soi qu'il ne les atteindras jamais et j'y veillerais par soft !
 

BESQUEUT

Senior Member
les dix valeurs reçues seront plus rapides qu'une seul .
sans moyenne et a 50ms si une erreur est reçue elle durera 50ms .
avec moyenne et a 30 ms si une erreur est reçue elle sera minimiser car moyenner avec 9 autres bonnes . et ne durera que 30ms . on aura donc une valeur dégradé mais pas trop fausse et plus courte ;
Mais ça veut dire aussi que le bidule mettra dix fois plus de temps à réagir (dans le cas d'une moyenne flottante).
Par exemple, à partir d'une position "droit devant" l'ordre "à fond à droite"
va donner 1/10 à droite
puis 2/10 à droite
etc...
et "à fond à droite" au bout de dix commandes.
Question "réactivité" ça ne me semble pas optimal...
Je pense qu'il en faut 5 . 2 octets pour les TOR ( b0 et b1) . et trois pour les valeurs analogiques .
Pour transmettre 2 TOR, il faut 2 bits, pas 2 octets.
Quoi qu'il en soit, on peut utiliser une trame de 8 octets avec le checksum et même suffisement de redondance pour reconstituer la trame au cas où le checksum serait invalide. Pour moi, le "moyennage" est inutile et contre productif.
A valider par expérimentation comme indiqué ci-dessus, par un protocole rigoureux permettant de mesurer le taux d'erreur. Sur la base de 4 octets, un simple compteur permet de valider (ou d'invalider) les trames reçues.
Enuite, on écarte émetteur et récepteur progressivement pour savoir jusqu'à quelle distance la solution est validée.
 

dje8269

Senior Member
Mais ça veut dire aussi que le bidule mettra dix fois plus de temps à réagir (dans le cas d'une moyenne flottante).
Par exemple, à partir d'une position "droit devant" l'ordre "à fond à droite"
va donner 1/10 à droite
puis 2/10 à droite
etc...
et "à fond à droite" au bout de dix commandes.
Question "réactivité" ça ne me semble pas optimal...
Non non ,

toujours pas , je parle de cette moyenne flottante dans le cas d'utilisation de PIC pour faire le codage et non de picaxe . ce qui réduit énormément le temps entre deux envois ; C'est pourquoi j'avais signalé que cette discussion n'avait pas trop lieu d'être ( même si je trouve ca très intéressant) , car l'utilisation n'est plus envisageable pour des questions de délais .

avec un picaxe la voiture reçoit un ordre tout les 50ms ( 37 pour l'envoie et 13 pour les calculs avant de ré-envoyer etc .....
Avec un PIC j'estime a un ordre tout les 3ms . ( 2ms pour le codage 1 ms pour les calculs si ils se font sur un autre µC) . 3ms c'est très court me permettant de faire une moyenne sur 10 valeurs . Donc la voiture recevrais une valeur de moyenne flottante toutes les 30 ms contre 50 ms avec un picaxe ; la réactivité serait bien meilleure , et en plus lisserais d'éventuelle erreurs . c'était ca ma réflexion et mon idée .

Pour transmettre 2 TOR, il faut 2 bits, pas 2 octets.
Je n'ai pas écrit 2 TOR, j'ai bien écrit 2 octets pour les TOR ( il y as 9 TOR en tout, il me faut donc 2 octets )

Quoi qu'il en soit, on peut utiliser une trame de 8 octets avec le checksum et même suffisamment de redondance pour reconstituer la trame au cas où le checksum serait invalide. Pour moi, le "moyennage" est inutile et contre productif.
A valider par expérimentation comme indiqué ci-dessus, par un protocole rigoureux permettant de mesurer le taux d'erreur. Sur la base de 4 octets, un simple compteur permet de valider (ou d'invalider) les trames reçues.
Enuite, on écarte émetteur et récepteur progressivement pour savoir jusqu'à quelle distance la solution est validée.
La pour le coup c'est moi qui ne voit pas ou vous voulez en venir ?
 

PieM

Senior Member
Quoi qu'il en soit, on peut utiliser une trame de 8 octets avec le checksum et même suffisement de redondance pour reconstituer la trame au cas où le checksum serait invalide. Pour moi, le "moyennage" est inutile et contre productif.
A valider par expérimentation comme indiqué ci-dessus, par un protocole rigoureux permettant de mesurer le taux d'erreur. Sur la base de 4 octets, un simple compteur permet de valider (ou d'invalider) les trames reçues.
Enuite, on écarte émetteur et récepteur progressivement pour savoir jusqu'à quelle distance la solution est validée.
Je me répète, #18 , mais si comme je le pense les RFIN et RFOUT sont utilisés, le contrôle est effectué par le CRC implémenté dans l'instruction.
donc en principe taux d'erreur visible = 0

Par contre cela ne supprime pas les erreurs liées à la prise d'info, défectueuse ou parasitée.
 

dje8269

Senior Member
Je me répète, #18 , mais si comme je le pense les RFIN et RFOUT sont utilisés, le contrôle est effectué par le CRC implémenté dans l'instruction.
donc en principe taux d'erreur visible = 0
C'est exact !

Par contre cela ne supprime pas les erreurs liées à la prise d'info, défectueuse ou parasitée.
la moyenne glissante aurait pus faire le job !

Je ne vois pas trop de solution avec un picaxe .

Si vous voulez bien, on pourrait revenir vers l'architure qui nous intéresse !

Donc que pensez vous de dédié au 20x2 en mode esclave chargé de lire 3 valeurs analogiques et d'envoyer par un RFout 8 octets c'est tout :

1 octet pour 8 TOR (b0)
1 octet pour 1 TOR ou plus (b1)
1 octet pour ana1 (b3)
1 octet pour ana2 (b5)
1 octet pour ana3 (b7)

b0 et b1 seront modifiés par la liaison I2c

Un deuxième 20X2 en mode master :

Qui lira les valeurs analogiques de l'esclave , effectuera les calculs pour savoir le positionnement des joysticks .
Qui lira tout les TOR
Qui s'occuperas des temporisations sur certain TOR .
Qui gèrera l'affichage du module barregraphe ( lecture de la tension de la batterie)
Qui gèrera le buzzer.

En option gèrera un écran graphique 128x64 comme celui du compte à rebours)

Voila j'en ai certainement oublié . mais pour degrossir , voila ce a quoi j'aspire . voyez vous quelques choses qui cloche ?
 

PieM

Senior Member
Donc que pensez vous de dédié au 20x2 en mode esclave chargé de lire 3 valeurs analogiques et d'envoyer par un RFout 8 octets c'est tout :

1 octet pour 8 TOR (b0)
1 octet pour 1 TOR ou plus (b1)
1 octet pour ana1 (b3)
1 octet pour ana2 (b5)
1 octet pour ana3 (b7)

b0 et b1 seront modifiés par la liaison I2c

Un deuxième 20X2 en mode master :

Qui lira les valeurs analogiques de l'esclave , effectuera les calculs pour savoir le positionnement des joysticks .
Qui lira tout les TOR
Qui s'occuperas des temporisations sur certain TOR .
Qui gèrera l'affichage du module barregraphe ( lecture de la tension de la batterie)
Qui gèrera le buzzer.

En option gèrera un écran graphique 128x64 comme celui du compte à rebours)

Voila j'en ai certainement oublié . mais pour degrossir , voila ce a quoi j'aspire . voyez vous quelques choses qui cloche ?
Si tu mets un 20X2 en RFOUT, c'est qu'il ne doit faire que ça. Pourquoi lui faire lire l'analogique ? Donc son temps de cycle sera disons de l'ordre des 40ms.
En arrière plan il recoit les infos de l'autre. Mais si l'autre a un temps de cycle de 50 ms ça fiche tout en l'air.
Il faut donc que le second picaxe ait un temps extrêmement court aussi. Donc qu'il ait le minimum de chose à faire, et très rapidement. Donc fréquence d'horloge élevée contrairement à l'autre.
ça signifie que les données à transmettre doivent être des données brutes, les calculs se faisant à la réception en fonction de la criticité du timing.

Les tempo des TOR n'ont rien à faire à l'émission ! Tu parlais de temporiser le passage de vitesse, ça c'est un problème à traiter à l'arrivée! à la limite un truc un peu spécial à traiter va être confié à un picaxe particulier (j'exagère exprès). Tu lui dis de changer de vitesse et lui s'occupe de gérer la boite. C'est ainsi qu'on peut optimiser.

En outre, tu as choisi aussi un système d'afficheur comme de bargraph qui sont très lourd à gérer en temps. et eux ils n'ont pas besoin d'être rafraîchis toutes le 10 ms ! Fais y attention!
Donc en résumé, il a des chose à faire dans l'urgence et qui doivent être traitées indépendamment des autres bricoles d'affichage, de changement de vitesse ou de buzzer.
 

BESQUEUT

Senior Member
si comme je le pense les RFIN et RFOUT sont utilisés, le contrôle est effectué par le CRC implémenté dans l'instruction.
donc en principe taux d'erreur visible = 0.
Si 8 octets sont envoyés et 8 reçus, soit il faut inclure le checksum dans ces 8 octets, soit le protocole envoie au moins un octet en plus pour le CRC.
Je n'avais pas vérifié, mais effectivement le protocole du NKM2401 envoie un octet de plus pour le CRC, ce veut dire qu'il n'y a pas 8 mais 9 octets transmis à chaque paquet, ce qui prends un peu plus de temps...
Tant que je suis dans le datasheet, je constate que la transmission se fait à 2400 bauds, et qu'il faut prévoir du temps entre chaque trame :
time must be allowed for the completion of the transmission and
reception of the message before sending any more data. (typically 120mS )

Inutile donc d'envoyer plus de 8 trames par seconde avec ce protocole.

Le taux d'erreur doit être effectivement très faible (mais pas zéro, car un CRC ne garanti pas que les données soient exactes).

Par contre,on peut mesurer le nombre de trames perdues. En envoyant des nombres successifs, on peut facilement vérifier qu'il manque des trames. Rien ne sert d'envoyer 50 trames par seconde si le récepteur en éjecte une sur 2...

Vu la limitation à l'émission, il est peu probable que des trames manquent, ce qui explique l'excellente réputation des commandes RFIN/RFOUT.
Mais pour faire mieux que 8 trames par seconde, il faut utiliser autre chose...
 
Last edited:

PieM

Senior Member
ce veut dire qu'il n'y a pas 8 mais 9 octets transmis à chaque paquet,
Il y a même 11 octets car un octet de contrôle, un de syncro et un de CRC.

je constate que la transmission se fait à 2400 bauds, et qu'il faut prévoir du temps entre chaque trame :
time must be allowed for the completion of the transmission and
reception of the message before sending any more data. (typically 120mS )

Inutile donc d'envoyer plus de 8 trames par seconde avec ce protocole.
Les 120 ms sont pour le NKM2401 qui recoit ses infos via un serin à 2400 bauds. Ici c'est une implémentation dans le picaxe. Il n'y a pas cette contrainte de liaison.
 

dje8269

Senior Member
En tout cas je le repeterais jamais assez , mais merci a tous les deux de m'aiguiller.

alors je vais repondre dans l'ordre :

Si tu mets un 20X2 en RFOUT, c'est qu'il ne doit faire que ça. Pourquoi lui faire lire l'analogique ?
La toute première réponse qui me viens a l'esprit , c'est le hard . Comme sur le proto on as vu que ces entrées sont trés sensibles avec un emetteur a coté . pour bien les raccordés elle doivenet etre au plus pret avec un petit condo . ce qui en pratique me fait placer le connecteur juste a cote du µC et donc me bouche 3 ou 4 entrées .
Mais aussi question logiciel ; car on peut se permettre de loupé une infos TOR mais moins moteur ou direction . ce qui me fais peur pour tout vous dire c'est la conduite. Sur le proto c'est trés bien 50ms c'est une trés bonne réactivité ; surtout pour stopper le VHL .
Pour grandement simplifié le hard aussi, la broche Enable de l'emetteur devrait etre active pour ce µc

Dans ma tête le programme du 20X2 ressemblerais a ca .
Code:
 do
If bitx =1 then Enable ON
   else OFF
readadc C.x
readadc C.x
readadc C.x
Rfout X,  (b0,b1,b2,b3,b4,b5,b6,b7)
loop
Voila en gros ce a quoi j'avais pensé
Donc son temps de cycle sera disons de l'ordre des 40ms.
Oui dans ces eaux la !

En arrière plan il recoit les infos de l'autre. Mais si l'autre a un temps de cycle de 50 ms ça fiche tout en l'air.
Euh la quand même ....... 50ms ça en laisse du temps pour faire des choses sans une fréquence élevée . Vite fait, il y quelques calculs , quelques comparaisons une écriture dans le scratchpad et une lecture lecture des etats des broches , je pense etre vraiment loin des 50ms .
Et^soyons fou, disons que cela prends plus de 50ms, cben c'est pas grave de loupé un envoi car il n'y as rien de critique dans les TOR dumoins pas a 50ms pret , c'est l'avantage aussi d'avoir les lectures analogiques sur l'autre ; car elle peuvent etre critique !.

ça signifie que les données à transmettre doivent être des données brutes, les calculs se faisant à la réception en fonction de la criticité du timing.
Avant de s'avancer sur ce point, je pense que l'oscillo nous parleras plus . Mais oui les données seront brutes etant donné que ce sont des TOR c'est pas genant . on allume le phare IR ou on l'eteint par exemple . les seules données a traites seront les analogiques et oui comme sur le proto tu me l'avais deja conseillé , ca se feras a la reception .


Tu parlais de temporiser le passage de vitesse, ça c'est un problème à traiter à l'arrivée!
Oui et non . oui l'action se feras a l'arrivée , mais l'inibition des commandes doit se faire aussi a la télécommande , car je souhaite temporisé cette commande , genre un appui de 2 secondes lance le passage de vitesse ;

à la limite un truc un peu spécial à traiter va être confié à un picaxe particulier (j'exagère exprès). Tu lui dis de changer de vitesse et lui s'occupe de gérer la boite. C'est ainsi qu'on peut optimiser.
Oui je suis pas contre du tout, si multiplié les µC pour les dédiées a des fonctions précise c'est pas plus mal pour dépanner en plus ! Je trouve que c'est une bonne idée ! amis ca c'est quand on aborderas la partie recetpion !!!! il va falloir du lourd aussi ( 9 servo moteur a gérer pour vous donner une idée)

En outre, tu as choisi aussi un système d'afficheur comme de bargraph qui sont très lourd à gérer en temps. et eux ils n'ont pas besoin d'être rafraîchis toutes le 10 ms ! Fais y attention!
J'ai choisis le barregraphe pour l'estehtique et la place de la vitre s'y pretait parfaitement . mais merci de cette mise en garde , j'avoue ne pas avoir testé encore ce genre de module , ce seras de l'impro lol .

Donc en résumé, il a des chose à faire dans l'urgence et qui doivent être traitées indépendamment des autres bricoles d'affichage, de changement de vitesse ou de buzzer.
Ben les seules choses a faire dans l'urgence c'est le pilotage, donc les valeurs analogiques ; le reste ce sont les périphériques ne demandant pas d'urgence .

Le processus complet nécessite 128ms
??? alors la !!! mon oscillo etati tres clair la dessus 36ms la trame . et crois moi sur parole j'ai fais enormement de test .
Par contre, il faut mesurer le nombre de trames perdues. En envoyant des nombres successif, on peut facilement vérifier qu'il manque des trames. Rien ne sert d'envoyer 50 trames par seconde si le récepteur en éjecte une sur 2...
Pourquoi faire ? ; les commande Rfin/our sont bloquantes on ne peut pas mesurer le nombre de trames perdues .
 

BESQUEUT

Senior Member
??? alors la !!! mon oscillo etati tres clair la dessus 36ms la trame . et crois moi sur parole j'ai fais enormement de test .
Pourquoi faire ? ; les commande Rfin/our sont bloquantes on ne peut pas mesurer le nombre de trames perdues .
Le problème n'est pas de mesurer une trame, mais le délai entre deux trames correctement reçues...
D'après le datasheet, la trame fait 35ms, mais on ne doit pas envoyer une nouvelle trame tant que le signal "Busy" est activé, soit 120 ms

Vous pouvez bien sur tenter d'envoyer des données toutes les 36 ms, mais 3 trames sur 4 seront perdues...
Pour vous en convaincre, envoyez des nombres successifs avec un compteur word.
A l'arrivée, vous vérifiez que vous recevez bien 1234,1235,1236,1237, etc...

Si vous recevez 1234,1237,... ben vous avez perdu 2 trames...

Vous pouvez dire que ce n'est pas grave de perdre des trames, vu qu'il y a en d'autre... sauf que
- si vous perdez 3 trames sur 4, la réactivité est 4 fois moins bonne que ce que vous espérez,
- si les commandes TOR ne sont émises que de temps en temps, elles sont perdues,
- si vous pilotez en donnant un coup brusque, cet ordre risque d'être perdu.
 
Last edited:

dje8269

Senior Member
D'après le datasheet, la trame fait 35ms, mais on ne doit pas envoyer une nouvelle trame tant que le signal "Busy" est activé, soit 120 ms
Quels DS regardez vous ?

Vous pouvez bien sur tenter d'envoyer des données toutes les 36 ms, mais 3 trames sur 4 seront perdues...
Je vous assure que j'envoie une trame toutes les 50 ms , et que je la recois toutes les 50ms . grace au hi2cflag .
J'ai passé un moment la dessus .
en gros le programme de réception et de traitement de l'info est plus rapide que les 37 ms d'un envoi ; c'est donc lui qui attend en permanence de recevoir quelques choses pour ce déclencher. et d'apres mes tests , lui se lance toutes les 50 ms , il n'y as donc quasiment aucun raté.

Voici le lien ou commence les mesures si ca vous interresse .

lien des test a l'oscillo

Vous pouvez dire que ce n'est pas grave de perdre des trames
Non non c'est grave de perdre des trames . au debut j'en perdais beaucoup ! mais ce probléme la a été réglé ; la je peux pas vous expliquer tout les test et le soft . mais disons que j'ai trés peu de loupé . de temps en temps une trame mais plus de temps a partir mais rien de bien méchant . comme la commande est bloquante ca ne saute pas une info, soit ca la retarde, soit elle est fausse
 

PieM

Senior Member
Quels DS regardez vous ?
Ben celui du NKM2401 !. mais on est pas du tout dans cette config puique là c'est le même µC qui assure tout. Donc il n'y a pas le même timing, hormis celui de la trame finale pour des raisons de compatibilité.
 

BESQUEUT

Senior Member
Quels DS regardez vous ?


Je vous assure que j'envoie une trame toutes les 50 ms , et que je la recois toutes les 50ms . grace au hi2cflag .
J'ai passé un moment la dessus .
en gros le programme de réception et de traitement de l'info est plus rapide que les 37 ms d'un envoi ; c'est donc lui qui attend en permanence de recevoir quelques choses pour ce déclencher. et d'apres mes tests , lui se lance toutes les 50 ms , il n'y as donc quasiment aucun raté.

Voici le lien ou commence les mesures si ca vous interresse .

lien des test a l'oscillo


Non non c'est grave de perdre des trames . au debut j'en perdais beaucoup ! mais ce probléme la a été réglé ; la je peux pas vous expliquer tout les test et le soft . mais disons que j'ai trés peu de loupé . de temps en temps une trame mais plus de temps a partir mais rien de bien méchant . comme la commande est bloquante ca ne saute pas une info, soit ca la retarde, soit elle est fausse
Lien vers le datasheet du nkm2401.pdf
Bien sur, le PICAXE peut faire mieux, mais il doit rester compatible.
Admettons qu'on ait un paquet toutes les 50 ms. Si ça vous convient , il n'y a pas à chercher mieux.
Par contre, je ne comprends pas pourquoi vous vous inquiétez de commandes invalides #14 et la toute dernière affirmation de ce post ?
Qu'entendez-vous par "soit elle est fausse" ?

Le fait que la commande soit bloquante ne garanti pas qu'aucune trame ne soit perdue. Si une trame est altérée, elle est ignorée et c'est la suivante qui est reçue. Comme vous ne numérotez pas les trames, vous avez l'impression que la trame a mis plus de temps à être émise. Mais c'est plus probablement une trame perdue.

Par contre, si vous êtes certain d'émettre une trame toutes les 50ms, et que vous recevez également un paquet toutes les 50ms, il ne peut effectivement pas y avoir de trames perdues.

(à ce sujet, puisqu'il reste 2 octets inutilisés, vous pourriez numéroter vos trames, et donc avoir un indicateur de trames perdues...)

Pour le choix du ou des picaxes à utiliser à l'émission et à la réception, tenez compte de l'Appendix 4 - Possible Conflicting Commands.
En particulier, le RFout devrait être perturbé par I2C background receive...
Mieux vaudrait lire 9 broches du Picaxe juste avant de faire le RFOUT.
De même à la réception, les commandes "Background I2C slave mode" et "servo" sont incompatibles...
Ca peut expliquer les "commandes fausses" que vous évoquez... et que vous attribuez à un problème de transmission.
Je pense que ce serait plus fiable d'utiliser un seul Picaxe.


Vous devez absolument concevoir en même temps le récepteur et l'émetteur. Une modification d'un coté peut chambouler complètement l'architecture de l'autre coté.

Attention aussi au fait que les commandes RFIN et RFOUT font retomber le Picaxe à 4Mhz.

Si on fait le bilan, on s'aperçit que la seule justification de cette usine à gaz est de permettre un pré-traitement pour les 9 TOR, lesquels ne nécessitent pas une réctivité très importante. Par contre les 3 servos nécessitent réactivité et fiabilité.

Dans ces conditions, pourquoi ne pas utiliser des ensembles E/R classiques, éprouvés, fiables, réactifs... ?
Quitte à utiliser un Picaxe pour faire un pré-traitement sur les TOR.
Il y a des options jusqu'à 30 km systeme-long-range-dragonlink-2-
 
Last edited:

dje8269

Senior Member
Qu'entendez-vous par "soit elle est fausse" ?
Chaud à expliquer . En fait je n'ai pas testé si c'est la commande envoyé, reçues , ou interprétée qui est fausse . Mais les tests en condition réel parle d'eux même . La voiture(on parle du proto la) alors que j'avance en permanence de temps en temps donne un coup d'arret . il y as deux cas possible je pense qui explique ce phénomène .
La transmission est perdue est la voiture active son protocole d'arrêt .(le plus probable)
ou la commande interprété ou recue ou envoyée est une marche arrière ( un point mort ne ferais pas un acoup aussi fort la voiture serait en roue libre)

ce problème n'est pas récurent voir rare, mais il existe . je pourrais tout simplement essayé en désactivant le protocole de perte de liaison . a faire !
Le fait d'avoir un emetteur de 450mW en emission radio et un emetteur vidéo de 1w coté voiture ne facilite pas la détection d'où provient l'erreur

Le fait que la commande soit bloquante ne garanti pas qu'aucune trame ne soit perdue.
Du point de vue de l'émetteur, si . il n'y auras rien d'envoyer tant que la trame ne sera pas complète , donc rien de perdu, mais retardé ; qui peut s'aparenter a un perdu si le retard fais plus de 50ms . je vous l'accorde

Si une trame est altérée, elle est ignorée et c'est la suivante qui est reçue
Non , si une trame est alteré, mais existante , elle est interprétée comme-t-elle ,avec son erreur . jusqu'à que la suivant corrige l'erreur ( d'où la moyenne glissante pour limiter cette erreur)
 

BESQUEUT

Senior Member
Chaud à expliquer . En fait je n'ai pas testé si c'est la commande envoyé, reçues , ou interprétée qui est fausse . Mais les tests en condition réel parle d'eux même . La voiture(on parle du proto la) alors que j'avance en permanence de temps en temps donne un coup d'arret . il y as deux cas possible je pense qui explique ce phénomène .
La transmission est perdue est la voiture active son protocole d'arrêt .(le plus probable)
ou la commande interprété ou recue ou envoyée est une marche arrière ( un point mort ne ferais pas un acoup aussi fort la voiture serait en roue libre)
Avec RFIN/RFOUT, il est impossible qu'une commande soit altérée lors de la transmission. Je ne vois pas non plus comment expliquer l'émission d'une commande de marche arrière...
A ma connaissance, votre protocole failsafe n'inclu pas une marche-arrière.
Par contre, la notice dit clairement que le bakground I2C receive et la commande servo sont incompatibles...
ce problème n'est pas récurent voir rare, mais il existe . je pourrais tout simplement essayé en désactivant le protocole de perte de liaison . a faire !
Le fait d'avoir un emetteur de 450mW en emission radio et un emetteur vidéo de 1w coté voiture ne facilite pas la détection d'où provient l'erreur
Si vous suspectez une altération des paquets malgrès le CRC, utilisez un des octets disponibles pour faire un checksum interne. Mais je n'y crois guère.
Si vous suspectez une perte de trame, utilisez un ou deux octets pour numéroter les trames.
Mais si c'est la commande servo qui est perturbée par le background I2C receive... je ne vois pas d'autre moyen que de changer d'architecture...
Du point de vue de l'émetteur, si . il n'y auras rien d'envoyer tant que la trame ne sera pas complète , donc rien de perdu, mais retardé ; qui peut s'aparenter a un perdu si le retard fais plus de 50ms . je vous l'accorde
Si je comprends bien, vous n'êtes pas certain que l'émission se fasse toutes les 50 ms ?
Facile à vérifier à l'oscillo.
Si ce n'est pas le cas, il n'est pas possible à la réception de savoir si la trame n'a pas été émise ou si elle a été perdue, sauf si les trames sont numérotées...
Non , si une trame est alteré, mais existante , elle est interprétée comme-t-elle ,avec son erreur . jusqu'à que la suivant corrige l'erreur ( d'où la moyenne glissante pour limiter cette erreur)
Ce n'est pas ce que j'ai compris :
The CRC is calculated on the received data and if correct the ‘Data Ready Output’ line is set low.
On peut supposer que le Picaxe fait de même et ne monte le flag que si le CRC est correct.
Si le Picaxe n'utilise pas le CRC :
- il ne serait pas compatible avec le NKM2401 ce qui serait plus qu'étonnant,
- il faudrait utiliser un checksum interne au paquet.

Il est bien plus probable que de temps en temps une trame soit altérée, le CRC pas bon et la trame rejetée. Mais vous ne le saurez que si vous numérotez vos trames...
 
Last edited:

dje8269

Senior Member
Par contre, la notice dit clairement que le bakground I2C receive et la commande servo sont incompatibles...
Le picaxe de réception est dédié a la réception , il ne fait que recevoir et écrire dans le scratchpad d'un 28X2 qui lui utilise la commande servo . pas de soucis de compatibilité


Avec RFIN/RFOUT, il est impossible qu'une commande soit altérée lors de la transmission.
Si tel est le cas , c'est donc que le problème ce trouve en amont ou en aval . donc avant l'émission ou après la réception , ou a l'interprétation ce qui reviens a après la réception .
Il se peu que se soit aussi une perte de com . qui sera vite "testable" en enlevant ce protocole . mais le protocole passe par une phase de freinage , que je ne crois pas avoir vu . enfin je peux pas l'affirmer à 100% .

Si vous suspectez une altération des paquets malgrès le CRC
l'altération a lieu avant ou après .
 

BESQUEUT

Senior Member
Le picaxe de réception est dédié a la réception , il ne fait que recevoir et écrire dans le scratchpad d'un 28X2 qui lui utilise la commande servo . pas de soucis de compatibilité
Et il fait comment le 28 X2 pour recevoir les commandes I2C dans son scratchpad ?
Ca serait-y pas via un I2C background receive ?
Sur tous les forums Picaxe, dès qu'on évoque un problème de transmission, on trouve quelqu'un qui dit "il suffit de dédier un Picaxe à la réception"
Ben voyons !
Et comment on communique avec ce Picaxe soit disant "dédié" à la réception, sinon en ajoutant de nouveaux problèmes de transmission ?
Si tel est le cas , c'est donc que le problème ce trouve en amont ou en aval . donc avant l'émission ou après la réception , ou a l'interprétation ce qui reviens a après la réception .
Il se peu que se soit aussi une perte de com . qui sera vite "testable" en enlevant ce protocole . mais le protocole passe par une phase de freinage , que je ne crois pas avoir vu . enfin je peux pas l'affirmer à 100% .
l'altération a lieu avant ou après .
A mon avis, le protocole "FailSafe" n'est pas en cause.
Comme indiqué en #1, vous souhaitez améliorer votre conception.
Vous devez disposer de certitudes et non d'impressions non confirmées.
Le protocole RFIN/RFOUT me semble bien blindé, PieM en est convaincu et c'est le sentiment général.
Par contre les différentes bidouilles de communications entre Picaxes me semblent un peu fumeuses, surtout quand elle utilisent des commandes réputées incompatibles suivant la notice.
Peut-être que ça marche quand même par miracle.
Mais dans ce cas, il faut faire un test rigoureux.

Lorsque le 28X2 est occupé à émettre une commande servo, il passe son temps à configurer de beaux signaux rectangulaires sur la base d'un timing précis.
Tout d'un coup, il reçoit une commande I2C. Sa temporisation est perturbée et au moins un signal rectangulaire est fantaisiste. D'où le coup de servo ou la marche arrière...
C'est encore pire si le 28X2 n'est pas à 4Mhz. La reception I2C le fait retomber à 4Mhz et en même temps il fait n'importe quoi sur le servo...
 
Last edited:

dje8269

Senior Member
Et il fait comment le 28 X2 pour recevoir les commandes I2C dans son scratchpad ?
Ca serait-y pas via un I2C background receive ?
Hummmmm..... la vous mettez le doigt sur quelque chose d'intéressant ! mais je ne suis pas assez calés pour tout comprendre .

Vous devez disposer de certitudes et non d'impressions non confirmées.
100% d'accord , mais malheureusement je doute que l'on peut être toujours a 100% de certitude avec des transmissions radio . J'en ai fais le frais plusieurs fois lors du montage de ce proto . Une liaison a radio a un coté hasardeux et sporadique.

Lorsque le 28X2 est occupé à émettre une commande servo, il passe son temps à configurer de beaux signaux rectangulaires sur la base d'un timing précis.
Je risque de dire des âneries , car je suis a des années lumière de vos expériences; mais la commande se fait en tache de fond et dispose de son propre timing non ? timer 1 et 2 je crois d ememoire
Tout d'un coup, il reçoit une commande I2C. Sa temporisation est perturbée et au moins un signal rectangulaire est fantaisiste. D'où le coup de servo ou la marche arrière...
c'est possible , auriez-vous un test de derrière les fagots a effectuer par validez votre théorie ?

Sur tous les forums Picaxe, dès qu'on évoque un problème de transmission, on trouve quelqu'un qui dit "il suffit de dédier un Picaxe à la réception"
Dans mon cas ; la solution du picaxe dédié à la base , était fait pour détecter une perte communication et non réglé quelque problème de transmission .
 

BESQUEUT

Senior Member
Hummmmm..... la vous mettez le doigt sur quelque chose d'intéressant ! mais je ne suis pas assez calés pour tout comprendre .
Ben... quand vous utilisez ce flag dans votre programme, c'est bien parce qu'il signale que des données ont été reçues en tâche de fond sur I2C ?
100% d'accord , mais malheureusement je doute que l'on peut être toujours a 100% de certitude avec des transmissions radio . J'en ai fais le frais plusieurs fois lors du montage de ce proto . Une liaison a radio a un coté hasardeux et sporadique.
Ca n'empêche pas de savoir que X% des trames sont reçues sans altération (et donc que 100-X % sont perdues...)
Mais dans votre cas, j'ai l'impression (donc je ne sais pas...) que la transmission est moins en cause que ce qui se passe en aval...
la commande se fait en tache de fond et dispose de son propre timing non ? timer 1 et 2 je crois d ememoire
c'est possible , auriez-vous un test de derrière les fagots a effectuer par validez votre théorie ?
On pourrait programmer un Picaxe pour qu'il envoie des tas de trames identiques via I2C vers le 28X2, tant qu'on appuie sur un poussoir.
Normalement, après le premier appui, les 3 servos doivent rester fixe à la position indiquée.
Par appui successifs sur le poussoir on sollicite son background receive sans que ça change rien coté servo.
Si un des servos bouge, il y a un blème.


Dans mon cas ; la solution du picaxe dédié à la base , était fait pour détecter une perte communication et non réglé quelque problème de transmission .
ah ? Une perte de communication, ça n'est pas un problème de transmission ?
 

BESQUEUT

Senior Member
Hummmmm..... la vous mettez le doigt sur quelque chose d'intéressant ! mais je ne suis pas assez calés pour tout comprendre .
Ben... quand vous utilisez ce flag dans votre programme, c'est bien parce qu'il signale que des données ont été reçues en tâche de fond sur I2C ?
100% d'accord , mais malheureusement je doute que l'on peut être toujours a 100% de certitude avec des transmissions radio . J'en ai fais le frais plusieurs fois lors du montage de ce proto . Une liaison a radio a un coté hasardeux et sporadique.
Ca n'empêche pas de savoir que X% des trames sont reçues sans altération (et donc que 100-X % sont perdues...)
Mais dans votre cas, j'ai l'impression (donc je ne sais pas...) que la transmission est moins en cause que ce qui se passe en aval...
la commande se fait en tache de fond et dispose de son propre timing non ? timer 1 et 2 je crois d ememoire
c'est possible , auriez-vous un test de derrière les fagots a effectuer par validez votre théorie ?
On pourrait programmer un Picaxe pour qu'il envoie des tas de trames identiques via I2C vers le 28X2, tant qu'on appuie sur un poussoir.
Normalement, après le premier appui, les 3 servos doivent rester fixes à la position indiquée.
Par appui successifs sur le poussoir on sollicite son background receive sans que ça change rien coté servo.
Si un des servos bouge, il y a un blème.
Si rien ne bouge même en appuyant longtemps j'e m'inquiète à tord sur cet aspect.
Mais dans ce cas, il faudra expliquer pourquoi des ordres incohérents sont transmis aux servos :
- à l'émission (bizarre ?)
- à la transmission RF (peu probable vu le protocole utilisé)
- entre le premier et le second Picaxe ?
- lors de la génération du signal PWM pour le servo ?
Dans mon cas ; la solution du picaxe dédié à la base , était fait pour détecter une perte communication et non réglé quelque problème de transmission .
ah ? Une perte de communication, ça n'est pas un problème de transmission ?
 
Last edited:

dje8269

Senior Member
Ben... quand vous utilisez ce flag dans votre programme, c'est bien parce qu'il signale que des données ont été reçues en tâche de fond sur I2C ?
En fait je l'utilise en inverse . lol .

Il faut imaginer en fait les fait suivants; malheureusement je crois que ca fait capoter votre réflexion .

le programme attend que le hi2cflag passe à 1 , donc on as recu des données .
on réarme la flag
On met à jour les données avec celles reçues ( moteur direction etc.....) .
Puis on re-attend de recevoir des données et donc que le passe hi2cflag revienne à 1. pour remettre a jour etc etc etc .

Pendant que le programme attend que le flag passe à 1 en fait il n'attend pas vraiment, mais il compte . s'il atteint une certaine valeur , cela signifie que cela fait longtemps qu'il n'a rien recu, trop longtemps , donc perte de com, donc safesail.

Ce qui veut dire , qu'il n'y as pas de commande servo pendant la réception de l'i2c . Le programme ca beaucoup plus vite que les 50ms de réception d'un flag . j'ai plus le chiffre en tête , mais je crois que c'est de l'ordre d'une petite dizaine de ms tout au plus.
Mon programme passe beaucoup plus de temps à attendre les données qu'a les mettre a jour ! .
 

BESQUEUT

Senior Member
En fait je l'utilise en inverse . lol .

Il faut imaginer en fait les fait suivants; malheureusement je crois que ca fait capoter votre réflexion .

le programme attend que le hi2cflag passe à 1 , donc on as recu des données .
on réarme la flag
On met à jour les données avec celles reçues ( moteur direction etc.....) .
Puis on re-attend de recevoir des données et donc que le passe hi2cflag revienne à 1. pour remettre a jour etc etc etc .

Pendant que le programme attend que le flag passe à 1 en fait il n'attend pas vraiment, mais il compte . s'il atteint une certaine valeur , cela signifie que cela fait longtemps qu'il n'a rien recu, trop longtemps , donc perte de com, donc safesail.

Ce qui veut dire , qu'il n'y as pas de commande servo pendant la réception de l'i2c . Le programme ca beaucoup plus vite que les 50ms de réception d'un flag . j'ai plus le chiffre en tête , mais je crois que c'est de l'ordre d'une petite dizaine de ms tout au plus.
Mon programme passe beaucoup plus de temps à attendre les données qu'a les mettre a jour ! .
Servo command is different to most other BASIC commands in that the pulsing mode continues until another servo, high or low command is executed.
En gros, une fois que vous avez lancé la commande servo, Le PIC fait ça tout le temps...
Mais comme on n'a pas le code exécuté, on ne peut effectivement que suputer les problèmes éventuels. Peut-être qu'il n'y en a pas. Mais dans ce cas, pourquoi la notice indique que ces commandes sont incompatibles ?
Vous pouvez vérifier à l'oscillo que les servos recoivent des impulsions en permanence... et donc y compris au moment où vous écrivez sur l'I2C.
Croyez bien que je ne cherche pas à démontrer que ça ne peut pas marcher. Je cherche juste ce qui peut expliquer les dysfonctionnements que vous constatez. Si on n'est pas certains de la cause d'un problème, la correction relève de la boule de crystal...
Petite précision concernant votre fail-safe :
Si la tempo a été dépassée et que la procédure fail-safe est engagée, et pile à ce moment une commande valide arrive :
- vous ignorez cette commande et stoppez le véhicule avant d'accepter de nouvelles commandes ?
- ou bien vous exécutez la commande reçue (alors que le freinage ou l'arrêt est en cours) ?

Vous n'avez pas argumenté par rapport à ma question à la fin du #31 ; êtes-vous certain de l'avantage des E/R envisagés par rapport à une radio-commande de modélisme standard ? La portée indiquée est une donnée maximale, de même que la bande passante. Qu'en est-il en situation réelle au sol avec obstacles ?
 
Last edited:
Top