Projet Véhicule RC

BESQUEUT

Senior Member
Vous avez des actions chez eux , avouez ?!!! :eek:
Juré : NON
L'idée pour la domotique ce serait plutôt Androïd. Mais là encore, bonjour le temps passé...

je met quoi dessus ? potar ? ecran , inter et Bp . des leds ? la base pour faire des tests ?
Je dirais deux identiques avec un LCD, une LED en plus du témoin d'alim, 2 potars, un inter et 2 poussoirs, le support pour le transceiver, l'alim 3,3V, la mise à niveau, le connecteur de programmation et un peu de marge.

Mais... vous avez déjà les transceivers ?
 

dje8269

Senior Member
Bonjour,

Oui je les possède déjà ceux ci .

Allez je me colle à la création d'un schéma.
Pour les tests, pendant les vacances, je les mettrais sur veroboard seulement . ce sera bien plus simple .
 

BESQUEUT

Senior Member
Le transceiver est en full duplex ? et aucune interférence possible dans les accès ?
Au niveau UART oui : on peut émettre et recevoir des données simultanément.
Au niveau radio, c'est le transceiver qui gère, mais ça n'influence pas le dialogue avec l'UART.
Avec l'architecture que j'ai proposé, chaque sens est géré par un µ différent, donc pas d'interférence.
Si j'ai bien compris le feed back va consister à enregistrer une multitude de données et les restituer après mise en forme de façon à pallier la défaillance du pilotage direct, jusqu'à retrouver (peut être) une liaison radio.
Je n'ai pas exactement compris la même chose :
Pour moi, il s'agit de visualiser sur la télécommande des compléments d'information difficile ou impossible à voir sur la vidéo :
- niveau de réception d ela radio,
- niveau des batteries,
- inclinaison de l'engin,
- distance parcourue,
- trace GPS,
En parallèle , le véhicule mémoriserait la fin de la trace GPS pour être en mesure de revenir en arrière en cas de besoin.
Mon intervention faisait suite simplement au soucis de maintenir la même réactivité lors de la conduite, qu'avec le proto. Soit une période de mise à jour de 50 ms maxi.
Sur le prototype j'étais à 20 infos (50ms grossomodo) par seconde est la réactivité était top. Je voudrais réussir soit à faire mieux , soit aussi bien , en renforçant la fiabilité .
Tous ceci ne constitue pas un critère objectif.
Il faudrait savoir quelle est la relation entre la fréquence de rafraichissement (coté véhicule) et la sensation du pilote. En dessous de quelle fréquence le pilote ressent un manque de réactivité ? Pour le savoir, seul un test en double aveugle (double insu) serait significatif.
En outre, à ma connaissance, la fréquence évoquée est celle de l'émission. On n'a jamais mesuré la fréquence des trames effectivement utilisées. On peut en perdre une sur deux : on n'en sait rien !
Là encore, un protocole de test rigoureux est indispensable si on veut parler d'amélioration de la qualité.
 
Last edited:

dje8269

Senior Member
Pour moi, il s'agit de visualiser sur la télécommande des compléments d'information difficile ou impossible à voir sur la vidéo :
- niveau de réception d ela radio,
- niveau des batteries,
- inclinaison de l'engin,
- distance parcourue,
- trace GPS,
En parallèle , le véhicule mémoriserait la fin de la trace GPS pour être en mesure de revenir en arrière en cas de besoin.
C'est exactement ca . Je rajouterais , aussi l’état des TOR présent sur le VHL .

Encore une autre, je viens de remarquer qu'il y a toujours un joystick moteurs droit, et un moteurs gauche; j'ai dit ce que j'en pensais: c'est une hérésie sur le plan ergonomique.: Outre le fait que ça mobilise les deux mains, il est impossible de synchroniser l'action des deux mains sur une télécommande, donc impossible d'aller droit lors d'une accélération ou d'un ralentissement.
??? Effectivement la méthode char d'assaut, serait pas vraiment pratique . mais jamais AU grand jamais , il n'en a été question !!!!!! . Ca se pilotera comme n'importe quelle voiture télécommandée . A savoir quand vous avez la télécommande dans les mains .

le joystick de gauche :
- mouvement haut/bas : pour avancer et reculer .
- mouvement droite/gauche pour piloter la camera en PAN quand se sera autorise par l’interrupteur.

le josytick de droite :
- mouvement haut/bas : inutilisé en mode normal
- mouvement droite/gauche , pour faire pivoter le VHL , par accélération ou decceleration d'un cote ou de l'autre ou les deux
 

dje8269

Senior Member
Petite remarque à cette occasion (à déplacer dans l'autre post) : les drivers moteurs ne se commandent pas en PWM. rien que ce type de détail conditionne l'architecture.
Tu m'as mis le doute . mais Oui il peuvent se commandés en PWM non ?

datasheet page 2 :

Ultra-sonic switching frequency:
Sabertooth 2x5 features a PWM frequency of 32kHz, w
hich is well above the maximum
frequency of human hearing. Unlike some other motor
drivers, there is no annoying whine when
the motor is on, even at low power levels.
La commande des deux moteurs peut se faire à l'aide d'une tension analogique, d'un signal RC ou d'un signal série.
je crois qu'en signal RC il parle de PWM !

Mais effectivemetn ca rentre en compte pour l'architecture
 

BESQUEUT

Senior Member
le joystick de gauche :
- mouvement haut/bas : pour avancer et reculer .
- mouvement droite/gauche pour piloter la camera en PAN quand se sera autorise par l’interrupteur.

le josytick de droite :
- mouvement haut/bas : inutilisé en mode normal
- mouvement droite/gauche , pour faire pivoter le VHL , par accélération ou decceleration d'un cote ou de l'autre ou les deux
Pas de pilotage haut/bas pour la camera ?
 

PieM

Senior Member
Ce que je nommais feed back (tel que l'appelle dje) c'est le principe de retour en arrière .
Ce qui est rapatrié sur la télécommande c'est ce que j'appelle la télémesure.

Donc pour ce feed back, s'il suffit d'enregistrer les dernières positions GPS c'est une chose . Il me semblait qu'il s'agissait d'autre chose... Comme quoi tout n'est pas clair.
Piloter un retour en aveugle rien qu'au GPS, il vaut mieux être en terrain dégagé!

Signal RC c'est servo pas pwm

coté joystick il était plus simple de faire comme sur les engins chenillés (on est plus en 1930) à savoir un joystick commande avant arrière en Nord Sud et gauche droite en Est Ouest. Une seule main utilisée. Mais c'est sans importance.
 

dje8269

Senior Member
Si si , je ne voulais embrouiller encore plus .

toutes les précisons de ce que je rêve :

le joystick de gauche :
- mouvement haut/bas :
- mode conduite: pour avancer et reculer
- mode camera : commande tilt camera.

- mouvement droite/gauche
-mode conduite :aucun effet
-mode camera : pour piloter la camera en PAN

le joystick de droite :
- mouvement haut/bas :
- mode conduite : inutilisé
-mode camera : Zoom avant - zoom arriere

- mouvement droite/gauche
- mode conduite : pour faire pivoter le VHL , par accélération ou decceleration d'un cote ou de l'autre ou les deux
- mode camera : réglage du contraste ou luminosité ou sensibilité

Ce que je nommais feed back (tel que l'appelle dje) c'est le principe de retour en arrière .
Back-up ! mdr

Signal RC c'est servo pas pwm
Aie !!! mais ce n'est pas pareil ? les servos se pilotent en pwm non ? j'insiste car c'est important quand même. Depuis le début je considère que les moteurs se piloteront en PWM moi !

coté joystick il était plus simple de faire comme sur les engins chenillés (on est plus en 1930) à savoir un joystick commande avant arrière en Nord Sud et gauche droite en Est Ouest. Une seule main utilisée. Mais c'est sans importance.
Oui je me souviens nous avions deja parler de cette facon ! . un peu genre jeux vidéo, un seul pouce pour toutes la voiture . Mais question précision, ce n'est vraiment pas a la hauteur . Il est trés difficile d'avancer doucement et de tourner un peu par exemple .
 
Last edited:

PieM

Senior Member
Back-up ! mdr
Aie !!! mais ce n'est pas pareil ? les servos se pilotent en pwm non ? j'insiste car c'est important quand même. Depuis le début je considère que les moteurs se piloteront en PWM moi !

Oui je me souviens nous avions deja parler de cette facon ! . un peu genre jeux vidéo, un seul pouce pour toutes la voiture . Mais question précision, ce n'est vraiment pas a la hauteur . Il est trés difficile d'avancer doucement et de tourner un peu par exemple .
Back-up ? J'ai confondu sorry.
Par contre un joystick gauche qui fait un peu de conduite et un peu de camera, et un joystick droit qui fait un peu de caméra et un peu de conduite ne me semble pas très judicieux...
Et l'obligation de commuter des modes conduite/ caméra non plus. un stick pour la conduite et un stick pour la caméra me semblait plus conforme aux nécessités de la conduite.
Ma référence n'est pas les jeux vidéos mais des engins chenillés réels modernes. Mais chacun fait comme il le sent. Il est vrai qu'en utilisant des consoles de télécommande jouet amélioré on est dans un domaine un peu différent. Je parlais de vrais joysticks qui se manipulent avec les doigts et non avec un pouce...

Sur Picaxe les servos se pilotent par une commande servo depuis longtemps.
 

dje8269

Senior Member
Ma référence n'est pas les jeux vidéos mais des engins chenillés réels modernes. Mais chacun fait comme il le sent. Il est vrai qu'en utilisant des consoles de télécommande jouet amélioré on est dans un domaine un peu différent. Je parlais de vrais joysticks qui se manipulent avec les doigts et non avec un pouce...
Oui , j'ai hésité entre la télécommande "jouet" comme tu dis , et une pupitre de contrôle qui se pilote avec les doigts . J'ai opté pour la télécommande.
 

PieM

Senior Member
Petit rappel encore: le duty cycle d'émission en 869 MHz ne doit pas dépasser 10%.
Ce qui veut dire que si la période de transmission est de 50 ms, le temps total d'émission (conduite + télémesure) ne doit pas dépasser 5 ms . à 4800 bauds, cela mérite un petit calcul avant de se lancer dans de la programmation!
 

dje8269

Senior Member
Ok merci PieM . Je suis pour le moment loin d’être en mesure d'emettre quoi que ce soit , au vue de mes déboires a faire fonctionner mes transceiver ! lol
 

PieM

Senior Member
Ok merci PieM . Je suis pour le moment loin d’être en mesure d'emettre quoi que ce soit , au vue de mes déboires a faire fonctionner mes transceiver ! lol
Je crois que tu n'as pas compris l'enjeu !
si c'est destiné à un appareil que tu souhaites officialiser, voire commercialiser, ben c'est pas certain que tu puisses faire grand chose avec tes transceivers 500 mW compte tenu de la législation. Il serait bon que tu t'informes. On ne peut pas tout faire en bricolant par essais successifs.

Il existe des normes en matière d'utilisation des fréquences radio. Et au vu(rapide) de ta doc du transceiver qui ne possède pas d'étalement par saut de fréquence (FHSS) la limitation d'utilisation de ton engin sera de 6 minutes toutes les heures !
Cela résout le problème des batteries qui auront largement le temps de se recharger...
Et à 4800 bps de liaison radio, vu la longueur des messages (12 bytes plus les datas cde) dans un sens et dans l'autre (12 bytes plus les datas télémesure) pas certain que tu aies la réactivité souhaitée.
J'ignore sur quels critères tu a acheté ces transceivers, mais pas certain que cela ait été bien étudié... avant.
 

dje8269

Senior Member
si c'est destiné à un appareil que tu souhaites officialiser, voire commercialiser
Absolument pas . Je n'ai pas les prétentions d’être a ce niveau. Il s'agit d'un projet personnel, mais validé dans le cadre de mon emploi . ce qui me permet d'avoir quelques faveurs.

On ne peut pas tout faire en bricolant par essais successifs.
J'aimerais bien , faire un bon de 25 ans en arrière pour apprendre la programmation au lycée, et en faire mon métier . aurait tu cette machine à remonter le temps ? j'en profiterais aussi , pour me concentrer pendant les cours d'anglais, au lieu de faire le zouave .

Il existe des normes en matière d'utilisation des fréquences radio
Tu les connais certainement mieux que moi, et plierai ce projet en moins de temps qu'il me faut , pour transmettre un caractère avec ces transceivers, je n'en doute pas. Nous avions exactement la même problématique avec le proto. LE projet n'est pas forcement destiné a être employé sur le sol français, mais le sera pour les test je dois le confesser.

Tes remarques sont toujours constructives,et je les écoutent avec attention, mais a la longue , ça commence a ressembler à des reproches! Je sais bien , que je fais pas tous comme il faut , avec le matériel qu'il faut , avec les connaissances qu'il faut ;
 

jojojo

Senior Member
Il existe des normes en matière d'utilisation des fréquences radio. Et au vu(rapide) de ta doc du transceiver qui ne possède pas d'étalement par saut de fréquence (FHSS) la limitation d'utilisation de ton engin sera de 6 minutes toutes les heures !

Oui, Piem.

Et, pour que notre ami ne casse pas trop de matos, il est bon de savoir, que les fondeurs, se servent de ces normes, pour "gratouiller" les prix... Aussi !

J'ai longuement testé des module RADIOMETRIX TX3H869.

J'en ai tué 3.

Le duty était à 60%. Ils ne sont pas fait pour ça.

Avec une bonne ventilation (petit ensemble dissipateur-ventilo de PC), ils tiennent plutôt bien, à 50%. (en ai plus cassé, depuis).

Juste pour expliquer, que, même si l'on se fiche des réglements, il faut se méfier des DS.

On nous dit au début "500mW"

Et, en petit, à la fin de la doc, on nous dit "réglementation=10%" . Sans préciser, bien-sûr, que le matos N'EST PAS FAIT POUR DU 100%.

Bonne chance, Jeremy.
 

PieM

Senior Member
LE projet n'est pas forcement destiné a être employé sur le sol français, mais le sera pour les test je dois le confesser.
Alors à fortiori, il vaut mieux être dans les clous de la norme ! Quelle que soit la destination il y a une réglementation. maintenant si tu roules à 120 sur une route à 50 c'est ton problème et tu assumes.
Je suis désolé les normes ne sont pas faites d'aujourd'hui, et on en parle dans ta doc que j'ai pris un peu le temps de parcourir aujourd'hui. Alors il suffit d'aller sur Goo et de lire, c'est en français. Ce problème du duty en émission a déjà été évoqué lors du proto.
Et en plus la remarque de Georges est tout à fait judicieuse sur un plan purement technique.

Tes remarques sont toujours constructives,et je les écoutent avec attention, mais a la longue , ça commence a ressembler à des reproches! Je sais bien , que je fais pas tous comme il faut , avec le matériel qu'il faut , avec les connaissances qu'il faut ;
J'ai déjà dit ce que je pensais de l'approche qui était faite. Le principe d'acheter a priori du matériel sans prendre la peine de calculer quelques trucs ou de lire une doc, ne date pas d'aujourdh'ui.
Tu veux transmettre des infos et avoir de la réactivité ? Vous n'avez même pas encore évalué la teneur des messages, donc leur longueur donc la durée nécessaire à 4800 bauds. Mais il n'y aurait pas de problème parceque le transceiver sait tout faire en même temps ?
Maintenant puisque c'est plus des reproches qu'autre chose, je n'insiste surtout pas.
Si les gens se jette systématiquement à l'eau sans savoir nager, sous prétexte qu'ils n'ont pas appris quand ils étaient petits, c'est pas mon problème.

Pour être plus précis:

4800 bps, c'est 436 bytes par seconde.
si tu veux une période de transmission de 50 ms ça fait 22 bytes par message.
Sachant qu'un message est composé, outre les datas, de préambule et checksum soit 12 bytes de plus (dixit la doc) il reste 10 bytes transmissibles sans incident de parcours...
et la il n'a même pas le temps de recevoir les infos de la télémesure et fonctionne à 100%.
 
Last edited:

dje8269

Senior Member
Quelle que soit la destination il y a une réglementation.
Non
si tu roules à 120 sur une route à 50 c'est ton problème et tu assumes.
Parfaitement

J'ai déjà dit ce que je pensais de l'approche qui était faite
Oui c'est moi qui l'est faite ! elle est pourrie , elle est pourrie ..... Je ne travaille pas dans un bureau d’étude technique !! on ne peut pas avoir tous la même approche que toi, les même sconnaissance et les mêmes outils!

Le principe d'acheter a priori du matériel sans prendre la peine de calculer quelques trucs ou de lire une doc
C'est toujours le serpent qui se mord la queue ! . je ne comprends pas trop l'anglais technique, je ne suis pas a crack en programmation ou en électronique, alors je suis incapable de décrypter une DS, au point de savoir choisir tel ou tel composant. Alors je fais quoi ? je te le demande , je fais quoi ?
Je vous demande ce que je dois acheter? et vous me direz que cous êtes pas la pour faire mon travail et vous aurez raison. Et après, tu va me demandé, les infos qu'il faut envoyer ,le débit, la vitesse etc ..... je vais te dire que j'en sais rien, ça dépendra du module ...... Soit on fixe un module et on fais avec ce module en choisissant ce qu'on peut en faire . soit on choisis ce qu'on veut faire , et après on choisis un module . cette dernière solution la mieux , mérite de savoir , comment faire ce que l'on souhaite faire . moi je sais ce que je veux faire, mais je sais pas comment y arriver .

Résultat des courses, je peux pas choisir de module, car je sais pas comment faire . Donc on fait rien , donc fin du projet ;
Grâce a vous tous, j'ai fais un truc génial avec des modules radiometrix . Alors j'ai pris le niveau du dessus, en regardant les caractersitques générales, que je pouvais comprendre. Je croyais bien faire , apparemment non .

Tu parle de 4800 bauds , mais il me semble , que ce module peut aller bien au delà ! non ? je dois me tromper certainement .

Si les gens se jette systématiquement à l'eau sans savoir nager, sous prétexte qu'ils n'ont pas appris quand ils étaient petits, c'est pas mon problème.
Oui c'est vrai, il faudrait que de tres bosn nageurs, pour nager . les autres non pas le droit d'essayer et de patauger au bord . soit on est bon , soit on ferme sa bouche ?

Je sais plus quoi dire , et je sais pas si je me suis fais comprendre! je suis dégouté de ta réaction

Voila je suppose qu’après ce message, tu ne participera plus , je suis dégouté, mais J'assume ! mais vouloir du professionnalisme et l’élitisme de la part d'amateur passionné , et les engueuler car il font mal, c'est pas sport du tout !

Ces modules j'ai pas trouvé mieux!
 

BESQUEUT

Senior Member
Ce qui me semble essentiel, c'est de mesurer la période réellement nécessaire pour maintenir une réactivité acceptable.
On sait a peu prêt à quelle fréquence on émet les trames.
On ne sait pas combien de trames sont ignorées à la réception.
On n'a jamais fait d'essais en aveugle pour savoir à partir de quand l'opérateur se rends réellement compte que c'est "mou".
En réfléchissant un peu, on peut se contenter de 4 ou 5 octets pour le pilotage, et si on a 20 octets de télémesure à retourner, on peut ne le faire que toutes les 10 trames, soit en moyenne 2 octets par trame. Je pense qu'on doit passer avec 22 octets/trames tout compris, un poil moins en réfléchissant beaucoup.

Les chiffres de PieM signifient également, qu'on a 20 trames/s avec un duty proche de 100%
10 trames/s à 50 %
5 trames à 25 %
4 trames à 20%
2 trames à 10%
1 trame à 5%
C'est sur que c'est très limite, mais je voudrais bien connaitre le ressenti pilote autour de 2 à 4 trames/seconde.

Pour ce qui est de l'échauffement, outre le ventilateur, on peut baisser la puissance quand les conditions sont favorables, ou faire un compromis :
- grosse puissance mais duty cycle faible,
- plus de duty cycle mais moins de puissance
 

BESQUEUT

Senior Member
Remarques suite à la mise à jour des schémas au #1

Pour les 2 schémas :
Même pour le bus I2C, indiquer dans quel sens vont les données et de où à où, et qui a l'initiative (le Master donc).
Si des données vont dans les deux sens, mettre différentes flèches avec un numéro pour chaque.
Mettre aussi un numéro sur les PWM, TOR et autres SERVO puisqu'il y en a plusieurs par schéma.
Il faudra probablement un µ dédié à la gestion de l'énergie., et même un par batterie.
Faire un tableau à part indiquant pour chaque flux :
- la nature des infos transmises,
- la taille de chaque trame,
- la fréquence.

Véhicule :
Les encodeurs vont sur le µN°12 et non sur le N°10.
De quoi s'agit-il ? (Uniquement compteur ou bien compteur et sens ?)
La nacelle est en SERVO et non en PWM.
Pourquoi faire transiter les commandes Nacelle, TOR, ETC... par le µ12 alors que c'est le µ10 qui a l'info ?
Pour moi c'est le µ10 qui fait ce travail.


Télécommande:
Le µN°2 ne peut avoir qu'un seul bus I2C( mais la représentation est bonne, sauf la flèche à double sens Flux N°3 : ce sont 2 flux différents)
Le gyro produit des donnés ; donc il devrait les envoyer au µN°1
Le cadre "Menu" est géré par le µN°3 ou par l'écran graphique suivant la solution retenue.
De même pour le buzzer.
A quoi servent les inters et potars reliés au µN°2 (hors cadre Menu) ?
 
Last edited:

BESQUEUT

Senior Member
Suite du #138 : optimisation de la bande passante.

Outre les remarques faites sur les possibilités du transceiver de changer de fréquence,
il est sans doute possible d'optimiser l'utilisation de la bande passante en optant pour un débit à taux variable sur le flux de pilotage qui est le plus contraignant :
- au cas d'inaction sur les joystick, se contenter de quelques trames/s pour que lien reste "valide"
- dès action, envoi immédiat et avec un débit plus soutenu pour maintenir une bonne réactivité.

Vu l'usage envisagé, ce mode de fonctionnement permettrait en moyenne une utilisation raisonnable de la fréquence.
 

dje8269

Senior Member
qui a l'initiative (le Master donc).
Je ne suis pas trop en mesure de savoir encore qui sera master, même si je penche pour les 28X2 ou 40X2 dans les deux cas.

Mettre aussi un numéro sur les PWM, TOR et autres SERVO puisqu'il y en a plusieurs par schéma.
On ne sait pas combien il y en , je pense que ca alourdi trop le schéma .

Les encodeurs vont sur le µN°12 et non sur le N°10.
Oui les infos ne sont pas prioritaire

De quoi s'agit-il ? (Uniquement compteur ou bien compteur et sens ?)
Je ne sais pas . j’espère les deux, mais pour le sens on aura l'info moteur pour le savoir

Pourquoi faire transiter les commandes Nacelle, TOR, ETC... par le µ12 alors que c'est le µ10 qui a l'info ?
Car le µ10 traire les infos prioritaire seulement

Le gyro produit des donnés ; donc il devrait les envoyer au µN°1
Information non prioritaire , traité en amont par le µ2

Le cadre "Menu" est géré par le µN°3 ou par l'écran graphique suivant la solution retenue.
Exact on ne sait pas encore

A quoi servent les inters et potars reliés au µN°2 (hors cadre Menu) ?
A activer des options Hors menu .

MaJ de l'organigramme effectué

Sans titre3.png
 

BESQUEUT

Senior Member
Je ne suis pas trop en mesure de savoir encore qui sera master, même si je penche pour les 28X2 ou 40X2 dans les deux cas.
Il faut faire un choix, en particulier pour la télécommande, puis vérifier que ça marche pour tous les flux. Si pas bon, inverser Master et Slave et recommencer...
Oui les infos ne sont pas prioritaire. Je ne sais pas . j’espère les deux, mais pour le sens on aura l'info moteur pour le savoir[
Si on utilise l'info de commande moteur, il faut prévoir un flux de µ10 vers µ12.
Si encodeur quadratique, il faut un µ dédié, et ce sera aussi nécessaire si le comptage est à haute fréquence.
Car le µ10 traire les infos prioritaire seulement
C'est µ10 qui a l'info et il devra passer du temps pour la mettre à disposition de µ12. Autant utiliser ce temps pour piloter directement ce qui doit l'être et simplifier les flux !
Information non prioritaire , traité en amont par le µ2
Même problème : µ1 devra de toutes façon passer du temps pour gérer cette info. Autant simplifier et libérer du temps pour µ2.
Exact on ne sait pas encore
Oui, mais on sait que ce n'est pas µ2.
A activer des options Hors menu .
Serait-il possible de savoir à quoi vous pensez ?

Sur le schéma télécommande, séparer les flux 3a et 3b
Flux télécommande :
Flux 1a : il faut se donner des bornes. je dirais : variable (suivant action sur les joystick) entre 2/s et 20/s
Flux 1b : il faut se donner un ordre de grandeur : je dirais 2 octets pour simplifier le traitement à la réception, variable avec un maxi à 2/S
Flux 2 : 6 octets toutes les s
Flux 3a : quoi ?
Flux 3b : quoi ?

Flux 4 : Attitude et direction du véhicule (issue de l'accéléromètre et du compas)
Trace du véhicule issue du GPS,
NRJ coté véhicule et coté télécommande
Niveau de réception HF dans chaque sens ?
Autres ?

Flux 6 : devrait être sur µ1 : 2 octets 2 fois/s

Le µ2 ne pourra pas gérer l'énergie en direct. Il faudra prévoir un flux (I2C ou //) pour allez lire l'info sur le µ NRJ.

Flux 10a : variable (suivant action sur les joystick) entre 2/s et 20/s
Flux 10b: 2 octets , variable avec un maxi à 2/s

Flux 11a : inutile : µ10 ne passera pas plus de temps à faire le travail directement.
Flux 11b : Quoi ? et de toutes façon µ10 ne transmet rien !

Flux 12 : 1 octets/s maximum, soit une vitesse maxi de 11 km/h avec une précision de 40cm, ou 2 o/s pour une précision de 4cm jusqu'à 14 km/h
Flux 13 : Vous pensez sans doute à l'attitude : accéléromètre et compas. Disons 3 octets/s

Flux 14a : µ10 est normalement en esclave I2C. Je propose une bascule en mode Fail-safe par une sortie TOR du µ10
Dans ce cas µ12 libère le bus, pour que µ10 puisse aller lire les données EEPROM
Ca ne peut pas marcher : µ10 ne saura pas où est le dernier octet écrit.
Donc, c'est µ12 qui garde l'info dans sa RAM ou son EEPROM, et qui pousse les données vers µ10.
µ10 sait qu'il doit traiter les données I2C esclave car il est en mode fail-safe.
En mode normal, µ12 n'écrit jamais sur µ10 pour éviter de perturber la réception des données, le PWM, le SERVO, etc...

Flux 14b : la flèche part de µ12. 1 octet/s maximum ; même pour 1 minute, pas besoin d'EEPROM externe ?

Manque le flux NRJ.
 
Last edited:

dje8269

Senior Member
Je vais essayer de répondre dans l'ordre . Mais croyez que c'est pas évident , et que ca ressemble a du travail de professionnels pour moi a ce niveau la .

Je pense qu'il faut trouver le compromis entre simplicité et efficacité .

Simplicité deja, avec le gestion de l'energie qui se feras tout simplement, sans µC dédié pour le moment .

Il faut faire un choix, en particulier pour la télécommande, puis vérifier que ça marche pour tous les flux. Si pas bon, inverser Master et Slave et recommencer...
Ce sera donc le coeur du systeme qu iser maitre , donc µ12 et µ2 .

Si on utilise l'info de commande moteur, il faut prévoir un flux de µ10 vers µ12.
Il y est: 11a
Si encodeur quadratique, il faut un µ dédié, et ce sera aussi nécessaire si le comptage est à haute fréquence.
lien vers moteur avec encodeur
"It has an integrated 48 CPR quadrature encoder on the motor shaft, which provides 3592 counts per revolution of the gearbox’s output shaft"

Je suppose donc q'uil faudra un µC dédié . je pense donc oublié cette option ! . Un µC pour seulement connaitre le nombre de tour de roue, je ne le souhaite pas . Ça restera tout de même dans un coin .
C'est µ10 qui a l'info et il devra passer du temps pour la mettre à disposition de µ12. Autant utiliser ce temps pour piloter directement ce qui doit l'être et simplifier les flux !
Le je ne suis pas d'accord avec vous . µ10 reçoit les infos, car en Hard c'est lui qui sera câblé sur le Tx du transceiver , mais : 1 il traite les données prioritaire et dans un second temps il met a dispo les données ; ce n'est pas a lui de faire des calculs sur ces données, si calcul il y a u mise a l'echelle ou je ne sais quoi d'autre, mais a µ12 . Le taches sont ainsi séparées , facilitant la compréhension , le débogage et la fiabilité .

Même problème : µ1 devra de toutes façon passer du temps pour gérer cette info. Autant simplifier et libérer du temps pour µ2.
Pareil qu'au dessus, je rajouterais que ce n'est pas a µ2 ou à µ12 d'avoir du temps de liberer mais bien l'inverse ; car ce sont des taches secondaire !

Serait-il possible de savoir à quoi vous pensez ?
Je pensais faire des réglages via le menu, mais certaines commande doivent être plus pratique; et notamment pouvoir s'allumer ou s’éteindre ,sans enlever les lunettes d’immersion . comme l'allumage de la vidéo, la position observation, ou 'l’allumage de phare .
Les réglages menus je les voyaient plus pour la luminosité, le sound , les trims des choses dans ce genre .

Flux 1a : il faut se donner des bornes. je dirais : variable (suivant action sur les joystick) entre 2/s et 20/s
Oui bonne idée

Flux 1b : il faut se donner un ordre de grandeur : je dirais 2 octets pour simplifier le traitement à la réception, variable avec un maxi à 2/S
Je rajoute qu'en temps normal , deux octets pour les TOR c'est bien . mais il y a aussi les valeurs du Head tracker si celui est activé . il faudra donc en rajouter 2 de plus ( haut/bas , droite/gauche)
Flux 3a : quoi ?
Flux 3b : quoi ?
3a : écriture de la valeur des TOR a envoyer, car µ1 ne fait que envoyer les infos qu'on lui fournis toutes machées .
3b : récupération des infos , sur la valeurs des joystick pour savoir si il sont au point mort ou non , permettant l'allumage d'une led ! par exemple . et également des trims. pour affichage

Niveau de réception HF dans chaque sens ?
je comprends pas ! la réception est la même dans les deux sens ! a voir

Flux 6 : devrait être sur µ1 : 2 octets 2 fois/s
Infos non prioritaires a traiter par µ2 et ensuite mettre à disposition pour µ1

Flux 11a : inutile : µ10 ne passera pas plus de temps à faire le travail directement.
Flux 11b : Quoi ? et de toutes façon µ10 ne transmet rien !
Pas d'accord . µ10 dois seulement gerer les moteurs et mettre les données a dispostion pour que µ12 viennent les récuperer . toujours dans le principe de priorité de travail . l'un gere la priorité l'autre tous le reste .

1 octets/s maximum, soit une vitesse maxi de 11 km/h avec une précision de 40cm, ou 2 o/s pour une précision de 4cm jusqu'à 14 km/h
Ok

Flux 14a : µ10 est normalement en esclave I2C. Je propose une bascule en mode Fail-safe par une sortie TOR du µ10
J'ai pas compris

Flux 14b : la flèche part de µ12. 1 octet/s maximum ; même pour 1 minute, pas besoin d'EEPROM externe ?
Ca depend non? de ce que l'on enregistre ! coordonées gps vitesse , direction valeur moteur, sens moteur etc ...
 

dje8269

Senior Member
Le dossier de spécifications détaillée devient ingérable sous forme de post.
Pas que sous forme de post . Je perd le fil petit a petit , et surtout je perd le gout ! .

Pour moi c'est trop professionnel et perfectionniste , je n'ai pas l'habitude.

Ne le prenez surtout pas comme une critique , bien au contraire, mais je suis hors des clous.Ppour moi c'est comme si me me demandiez le nombre de parpaings exacts qu'il faut pour construire une maison. Moi je me fais livrer des palettes entières et je vais au résultat, s’il en manque je réduis la surface, si y'en a trop, ben je laisse de coté. Je ne recherche pas la rentabilité ou la productivité, mais le plaisir de construire un truc qui tiens la route, sans forcement être parfait.

Je conçois parfaitement qu'il faille une architecture générale , mais pas aussi poussé dans les détails. on va rencontrer des problèmes, c'est sur ! et tout ce travail sera réduit à néant. A la base je voulais votre avis sur la faisabilité et surtout sur l'interopérabilité des différentes communication entre µC . Par exemple le fait de savoir que le SPI et l'I²C utilise les même broches comme la signalé PieM, et donc ne peuvent pas travailler ensemble. Ou encore votre idée de différencier l’émission de la réception !.

Mais au contrario ,De mon point de vue je ne vois pas l’intérêt d'avoir une trame de 2 octets , tout en sachant que le module devra en envoyé 7 ou 8 octets.

J'ai surtout l'impression de travailler plus à votre manière, que la mienne; Je sais que c'est vous qui êtes dans le vrai , mais pour un truc de pro , pas un truc d'amateur comme moi.
 

le belge

Senior Member
Salut ,

je vois que tu lances dans un super projet !

en tous cas , tu peux être fier de toi car tu es persévérant .... tu apprends au fur et à mesure , même si parfois vous ne vous comprenez pas (ce n'est pas évident car de clavier à clavier , on ne parle pas de la même manière)

Ne baisse pas les bras ... souvent , il faut prendre un peu de recul pour pouvoir mieux repartir !!!!!

Mike
 

dje8269

Senior Member
je vois que tu lances dans un super projet !
Oui un de plus, mais celui la prend du plomb dans l'aile !

en tous cas , tu peux être fier de toi car tu es persévérant .... tu apprends au fur et à mesure , même si parfois vous ne vous comprenez pas (ce n'est pas évident car de clavier à clavier , on ne parle pas de la même manière)
Merci ca fait plaisir , en tout cas .
Malheureusement je crains que sans PieM et BESQUEUT , ça tombe à l'eau . Il est effectivement, très très délicat de partager et de confronter des idées par clavier interposés . Je dirais même, que les compétences changent completement la vision des choses, se qui rend les choses plus complexes . Ce qui aprait évident pour l'un, est incompréhensible pour l'autre !.
 

PieM

Senior Member
Hello PieM,
268 posts mais à priori il semblerait que les transceivers fonctionnent ?


Oui la liaison fonctionne, même si je n'en ai pas encore compris toutes les subtilités.

Alors il me semble qu'avant de savoir s'il faut mettre 2 bytes ou 3.5 par trame , il serait urgent de connaître assez précisément le timing réel des µC en émission , donc les traitement qu'ils ont à faire, et quelles sont les fenêtres d'émission libres pour le copain.
Donc il faut savoir de façon précise ce qui est associé aux commandes prioritaires en acquisition d'info, en traitement, en commandes.
Donc chaque info doit faire l'objet d'une réflexion sous forme d'organigramme.
par exemple la commande moteur:
elle part d'une position de joystick:
elle arrive sous quelle forme au drivers moteur, et après quel traitement.
ou se fait le traitement? au départ , à l'arrivée?
donc quelle est l'info transmise par RF.


En fait tout ça , c'est la partie, du "pourquoi" j'ai ouvert l'autre post . Car je ne sais pas le dire, c'est pour ça que je fais appel à vous ! Je peux essayer de vous donner toutes les infos dont vous avez besoin, mais une telle réflexion en avance, n'est pas de mon niveau.

Moi Jérémy qu'est ce que je sais ? ( certes pas grand choses) . Que Je dois transmettre des infos d'un point A vers B et de B vers A . Je ne connais pas ces infos, car le projet dans sa globalité est énorme( pour vous dire je croyais que les moteurs se pilotaient en PWM bref! :eek: ). Il faudrait connaitre chaque fonctions pour savoir ce qu’elles doivent/peuvent transmettre, pour les collationner. Chaque fonction mérite presque un post à elle seule . Mais que va--il se passer une fois qu'on aura déterminer tout le sinfos , et qu'on va se rendre compte qu'il faudrait peut être savoir si le transceiver va pouvoir les transmettre ou non ?

Une fois le résultat obtenu, il faudra savoir ce que peux transmettre le transceiver ? certains diront qu'il font savoir ce que peux transmettre le transceiver et adapter les infos en fonction. ( moins cohérent a mon avis)

Voila ma vision , c'est le serpent qui se mord la queue ( pour moi tout du moins, je me doute que pour vous c'est clair) . Donc il faut prendre un point de départ à un moment ou à un autre . Les transceiver , j'ai l'avantage de les possédés. Alors commencé a les manipuler a connaitre leur performances etc , ne me parait pas loufoques, qu'il faille transmettre 2 bytes ou 16, au moins on aura une idée des capacités .

Par exemple: je ne sais pas qui doit traiter l'info. C'est à moi de poser la question lol.
D’après vous ou doit on traiter l'info ? Comment vous y prendriez-vous vous ?

Le proto reste ma seule expérience, et l'info était traiter sur le VHL . les valeurs enregistrer dans l'EEPROM pour le back -up était brutes , et lors de la restitution, venant simplement en remplacement des valeurs recues en RF, il avait donc un traitement a subir avant d’être envoyés au moteur .
En fait tu viens de faire penser à un truc, mais ça n'as pas ça place dans ce post mais sur l'autre .

A tu vu les organigrammes ICI à la fin du post
Bon je continue ici
Le projet c'est quoi :
Je veux faire un engin qui se pilote
ou bien
J'ai un transceiver, qu'est ce que je peux faire avec.

Il faudrait connaitre chaque fonctions pour savoir ce qu’elles doivent/peuvent transmettre, pour les collationner. Chaque fonction mérite presque un post à elle seule . Mais que va--il se passer une fois qu'on aura déterminer tout le sinfos , et qu'on va se rendre compte qu'il faudrait peut être savoir si le transceiver va pouvoir les transmettre ou non ?
Eh ben oui !
parce que déjà que c'est pratiquement hors des clous rien que pour les infos mini nécessaires à la conduite, je vois mal la somme de gadget déjà listée dans ce projet.

Ex: Commande moteur: il faut voir la DS en détail!
3 modes de commandes possibles
ana , servo, UART
tu peux faire de l'ana avec un pwm
qu'est ce qui demande moins de traitement et qui est le plus transparent pour un picaxe ?
Il faut savoir que tu as un mode mixte qui te permet de rentrer directement l'info vitesse et l'info direction. C'est le driver qui fait le boulot du calcul différentiel de vitesse. Toujours ça de gagné. à tester. Sur ton schéma tu mets des trims : ils agissent sur quoi ?
Tu as sur les drivers une sécurité batterie Lithium cutt-off. peut être intéressant de récupérer l'info qui fait partie aussi des choses prioritaires de sécurité. à tester

Toujours dans les commandes prioritaires:
le Backup: ouvrir un sujet à part! car rien que vos histoires de GPS - encodeurs etc c'est pas clair.
- enregistrer des coordonnées GPS et faire ensuite un calcul de trajectoire avec un picaxe, je demande à voir!
- quant à faire du décodage en quadrature à plusieurs kHz, je demande aussi à voir.
- travailler en odométrie, c’en est une autre.
Donc beaucoup de travail préliminaire avant de compter les octets et les pattes des picaxes...
 

dje8269

Senior Member
Le projet c'est quoi :
Je veux faire un engin qui se pilote
ou bien
J'ai un transceiver, qu'est ce que je peux faire avec.
:D un mix des deux. je voudrais piloter un VHL avec ce transceiver !

Je suis conscient, que d'un point de vue "professionnel", il faille prendre en compte la totalité des contraintes , avant de réfléchir à la meilleure solution à adopter. Mais envisager tel ou tel choix, implique la compréhension des problèmes que l'on va rencontrer, on optant pour tel ou tel option.
C'est en ce point précis, ou je suis incapable d'avoir une vision, et c'est pile poil en ça , ou vous êtes fort !.

En prenant en compte la partie humaine du projet et en me connaissant, je dois aussi prendre en compte la motivation et intéressement, afin d’être performant et de garder une dynamique.

Si la barre est trop haute, ça décourage, surtout quand il n'y a pas forcement besoin de haut niveau . Un exemple parlant, l'estimation de la batterie, ma complétement retourné. Je préfère un truc grossier mais que je comprenne, plutôt qu'une usine à gaz , efficace , mais à laquelle j'aurais fournis énormément d'effort, pour ne comprendre que les grandes lignes.
Mettre un µC par batterie me parait hors de portée. il s'agirai d'avoir une estimation grossière. exactement comme sur nos téléphones ; il peut marquer 90% , maintenant, si vous cherchez le réseau en permanence , en jouant à un jeu avec la luminosité de l'écran a fond, ne veut pas dire que vos 90% vont pas s'effondrés en 30minutes, alors que vous auriez eu plusieurs heures de communications. c'est exactement pareil, on avait tant au départ, on a dépensé tant donc il nous reste tant . c'est grossier et la , l’expérience parlera d'elle même.

L'idéal pour moi , serait d'avancer au fur et à mesure, pas à pas, fonction par fonction. Mais en ayant une idée global des problèmes que l'on va rencontrés grâce à vous , sans rentrés dans les solutions pointues;

Je sais que c'est difficile pour vous, voir même inconcevable ! :p

En gros je vous demande de me faire avancer tout en prévoyant les futurs problèmes à lequel on va se confronter.

Par exemple, on sait qu'on va voir pas mal d'infos à envoyer, donc on sait qu'on ne va pas partir sur 3 octets , partons plutôt sur un grand classique de 8 octets . On verras par la suite ce qu'on peut y mettre , et comment les mettre ou les dispatcher, s'il faut plusieurs trames ben on fera en sorte de diminuer la réactivité ou d’augmenter le débit ou les deux , on s’adaptera comme on a toujours fait !.

en gros on fait rouler le VHL, ensuite on travaille sur la perte de com, ensuite on lui rajoute un GPS , ensuite un gyro , ensuite un back-up etc ...... Avançons étape par étape, en ayant une idée de la prochaine, sans forcement essayer de la résoudre . sauf , si cela est évident bien sur !

Certains choix aujourd'hui, engendrerons surement les soucis de demain.

Il faut savoir que tu as un mode mixte qui te permet de rentrer directement l'info vitesse et l'info direction. C'est le driver qui fait le boulot du calcul différentiel de vitesse.
C'est exactement ce genre de phrase, que j'adore. cette phrase résume exactement le besoin que j'ai et c'est ce qui fais que sans vous j'irai pas loin . je me répète mais je croyais que les moteurs se pilotaient en pwm moi !! Donc je part tête baissée et toi tu me la relève en me disant " Hé garçon, tu peux les commander comme ça plutôt tes moteurs, ça t'évitera de faire des calculs a tes µC". Moi je vais partir vers la solution la plus simple et la plus compréhensible, mais pas forcement la plus adéquate, et c'est la ou vos interventions sont vitales pour moi !

Voila , j’espère que vous y voyez clair dans ma façon de voir les choses, même si elle est l'opposé de la vôtre. Pour moi , il ne m'est pas possible de vous dire le nombre d'octets dont j'ai besoin , car je n'ai même pas acheter de module GPS par exemple, je sais encore moins comment ça fonctionne, et encore moins les infos que ça renvoie . Vous comprendrez que j'aurais du mal a vous dire le nombre d'octets.

Si vous arrivez à avoir une idée, de part vos expériences perso ou pro , moi je suis tout ouvert à tous . Mais il ne faut pas me demandé d'avoir les mêmes visions que vous . je me base seulement sur mes maigres connaissances et ma maigre expérience du proto .

Donc d’après vous est ce que l'architecture faite en #1 tiens la route ?

Un savoir un picaxe s'occupant de transmettre les infos en UART et de s'occuper de la gestion des commande moteurs qui sont prioritaires a envoyées en RF ?
Un picaxe ou autres gérant l'affichage sur écran
Un enfin un dernier pour gerer tout le reste et envoyé des infos, au picaxe qui doit les envoyé au transceiver.
 

PieM

Senior Member
:D un mix des deux. je voudrais piloter un VHL avec ce transceiver !
je ne trouve rien de drôle à cela; car de ce qui était peut être une solution technique tu as réussi à en faire une contrainte peut être insurmontable.

en gros on fait rouler le VHL, ensuite on travaille sur la perte de com, ensuite on lui rajoute un GPS , ensuite un gyro , ensuite un back-up etc ...... Avançons étape par étape, en ayant une idée de la prochaine, sans forcement essayer de la résoudre .
Tiens le backup est devenu accessoire, après le GPS et un "gyro" ?
Alors fais rouler ton VHL....
et tu rajouteras tes gadgets au fur et à mesure, si tu peux, meilleur moyen pour arriver à une usine à gaz !.

Pour moi , il ne m'est pas possible de vous dire le nombre d'octets dont j'ai besoin , car je n'ai même pas acheter de module GPS par exemple, je sais encore moins comment ça fonctionne, et encore moins les infos que ça renvoie
Je m'en fous du nombre d'octets. Mais j'aurais souhaité que la décision de mettre un GPS (solution technique) soit autre que celle de faire joli!

Personnellement je ne vais pas passer mon temps à lire des dizaines de pages de docs en fonction de ton inspiration du moment. Désolé, je ne vais pas passer à plein temps sur ce forum.

Tu ne veux pas suivre un minimum de démarche constructive, libre à toi, mais n'accuse pas les autres de baisser les bras.
J'ai l'impression que rien ne s'est passé depuis le premier proto!
 

dje8269

Senior Member
Tiens le backup est devenu accessoire, après le GPS et un "gyro" ?
Non ce n'est pas ce que j'ai voulus dire ! le back-up, le gps et le gyro ne sont pas accessoire ! Je voulais dire, qu'on commence par faire rouler le VHL , une fois qu'il roule , on rajoute le GPS comme il roule se sera plus facile pour les test , puis une fois finis on rajoute le gyro etc... étape par étape ; petit à petit quoi .

Je m'en fous du nombre d'octets. Mais j'aurais souhaité que la décision de mettre un GPS (solution technique) soit autre que celle de faire joli!
Encore une fois je ne comprends pas ta réaction ..... Il n'a jamais été question de remettre en cause l'utilisation du GPS . Il m'est indispensable pour connaitre la position GPS du VHL , sa trace , sa vitesse et sa direction.
Tu ne veux pas suivre un minimum de démarche constructive, libre à toi, mais n'accuse pas les autres de baisser les bras.
Apres un cahier des cdc fournis, un organigramme fourni, vraiment je comprends pas , dis moi clairement ce que tu attends de moi , car la , je suis perdu ?

Tu me renvoie dans les cordes à chaque fois . S'il te plait , dis moi ce que je dois faire , et je le ferais , je peux pas te dire mieux que ca !
 

PieM

Senior Member
S'il te plait , dis moi ce que je dois faire , et je le ferais , je peux pas te dire mieux que ca !
C'est une blague ?
Mais non tu fais ce que tu veux depuis toujours c'est différent.
Quand on veut réaliser quelque chose de compliqué on ne se lance pas sans un minimum de méthode.
Chose que tu as toujours refusée.

tu passes ton temps à acheter des composants sans savoir a quoi ils servent et après tu te demandes ce que tu peux en faire.
Le GPS comme ton gyro comme ton transceiver sont des moyens techniques, pas une fin en soi.
Il n'a jamais été question de remettre en cause l'utilisation du GPS
Et bien c'est un tord!
Le gps c'est pour quoi faire :
la position ? à 3m - 5m près ?
sa trace à 3m près au mieux pour faire quoi ?
sa vitesse pour quoi faire donc avec quelle précision ? pourquoi avec le GPS
sa direction (par rapport à quoi ?!)avec quelle précision ? pourquoi avec le GPS
Il n'y a pas besoin d'acheter un GPS ni de faire rouler ton engin pour savoir les données produites, les calculs à faire, etc...
Encore faut-il connaître l'objectif.
Le Gyro (CMPS11)? pour quoi faire ?

Comme il n'était pas besoin d'acheter des codeurs moteurs pour savoir que tu ne pourras pas les utiliser avec les picaxes.
Alors quelle solutions pour le backup ? c'est vraiment gênant d'y réfléchir avant ?

et tout ça tu l'intègres après coup dans ton système sans état d'âme ? ou tu comptes sur les autres pour se dém.... avec?
Un projet comme ça n'est pas un Légo dans lequel on achète les briques les unes après les autres.

Je t'ai dit que je n'allais pas passer mon temps sur ce forum. Tout fini par lasser et je pense que nombreux sont ceux qui auraient déjà jeté l'éponge.
Je ne connais pas un seul forum ou un sujet ait réunis autant de posts que sur tes appareils.
 

dje8269

Senior Member
Mais non tu fais ce que tu veux depuis toujours c'est différent.
Quand on veut réaliser quelque chose de compliqué on ne se lance pas sans un minimum de méthode.
Chose que tu as toujours refusée.
La messe est dite !

Et bien c'est un tord!
Ah..... ok.... bon ! je vois pas trop comment connaitre la position GPS du VHL, sans GPS ( spécifié dans le CDC)

la position ? à 3m - 5m près ?
Oui c'est déjà bien 3/5m

sa trace à 3m près au mieux pour faire quoi ?
Pour pouvoir le récupérer si c'est possible; pour pouvoir le situer sur une carte, pour pouvoir connaitre la distance parcouru ou la distance nous separant a vol d'oiseau par exemple

sa vitesse pour quoi faire donc avec quelle précision ? pourquoi avec le GPS
J'avais envisagé de connaitre sa vitesse, pour modifier ses réactions en fonction de sa vitesse justement. Il manquait un tel capteur sur le proto.

sa direction (par rapport à quoi ?!)avec quelle précision ? pourquoi avec le GPS
Sa direction, par rapport au Nord ! pas beaucoup de précision , je ne pourrait pas la quantifier ( 30°) ca me suffirait, pourquoi pas avec le GPS le probléme avec le GPS c'est que le VHL devrait etre obligé d'avancer pour connaitre sa direction! c'est pour ca , que je préférerais la connaitre avec une boussole compensée . mais ce n'est qu'une suggestion .

Il n'y a pas besoin d'acheter un GPS ni de faire rouler ton engin pour savoir les données produites, les calculs à faire, etc...
Tu parle pour toi la ! pour moi j'en ai besoin, une Ds en anglais lme laisse avec beaucoup trop de doute et d'interrogations

Le Gyro (CMPS11)? pour quoi faire ?
Connaitre le devers ou une pente

Comme il n'était pas besoin d'acheter des codeurs moteurs pour savoir que tu ne pourras pas les utiliser avec les picaxes.
Tu parle pour toi encore ,moi je le savais pas . maintenant oui

Alors quelle solutions pour le backup ? c'est vraiment gênant d'y réfléchir avant ?
Si je me souviens bien avec le proto, c’était pas faisable , et je partais en vrille. Pourtant le résultat obtenu est pas trop mal . il suffisait largement à me dégager d'un obstacle en cas de perte de com . je me dis qu'avec les capteurs que l'aurais a bord je pourrais faire certainement mieux ce coup . mais si ca va pas je ferais comme sur le proto, y'a pas de problème.

et tout ça tu l'intègres après coup dans ton système sans état d'âme ?
sans état d'âme ! comme je ne sais pas faire autrement, jefais comme ca .

ou tu comptes sur les autres pour se dém.... avec?
Ca c'est petit .

Je t'ai dit que je n'allais pas passer mon temps sur ce forum.
Mais je te l'ai pas demandé, tu es libre ...et tu peut intervenir quand bon te semble . tes interventions sont précieuses pour moi et ce sera beaucoup plus difficile sans ....

Tout fini par lasser et je pense que nombreux sont ceux qui auraient déjà jeté l'éponge.
tu as entierement raison

Je ne connais pas un seul forum ou un sujet ait réunis autant de posts que sur tes appareils.
Bon ben désolé de polluer le forum ;
 

chimere322

Senior Member
Bonjour Jeremy,
que nombreux sont ceux qui auraient déjà jeté l'épong
Il suffit de regarder tous les post depuis 2013 pour comprendre qu'il y en a que pour toi et ton espèce de drone.Mais du coup les gens qui postes se sentes vraiment minable et ce qui dérange le plus par rapport au lecteur c'est la façon de penser et de dire comment tu commande tes composants et tes appareils de mesures par l'intermédiaire de ta boite.Et ça franchement pour un amateur ça choque qui plus est sur un site d'amateur.Il suffit de lire tes topics en parlant de clients.Exemple: J'ai pas le matériel a la maison,je vais le récupérer à la boite: Messieurs comprenez ce qu'il y a à comprendre.Je ne suis pas jaloux mais lorsque je regarde tes interventions sur beaucoup de forum,je m'aperçois que PieM avait vu juste.
 

dje8269

Senior Member
mode modéré : ON
Bonjour Jean-claude,

Toujours aussi percutantes tes interventions .... .

mode modéré : OFF
Il suffit de regarder tous les post depuis 2013 pour comprendre qu'il y en a que pour toi
A preuve du contraire ce forum est ouvert à tous, si tu n'as pas de projet dans la vie ou de passion (à part écrire des message assassins , sans aucun rapport et hors sujet), ce n'est pas de ma faute.
Je ne crois que mes post ou ma présence ai empêché quiconque de poster ou d'obtenir une réponse à son problème.

et ton espèce de drone.
Merci de respecter le travail d'un an, en partant de zéro, et que tu critique par mes trop nombreuses interventions. c'est sur qu'avec tes 77 messages, tu ne te bouscule pas trop pour répondre ! Il est d'autant plus honorable , que cet espèce de drone a été fait en équipe grâce au intervenant de ce forum, ce qui augmente encore plus la difficulté de part la compréhension.

Mais du coup les gens qui postes se sentes vraiment minable
Tu parle pour toi la j’espère ? je ne vois vraiment pas pourquoi !

ce qui dérange le plus par rapport au lecteur c'est la façon de penser et de dire comment tu commande tes composants et tes appareils de mesures par l'intermédiaire de ta boite
D'accord , donc d’après toi je devrais peut-être m'excuser, d'avoir la chance de pouvoir bénéficier de tout ça ?

Il suffit de lire tes topics en parlant de clients
La vraiment tu divague complètement !!! tu as mal interpréter et compris, ou pas tout lus, pour connaitre le contexte ! mdr

J'ai pas le matériel a la maison,je vais le récupérer à la boite
c'est vrai , j'avoue , j'ai pas d'analyseur logique à 50€ à la maison , ni de 28X2 dans ma table de nuit . Soit je les achètes, soit je vais les chercher au travail ..... je suppose que tu les achèterai toi !

je m'aperçois que PieM avait vu juste.
PieM a très souvent juste, mais j'estime encore avoir le droit de faire à ma façon, aussi peu démocratique et appréciée soit elle ! .

Sur ce chimere322, si tu n'as rien de plus constructifs à dire, Si tu n'as pas de suggestions pou améliorer mon espèce de drone, si tu n'as pas d'idée pour compléter mon cahier des charges, merci de t'abstenir de poster .

mode modéré : ON
Passe une bonne journée Jean-claude .
 

chimere322

Senior Member
Bonjour dje8269,

J'apprécie ton projet, certes intéressant mais audacieux (c'est tout à ton honneur). Mais ce que tu n'arrives pas à te mettre en tête, c'est le principe même des picaxes. A la base les picaxes ont été conçus par RevEd pour la technologie au collège afin de former les élèves à la programmation des microcontroleurs avec pour fabricant MICROCHIP et un bootloader propre à RevED. Des picaxes Il n'y en à pas à la pelle. Et ce n'est pas les plus performant pour ce que tu envisage de faire. J'ai lu aussi que tu avais une platine de dév Easypic7 de mikroelectronica et que tu avais acheté la version complète de MIKROC. Je t'ai d'ailleurs fourni des renseignements à ce sujet et sur Pickit3 sur un autre forum.
Je ne suis pas un intervenant assassin, mais j'essaie de te faire comprendre qu'avec d'autres matériels dont tu disposes, ton projet pourrait être concret. Pour ce qui est d'un module GPS, oublie le tu ne pourras jamais faire du tracking avec. Je pourrais t'en écrire un livre complet mais ce n'est pas le bon lieu pour en expliqué le principe.
Je n'ai rien contre toi et je respecte tes ambitions, revoie juste ton approche et les techniques.

Je te souhaite une bonne journée et surtout de réussir.
 

dje8269

Senior Member
Bonjour,

J'apprécie ton projet
Moi aussi lol , et j’espère que d'autres l'aiment aussi !

certes intéressant mais audacieux
Pourquoi écrire "mais" , intéressant Et audacieux , aurait été plus approprié . car le "mais" à une connotation d'impossibilité je trouve dans la tournure de la phrase. J'ose croire et espérer le mener à terme: à vaincre sans péril on triomphe sans gloire. Je pourrais me complaire à allumer des leds certes !

Mais ce que tu n'arrives pas à te mettre en tête, c'est le principe même des picaxes.
Ça doit être moi , mais encore une fois tu es a coté de la plaque. Je commence à avoir quelques notions ( il serait temps après un an et demi), et si tu relie bien le CdC , je précise que les picaxes ne sont pas une fin en soi , et je comprends parfaitement qu'ils peuvent atteindre leurs limites dans ce projet aussi en vitesse de traitement, que sur les calculs flottants et trigo ( notamment avec un GPS).

Et ce n'est pas les plus performant pour ce que tu envisage de faire
Évidemment que ce n'est pas les plus performants ni même les plus appropriés, j'en suis conscient. Mais voila , je connais qu'eux .

J'ai lu aussi que tu avais une platine de dév Easypic7 de mikroelectronica et que tu avais acheté la version complète de MIKROC
J'y travaille effectivement

Je t'ai d'ailleurs fourni des renseignements à ce sujet et sur Pickit3 sur un autre forum.
Oui sur futura , et j'en te remercie, car ton conseils celui que j'attendais . a titre perso , j'ai acheté le cordon d'adaptation , et ça fonctionne parfaitement .

Pour ce qui est d'un module GPS, oublie le tu ne pourras jamais faire du tracking avec.
Je ne serais pas aussi affirmatif que toi, la dessus . je ne cherche pas a faire du tracking à proprement parlé , mais seulement a recevoir des coordonnées GPS et à les envoyés par voir radio. ca y ressemble mais en plus lent.
Je n'ai rien contre toi et je respecte tes ambitions, revoie juste ton approche et les techniques.
heureusement que tu n'as rien contre moi, sinon faudrait m'expliquer !.

Mon approche et celle que j'imagine. depuis 1an et demi que je vous bassine (apparemment), j'ai fais quelques bidouilles , j'ai vraiment aimé travailler avec les personnes que j'appelle experts ( et qui le sont peut être en vrai), car elles ont toujours su m'apportés des réponses .

Maintenant rien ne m’empêche de demander à des personnes compétente en la matière, en de surcroit que je connais de plus en plus, de me donner leurs avis . Si le projet n'est pas possible en picaxe, Ok ! Si le fait de mélanger des PIC et des picaxe et problématiques pour le forum Ok! mais qu'on me le dise.

Pourquoi suis je rester la . car apprécie les conseils d'experts ; car je commence a connaitre les picaxes. et que je me sent bien sur se forum (pas trop de monde) , ça part pas dans les sens , j'ai l'impression d’être entre nous . Mais apparemment ce n'est pas vu de la même façon par tout le monde.

Mais pour te rassurer, ce projet prend beaucoup de plomb dans l'aile ! que ce soit avec mes relations avec PieM , ou la coupure internet de BESQUEUT . Seul je ne peux pas y arrivé , ça c'est une des seules choses dont je suis sure ! Alors je finirais certainement par baissé les bras, à mon tour , ce qui n'est pas vraiment mon genre mais bon , faut savoir se résigné.
 

le belge

Senior Member
Bonjour à tous !

un bon bol d'air frais , un peu de distance quelques temps et ça repart !!!

je pense être très bien placé pour comprendre ..... car sans les experts du forum (surtout Michel !) le chrono serait encore en état de rêve !!!!

Mike
 

dje8269

Senior Member
Bonjour à tous ,

@BESQUEUT: vous devriez avoir une proposition en MP, n'ayant pas de réponse je ne sais pas si vous avez pus la lire ?
 
Top