problème utm.latLong() avec jcoord

matSimonnet commented 11 years ago

Mister Stott est english, là où il habite les longitudes sont négatives comme chez nous, un bon point pour lui :-) . Par contre aux Pays-bas et dans le Kent, les longitudes sont positives. Le problème c'est que la fonction toLatLng() renvoie toujours des longitudes négatives. Il nous faudra donc modifier la lib ou en utilise une autre.

legras commented 11 years ago

Le problème vient simplement du fait que j'ai codé en dur la zone UTM dans le code de UAVDataPoint. D'ailleurs je me rends compte que nous avons un champ name="utm_zone" type="uint8" qui nous vient de Paparazzi. Une idée de comment on extrait la lngZone (chiffre, ici 30) et latZone (caractère, ici U) de là ?

package com.deev.interaction.uav3i.model;

import uk.me.jstott.jcoord.LatLng;
import uk.me.jstott.jcoord.UTMRef;

public class UAVDataPoint
{
    public LatLng latlng;
    public double altitude;
    public double course;
    public long time;

    /**
     *  <message name="GPS" id="8">
     *  <ul>
     *  <li><field name="mode"       type="uint8"  unit="byte_mask"/></li>
     *  <li><field name="utm_east"   type="int32"  unit="cm" alt_unit="m"/></li>
     *  <li><field name="utm_north"  type="int32"  unit="cm" alt_unit="m"/></li>
     *  <li><field name="course"     type="int16"  unit="decideg" alt_unit="deg"/></li>
     *  <li><field name="alt"        type="int32"  unit="mm" alt_unit="m"/></li>
     *  <li><field name="speed"      type="uint16" unit="cm/s" alt_unit="m/s"/></li>
     *  <li><field name="climb"      type="int16"  unit="cm/s" alt_unit="m/s"/></li>
     *  <li><field name="week"       type="uint16" unit="weeks"/></li>
     *  <li><field name="itow"       type="uint32" unit="ms"/></li>
     *  <li><field name="utm_zone"   type="uint8"/></li>
     *  <li><field name="gps_nb_err" type="uint8"/></li>
     *  </ul>
     */
    public UAVDataPoint(int utm_east, int utm_north, int c, int alt, long t)
    {
        UTMRef utm = new UTMRef((double) utm_east/100f, (double) utm_north/100., 'U', 30);
        ...
    }
}

phtanguy commented 11 years ago

Je viens de trouver ! Je suis en train de commiter la modif sur le master... Il faudra attendre quelques minutes mais ça marche modulo quelques interrogations que je vais commenter sur le commit.

Philippe.

Le 24/10/2013 09:46, François Legras a écrit :

Le problème vient simplement du fait que j'ai codé en dur la zone UTM dans le code de |UAVDataPoint|. D'ailleurs je me rends compte que nous avons un champ |name="utm_zone" type="uint8"| qui nous vient de Paparazzi. Une idée de comment on extrait la lngZone (chiffre, ici 30) et latZone (caractère, ici U) de là ?

package com.deev.interaction.uav3i.model;

import uk.me.jstott.jcoord.LatLng; import uk.me.jstott.jcoord.UTMRef;

public class UAVDataPoint { public LatLng latlng; public double altitude; public double course; public long time;
 /**
  *  <message name="GPS" id="8">
  *  <ul>
  *  <li><field name="mode"       type="uint8"  unit="byte_mask"/></li>
  *  <li><field name="utm_east"   type="int32"  unit="cm" alt_unit="m"/></li>
  *  <li><field name="utm_north"  type="int32"  unit="cm" alt_unit="m"/></li>
  *  <li><field name="course"     type="int16"  unit="decideg" alt_unit="deg"/></li>
  *  <li><field name="alt"        type="int32"  unit="mm" alt_unit="m"/></li>
  *  <li><field name="speed"      type="uint16" unit="cm/s" alt_unit="m/s"/></li>
  *  <li><field name="climb"      type="int16"  unit="cm/s" alt_unit="m/s"/></li>
  *  <li><field name="week"       type="uint16" unit="weeks"/></li>
  *  <li><field name="itow"       type="uint32" unit="ms"/></li>
  *  <li><field name="utm_zone"   type="uint8"/></li>
  *  <li><field name="gps_nb_err" type="uint8"/></li>
  *  </ul>
  */
 public  UAVDataPoint(int  utm_east,  int  utm_north,  int  c,  int  alt,  long  t)
 {
     UTMRef  utm  =  new  UTMRef((double)  utm_east/100f,  (double)  utm_north/100.,  'U',  30);
     ...
 }
}

— Reply to this email directly or view it on GitHub https://github.com/legras/uav3i/issues/17#issuecomment-26972523.

Philippe TANGUY

Institut TELECOM - TELECOM Bretagne

Département LUSSI. Bureau F01 - 109A

Technopôle Brest-Iroise CS 83818 F-29238 Brest Cedex 3 France

tel: +33 2 29 00 14 36

phtanguy commented 11 years ago

Principe de la correction :

L'accès au fuseau et à la bande UTM se font à partir de la classe FlightPlanFacade qui permet un accès plus aisé aux données du plan de vol.
À partir du point initial défini dans le plan de vol (attribut lat0 et lon0 de l'élément flight_plan), on mémorise dans la classe un attribut LatLng (startPoint) pour lequel on peut définir la référence UTM (startPoint.toUTMRef()).
Il est alors facile de récupérer le fuseau (utmRef.getLngZone()) et la bande (utmRef.getLatZone()).
Deux getters sont disponibles dans la la classe FlightPlanFacade et sont utilisés lors de la construction d'un UAVDataPoint.

Reste à voir ce qu'il se passe quand le point de départ est situé à la limite d'une bande et/ou d'un fuseau et que le vol du drone est susceptible de passer de l'un à l'autre... Par exemple Brest est dans la bande U mais Douarnenez serait dans dans la bande T. Je teste ça avant de clore le ticket.

Voir http://gerssat.chez-alice.fr/liens/tutdroitref/UTM.htm

matSimonnet commented 11 years ago

Good idea Pilip ! Je n'avais pas pensé à prendre le point du départ du flight plan. Il me semble qu'on peut rester comme ça pour le moment parce que la zone T commence au sud d'audierne, et que les autres démo sont en zone 31U loin des limites. pecap !

2013/10/24 Philippe TANGUY notifications@github.com

Principe de la correction [image: :+1:]

L'accès au fuseau et à la bande UTM se font à partir de la classe FlightPlanFacade qui permet un accès plus aisé aux données du plan de vol.

À partir du point initial défini dans le plan de vol (attribut lat0 et lon0 de l'élément flight_plan), on mémorise dans la classe un attribut LatLng (startPoint) pour lequel on peut définir la référence UTM ( startPoint.toUTMRef()).

Il est alors facile de récupérer le fuseau (utmRef.getLngZone()) et la bande (utmRef.getLatZone()).

Deux getters sont disponibles dans la la classe FlightPlanFacade et sont utilisés lors de la construction d'un UAVDataPoint.

Reste à voir ce qu'il se passe quand le point de départ est situé à la limite d'une bande et/ou d'un fuseau et que le vol du drone est susceptible de passer de l'un à l'autre... Par exemple Brest est dans la bande U mais Douarnenez serait dans dans la bande T.

Voir http://gerssat.chez-alice.fr/liens/tutdroitref/UTM.htm

— Reply to this email directly or view it on GitHubhttps://github.com/legras/uav3i/issues/17#issuecomment-26978919 .

phtanguy commented 11 years ago

La limite entre les bandes U etT passe pile au niveau de Quimper (on peut afficher les coordonnées UTM dans Google Earth). Je vérifierai le comportement par acquis de conscience...

phtanguy commented 11 years ago

Peut-être une idée : passer en WGS84 qui est un référencement mondial. La librairie jcoord-1.0 doit permettre de faire ça.

matSimonnet commented 11 years ago

mais pour transformer l'UTM récupéré depuis l'autopilote en lat/lon WGS84, il me semble qu'il nous faut la zone...

2013/10/24 Philippe TANGUY notifications@github.com

Peut-être une idée : passer en WGS84 qui est un référencement mondial. La librairie jcoord-1.0 doit permettre de faire ça.

— Reply to this email directly or view it on GitHubhttps://github.com/legras/uav3i/issues/17#issuecomment-26980759 .

phtanguy commented 11 years ago

On ne devrait pas avoir besoin de passer par du WGS84 et cependant gérer correctement ce potentiel problème...

Comme disait Fanfan, on a aussi la donnée name="utm_zone" type="uint8" qui correspond au numéro du fuseau UTM et qui est transmis avec chaque coordonnée GPS. En plus, dans la librairie jcoord-1.0, on peut utiliser la méthode statique UTMRef.getUTMLatitudeZoneLetter(double latitude) qui nous permet de récupérer la bande UTM pour chaque point reçu.

Du coup, plus aucune ambigüité par rapport au point d'origine du plan de vol... Je fais la modif dès que possible.

phtanguy commented 11 years ago

Oui mais non !!! En fait on se mord la queue...

Pour avoir la latitude, il faut la traduire de l'UTM donc il nous faut le fuseau (c'est bon) mais aussi la bande et là c'est pas bon !

Mathieu proposait de calculer la limite nord et sud (calculable à partir de max_dist_from_home) dans le plan de vol et de voir ainsi si on changeait de bande. C'est une piste.

Pour le moment, je laisse tel quel, c'est pas une urgence. J'explorerai un peu plus loin la librairie jcoord-1.0.

phtanguy commented 11 years ago

Suite des tests lors des changements de zone (plus particulièrement pour le changement de fuseau)...

Plusieurs paramétrages sont possibles pour la transmission des données GPS. Ce paramétrage s'effectue au sein du fichier de config de l'appareil (Airframe dans Paparazzi Center), dans le cas de la simu, il s'agit du fichier microjet.xml. Ce paramétrages est documenté à l'URL : http://paparazzi.enac.fr/wiki/Subsystem/gps

J'ai testé trois de ces paramètres : ublox_utm (paramétrage initial, catastrophique au moins dans notre cas !), ublox et nmea. Pour l'instant, rien ne me semble totalement satisfaisant...

ublox_utm Dans ce paramétrage, deux problèmes :
- La coordonnée UTM "Est" change lors de changement de fuseau (normal !) mais le numéro du fuseau est transmis. Comme on ne changeait pas le fuseau (on prenait toujours le fuseau du point de départ), on se retrouvait avec un décalage de plusieurs centaines de km... J'ai fait la modif pour prendre en compte le fuseau dans ce qui est transmis sur le bus Ivy, on se retrouve donc avec un positionnement géographique cohérent.
- Lors du changement de fuseau, Paparazzi estime que rien ne va plus !!! Il affiche Microjet, mayday, kill mode. Ce mode semble donc inutilisable...
ublox Pas de problème dans Paparazzi qui n'est pas affecté par le changement de fuseau ni dans uav3i. Le problème, si c'en est un, est que la coordonnée UTM "Est" est donnée avec toujours par le même fuseau (celui d'origine). Dans le plan de vol de test (environ du Mans avec à la fois un changement de fuseau et de bande), on passe du fuseau 30 au 31 mais les références sont toujours données par rapport au fuseau 30. Peut-être un problème d'imprécision ? À voir...
nmea Exactement le même comportement que ublox.

Dans tous les cas, lors du build, j'obtiens le warning suivant : Warning: You are close (less than twice the max distance) to an UTM zone border ! The navigation will not work unless the GPS_USE_LATLONG flag is set and the GPS receiver configured to send the POSLLH message. Je n'ai pas trouvé dans la documentation quelque chose qui traite de GPS_USE_LATLONG. Contrairement à ce qui est annoncé, la navigation a l'air de fonctionner...

Pour le moment, il faut donc positionner dans le fichier microjet.xml le type à ublox à la ligne <subsystem name="gps" type="ublox"/>. J'ai commité la prise en compte de la transmission du fuseau même si ce n'est pas très utile dans le moment.

phtanguy commented 10 years ago

Problème réglé : une nouvelle clôture de ticket !

legras / uav3i