Projet Véhicule RC

#81
Le fonctionnel c'est d'assurer le bon fonctionnement du véhicule dans toutes les conditions.
Dans le cadre de l'analyse de projet, on distingue le "fonctionnel" du "technique".
Le fonctionnel est ce que voit l'utilisateur, et donc le technique ce qu'il ne voit pas.
Je suis d'accord, ces termes sont spécifiques à ce contexte et j'aurais du le préciser.
Quand on fait une analyse fonctionnelle, on ne prends en compte que ce que doit faire ou ressentir l'utilisateur.
Il peut exister des tas de solutions techniques pour un même fonctionnel. En règle générale, on détermine d'abord le fonctionnel, puis on cherche la meilleure solution technique en terme de coût, fiabilité, délai de livraison, performances,...

Quant à la bonne gestion de la batterie je ne vois pas ce qu'il y a de contradictoire avec le fait de détecter la chute de tension.
Si on attends que la tension chute franchement, c'est déjà trop tard.
Mais un peu avant, c'est très difficile justement à cause de la consommation qui fait varier la tension dans de larges proportions. Il faudrait attendre une bonne heure à l'arrêt avant de pouvoir mesurer la capacité restante. Par contre la mesure de tension au repos peut être utilisée pour mesurer la charge à la mise sous tension et pour ré-étalonner la capacité restante en fin de mission.
Une puce dédiée est ici http://datasheets.maximintegrated.com/en/ds/MAX17043-MAX17044.pdf et ce n'est pas une simple mesure de courant!
Cette puce est très spécifique et ne mesure effectivement pas le courant.
Mais celle-ci (5721) le fait.
C'est juste pour illustrer que le calcul de capacité restante par la consommation est très classique.
Le besoin fonctionnel est d'avoir une jauge car si l'opérateur reçoit une alarme uniquement à mi-capacité, c'est peut-être trop tard ou trop tôt.
 
Last edited:

dje8269

Senior Member
#82
Oulalalalala ..... je dois forcement trancher ?? la confrontation d'idée est bien la en tout cas , et fais avancé le schimblic , obligeant chacun a réfléchir et avancé ces arguments . Moi au milieu j'ai l'impression de compter les points . lol.

@ Piem ; peut tu me donner les inconvénients de ta facon de voir ?

@ Besqueut : pouvez vous me donner les inconvenients de votre système ?

L'auto critique et l'auto analyse sont parfois de bonnes choses .

Pour ma part , dommage que vous ne soyez pas d'accord, ca m'aurait arranger! j'avoue être plus a l'aise sur la méthode de la batterie propo + électronique .
Mon premier argument sera que j'ai l'habitude de travailler comme ça ; bon je vous l'accorde peut être une mauvaise habitude .( mon proto est fait comme ca).
Mon deuxième serait de dire qu'a part l'émetteur vidéo et la camera , il est possible que d'autre capteur se greffe dessus, c'est d'ailleurs le principe en quelques sorte (périphérique inconnu) .
Je ne suis nul mais un relais de 30A doit être plutôt conséquent non ? niveau place c'est pas la panacée . sans parlé des pistes du typon .
L'argument de BESQUEUT tient la route, ce n'est par ce qu'on a passé un accu, que le deuxième pourra suffire pour revenir . pour moultes raisons. Il est indéniable que l'humain doit avoir un esprit de jugeote sur cette gestion .

Inconvenients :
gaspillage , obligé de rentrer même si une des deux batteries est encore pleine .
deux gestions et deux surveillances a effectuées et deux infos a envoyer par Voie radio , plus deux infos a affichées
Vu la difficulté a connaitre l'autonomie restante, ce sera une approximation .

peut etre qu'un protocole peut etre envisager en cas de faible batterie ( niveau moteur ou emetteur vidéo si c'est possible)

Le besoin fonctionnel est d'avoir une jauge car si l'opérateur reçoit une alarme uniquement à mi-capacité, c'est peut-être trop tard ou trop tôt.
Oui , car il faut que l'utilisateur sache ce qu'il entreprendre ou non , avec ou sans risque . il doit avoir ne estimation permanente ; de ce qu'il a gaspillé en terme d'energie
 
#83
@ Besqueut : pouvez vous me donner les inconvenientes de votre systeme ?
Quasi obligation de dédier un processeur à cette supervision. En général, il est attaché au pack de batterie ce qui permet de changer de pack sans perdre l'étalonnage.
Ça permet éventuellement aussi de faire une mesure de tension au repos (la consommation de cette supervision étant considérée comme négligeable).
Sur les batteries d'ordinateurs portables, il gère aussi une petite échelle de LEDs.
Soit on trouve un module qui fait ça, soit il faut écrire le programme ad-hoc.
peut etre qu'un protocole peut etre envisager en cas de faible batterie
Au niveau fonctionnel, on peut envisager un acquit de l'opérateur par exemple à mi-jauge.
Ca peut être un appui sur l'écran tactile, ou un poussoir dédié.
En cas de non acquittement, alarme sonore,...
Si c'est vraiment important on peut avoir plusieurs niveaux d'alarme de plus en plus critique, mais ce besoin ne me semble pas avoir été décrit.
Comme je ne préconise qu'une seule batterie, il n'y a qu'une seule jauge.
L'opérateur peut passer une heure à observer ce qui l'entoure sans déplacer l'engin.
Ou bien rouler à fond les bananes en permanence.
La seule chose importante, comme vous le faite avec votre automobile ou votre téléphone portable c'est de jeter un œil à la jauge de temps en temps.
 
Last edited:

dje8269

Senior Member
#84
Comme je ne préconise qu'une seule batterie, il n'y a qu'une seule jauge.
??? rahh zut .. j'avais pas compris ca ! . je pensais que vous parliez d'une seule batterie pour une seule fonction ; tandis que PieM voyait une seule batterie , pour toutes les fonctions .

DOnc résultat des courses , tout les deux , vous voyez qu'une seule batterie sur l'engin gérant toute l'énergie a elle seule ; Quand je dis une seule je veux dire par la que PieM en utilise deux mais deux fois plus petite en capacité .
La on Vous utiliserez une 10000mah , Piem en utiliseras deux de 5000mAh , mais dans les deux cas , la batterie gere tout .
sauf que vous BESQUEUT , vosu avertissez quand on est a la moitié , et que PieM bascule de batterie .
 

dje8269

Senior Member
#85
H-S sur l'energie : au fil de mes recherches je suis tombé la dessus ? mon anglais n'etant pas terrible , j'a ides doutes , mais ne serait-il pas possible de remplacer les moteurs par ceux ci , avec encodeur en plus ?

https://www.pololu.com/product/1575

et pourquoi changer la reduction pour aller un peu plus vite, quitte a perdre un peu de couple
 
Last edited:

PieM

Senior Member
#86
Besqueut said:
Si on attends que la tension chute franchement, c'est déjà trop tard.
votre document:
"Il est recommandé partout de ne pas utiliser plus de 80% de la capacité de la batterie, ce qui correspond à peu de chose près au début de la chute finale de tension"

Besqueut said:
Cette puce est très spécifique et ne mesure effectivement pas le courant.
Mais celle-ci (5721) le fait.
sauf qu'elle n'intègre pas l’algorithme de calcul ModelGauge nécessaire!
Quand on fait une analyse fonctionnelle, on ne prends en compte que ce que doit faire ou ressentir l'utilisateur.
Par exemple bronzer en sirotant un pastis, dans le cas d'un robot tondeuse de gazon. ..

Merci, mais j'ai dirigé un bureau d'études techniques machines spéciales pendant de nombreuses années.bon maintenant je sature ...
 
Last edited:

dje8269

Senior Member
#87
:( zen :confused: j'ai besoin de vous.

On dirait deux mâles à comparer leur tailles de ..... .
Confrontez vos idées , sans porté de jugement sur l'autre, ça évitera les Piques (Pic jeu de mot ) en permanence
 

dje8269

Senior Member
#88
Bonjour,

Que pensez vous de l'idée de changer deux moteurs , par les moteurs avec encodeurs ? Ce serais bien ça , pour connaître la vitesse et pour le backup?
Je pense en mettre un de chaque côté
 

dje8269

Senior Member
#89
Je me sens bien seul d'un coup.
J'ai commencé à faire un petit croquis pour l'architecture des différents modules. Je vous montrerais un fois plus propre et les types de connections finalisées .
 

dje8269

Senior Member
#90
Bonsoir à tous,

Je suis sur que certains avait cru que javais abandonné !!! hein .... !!!

Après pas mal de taf , j'ai finis par réussir à faire mon organigramme; Alors je reviens vous enquiquiner , surtout que ça à l'air plutôt calme en ce moment .

Il s'agit d'un premier jet . j'aimerais avoir vos remarques et suggestions. Dans cette période estivale, j'ai dus faire des choix , et lancé une commande . j'ai donc pour le moment seulement commandé le châssis, deux moteurs avec encodeurs intégrés , les capteurs gyro , 3 platines d'alimentations de 5A comme préconisé par PieM et une platine d'alimentation de 25A en secours et pour tester. Si ca ne va pas je pourrais toujours acheter autres choses.

J'aurais donc de quoi commencé une petite base de quelques choses, pour faire des tests. Mais ne mettons pas las charrue avant les bœufs, étant donné que le plan d'attaque du projet n'est pas encore au point .

J'ai mis un µC a chaque fois , bien sur c'st une image, je suppose qu'il en faudra bien plus !

Sans titre1.png

Sans titre2.png

Bonne soirée
 
#91
j'aimerais avoir vos remarques et suggestions.
Non conforme à mes différentes remarques, par exemple #77 et voir aussi #34.
C'est quoi la différence entre "Num", "ADC" et "Analog" ?
Il n'y a pas 3 sorties PWM pour les moteurs, mais seulement 2 : droite et gauche.
Par contre, pour la nacelle, c'est 2 servos et non un PWM.
Le module de mesure de courant s'intercale dans la ligne d'alim. J'ai préconisé un µcontrôleur dédié par batterie.
Capteur de courant sur la télécommande ?
Sécurité basse tension ?
Est il plus pratique d'utiliser un menu sur l’écran plutôt que des interrupteurs
Le menu est évidement moins pratique, sauf s'il y a tellement d'interrupteurs qu'on ne sait plus lequel manœuvrer...
Donc : interrupteurs, poussoirs, molettes et potentiomètres pour les actions les plus courantes,
Menus pour les paramètres et fonctions peu fréquentes.
Comment navigue-t-on dans les menus ?
- poussoirs ?
- molette(s) ?
- mini-joystick ?
- écran tactile ?

Pour les liens série (I2C, RS232, SPI,...) il faut pour chaque lien :
- le sens ou bidirectionnel,
- le débit effectif attendu,
- la fréquence des échanges,
- le niveau de fiabilité attendu.
Pour le transceiver, il y a probablement plusieurs flux mixés : décrire chaque flux.

Je vois 3 niveaux de fiabilité :
- paquet perdu : si ça arrive conforme tant mieux, sinon, ça sera mieux la prochaine fois,
- paquet certifié : idem, mais un CRC permet de vérifier que le paquet est conforme,
- recommandé : un accusé de réception confirme qu'une info conforme a été reçue.

Il serait intéressant de dessiner les écrans attendus, ce qui constitue une façon de préciser les spécifications fonctionnelles...
 
Last edited:

dje8269

Senior Member
#92
Hello,

par rapport à #77, je ne suis pas tout a fait d'accord ; ce n'est peut être pas le moteur qui consomme le plus , mais l’émetteur vidéo ! ce n'est pas encore défini, etant donné que le choix n'est pas arreté ; En tout état de cause , je ouhaite garder le principe , une alim pour la propulsion et une autre pour l’électronique .

J'ai appelé num pour numerique c'est à dire 0 ou 1 .
ADC et analogique sont effectivement la même chose , c'est a dire la lecture d'une tension analogique appliqué en entrée.

Il n'y a pas 3 sorties PWM pour les moteurs, mais seulement 2 : droite et gauche.
Hum.... Pour vous; il suffit de deux signaux droite et gauche pour fournir l'information a trois modules . Ca peut être intéressant, car on economise des sorties µC) mais le signal ne sera pas trop faible ? Je comptais mettre un signal pwm ; par module, comme il y en as trois ( un par train de roues).

Le module de mesure de courant s'intercale dans la ligne d'alim. J'ai préconisé un µcontrôleur dédié par batterie.
Oui le nombre n'est pas déterminé comme je l'ai précisé . donc je dois intercalé un µC apres le capteur de courant c'est bien ca ?
 
#93
J'ai appelé num pour numerique c'est à dire 0 ou 1 .
Ah ? les trims, c'est 0 ou 1 ?
Hum.... Pour vous; il suffit de deux signaux droite et gauche pour fournir l'information a trois modules . Ca peut être intéressant, car on economise des sorties µC) mais le signal ne sera pas trop faible ? Je comptais mettre un signal pwm ; par module, comme il y en as trois ( un par train de roues).
Ben ...
C'est ou 2, ou 6 (2 PWMs par module : droite et gauche à chaque fois...)
Sinon, je pense qu'il vaut mieux se limiter à au maximum une entrée et une sortie série par µcontrôleur.
proposition d'architecture : Télécommande.jpg
le lien entre les 2 µ se ferait par tout ou rien ; à priori, il y a peu de choses.
Reste à valider que toutes les fonctionnalités peuvent passer dans une telle architecture.
 

dje8269

Senior Member
#94
Capteur de courant sur la télécommande ?
Sécurité basse tension ?
Oui la télécommande sera alimenté par une Li-Po aussi , donc je préconise la sécurité, une Li-po qui brule voir explose , ca craint . de plus pour le calcul de l'autonomie se pourrait etre aussi utile !.
Oui coupure de l'alimentation en cas de trop basse tension, pour protéger l'ensemble ( surtout la batterie)

Comment navigue-t-on dans les menus ?
J'ai évoqué cette problématique adns le CdC . J’espère pouvoir me servir, si présent, de l’outil déjà en place sur la télécommande que je choisirai . Une molette style encodeur rotatif parait pas mal, mais compliqué à gerer en soft . j'en ai faire l'experience, mais c'ests assez pratique je l'avoue .Je pense que ceci passe en second plan pour le moment non ?

Pour les liens série (I2C, RS232, SPI,...) il faut pour chaque lien :
- le sens ou bidirectionnel,
- le débit effectif attendu,
- la fréquence des échanges,
- le niveau de fiabilité attendu.
Mes petites flèches décrivent le sens de l'information . pour le débit , je ne peux pas vous dire, je suis pas assez calé ; pareil pour la fréquence des échanges dur a définir en avance de phase , et vu mon niveau, je comptais un peu sur votre experience en fait .

Il serait intéressant de dessiner les écrans attendus, ce qui constitue une façon de préciser les spécifications fonctionnelles...
Ok je vais m'y coller

Ah ? les trims, c'est 0 ou 1 ?
Oui les trim doivent être numériques dans le reglage . des BP pour regler les trim en soft . j'ai rencontrés des difficultés avec les trim analogiques et mécaniques, pour le soft . Obligé d'eteindre la télécommande pour reinitialiser le Point milieu etc ...

C'est ou 2, ou 6 (2 PWMs par module : droite et gauche à chaque fois...)
Oui vous avez raison . je pense opté pour deux alors .
 
#95
Je pense que ceci passe en second plan pour le moment non ?
On entre dans une phase de cycle itératif :
- définition d'une architecture technique,
- validation fonctionnelle...
- modifications de l'architecture technique,
- validation fonctionnelle...
- etc...
Petit à petit, on introduit les µ et on compte les pattes, tout en vérifiant que toutes les fonctionnalités sont assumées.
Du coup, un détail fonctionnel peut faire basculer un choix d'architecture...
Comme vu, la gestion d'un ou plusieurs encodeurs n'est pas anodine si le µ doit faire autre chose en même temps...
En outre, ajouter un µ au dernier moment est une galère si on limite les communications séries comme proposé.
Par ailleurs, gérer une entrée et une sortie série sur un même µ, c'est déjà pas simple ; alors plusieurs...

Merci de mettre à jour les schémas.

Pour la description des flux, outre le sens, il manque l'initiateur. Je m'explique :
- on peut avoir des données qui transitent de A vers B à l'initiative de A ou de B : c'est très différent !
Ce serait bien sur les schémas de mettre un numéro sur chaque flux de façon à pouvoir le documenter séparément.
 

PieM

Senior Member
#96
Quelques remarques rapides:
au vu du schéma, il me semble que l'on mélange un peu tout entre fonctions principales et les autres.
je doute que la lecture du GPS et son exploitation soit au même niveau que la conduite de l'engin.
Si les moteurs sont équipés de codeurs, il faut définir à quoi ça va servir. Car si c'est pour assurer la trajectoire comme j'ai pu lire un jour, bonne chance pour faire du décodage à 2.5 kHz avec des picaxes.
Si une des contraintes du projet est de n'utiliser que des Picaxes alors il faut faire des choix.
Liaison SPI et I2C , c'est le même canal sur un Picaxe.
Je vois que la vérité d'hier de tout faire par un seul Picaxe n'est plus d'actualité. mais quant à faire les échanges entre µC en TOR, j'ai quelques doutes.
 

dje8269

Senior Member
#97
On entre dans une phase de cycle itératif :
Lol bon, déjà j'ai dus aller regarder la définition de "itératif" mdr ......

Comme vu, la gestion d'un ou plusieurs encodeurs n'est pas anodine si le µ doit faire autre chose en même temps...
Oui ça c'est sur . Si encodeur il y a, il sera tout seul. Et sera certainement actif que dans un menu défini , sinon le µC ne tiendra pas la route , car je ne veux pas dédié un µC pour ca .

D’après ma maigre expérience, la seule contrainte de rapidité de "rafraichissement" si on peut dire, serait dans les ordres de pilotage envoyés de la télécommande au VHL . le reste n'as pas besoin d’être réactif et mise a jour souvent.

Pour être honnête , j’avais pensé faire une architecture en I²C . avec un µC par fonction .

Par exemple un µC pour communiquer avec le transceiver .
Un µC pour recevoir les TOR
Un µC pour gérer l’écran et autre bricoles .

Tout ce petit monde en I²C. Mais je pense que je me mets le doigts dans l'oeil, et c'est la ou votre expérience portera tout ces fruits ; Comme sur le prototype, je ne veux pas me tromper dans le meilleur choix possible , notamment pour la perte de communication qui m'as donné tant de mal . Je m'en refere a vous , si vous voulez bien m'aider pour cette partie , car je pense pas avoir le niveau, mais j'ai soif d'apprendre .

Oui pour la mise a jour des schéma, mais je fais la nounou en même temps alors chaud les marrons . Surtou que je sais pas trop quoi mettre à jour pour le moment.

Voici l'ecran de télécommande dont je réve . un premier jet du moins

Sans titre3.png

je doute que la lecture du GPS et son exploitation soit au même niveau que la conduite de l'engin.
Je n'ai aps compris ce que tu voulais dire par la ?

Si les moteurs sont équipés de codeurs, il faut définir à quoi ça va servir. Car si c'est pour assurer la trajectoire comme j'ai pu lire un jour, bonne chance pour faire du décodage à 2.5 kHz avec des picaxes.
Voila l'exemple parfait, qui me fait dire que je ne peux pas y arriver tout seul . Vous avez une vision énorme des problémes a venir car vous savez a quoi vous attendre , pas moi .
Pour répondre a ta question , les encodeurs serviront a connaitre la vitesse du VHL, et également d'estimé grossierement la distance parcouru pour le back up. diametre de la roue, nombre tour = distance . en faisant FI des erreurs ( patinages etc ...)

Si une des contraintes du projet est de n'utiliser que des Picaxes alors il faut faire des choix.
Non ce n'est pas obligatoire, j’étudie actuellement les PICs avec le langage "C" . Mais si vous acceptez de poursuivre avec moi, même si il n'y as pas que des picaxes , je suis plus que Fana . Maintenant si vous dites que si y'as des PIC vous m'aidez plus , alors y'auras pas de PIC et que des PICaxes . sans vous j’emmènerais jamais ce projet a termes , ça c'est une certitude .

Je vois que la vérité d'hier de tout faire par un seul Picaxe n'est plus d'actualité. mais quant à faire les échanges entre µC en TOR, j'ai quelques doutes.
??? je ne pense avoir dis une seul fois qu'un seul µC pourrait tout faire . Rien que dans le proto il y en avait deux , la j'en voit plutôt 3 ou 4 .
 
Last edited:

PieM

Senior Member
#99
Je n'ai aps compris ce que tu voulais dire par la ?
Simplement que la fréquence de rafraîchissement des infos leur priorité leur traitement et les échanges n'est certainement pas la même que celles liées au pilotage.
C'est à prendre en compte dans l'architecture. Avant de définir l'architecture, il aurait été souhaitable de définir les blocs fonctionnels. Mais je ne suis pas un pro de la chose.

les encodeurs serviront a connaitre la vitesse du VHL, et également d'estimé grossierement la distance parcouru pour le back up.
donc c'est du décodage comptage permanent ... Il vaudrait mieux valider cette faisabilité avant de se lancer la dedans!

j’étudie actuellement les PICs avec le langage "C"
Avoir choisi les Pics et le C, j'espère que tu es conscient du développement à faire vu le projet ...
Trouve un bon forum pour cette partie...

Merci d'expliciter la nature de vos doutes ?
Vu l'architecture qui se dessine, mais qui est loin d'être claire pour moi, n'avoir que des échange en TOR entre µC, je demande à voir.
 
Vu l'architecture qui se dessine, mais qui est loin d'être claire pour moi, n'avoir que des échange en TOR entre µC, je demande à voir.
OK : vous pensez qu'il y plus que quelques statuts/alarmes à transmettre entre la partie "émission" et "réception".
Au vu du CDC, ça semble bon, mais il faut effectivement valider l'ensemble des fonctionnalités pour être sur.
 
Simplement que la fréquence de rafraîchissement des infos leur priorité leur traitement et les échanges n'est certainement pas la même que celles liées au pilotage
D'accord , j'ai saisi l'idée. Tu as entièrement raison .

Avant de définir l'architecture, il aurait été souhaitable de définir les blocs fonctionnels. Mais je ne suis pas un pro de la chose.
C'est a dire , ce n'est pas ce que fais mon petit organigramme ?

donc c'est du décodage comptage permanent ... Il vaudrait mieux valider cette faisabilité avant de se lancer la dedans!
Ok , effectivement , attendons que je les ai reçus pour tester .

Avoir choisi les Pics et le C, j'espère que tu es conscient du développement à faire vu le projet ...
Je n'ai pas choisis les PIC spécifiquement pour ce projet, juste pour aller un peu plus loin que les picaxes. En fait je comptais mixer les deux ! Tous ce qui mérite de la performance ou pas accessible pour un picaxe, Je pourrais le faire ne PIC et tout le reste en picaxe . Il existe de nombreuses bibliothèques en "C" facilitant grandement le travaille , un peu comme sur arduino . Mais arduino est encore un autre langage , mais je suis pas contre si vous me coaché !.
Je prends un exemple simple, pur la gestion de l’écran, peut être qu'un picaxe sera limite niveau performance ou autres ( mémoires, fonction ..) , j'aurais donc seulement ça a traiter avec les PICs et a relier en I²C. Mais ce n'est qu'une idée je suis peu être dans le faux. Je ne compte pas faire tout le projet en PIC se serait vraiment trop long, vu le travail a faire.

Vu l'architecture qui se dessine, mais qui est loin d'être claire pour moi, n'avoir que des échange en TOR entre µC, je demande à voir.
Qu'est ce qui ne te parait pas clair ? je voudrais réussir à enlever toutes les zones d'ombres !
 
En post #1 j'ai mis les organigrammes modifiés, un peu plus précis . Mais je ne sais pas trop comment faire , c'est tout nouveau pour moi de faire des choses comme ca .

Comme je ne peut mettre que deux image par post, l'ecran n'apparaitras pas !

Qu'en pensez vous ? suis-je sur la bonne voie ?
 
C'est plus un schéma fonctionnel qu'un organigramme mais peu importe.

Je maintiens qu'il vaut mieux se limiter à une seule ligne série(ou I2C ou SPI) en entrée et une en sortie par µ.
Et c'est à cause de ça que c'est souvent plus facile d'utiliser un seul µ puissant que de parvenir à en synchroniser 5 poussifs.
En outre il est impératif d'indiquer le sens des données et l'initiateur (par exemple un i du coté de l'initiateur)
A la rigueur, on peut lire plusieurs ports série si on a l'initiative et si la fréquence n'est pas trop élevée.
C'est encore bien trop tôt pour indiquer "maître" ou "esclave".
J'ai plus raisonné en flux de données qu'en fonction : un µ lit des infos d'un coté et en recrache de l'autre, mais il faut faire attention à ce qu'il ne doive pas surveiller trente six trucs en même temps, en particulier plus qu'une seule entrée série dont il n'est pas initiateur.
C'est pour ça que je voyais un µ pour préparer et envoyer les données au transceiver,
et un autre pour recevoir les données du transceiver et les traiter.


Manque les N° sur chaque flux pour pouvoir le documenter explicitement.

Pour le pack de batterie, le principe c'est un ensemble complet comprenant :
- la batterie,
- le capteur courant/tension,
- le µ (et sa mémoire permanente intégrée)
- la connectique ad hoc,
- éventuellement un indicateur d'état.

C'est la seule façon de gérer correctement l'énergie si la batterie est amovible.
 
C'est pour ça que je voyais un µ pour préparer et envoyer les données au transceiver,
et un autre pour recevoir les données du transceiver et les traiter.
Je ne suis pas un expert , mais comment différencier le bus de réception et d’émission d'info . LE transceiver est prévue pour communiquer avec un µC en UART en émission et en réception , je pense qu'il en faut qu'un pour cette fonction .

Pour compléter le schéma , voici ce à quoi j'avais pensé.

Partie VHL :

Le récepteur reçoit les infos , et les transmets à un µC. En gros il passera plus de temps à recevoir qu'a émettre du coté du VHL. Je ne sais pas si c'est possible de faire ça !
Ce µC dispatche les infos reçues sur tous les µC , qui EUX feront le tri des infos , pour ne prendre en compte que celle qui leurs sont destinées. Une priorité si possible sera attaché au commande des moteurs.

Ensuite, si c'est lui le maitre, ce µC va cherché les infos qu'il a besoin d'envoyer, à la fréquence défini . Je ne vois pas pour le moment de chose hyper-importante à envoyer à la télécommande, il ne s'agit que de compte rendu de son état ou de sa position etc ...

Partie télécommande :
A mon avis le plus compliqué, car c'est le donneur d'ordre.
contrairement au transceiver du VHL lui , devrait passer plus de temps à émettre des ordres , qu"a recevoir des infos . celui ci pourrait être esclave ,car il n'aura que peu d'info à traiter . Son rôle sera vraiment d'envoyer le plus d'infos possible . la mise à jour des ces infos pourrait se faire par le maitre qui lui écrira dessus .
Le maitre devra avoir le moins de taches possible pour mettre a jour le plus souvent possible . c'est pourquoi les commandes de déplacement du VHL doivent être traiter par celui ci . le reste ca a le temps d’être traiter .

En outre il est impératif d'indiquer le sens des données et l'initiateur (par exemple un i du coté de l'initiateur)
Qu'entends tu exactement par initiateur ? celui qui demande des infos ? celui qui va chercher les infos ? celui qui envoie les infos ?
Les flèches indiquent le sens de circulation des infos . ou alors donnez moi un exemple , le trim c'est quoi pour vous un initiateur ou non ?
 
Last edited:
par rapport à #77, je ne suis pas tout a fait d'accord ; ce n'est peut être pas le moteur qui consomme le plus , mais l’émetteur vidéo !
Ce sera pas mal de le savoir maintenant ; vous avez bien un ampèremètre ou l'équivalent ?
Je ne sais toujours pas quel avantage on a à gérer deux batteries au lieu d'une seule.
LE transceiver est prévue pour communiquer avec un µC en UART en émission et en réception , je pense qu'il en faut qu'un pour cette fonction .
Il y a bien une ligne en entrée et une ligne en sortie. Donc rien n'oblige techniquement à ce que le même µ gère simultanément les deux !
Par contre, ce qui est certain, c'est qu'un micro "bas de gamme" a beaucoup de mal à gérer simultanément deux lignes série s'il n'en est pas l'initiateur==> d'où la nécessité d'un schéma très clair à ce niveau.
Après, il faut voir au niveau fonctionnel s'il y a un intérêt. Par exemple la gestion des acquis de réception peut nécessiter un retour de l'info vers l'émetteur. Mais ce besoin fonctionnel n'est pas mentionné.

Partie VHL :

Le récepteur reçoit les infos , et les transmets à un µC. En gros il passera plus de temps à recevoir qu'a émettre du coté du VHL. Je ne sais pas si c'est possible de faire ça !
Ce µC dispatche les infos reçues sur tous les µC , qui EUX feront le tri des infos , pour ne prendre en compte que celle qui leurs sont destinées. Une priorité si possible sera attaché au commande des moteurs.

Ensuite, si c'est lui le maitre, ce µC va cherché les infos qu'il a besoin d'envoyer, à la fréquence défini . Je ne vois pas pour le moment de chose hyper-importante à envoyer à la télécommande, il ne s'agit que de compte rendu de son état ou de sa position etc ...

Partie télécommande :
A mon avis le plus compliqué, car c'est le donneur d'ordre.
contrairement au transceiver du VHL lui , devrait passer plus de temps à émettre des ordres , qu"a recevoir des infos . celui ci pourrait être esclave ,car il n'aura que peu d'info à traiter . Son rôle sera vraiment d'envoyer le plus d'infos possible . la mise à jour des ces infos pourrait se faire par le maitre qui lui écrira dessus .
Le maitre devra avoir le moins de taches possible pour mettre a jour le plus souvent possible . c'est pourquoi les commandes de déplacement du VHL doivent être traiter par celui ci . le reste ca a le temps d’être traiter .
Rien compris...
Je ne sais pas ce qu'est un "maitre" ou un "esclave"
Merci de numéroter chaque flux sur le schéma, d'indiquer le sens de transit des données et l'initiateur de l'échange.
En particulier, même si sur un BUS I2C les données peuvent transiter dans les deux sens, merci de mettre la flèche dans le sens ad hoc, et s'il doit y avoir des échanges dans les deux sens, de mettre deux flèches.
 
Last edited:
Ce sera pas mal de le savoir maintenant ; vous avez bien un ampèremètre ou l'équivalent ?
Oui je posséde bien un ampermetre, mais je ne possède ni les moteurs, ni le châssis( mais qui sont en commande) , et pas d’Émetteur vidéo, qui veindras ce greffer par la suite mais sera indépendant .

Je ne sais toujours pas quel avantage on a à gérer deux batteries au lieu d'une seule.
C'est mon quatrième VHl en picaxe, mine de rien , et sur chaque VHL la batterie électronique est séparée du gros consommateurs . Notamment pour les retours de parasites , de chute de tension , de masse etc ......... surtout sur les servos moteurs, alors avec un GPS u ngyro etc ; tout mettre sur une seule batterie me parait pas possible ;

de plus cela permettrais une meilleur gestion , même si comme le Dis PieM il y aurais de la perte . on pourrait etre obligé de revenir car la batterie elecro serait vide , et la batterie propu pleine . c'est une chose que j’admets . mais je préfère faire comme ça , car j'ai l'habitude .

Je ne sais pas ce qu'est un "maitre" ou un "esclave"
Vous m’étonnez ?? tout de même !. En I²C , le maitre fournis le signal d'horloge et peut écrire et lire sur un esclave , un esclave peut seulement lire .
Merci de numéroter chaque flux sur le schéma, d'indiquer le sens de transit des données et l'initiateur de l'échange.
La c'est moi qui ne saisi pas votre histoire de flux ? parlez vous de liaison, voulez vous que je mette un numéro sur chaque flèche ?
 
Voici comment je vois les choses :
Telco_02.jpg
Le µ1 récupère les données numériques et les mets en forme le plus vite possible à destination du tranceiver (flux 2). Sans interférer avec cette tâche primaire, il récupère les données du headtracker (flux 1) et les intercale dans les données à destination du transceiver.

Le µ2 reçoit les données du transceiver sans en être à l'initiative (flux 3). C'est délicat, mais on peut se permettre de perdre certaines trames. En même temps il récupère les données NRJ et mets en forme les données à destination du module d'affichage.

Vehi_02.jpg

Le µ3 collecte les infos NRJ, GPS et GYRO (flux 10,11 et 12) et les mets en forme à destination du tranceiver (flux 13). Il a tout le temps pour rafraichir ces données.

Le µ4 ne fait que recevoir le flux 14 et commander les moteurs et les servos. Il doit avoir une excellente réactivité.
 
Last edited:
En I²C , le maitre fournis le signal d'horloge et peut écrire et lire sur un esclave , un esclave peut seulement lire .
La c'est moi qui ne saisi pas votre histoire de flux ? parlez vous de liaison, voulez vous que je mette un numéro sur chaque flèche ?
Sur ce schéma, pour les communications entre µ, on ne sait pas quel protocole on va utiliser. On doit définir qui est à l'initiative et dans quel sens vont les données. Après on saura si un bus I2C est adapté et comment le configurer.
Par exemple le µ2 n'est pas à l'initiative des données qu'il reçoit du transceiver. C'est une contrainte importante car il doit être très disponible pour "écouter" la ligne série. Par contre, même si on ne sait pas quel sera le protocole à destination du module d'affichage, on sait que c'est le µ2 qui a l'initiative pour envoyer des données, de même que c'est lui qui décide de recevoir les données du µ NRJ.
Vous savez que si on a besoin de 2 maitres sur un même bus, on est coincé.
De même la réception en tâche de fond est perturbée quand on utilise les commande de sortie série, que ce soit RS232, SPI ou I2C...

A ce dernier sujet, est-on OK pour un µ dédié par batterie à superviser ?

Je ne vois aucun inconvénient à ce que fassiez figurer un bus I2C là où c'est décidé. On pourrait remplacer le i par un M et des E pour chaque bus.
A mon stade de réflexion, ce choix ne me semble pas évident partout vu que mon architecture diffère notablement de la votre.
 
Last edited:
Moi trés honnêtement je vous fais confiance . Mais , car il y a toujours un "MAIS" , il faut aussi que je comprenne ce que je fais !. par exemple :

A ce dernier sujet, est-on OK pour un µ dédié par batterie à superviser ?
Je dis OUI ça ne me dérange pas, car la gestion et l'indication des batteries est une option, certes, mais importante tout de même . Maintenant pourquoi dédié un µC pour gérer une batterie alors qu'on aurait le temps de le faire avec un µC général ? la je vois pas le truc !

Le µ4 ne fait que recevoir le flux 14 et commander les moteurs et les servos. Il doit avoir une excellente réactivité.
Vous dites que le µ4 ne fait que recevoir le flux, mais non , il reçoit TOUT le flux, et donc tout les ordres , il doit forcement les redistribuer . car dans la théorie , on peu dire oui il fait ca , mais dans la pratique envoer un ordre au moteur , se fait après moultes calcul !

De plus , mon anglais technique et non technique d'ailleurs ne me permettent pas en amont de connaitre le fonctionnement exact de ces transceivers ; mais je doute qu'on puisse séparé émission et réception , a cause des checksum et des A/R , ainsi que les horloges ou autres broutilles .

Le µ1 récupère les données numériques et les mets en forme le plus vite possible à destination du tranceiver (flux 2)
Je suis d'accord la dessus, si ce n'est que les données sont analogiques ( les joysticks sont des potars) . le Headtracker devrait etre gerer par un autre a mon avis .

Le µ2 a énormément de boulot , mais n'est pas pressé . gérer un écran n'est pas chose facile, mais surtout la gestion de tous les TOR avec anti rebond vérification de changement de positions etc .. plus le buzzer et j'en passe .

Je pense avoir saisi votre numérotation , je m'y colle ! et je mets a jour mon organigramme après quelques modifs
 
il faut aussi que je comprenne ce que je fais !
Ce point est absolument essentiel.
Maintenant pourquoi dédié un µC pour gérer une batterie alors qu'on aurait le temps de le faire avec un µC général ? la je vois pas le truc !
C'est à cause de la mémoire qui doit rester solidaire de la batterie. On pourrait se contenter d'une puce mémoire, mais vu le faible coût du µ, autant l'attacher à la batterie et s'en servir au moins pour mesurer la tension. A ce niveau un petit ampli-op permet de gagner un facteur 3 en précision, ce qui n'est pas négligeable.
Vous dites que le µ4 ne fait que recevoir le flux, mais non , il reçoit TOUT le flux, et donc tout les ordres , il doit forcement les redistribuer . car dans la théorie , on peu dire oui il fait ca , mais dans la pratique envoer un ordre au moteur , se fait après moultes calcul !
Ben oui : un flux, c'est une succession de commandes.
Si on s'est bien mis d'accord avec l'émetteur pour des unités de mesure commodes, il n'y a pas grand chose ou rien à calculer. Je n'ai vu aucunes spécifications à ce niveau. A ma connaissance, les commandes sont :
- tension gauche,
- tension droite,
- PWM Horiz pour la camera,
- PWM Verti pour la camera,
- bits d'état des relais et sorties.

A priori, si vous devez faire des tas de calculs au niveau du véhicule, c'est que vous recevez (inutilement) des tas de valeurs et de paramètres. Autant faire le calcul avant d'envoyer les données qui seront de fait moins volumineuses donc plus rapide et plus facile à transmettre.
De plus , mon anglais technique et non technique d'ailleurs ne me permettent pas en amont de connaitre le fonctionnement exact de ces transceivers ; mais je doute qu'on puisse séparé émission et réception , a cause des checksum et des A/R , ainsi que les horloges ou autres broutilles .
Ben c'est urgent de récupérer l'info ! (au moins parce que ça conditionne pas mal l'architecture !)
Cela dit c'est du RS232, donc il y a un TXD et un RXD, donc rien n'oblige à ce que ce soit le même µ.
Tout le bazar des checkksum et des AR est géré par le µ sur la platine. Donc on n'a rien à faire en amont ou en aval. C'est pour ça que c'est pro (et sans doute cher...)
 
Last edited:
C'est à cause de la mémoire qui doit rester solidaire de la batterie.
Oups , je crains avoir compris ! vous voulez qu'on scotch un µC sur la memoire ? ah ben la effectivement ca va pas etre possible !

A priori, si vous devez faire des tas de calculs au niveau du véhicule, c'est que vous recevez (inutilement) des tas de valeurs et de paramètres. Autant faire le calcul avant d'envoyer les données qui seront de fait moins volumineuses donc plus rapide et plus facile à transmettre.
Que le calcul se fasse en amon ou en aval, le temps sera le même ! On ne recois pas de données inutiles mais des données a traitées .

il ne s'agit pas d'envoyer seulement la valeur d'une tension lue par un readadc , mais de la mettre a l’échelle et de la conditionnée . j'entends par la que si le VHL est a l’arrêt et que l'on tourne a droite, il faudrait faire tourner les roues droite dans un sens et les gauches dans l'autre ( faire un pivot comme les chars) ; tandis que si l'on roule, il faudra réduire la vitesse d'un cote et/ou de l'augmenter de l'autre . tout ceci dans des boucles qui autorise ou non le déplacement bien entendu.

Ben c'est urgent de récupérer l'info ! (au moins parce que ça conditionne pas mal l'architecture !)
Je suis honete et j'ai même pas honte en disant que je n'en suis pas capable. Je comptais faire ça par test. Ce sera plus rapide que d'apprendre l'anglais technique et les tournures des phrases sur les DS .

Cela dit c'est du RS232, donc il y a un TXD et un RXD, donc rien n'oblige à ce que ce soit le même µ.
Oui il me semble avoir lu qu'une broche était prévue pour dire quand il était prêt a recevoir et une autre prêt a envoyer .

Je précise aussi, que je préfère dans le mesure du possible utiliser des bus que je connais un peu , comme l'I²C . j'ai quelques notions dessus avec le dernier projet , sans aucune prétention .
 
Oups , je crains avoir compris ! vous voulez qu'on scotch un µC sur la memoire ? ah ben la effectivement ca va pas etre possible !
Sur la batterie pour être précis. Moi, je ne veux rien.. je suggère : c'est tout. C'est comme ça que ça se fait sur tous les ordis portables et pas mal d'équipements de jardin et de bricolage pour lesquels les batteries sont amovibles (sinon ces batteries n'auraient que deux bornes ...)
Sans ça, c'est un peu plus contraignant en cas de remplacement des batteries qui devront donc obligatoirement être à pleine charge et reposées avant le démarrage.
Le vieillissement des batteries suppose un réétalonnage régulier qui ne pourra pas être automatisé. A part ça, rien de bloquant.

Que le calcul se fasse en amon ou en aval, le temps sera le même !
Faux : suivant le nombre de bits transmis pour chaque valeur, la bande passante peut varier du simple au double facilement. Il est important de ne transmettre que des bits significatifs.
Les calculs ne peuvent être monstrueux : au pire une multiplication et une addition, et quelques tests. Un simple sertxd ou i2Cout est bien plus gourmand en temps de calcul.
Je suis honete et j'ai même pas honte en disant que je n'en suis pas capable. Je comptais faire ça par test. Ce sera plus rapide que d'apprendre l'anglais technique et les tournures des phrases sur les DS .
C'est une bonne approche, nécessaire même vu l'importance de ce module de transmission dans le projet.
J'ai déjà suggéré de monter une plateforme de test mobile (avec les transceivers amovibles vu leur coût !)
Un Picaxe et un LCD a chaque bout. Et on envoie des paquets numérotés de taille et de vitesse variables (2 potars ?).
Le récepteur est chargé de mesurer le nombre de paquets perdus.
Reste plus qu'à varier la bande passante et la distance pour voir où sont les limites.
Ca permet aussi de valider le point délicat :
- réception de données sur un port série tout en transmettant des données sur un périphérique I2C.
SI on sépare émission et réception, inutile de faire le test dans les 2 sens puisque chaque µ n'aura qu'un sens à gérer.
Sinon, il faut aussi tester sur cette même plateforme la transmission simultanée de données dans les deux sens. Dans ce cas, bonne chance...

Par contre, il me semble inutile d'avancer sur l'architecture tant qu'on n'aura pas la conclusion de ces tests.
 
Last edited:
Oui il me semble avoir lu qu'une broche était prévue pour dire quand il était prêt a recevoir et une autre prêt a envoyer .
Excellent remarque qui n'a rien à voir avec le TXD et le RXD dont je parlais (notés TX et RX dans la doc, le D de Data étant sous entendu)
mais la mise à disposition (fortement conseillée dans la doc) d'un handshake hard laisse supposer la présence d'un buffer.
Vérification faite, sa taille est fixée à 120 caractères.
Ca veut dire que tant que le µ est occupé à autre chose (genre régler les PWM ou envoyer des données à un afficheur), il peut basculer une broche pour dire qu'il n'est pas prêt pour recevoir des données. C'est le transceiver qui va stocker les données reçues ! (dans la limite de la taille du buffer évidement)
Quand le µ est dispo, il bascule le flag et se mets à l'écoute.
Fo vraiment tester ça car ça conditionne à la fois l'architecture matérielle et aussi celle des programmes.
C'est mon quatrième VHl en picaxe, mine de rien , et sur chaque VHL la batterie électronique est séparée du gros consommateurs . Notamment pour les retours de parasites , de chute de tension , de masse etc ......... surtout sur les servos moteurs, alors avec un GPS u ngyro etc ; tout mettre sur une seule batterie me parait pas possible ;
Sauf que si mes souvenirs sont bons, la batterie est en 12V et que toutes les autres tensions sont fabriquées en PWM. Il est donc totalement impossible que des parasites se baladent sur ces lignes ! Il me semble que c'était aussi l'avis de PieM.
PS : penser à approvisionner ces modules : c'est tellement pas cher que ça ne vaut pas la peine de les fabriquer...
 
Last edited:
Sur la batterie pour être précis
Lol , oui pas sur la mémoire . vous l'aurez compris ! . je suis pas fana du tout de cette méthode pour plusieurs raisons , par exemple le jour ou il faudra acheter des batteries et que je suis pas la , ben c'est mort . Faire en sorte d'avoir des batteries pleine a chaque allumage me parait pas dénouer de sens ; Je vote pour cette méthode ! Pour cette partie je reste persuadé , qu'une estimation du courant consommé , plus une mesure de tension reference ( en emission par exemple) plus , une table de données estimatifs , nous rendrait assez de précision !.

Les calculs ne peuvent être monstrueux : au pire une multiplication et une addition, et quelques tests. Un simple sertxd ou i2Cout est bien plus gourmand en temps de calcul.
Vous avez raison ! je me fait du soucis pour rien a mon avis .

J'ai déjà suggéré de monter une plateforme de test mobile (avec les transceivers amovibles vu leur coût !)
Un Picaxe et un LCD a chaque bout. Et on envoie des paquets numérotés de taille et de vitesse variables (2 potars ?).
Le récepteur est chargé de mesurer le nombre de paquets perdus.
Reste plus qu'à varier la bande passante et la distance pour voir où sont les limites.
J'adore cette idée ? je possède quelques modules pour faire cette plateforme ( j'avais commandé plusieurs couples) .

Et je suis d'accord aussi pour dire que ça peut changer beaucoup de chose . mais pas révolutionner le schimblic non plus. il faudra toujours dialoguer , mesurer, et afficher :)

Vous savez quelle est ma plus grande interrogations ? c'est cette maudite détection de perte de communication qui me hante . Ce fut une vrai galère sur le proto, et un vrai chemin de croix pour moi, même si au final j'ai appris énormément avec out mes problèmes . La platine de test pourrait nous en dire plus long la dessus aussi .

PS : Mise a jour de l’organigramme
 
Lol , oui pas sur la mémoire . vous l'aurez compris ! . je suis pas fana du tout de cette méthode pour plusieurs raisons , par exemple le jour ou il faudra acheter des batteries et que je suis pas la , ben c'est mort . Faire en sorte d'avoir des batteries pleine a chaque allumage me parait pas dénouer de sens ; Je vote pour cette méthode ! Pour cette partie je reste persuadé , qu'une estimation du courant consommé , plus une mesure de tension reference ( en emission par exemple) plus , une table de données estimatifs , nous rendrait assez de précision !.
Je suis persuadé du contraire :
- les tensions ne peuvent être mesurées que batterie au repos,
- les batteries neuves sont différentes, et diffèrent encore plus après le rodage,
- elles vieillissent différemment.

Une "estimation du courant consommé" ne sert à rien. Il faut une mesure et une intégration du courant consommé et une mesure de la tension, voire de la température.
Si on n'utilise pas un circuit spécialisé, le µ qui supervise la consommation ne peut quasiment faire que ça.

Attacher une mémoire à chaque batterie permet un ré-étalonnage automatique à chaque charge.

En cas d'achat d'une nouvelle batterie, il est de toutes façons nécessaire de faire un nouvel étalonnage, donc que ce soit quelqu'un qui sache.
Pour utiliser une bonne part de la capacité de chaque batterie sans remettre en cause sa durée de vie, il faut une gestion rigoureuse et des ré-étalonnages réguliers.

Mais il est aussi possible de n'utiliser les batteries qu'à moitié, ou d'accepter des remplacement plus fréquents par décharge inappropriée.

Vous savez quelle est ma plus grande interrogations ? c'est cette maudite détection de perte de communication qui me hante
Avec les modules choisis, ce devrait être un vrai bonheur. Mais ce serait bien de tester avant de décider.
Mise a jour de l’organigramme
On ne voit toujours pas dans quel sens circulent les données, ni qui est à l'initiative de chaque échange. Les flux ne sont pas tous numérotés, les µ encore moins, et l'architecture me semble inadaptée.
En ce qui concerne l'affichage, avez-vous avancé ? Que pensez-vous des modules suggérés ?
 
Last edited:
Sauf que si mes souvenirs sont bons, la batterie est en 12V et que toutes les autres tensions sont fabriquées en PWM. Il est donc totalement impossible que des parasites se baladent sur ces lignes ! Il me semble que c'était aussi l'avis de PieM.
??? J'ai eu énormément de soucis avec les alimentation . Que ce soit avec les moteurs et les servos moteurs; les moteurs avec l’émetteur vidéo et les servos moteurs bref les moteurs ca met une pagaille folle !

PS : penser à approvisionner ces modules : c'est tellement pas cher que ça ne vaut pas la peine de les fabriquer...
Lesquels ?

Je pense que je vais me lancer dans la création d'un platine Test transceiver alors .

On ne voit toujours pas dans quel sens circulent les données
Ben y'as mes petites fleches ? qui indiquent si les données rentrent ou sortent ! :(
ni qui est à l'initiative de chaque échange
Ben j'ai pas compris en fait !
Les flux ne sont pas tous numérotés
J'ai numéroter que les flux qui me paraissait importants !


En ce qui concerne l'affichage, avez-vous avancé ? Que pensez-vous des modules suggérés ?
Modules suggérés ? au tout début ? je crois de mémoire qu'ils étaient un chouille trop petit . je vais allez voir et je vous dis quoi !

EDIT : j'ai retrouvé le post .
je crois que c'st un peu petit , mais dans l'idée c'est ca . Si un ecran peut avoir son propre µC c'est le top . Car plus simple , et oins gourmant en ressources je suppose . Je l'avais dis dès le début , que tout ce qui peut s'acheter pour faciliter le Job , je prends . le budget est conséquent pour une base roulante .

PS : pour la création de la platine vous préférez que j'ouvre un autre post ou on continu sur celui ci ?
 
Last edited:
??? J'ai eu enormement de soucis avec les alimentation . Que ce soit avec les moteurs et les servos moteurs; les moteurs avec l'emetteur vidéo et les servos moteurs bref les moteurs ca met une pagaille folle !
C'était des alims PWM ?
Par exemple :DC-to-DC-4V-38V-to-1-25V-36V-5A-Step-Down-Power-Supply-Buck
ou bien
Ultra-small-size-DC-DC-Step-Down-Power-Supply-Module-3A
ou encore
DC-DC-Step-Down-Power-Module-4-2V-40V-to-1-25V-37V-Converter
C'est pas ce qui manque !
Je pense que je vais me lancer dans la création d'un platine Test transceiver alors .
Pas besoin que ce soit très chiadé, mais c'est toujours pratique d'avoir quelques platines dispos pour les tests.


Ben y'as mes petites fleches ? qui indiquent si les données rentrent ou sortent !
Sue le premier schéma, c'est pas très clair au niveau du flux N°4...

Ben j'ai pas compris en fait !!
Voir #95 :
on peut avoir des données qui transitent de A vers B à l'initiative de A ou de B : c'est très différent !
Pour un bus I2C, c'est le Master qui a l'initiative de l'échange, mais les données peuvent aller dans un sens ou dans l'autre.
Le Transceiver est initiateur sur son port TXD, ce qui implique que le récepteur ne peut pas l'être, sauf avec un handshaking.
Modules suggérés ? au tout début ? je crois de mémoire qu'ils étaient un chouille trop petit . je vais allez voir et je vous dis quoi !
Y a quand même pas mal de choix !
afficheurs-4d-systems
modeles-demmel-products
PS : pour la création de la platine vous preferez que j'ouvre un autre post ou on continu sur celui ci ?
Ben c'est votre thread : vous le polluez comme vous voulez...
Mais c'est un sujet un peu différent qui peut être utilisé par ailleurs, donc je pencherais plutôt pour un autre thread.
 
Last edited:
???? J'ai éditer mon avant dernier post . Et il y a eu un loupé sur votre post ?

C'était des alims PWM ?
Non pas toute , l'une passait par MOSFET la première , les deux autres par des ESC qui se piloter en PWM , mais l'alim du moteur était faite par un pont en H .
 
EDIT : j'ai retrouvé le post .
je crois que c'st un peu petit , mais dans l'idée c'est ca . Si un ecran peut avoir son propre µC c'est le top . Car plus simple , et oins gourmant en ressources je suppose . Je l'avais dis dès le début , que tout ce qui peut s'acheter pour faciliter le Job , je prends . le budget est conséquent pour une base roulante .
Euh.. l'écran est sur la télécommande ; à priori il ne risque rien. Mais c'est sur que c'est pas donné.
Mais une fois programmé, le µ peut lui envoyer juste les données via I2C, SPI ou RS232 TTL et il se charge à la fois de la mise en forme et de la gestion de l'écran tactile ou d'un mini joystick.
D'un autre coté, un Picaxe aura beaucoup de mal à gérer un LCD couleur de bonne taille. Et investir dans un environnement de développement PIC, c'est pas donné non plus et ça prends du temps...
Dans un cas comme dans l'autre, je ne pourrai pas aider car dès que ça dépasse le niveau Picaxe, je passe sur AVR, mais toujours en BASIC.

Chez 4D, l'environnement est téléchargeable gratuitement 4D_Workshop_4_IDE/
Et on peut même utiliser le PC comme écran de test via son port série.
Cerise sur ce gâteau, il y a une Picaso-Serial-PicAxe-Library
Je me demande si je ne vais pas en prendre un !
 
Last edited:
Mais c'est sur que c'est pas donné.
Le budget est large , aucun problème si ça aide , si ça facilite et si ça fait le Job !

investir dans un environnement de développement PIC, c'est pas donné non plus et ça prends du temps...
L'investissement est déjà fait. il me maque le temps lol . vivement la retraite lol .

Celui la sympa avec le peetit HP integr . mais il faut ciompter un cable de programmation en plus , et encore un langage a apprendre ; je sais pas si le jeu en vaut la chandelle .
http://www.lextronic.fr/P26144-afficheur-tft-couleur-ulcd-24ptu.html

Chez 4D, l'environnement est téléchargeable gratuitement 4dsystems
Et on peut même utiliser le PC comme écran de test via son port série.
Cerise sur ce gâteau, il y a une Picaso-Serial-PicAxe-Library
Je me demande si je ne vais pas en prendre un !
Vous avez des actions chez eux , avouez ?!!! :eek:

Ça a l'air très bien . je garde ca sous le coude et met a jour le lien dans le CdC pour eviter de chercher

Allez je file au lit , car de main j'ai du pain sur la planche . creer une platine d'essai . avec n peu de chance je filerai au boulot la sortir vite fait .et je pourrais tester pendant mes congés ! .

je met quoi dessus ? potar ? ecran , inter et Bp . des leds ? la base pour faire des tests ?
 
Last edited:
Top