Télécommande voiture RC + caméra

[dje8269]

Bon j'aime bien car ca fait avancer , surtout que je suis en train de preparer le cahier des charges du VHL .

Donc tu perds la com vidéo

;
ok!

mais ton truc a toujours la com radiocommande.

Oyi c'est une possibilité

donc il ne sais pas qu'il n'est plus guidé !

?? ben la il est guidé car j'ai la com. tu voulais peut être dire qu'il ne sait plus que sa vidéo n'est plus reçue .

donc il continue jusqu'à ce que tu lui dise d'arrêter.

?? a faire quoi ? a "obéir" ? oui . dans ce cas de figure on peut par exemple prévoir un BP pour lancer la procédure de back up manuellement ( hypothèse)

quant à retrouver le flag hi2c qui va te le dire à toi derrière tes lunettes aveugles !

Ben j'aurais retrouvé les commandes donc la liaison !! .

Et qu'est ce qui te dit que tu as perdu la com commande ?

Le hi2c flag absent ou la non "obéissance" du VHL ( j'ai le mot au bout de langue pour désobéissance mais j'arrive pas a mettre le grappin dessus).

Je précise que c'est qu'une et quelques tests , fort interressant, si c'est pas faisable, faut juste que je trouve les mots pour expliqué l'infaisabilité .

 

[BESQUEUT]

La voiture avance doucement sur du goudron, il n'y a donc aucun dérapage . mais je suis conscient , qu'un simple dérapage, patinage , montée descente change complètement le trajet, mais sur quelques mètres je pense que ca peut être jouable. Le but n'étant pas de sortir d'un labyrinthe lol .

Comme expliqué #1194 il y a obligatoirement un dérapage de plusieurs cm à chaque virage ; c'est du à la largeur des pneus ! Un pneu large qui ne dérape pas ne peux que aller tout droit !
Le résultat final est un "moyennage" entre le dérapage du bord intérieur et du bord extérieur. Comme expliqué également, ce dérapage est différent suivant que la voiture travaille en poussant ou en tirant.
Au final, votre vidéo montre que ce n'est pas si mal ! Mais vous êtes dans des conditions quasi idéales. N'espérez pas faire mieux.
Si ça vous suffit, tant mieux. Le tout est d'évaluer le "quelques mètres" à quelques chose de concret.
Sinon.... GPS et/ou inertie...

 

[dje8269]

Ok . je comprends mieux . donc en fait ce n'est pas une question d'angle , c'est l'effet que ca donne en tout cas ......

Peut etre qu'on peut estimer ce dérapage sur terrain "qui accroche" , afin de trouver une relation entre la marche avant et arrière . Sur la vidéo, c'était l'exemple le plus pourris niveaux précision, mais le plus potable niveaux vidéo.

Je suis de pouvoir mieux faire , mais comme vous le dites c'est en condition idéale !!! Quoi que .... des angles a 90° je pense ne seront pas courant en réel !!

j'étais persuadé qu'il y avait un truc mathématique qui m'avait échappé.

Sinon.... GPS et/ou inertie...

On avait déjà vu que la précision du gps n'était pas envisageable . et boussole compensée et gyro et accéléromètre , j'avais des doutes avec un émetteur de 5w a coté.

 

[PieM]

?? ben la il est guidé car j'ai la com. tu voulais peut être dire qu'il ne sait plus que sa vidéo n'est plus reçue .
T'as la com mais tu ne vois rien !!

?? a faire quoi ? a "obéir" ? oui . dans ce cas de figure on peut par exemple prévoir un BP pour lancer la procédure de back up manuellement ( hypothèse)

Ben j'aurais retrouvé les commandes donc la liaison !! . Mais si tu ne vois rien qu'est ce que tu commandes !

Le hi2c flag absent ou la non "obéissance" du VHL ( j'ai le mot au bout de langue pour désobéissance mais j'arrive pas a mettre le grappin dessus).

Mais tu ne sais pas que le flag est absent puisque tu n'as pas de visu !! donc tu ne sais pas si ton truc répond ou non aux commandes...

STP, avant de faire une usine à gaz tu réfléchis un peu aux divers cas de figure. Tu vas te rendre compte que ton rembobinage de commandes enregistrées ne sert à rien.
cas1 tu perds d'abord la vidéo : tu arrêtes tout et tu prends ton vélo.
cas 2 tu perds d'abord les commandes tu vois où est ton truc en balayant avec la cam en automatique ... et tu prends ton vélo.

 

[dje8269]

cas1 tu perds d'abord la vidéo : tu arrêtes tout et tu prends ton vélo.
cas 2 tu perds d'abord les commandes tu vois où est ton truc en balayant avec la cam en automatique ... et tu prends ton vélo.

Le but du VHL de reconnaissance est d'allé dans des zones ou l'humain ne veut/peut pas allé . c'est la tout le principe en fait . Si la com se perd adieu le vhl .

cas 1 je perds d'abord la vidéo : j'essaie de la retrouvé en me déplaçant à la base , sinon déclenchement manuel du back up , et marche arrière sur quelques mètres , perdus pour perdus autant tentés un truc .

cas 2 je perds d'abord les commandes ; back up automatique .

STP, avant de faire une usine à gaz tu réfléchis un peu aux divers cas de figure.

Sympa , car j'y ai réfléchi . tous les cas de figures ne peuvent pas être entrepris et prévus . Je suis peut être idiot , mais j'essaye et en plus j'y prends plaisir , alors je dois être maso .

 

[PieM]

Si la com se perd adieu le vhl .

Ah bon ! On en apprend tous les jours !...
alors je pense que l'approche globale en tant que sureté de fonctionnement, dont le choix d'équipement, est un peu superficielle.
Il fallait partir sur un transceiver et non un simple emetteur.

et boussole compensée et gyro et accéléromètre , j'avais des doutes avec un émetteur de 5w a coté.

une boussole ici n'a pas besoin d'être compensée, et n'est pas sensible à un émetteur HF !
un parcours sans GPS, c'est un cap et une distance.

 

[BESQUEUT]

On avait déjà vu que la précision du gps n'était pas envisageable . et boussole compensée et gyro et accéléromètre , j'avais des doutes avec un émetteur de 5w a coté.

Précision du GS : quelques mètres quel soit l distance parcourue. Mais pire si couverture végétale...
DGPS : quelques décimètres, voire, quelques cm, mis mise en ouvre complexe.
Plateforme IMU : quelques mm ou cm par mètre parcouru...
L'idéal est une combinaison des 2, mais c'est pas simple.

Sincèrement, à part reveir n arrière de quelques mètres : oubliez ça...

 

[dje8269]

alors je pense que l'approche globale en tant que sureté de fonctionnement, dont le choix d'équipement, est un peu superficielle.

Hum.... décidément . superficielle !!!! . je fais avec mes moyens et ceux qu'on me donne . Pour l'heure mon émetteur COFDM a 15000€ n'a pas été retenu mais un émetteur chinois Oui . le délais de an n'ont plus n'a pas été retenu . j'ai envisagé le transceiver effectivement , mais cela remettais tout en cause, notamment les portées les com et tous les test du proto etc ....... . délais plus long .

je ne vois pas en quoi le fais d'avoir un transceiver aurait permis de récupérer le VHL qu'on ne peut pas allé cherché . A la limite tant mieux pour l'emetteur COFDM car si la com se perd c'est 15.000€ de gagné .

Sincèrement, à part reveir n arrière de quelques mètres : oubliez ça...

Je demande pas beaucoup plus . une ou deux dizaines de mètres serait déjà pas mal ; car de toute façon si on perd la com vidéo ou radio , on s'arrête et pour la retrouvée je doute qu'il faille faire 50 metres ! .

 

[PieM]

je ne vois pas en quoi le fais d'avoir un transceiver aurait permis de récupérer le VHL qu'on ne peut pas allé cherché

Il aurait simplement permis de ne pas le perdre en anticipant la perte de signal !

quant à l'émetteur COFDM a 15000€ je ne vois pas trop l'intérêt .... Je comprends que le client ait tiqué !!

surtout que je suis en train de preparer le cahier des charges du VHL

comprends plus là ! je croyais qu'il était fait ....

 

[dje8269]

Il aurait simplement permis de ne pas le perdre en anticipant la perte de signal !

J'avoue le signal RSSI aurait été utile pour l'anticipation. A défaut d'avoir un transceiver , je suis partis du principe que la première perte du signal vidéo ferais office d'alerte , pertes répétées on ne joue plus . .

Mais ton idée est intéressante car on pourrais envisagé un espèce de RSSI ? difficilement intégrable mais faisable ; imagine une trio de led ( genre verte orange rouge) qui indique le niveau de réception sur le VHL ; je braque la caméra dessus pour avoir l'info ? bon c'est tiré par les cheveux mais faisable

quant à l'émetteur COFDM a 15000€ je ne vois pas trop l'intérêt

Pour la fiabilité de la transmission vidéo en milieu perturbé et urbain ;J"ai pas trouvé mieux lors de mes recherches .

On peut me demandé l'impossible, j'y réfléchirais !! mais je dirais pas que c'est faisable

 

[dje8269]

Pour en revenir a nos moutons , d'après vous la différence angulaire entre la marche avant et la marche arrière n'est pas compensable ?? ou calculable ?.

 

[BESQUEUT]

Pour en revenir a nos moutons , d'après vous la différence angulaire entre la marche avant et la marche arrière n'est pas compensable ?? ou calculable ?.

En affinant un peu vos essais (différentes vitesses, différents angles, différents types de sols...)
vous pouvez mesurer et tabuler ce correctif. C'est la méthode dite "empirique", pas très élégante, mais mieux que rien.
Après, s'il y a un problème pour accéder à ces tables, on peut déterminer une formule "empirique" qui donnera la fameuse compensation en fonction de l'âge du capitaine. Ca c'est faisable.

 

[dje8269]

Je déplace si possible le sujet du protocole de back up sur ce post , car tout les tests se feront sur le proto . et ainsi il sera plus facile de s'y retrouvé . Comme rien n'est décidé, mais tout en discussion sur ce fameux protocole, ne le melangons pas avec le VHL de reco.

Concernant l'enregistrement des ordres, il y a une alternative (donc 2 options) :
- soit on enregistre avec une périodicité connue (commode si les changement sont permanents),
- soit n'enregistre que les modifications et dans ce cas, on enregistre aussi à quel moment le changement a lieu.


En gros : ça ne sert à rien (et ça prends beaucoup de temps) d'écrire 100 fois la même information.
C'est plus pertinent d'écrire :
- Temps 0 : Moteur=0 Direction = 150
- T=123 M=145 D=150
- T=246 M=145 D=220
etc...
Bien que le volume par ligne soit plus important, la seconde solution mobilise souvent moins de volume de données et donc moins de temps d'écriture.
Cela dit, si c'est pour enregistrer les 10 derniers mètres du parcours, ça ne change pas grand chose. Et d'autre part, il existe des mémoire EEprom ou FRAM de très grande capacité à interface I2C ou SPI qui vont bien au delà des besoins.

Je suis bien d'accord avec les deux options .

par contre je pense que ca mérite des tests sur cette affirmation non ?

ça ne sert à rien (et ça prends beaucoup de temps) d'écrire 100 fois la même information.

Car sur le papier c'est exact mais dans les faits ; il va falloir calculer la durée de la pour une valeur donnée ; comme on travaille avec de l'analogique, les changements seront quasi permanents ; dur de tenir la même valeur avec un joystick

la seconde solution mobilise souvent moins de volume de données et donc moins de temps d'écriture.

La non plus je ne voyais pas les choses comme ca ; je dis pas que vous avez torts loin de la ; mais de mon point de vue vous écrivez 3 valeurs ,(moteur , direction, et temps) , alors que a dans la première deux suffisent ( direction et moteur) , et c'est le nombre d'information qui détermine le temps approximatif .

si c'est pour enregistrer les 10 derniers mètres du parcours

Oui mais le problème c'est qu'on ne ssait pas quand arrive les dix derniers mètres. donc il faut enregistré en permanence ..... et ensuite revenir sur x valeurs enregistrer qui détermineront le temps ou le nombre de mètres . en sachant qu'il faudra certainement prendre en compte si le VHL c'est arrêté par exemple .

Vous n'êtes pas d'accord ?

 

[dje8269]

Après, s'il y a un problème pour accéder à ces tables, on peut déterminer une formule "empirique" qui donnera la fameuse compensation en fonction de l'âge du capitaine. Ca c'est faisable.

Yes !!! ca fais plaisir

 

[BESQUEUT]

dur de tenir la même valeur avec un joystick
La non plus je ne voyais pas les choses comme ca ; je dis pas que vous avez torts loin de la ; mais de mon point de vue vous écrivez 3 valeurs ,(moteur , direction, et temps) , alors que a dans la première deux suffisent ( direction et moteur) , et c'est le nombre d'information qui détermine le temps approximatif .

Dans ce cas, c'est plus simple d'enregistrer en continu ; mais il faut que la périodicité soit absolument régulière.

Oui mais le problème c'est qu'on ne ssait pas quand arrive les dix derniers mètres. donc il faut enregistré en permanence ..... et ensuite revenir sur x valeurs enregistrer qui détermineront le temps ou le nombre de mètres . en sachant qu'il faudra certainement prendre en compte si le VHL c'est arrêté par exemple .

Oui : dans les 2 cas, il faut un buffer tournant. Le Picaxe en a un, mais il est utilisé par le Background receive...
Ca peut aussi se générer par programme sur une mémoire externe sans trop de mal.
Ca représente combien d'enregistrements 10 mètres ?

 

[dje8269]

il faut un buffer tournant

Je ne sais pas ce qu'est un buffer ! je file voir wiki ou autres .

Ca peut aussi se générer par programme sur une mémoire externe sans trop de mal.

c'est bien comme ça , que j'avais imaginé les choses, j'ai acheté des mémoires exprès en i2C

Ca représente combien d'enregistrements 10 mètres ?

Impossible a dire ça . suivant la vitesse si le VHl c'est arrêté entre temps ...... ce sera des choses a définir a la fin des tests , si l'idée est retenue . Par exemple imaginons quue le VHL s'arrête 1 minute puis repart et perds la communication . il ne devras pas s'arrete 1 minutes en marche arrière ..... mais je pense que c'est gérable dans le protocole de marche back up ca .
Pour la périodicité il n'y as aucun problème c'est 40ms , je peaufinerais en fin de test , suivant l'architecture retenue .

 

[BESQUEUT]

Pour la périodicité il n'y as aucun problème c'est 40ms , je peaufinerais en fin de test , suivant l'architecture retenue .

Donc on a 25 mesures par seconde, soit 10m à 40 km/h ou bien
50 mesures pour 10m à 20 km/h
Si pauses il y a, la méthode T M D est plus appropriée...
Par exemple :
123 150 150
124 150 151
125 0 0
1625 150 150
représente une séquence avec un arrêt d'une minute...

 

[dje8269]

C'est exact mais après réflexion, la méthode TMD ne pourras pas être trés efficace . j'ai pas encore mis le nez dans le protocole du back up , tant que les tests ne sont pas positifs et a peu pres viable .
en fait j'imagine que le VHL a l'arrêt signifie surtout qu'il ne reçoit plus d'infos ( normal les joystick sont au point mort) donc on ne fais pas d'enregistrement ! ou si juste une seconde le temps que le flag ne revienne plus.

de plus conduire a 20km/h reste quasi impossible, bien sur cela dependra des condition du terrain , mais j'en doute, j'imagine plutôt 3 ou 4 km/h .

 

[BESQUEUT]

C'est exact mais après réflexion, la méthode TMD ne pourras pas être trés efficace . j'ai pas encore mis le nez dans le protocole du back up , tant que les tests ne sont pas positifs et a peu pres viable .
en fait j'imagine que le VHL a l'arrêt signifie surtout qu'il ne reçoit plus d'infos ( normal les joystick sont au point mort) donc on ne fais pas d'enregistrement ! ou si juste une seconde le temps que le flag ne revienne plus.

de plus conduire a 20km/h reste quasi impossible, bien sur cela dependra des condition du terrain , mais j'en doute, j'imagine plutôt 3 ou 4 km/h .

Quand le véhicule ne reçoit plus de données, il continue à rouler un peu ? Si oui, et si méthode MD, alors il faut continuer à enregistrer scrupuleusement, toujours la même chose, toutes les 40 ms sinon vous n'êtes plus synchrone.
Avec la méthode TMD, vous n'enregistrez que quand les données changent, donc pas quand vous ne recevez rien.
Si le véhicule roule 5 fois moins vite, il faudra 5 fois plus de place pour stocker les données sur 10m.
(Comme le dit le dicton : plus tu pédales moins vite, moins tu avances plus vite !)

Par contre, si le fait de relâcher les joysticks stoppe l'émission de données, le véhicule va partir en fail-safe et revenir en arrière !
Je ne comprends plus rien ! (remarquez bien que je ne comprenais déjà pas grand chose, donc il n'y a pas une grosse perte...)

 

[dje8269]

Quand le véhicule ne reçoit plus de données, il continue à rouler un peu ?

Non , ou quasi pas . a faible allure l'arrêt seras instantané ; a vive allure il y as un protocole de freinage avant l'arrêt suivant la valeur de la vitesse avant la perte de com ; comme sur le proto .

L'espace memoire nécessaire n'est pas la priorité , je pense . de toute facon je dois enregistrer en permanence ( ou quand le VHL bouge). mais cela peut durer 30minute voir plus ! . je me souviens plus quel mémoire j'ai acheté des 64K ou 128K je crois. de quoi largement tenir .

Je pense plutôt privilégier la vitesse ( donc ecrire 2 octet) qui a " gaspiller" de la place , plutot que 3 octet en gagnant de la place . non ? c'est surtout le fait de compter le temps de chaque action qui me perturbe je pense , pas le fait d'écrire 1 octet de place , je pense que le temps est ridicule . par contre faire des calculs de timer , sur des changement de valeurs , la on tape deja plus dans le timing a mon avis .

La météo aujourd'hui, ne m'a pas permis de faire des tests ; je le ferais dès je peux . afin d'essayer votre méthode empirique.