Bienvenue aux nouveaux arrivants sur FantasPic !

- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.

--- L’équipe FantasPic ---

récupération d'une Trames GPS

https://docs-emea.rs-online.com/webdocs/147d/0900766b8147dbed.pdf

Forum général sur le langage C !

Modérateur : Jérémy

Avatar de l’utilisateur
paulfjujo
Expert
Expert
Messages : 2589
Enregistré en : juillet 2015
Localisation : 01800
Contact :

récupération d'une Trames GPS

Messagepar paulfjujo » ven. 30 nov. 2018 10:55

Jérémy a écrit :....
Soit je fais les calculs avec les PIC du robot , ainsi j'envoie par voir radio (à ma télécommande) peu de données car elles sont déjà transformées
Ou alors j'envoie les valeurs brutes par voie radio , mais ça fait beaucoup de données et je les traites avec mon PIC écran sur la télécommande qui lui se tourne un peu les pouces !
...


Pour la reactivité, je pencherai plutot sur le PIC Robot
pour qu'il puisse se debrouiller sans le PIC telecommande
et au besoin, si perte de communication entre les 2, retourne docilement à une position GARAGE .
( un peu comme sur les drones)

faire des Maths , ..calculs COS sur le PIC robot va prendre effectivement du temps MCU.

reste à evaluer quel temps tu disposes dans ta boucle principale ..
mesurable avec un Timer16 bits ..comptant le nb de cycles utilisés dans 1 boucle programme
( incluant le deroutage dû à l'interrupt recepetion ..)

nota : il existe des PICS FPU ( unite de clacul flottants) pour soulager le JOB du MCU principal
comme les 82387 intel pour le 80386
ou les FPU sur processeur DIGITALPDP LSI-11
Aide toi, le ciel ou FantasPic t'aidera

PieM
Membre
Membre
Messages : 21
Enregistré en : juin 2016

récupération d'une Trames GPS

Messagepar PieM » ven. 30 nov. 2018 11:05

Bonjour,

Petite précision encore: ne pas oublier dans ce type de calcul de tenir compte du signe des latitudes longitude, indiqué dans la trame par N,S,E,W.
Si on est vers Argentan, (long ~ 0) par exemple ça peut poser des problèmes !
Les différences de coordonnées deviennent alors des sommes si on est de part est d'autre du méridien 0 (ou de l'équateur si tu comptes envahir le congo!)...

Pour ton robot, plusieurs choses (ça me rappelle des vieux souvenirs, hein ?)
Ne pas oublier que tu vas recevoir tes trames avec une fréquence faible (1 Hz en principe)
- De quoi ton robot a t-il besoin en local, comme infos venant du GPS: nombre , et fréquence d'actualisation
- doit-il avoir une certaine autonomie en cas de pb de transmission ?
- coté télécommande, idem. Je doute par exemple que tu aies besoin d'actualiser la position toutes les 100 ms.
- liaison half duplex ou full duplex ?
Et pour les transmissions (et les calculs) être économe dans les déclaration de variable!

Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

récupération d'une Trames GPS

Messagepar Jérémy » ven. 30 nov. 2018 17:55

Bonsoir ,

reste à evaluer quel temps tu disposes dans ta boucle principale ..

Difficile à dire ou a mesurer ! Le PIC reçoit des consignes radio par UART, toutes les 100ms, quand le robot avance . Ensuite il pilote les moteurs avec 2 PWM généré par interruption. Il reçoit le signal GPS qu'il traite et enregistre .
Il doit faire des lectures analogiques pour vérifier la tension des batteries ( 1 batteries propulsion et 1 batterie électronique ).
Il doit dialoguer avec la boussole !!

Bref il s’ennuie pas et j'ai encore plein d'idée ! mais je suis optimiste !

PieM a écrit :Source du message Petite précision encore: ne pas oublier dans ce type de calcul de tenir compte du signe des latitudes longitude, indiqué dans la trame par N,S,E,W.

Oui je ferais un test avec condition pour avoir une valeur absolue

PieM a écrit :Source du message - De quoi ton robot a t-il besoin en local, comme infos venant du GPS: nombre , et fréquence d'actualisation

Si il peut avoir le cap se serait bien ( ça pourrait me libérè de l'utilisation du 9DOF). Le GPS est la pour obtenir un peu de télémétrie , position donc distance par rapport au point HOME . CAP . vitesse ground si possible mais je doute car trop faible distance et vitesse . Pour al vitesse j'ai des moteurs avec encodeur ( encore un peu de math en perspective) .
Pour la fréquence d’utilisation ce qui est possible pas de critère particulier ( 1/s me parait très bien)

PieM a écrit :Source du message doit-il avoir une certaine autonomie en cas de pb de transmission ?

Pas pour le moment ! ( mais j'y ai pensé.... ) Pour le moment en cas de perte de communication le robot s’arrête automatiquement

PieM a écrit :Source du message - coté télécommande, idem. Je doute par exemple que tu aies besoin d'actualiser la position toutes les 100 ms.

L"'idéale est d'actualiser quand il y a besoin . mais 1 fois par seconde pour la position vitesse cap .... 1/minute pour les batteries .... LE robot ne doitr pas trop dialoguer avec la télécommande, il est préférable qu'il reste dispo pour recevoir les consignes.

PieM a écrit :Source du message liaison half duplex ou full duplex ?

Liaison Half duplex !

Donc pour résumer , le robot doit recevoir ces consignes de la télécommande, en priorité . De temps en temps il envoie à la télécommande sa télémétrie.
Je vais me concentré pour le moment sur la partie GPS.
Car même si la formule à été trouvée, je rencontre des problèmes pour les calculs avec des débordements de variables ( même avec des long) .

Mais j'y travaille... I faut trouver le bon compromis entre précision et rapidité de calcul !
C'est en faisant des erreurs, que l'on apprend le mieux !!!

Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

récupération d'une Trames GPS

Messagepar Jérémy » ven. 30 nov. 2018 20:30

Je me faisais bananer car la fonction cos() de mikroC parle en radians alors que moi je suis en degré !
Du coup pour trouver mon coef je suis obligé de convertir en Radians

Code : Tout sélectionner

  Glcd_Write_Text_Adv("Coef=",0,24);
  Coef = cos(((Lat2 + Lat1)/200)*0.0174533) ;
  FloatToStr(Coef, Texte);
  Glcd_Write_Text_Adv(Texte,35,24);
C'est en faisant des erreurs, que l'on apprend le mieux !!!

Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

récupération d'une Trames GPS

Messagepar Jérémy » ven. 30 nov. 2018 21:57

Paul avait bien raison ( je n'en doutais pas) !! Les calculs avec des flottans sont sur 32 bits et non 64 .
Donc grosso modo je ne peux affiché que 7 chiffres plus la virgule.


Je souhaitais faire les calculs directement depuis ma trame GPS reçu , qui est de cette forme: Lat : 4885,8372
Mais le dernier chiffre est tronqué. Avec mikroC j'obtiens 4885.836 !!!

J'ai essayé en multipliant par 10000 , afin de me passer des virgules. Mais du coup les chiffres sont trop grand et je déborde même avec des "Long" .
Je ne sais pas si il existe une façon pour garder la précision des calculs ?

Je ne vais pas demandé la lune : car j'obtiens quand même : 24097 centimètres au lieu de 24127 centimètres soit une erreur de 30 cm . pas la mer à boire.

Je vous ai enlever la partie affichage sur mon écran pour ne montrer que la partie calcul .

Code : Tout sélectionner

  
  Lat1 
4885.837 ;
  
Lon1 229.4479 ;
  
  
Lat2 4886.030 ;
  
Lon2 229.5973 ;

  
// Latitude
  
if (Lat2 >= Lat1LatX = (Lat2 Lat1)*111317;
  else  
LatX = (Lat1 Lat2)*111317  ;

  
// Coefficient
  
Coef cos(((Lat2 Lat1)/200)*0.0174533) ;  // transformation en radian

  // Longitude
  
if (Lon1<0Lon1 abs(Lon1);
  if (
Lon2<0Lon2 abs(Lon2);
  if (
Lon2>=Lon1LonX = (Lon2 Lon1)*Coef*111317 ;
  else  
LonX = (Lon1 Lon2)*Coef*111317  ;

  
Distance sqrt( (LonX*LonX) + (LatX*LatX));

   
C'est en faisant des erreurs, que l'on apprend le mieux !!!

Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

récupération d'une Trames GPS

Messagepar Jérémy » ven. 30 nov. 2018 22:46

En gardant la même précision, que me donne le GPS . Voici mes équations :

Code : Tout sélectionner


  Lat1 
48858372 ;
  
Lon1 22944796 ;
  
  
Lat2 48860304 ;
  
Lon2 22959730 ;

  
// Latitude
  
if (Lat2 >= Lat1LatX = (Lat2 Lat1)*11.1317;
  else  
LatX = (Lat1 Lat2)*11.1317  ;

  
// Coefficient
  
Coef cos(((Lat2 Lat1)/20000000)*0.174533) ;

  
// Longitude
  
if (Lon1<0Lon1 abs(Lon1);
  if (
Lon2<0Lon2 abs(Lon2);
  if (
Lon2>=Lon1LonX = (Lon2 Lon1)*Coef*1.11317 ;
  else  
LonX = (Lon1 Lon2)*Coef*1.11317  ;


  
Distance = (sqrt( (LonX*LonX) + (LatX*LatX)));
   

Je tombe pile poil sur 24127 centimètres . Mais c'est beaucoup plus complique je trouve !

Je ne sais si c'est possible de simplifié ? Si ce n'est pas possible je pense que je vais rester sur la première approximation que je trouve bien plus simple
C'est en faisant des erreurs, que l'on apprend le mieux !!!

Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

récupération d'une Trames GPS

Messagepar Jérémy » sam. 1 déc. 2018 09:57

Test en condition réel, avec mon adresse + un point d'une rue plus loin. ca fonctionne pas .

Je viens de me souvenir que mon GPS donne une trame en DDDMM.MMMM . Je pense qu'il me manque une conversion car (Lar1 - Lat2) me donne des minutes et non des secondes .

Je trouve 780 mètre au lieu de 104 mètres

Je cherche ..
C'est en faisant des erreurs, que l'on apprend le mieux !!!

PieM
Membre
Membre
Messages : 21
Enregistré en : juin 2016

récupération d'une Trames GPS

Messagepar PieM » sam. 1 déc. 2018 10:00

Bonjour Jeremy,
Je rappelle que la trame GPS n'est pas en degrés décimaux !! (seule la puce SIRF donne des degrés décimaux signés à ma connaissance)
Les 48.858372 utilisés par tes calculs sont des degrés décimaux, donnés par exemple par G. Maps
Mais les latitudes et longitudes données par un GPS sont sous la forme degrés et minutes en décimale (DDMM.MMMM)
Donc la trame GPS correspondante serait 4851.5026 (soit 48°51'30.14'' dans un systeme DDMMSSSS

D'autre part Long et Lat du GPS ne peuvent être négatif puisque le signe est donné par les lettres N,S,E,W.
si c'est S ou W les valeurs sont négatives.
Donc tous tes tests if (Lat2 >= Lat1) ... et if (Lon1<0) sont inadaptés sous cette forme.

Concernant la précision, il faut comprendre que le dernier chiffre significatif donné par le GPS correspond à 18 cm !
Tu vas t'apercevoir que les valeurs reçues sont loin d'être stables au point d'assurer ça!
Si tu es à 3 m de précision ce sera très bien! mais je ne suis pas certain que tu les atteignes.
Je ne sais où ton robot va intervenir, mais si c'est en zone habitée tu risques d'avoir des écarts importants liées à l'environnement .
Comme déjà dit, une donnée importante pour estimer cette précision est la DOP horizontale (HDOP) donnée dans la trame GGA et GSA.
Plus cette valeur est faible meilleure est l'estimation de position, la valeur 1 étant idéale.
On peut avoir une DOP plus faible avec 5 satellites qu'avec 8 !

Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

récupération d'une Trames GPS

Messagepar Jérémy » sam. 1 déc. 2018 13:08

Re,

Je m’arrache les cheveux avec ces conversions. Mais je vais y arriver......

Tu as raison pour le signe , j'ai corriger mon programme en fonction de la lettre du point cardinal qu'il reçoit .

PieM a écrit :Source du message Je ne sais où ton robot va intervenir, mais si c'est en zone habitée tu risques d'avoir des écarts importants liées à l'environnement .

Dans mon quartier, piloter par mes enfants , mais quand leur papa leur aura fait une démo bien évidemment :twisted:

PieM a écrit :Source du message Comme déjà dit, une donnée importante pour estimer cette précision est la DOP horizontale (HDOP) donnée dans la trame GGA et GSA.

Suggére tu que je prenne en compte les données seulement si cette valeur est convenable !
C'est en faisant des erreurs, que l'on apprend le mieux !!!

Jérémy
Administrateur du site
Administrateur du site
Messages : 2722
Enregistré en : juillet 2015
Localisation : Dans le sud
Contact :

récupération d'une Trames GPS

Messagepar Jérémy » sam. 1 déc. 2018 13:43

Pfioou u ca saoule !!!! plus rien ne fonctionne

:mur: :mur: :mur: :furieux: :furieux: :furieux:
C'est en faisant des erreurs, que l'on apprend le mieux !!!


Retourner vers « Langage C »

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 39 invités