Noob questions on gps, navigation...

[Gil S]

 Hi folks:

First post here.  I am in the middle of a science fair project with my 14-yo son, to use an autonomous truck platform to investigate navigation algorithms.  I have been helping my kids with these fairs for seven years now, and we have always been able to run experiments over December break, but this year we need to get things done in a few short weeks, so we are scrambling to get something running.  Sadly, we won't be able to do as much as we would like in the shortened timeframe, but I am hoping to get a bit of insight from some folks here to help point us in the right direction.  I have read Wayne's stuff with great interest, and scoured to learn what I could from others running in the SF AVC, who are likely seeing the same problems we are.

As a quick bit of background, I am a 30+ year EE doing analog/digital/programming/layout and all that.  Last year for my daughter's sci fair we sent high-alt balloons to over 90Kft and had some good fun.  This year my son wants to do something cool with an AGV (autonomous ground vehicle, for lack of any commonly-used acronym we could find), but the schedule has pushed up on us.

What we have so far is a 1/10 scale Exceed RC Infinitive Truck, which seems like a quality chassis.  We added a platform on top for the controller (an Arduino Mega plugged under a custom board I did for HAB and future submersible ROV tests).  PWM control of motor and steering is easy enough.

First thing was to get the GPS and SD datalogging tested.  We are using an Adafruit Ultimate GPS, which worked great for HAB flights, but we cannot seem to get decent resolution for ground work.  I am using ladyada's parser, but am using the integer vars for better accuracy that the floats provide.  I have decimal degrees, am getting seven decimal places on both lat and long, and am pretty confident that they are mostly real digits.  I have the unit set to both fix and update at 5Hz.  I tried to enable waas, but never saw it enter that mode.  When I let the unit start up, it will get up to about 10 sats and an hdop of under 1.0 in 10 minutes or so, and if I grab some stationary data and plot it I see a scatter plot of a meter or two radius, which is not bad -- there is a larger lat/long offset, but that is easy to fix in excel before plotting.

But the gps problem is dynamic.  My first test was to let the gps get happy for a half hour or so, having decent stationary data, and then simply walk it around the yard.  What I got was a worthless skewed path, roughly in the shape of my walk, but smeared in both axes.  We ran another test today, driving the car around the perimeter of a basketball court in a park (see attached).  The plotted data, using the handy http://www.gpsvisualizer.com/map_input tool (not the kml version), kinda showed the rectangle, but distorted and skewed 50 feet north and 100 feet west.  Pretty worthless for being able to use any fixes during driving for navigation, imho.

My first question:  how are you guys using gps waypoints to guide you?  Do I just need a different gps unit?  I used this one since I had a couple, they worked reliably in extreme conditions, I got familiar enough to control them and even wrote my own parser for a pic.  But the data just seems to be crap for an AGV.  I could easily correct at start time for the offset, but the path just seems too distorted for nav.  I even considered a second stationary unit, a homebrew dgps if you will, sending updates to the AGV over an xbee link, but while that may remove some sat-propogation-distortion from the path, I am neither convinced it is worth the hassle, or really have time for it now.  But I would love to hear what you guys are doing with gps for nav.

So, having pretty much decided to rely on gps only for nice timestamps every 200ms on the sd card log, we moved on to a compass.  We are using a HMC5883 magna, corrected for declination, and it worked pretty well in open air.  Not so much on the truck chassis.  As we rotated the truck by 360 we saw something like 220 to 290 degrees at any point.  Hmm.  Pretty strong magnets in that motor.  Taking a cue from others, we mounted the mag 12" up on a post and the readings are pretty decent now.  Thought we might be just able to add a fixed deviation -- it is a bit more non-linear, but easy enough to interpolate the four quadrants to clean it up for a good heading.  So I got that going for me.

For distance measurement we have a trailing wheel gizmo made from lego parts (lots of stuff left over from years of FLL competitions).  A couple of neodyn magnets are glued to a gear and a hall-effect sensor is glued nearby.  We get two clean pulses per rev of the wheel, for about 3.5" resolution, and even corrected the cumulative distance for reversing.

We are hoping to be able to do some interesting nav tests with just the heading and distance. 

We considered obstacle avoidance, but I am unsure if we have time to add that in.  We have a maxsonar ultrasonic that seems pretty nice, and are considering mounting it on a servo to sweep some in the front.

Anyway, kind of a lot to do in a short time, but we will do what we can.  Any comments or pointers appreciated.

thx,  gil smith, af7ez

[Thomas Roell]

Comments embedded.

- Thomas

On Sunday, November 16, 2014 11:16:05 PM UTC-7, Gil S wrote:

First thing was to get the GPS and SD datalogging tested.  We are using an Adafruit Ultimate GPS, which worked great for HAB flights, but we cannot seem to get decent resolution for ground work.  I am using ladyada's parser, but am using the integer vars for better accuracy that the floats provide.  I have decimal degrees, am getting seven decimal places on both lat and long, and am pretty confident that they are mostly real digits.  I have the unit set to both fix and update at 5Hz.  I tried to enable waas, but never saw it enter that mode.  When I let the unit start up, it will get up to about 10 sats and an hdop of under 1.0 in 10 minutes or so, and if I grab some stationary data and plot it I see a scatter plot of a meter or two radius, which is not bad -- there is a larger lat/long offset, but that is easy to fix in excel before plotting.

There are a few gotchas with MT3339 based units.

WAAS/SBAS has to be selected and enabled via PMTK_API_SET_DGPS_MODE &  PMTK_API_SET_SBAS_ENABLED. There is also somewhere in the fine print that some MT3339 based units can do SBAS only with less than the max advertises 10Hz rate. I seem to recall that the Global Tech GPS unit that Adafruit is using says 5Hz, but I'd experiment. 

 

But the gps problem is dynamic.  My first test was to let the gps get happy for a half hour or so, having decent stationary data, and then simply walk it around the yard.  What I got was a worthless skewed path, roughly in the shape of my walk, but smeared in both axes.  We ran another test today, driving the car around the perimeter of a basketball court in a park (see attached).  The plotted data, using the handy http://www.gpsvisualizer.com/map_input tool (not the kml version), kinda showed the rectangle, but distorted and skewed 50 feet north and 100 feet west.  Pretty worthless for being able to use any fixes during driving for navigation, imho.

There are 2 possible issues going on. For one, the MediaTek based units have something called a static threshold. Unless you have some motion, they will not report any position deltas. I'm not sure why this would result in some wandering while being stationary, but I'd disabled that, just to be sure via  PMTK_API_SET_STATIC_NAV_THD.

The other minor detail is that MediaTek based units report only 4 digits fractional precision for longitude/latitude, which is about 18cm resolution at the equator. Here in my hometown Denver, this is roughly 14cm. So that is not that great to begin with as you will have quantization effects. Of course if your parser has rounding effects, then one LSB error will throw you off by 1 foot.

I had some code that I could share offline you might want to try out as to whether the problem is in the parser you are using or not. I am currently playing around with a similar unit to said Adafruit one (https://www.tindie.com/products/RobG/gps-boosterpack/), so there might be some more usable code in a week or so.

 

My first question:  how are you guys using gps waypoints to guide you?  Do I just need a different gps unit?  I used this one since I had a couple, they worked reliably in extreme conditions, I got familiar enough to control them and even wrote my own parser for a pic.  But the data just seems to be crap for an AGV.  I could easily correct at start time for the offset, but the path just seems too distorted for nav.  I even considered a second stationary unit, a homebrew dgps if you will, sending updates to the AGV over an xbee link, but while that may remove some sat-propogation-distortion from the path, I am neither convinced it is worth the hassle, or really have time for it now.  But I would love to hear what you guys are doing with gps for nav.

Depends upon whether you have time to order one ;-) I personally prefer UBLOX based units. I ran this here in 2014's AVC: http://www.aliexpress.com/item/VK16U6-ublox-GPS-Module-with-Antenna-TTL-Signal-Output-FZ0517-Free-Shipping-Dropshipping/922483051.html. For 2015 I will use the sucessor, the VK2828U7G5. Those units report one more fractional digit (1.8cm resolution) in NMEA mode, and do have a binary mode that allows 1cm resolution. Please note that the resolution does not have ANYTHING to do with precision, it will just avoid quantization effects, and get you to a say 2x2 cm grid, rather than a 20x20cm grid. The ones I cited have the cruical PPS output ... plus the EN pin to reset them. However I simply have not played enough with the MT3339 so really have any conclusive answer as to what is better. 

 

So, having pretty much decided to rely on gps only for nice timestamps every 200ms on the sd card log, we moved on to a compass.  We are using a HMC5883 magna, corrected for declination, and it worked pretty well in open air.  Not so much on the truck chassis.  As we rotated the truck by 360 we saw something like 220 to 290 degrees at any point.  Hmm.  Pretty strong magnets in that motor.  Taking a cue from others, we mounted the mag 12" up on a post and the readings are pretty decent now.  Thought we might be just able to add a fixed deviation -- it is a bit more non-linear, but easy enough to interpolate the four quadrants to clean it up for a good heading.  So I got that going for me.

Calibrating the magnetometer while the motor is running helps a lot. Mine was mounted diagonally opposite to the motor on the same plane (not raised). It was never off more than 10 degrees relative to the delay compensated heading the GPS reported. This was so usable that I dropped my complicated EKF for a GPS + Magnetometer solution.

- Thomas

[Gil S]

Hi Thomas:

Thanks for the input.  Regarding the waas issue, I sent this:

  // --- to get waas dgps:
  GPS.sendCommand("$PMTK313,1*2E\r\n");  // PMTK_API_SET_SBAS_ENABLED to enable search for SBAS satellite
  GPS.sendCommand("$PMTK513,1*28\r\n");  // PMTK_DT_SBAS_ENABLED to enabled
  GPS.sendCommand("$PMTK301,2*2E\r\n");  // PMTK_API_SET_DGPS_MODE to enable WAAS as DGPS Source

I did not send PMTK_API_SET_DGPS_MODE, so maybe that is it -- will try it when I get a chance.  Yes, 5Hz is the max rate according to the docs.  5Hz is also the max fix rate, so what is the point of a 10Hz update rate?  Twice the log size with redundant records?  I dunno.  I set rate with:

  // ----- set the gps update and fix rates (uncomment one rate pair):
  // --- 1 Hz rate:
  //#define PMTK_SET_NMEA_UPDATE  "$PMTK220,1000*1F"
  //#define PMTK_API_SET_FIX_CTL  "$PMTK300,1000,0,0,0,0*1C"
  // --- or 5 Hz rate:
  #define PMTK_SET_NMEA_UPDATE  "$PMTK220,200*2C"
  #define PMTK_API_SET_FIX_CTL  "$PMTK300,200,0,0,0,0*2F"
  //
  GPS.sendCommand(PMTK_SET_NMEA_UPDATE);
  GPS.sendCommand(PMTK_API_SET_FIX_CTL);

I will also look into the static threshold/PMTK_API_SET_STATIC_NAV_THD thing.


As for the precision, I am using the lib-provided 32-bit ints (GPS.latitude_fixed/GPS.longitude_fixed) to avoid the float rounding.  These were added to the adafruit lib by someone not too long ago, so if you have an earlier lib it may just have floats.  I peel off chars and format it to decimal minutes, getting seven digits after the radix.  I build it as a string since it goes into a csv file record, but I am not currently using it for nav (could just use the original ints for nav).  I'd be interested in the code you have -- does this forum pm?

  // ----- only if we have a fix (GPS.fix is true if RMC-status is 'A', and GPS.fixquality is from GGA:
  if( GPS.fix || GPS.fixquality )
  {
    // --- latitude field (orig DDMM.MMMM, now +/-DD.DDDDDDD):
    if (GPS.lat == 'S')
      currentLat = "-";
    else   
      currentLat = "";    
    // put int32 number into a string:
    ltoa(GPS.latitude_fixed, tmpCharArray, 10);
    // first two chars are degrees, plus add radix:
    currentLat += String(tmpCharArray[0]) + String(tmpCharArray[1]) + '.'; 
    // chars three to null are minutes:
    for (i=2; i<15; i++)                              
    {
      if (tmpCharArray[i])
        currentLat += String(tmpCharArray[i]);
      else
        break;
    }
    dataString += currentLat;  // add to log record
    dataString += ",";
(etc.  lon is the same except that the first three chars are degrees)


I see lots of folks seem to like the ublox.  Will need to try one, but won't have time for this project.  Why is PPS critical?  They all seem to have a PPS output.  Sounds like I need to learn a bunch more about gps to really know what is going on.

Thanks for the comments!

gil

[Thomas Roell]

Comments embedded.

- Thomas

On Monday, November 17, 2014 12:48:32 PM UTC-7, Gil S wrote:

Hi Thomas:

Thanks for the input.  Regarding the waas issue, I sent this:

  // --- to get waas dgps:
  GPS.sendCommand("$PMTK313,1*2E\r\n");  // PMTK_API_SET_SBAS_ENABLED to enable search for SBAS satellite
  GPS.sendCommand("$PMTK513,1*28\r\n");  // PMTK_DT_SBAS_ENABLED to enabled
  GPS.sendCommand("$PMTK301,2*2E\r\n");  // PMTK_API_SET_DGPS_MODE to enable WAAS as DGPS Source

I don't think PMTK513 is the right thing. That should be the answer to PMTK413, which is the query of what you set with PMTK313. 

I did not send PMTK_API_SET_DGPS_MODE, so maybe that is it -- will try it when I get a chance.  Yes, 5Hz is the max rate according to the docs.  5Hz is also the max fix rate, so what is the point of a 10Hz update rate?  Twice the log size with redundant records?  I dunno.  I set rate with:

  // ----- set the gps update and fix rates (uncomment one rate pair):
  // --- 1 Hz rate:
  //#define PMTK_SET_NMEA_UPDATE  "$PMTK220,1000*1F"
  //#define PMTK_API_SET_FIX_CTL  "$PMTK300,1000,0,0,0,0*1C"
  // --- or 5 Hz rate:
  #define PMTK_SET_NMEA_UPDATE  "$PMTK220,200*2C"
  #define PMTK_API_SET_FIX_CTL  "$PMTK300,200,0,0,0,0*2F"
  //
  GPS.sendCommand(PMTK_SET_NMEA_UPDATE);
  GPS.sendCommand(PMTK_API_SET_FIX_CTL);

Good questions. But I see you did find the duality of PMTK220 and PMTK300. 

I do have the sneaky suspicion that PMTK220 is a leftover from MT3329, and PMTK300 is for MT33xx. On the other hand, I have seen code that set 10Hz via PMTK220. 

I will also look into the static threshold/PMTK_API_SET_STATIC_NAV_THD thing.


As for the precision, I am using the lib-provided 32-bit ints (GPS.latitude_fixed/GPS.longitude_fixed) to avoid the float rounding.  These were added to the adafruit lib by someone not too long ago, so if you have an earlier lib it may just have floats.  I peel off chars and format it to decimal minutes, getting seven digits after the radix.  I build it as a string since it goes into a csv file record, but I am not currently using it for nav (could just use the original ints for nav).  I'd be interested in the code you have -- does this forum pm?

  // ----- only if we have a fix (GPS.fix is true if RMC-status is 'A', and GPS.fixquality is from GGA:
  if( GPS.fix || GPS.fixquality )
  {
    // --- latitude field (orig DDMM.MMMM, now +/-DD.DDDDDDD):
    if (GPS.lat == 'S')
      currentLat = "-";
    else   
      currentLat = "";    
    // put int32 number into a string:
    ltoa(GPS.latitude_fixed, tmpCharArray, 10);
    // first two chars are degrees, plus add radix:
    currentLat += String(tmpCharArray[0]) + String(tmpCharArray[1]) + '.'; 
    // chars three to null are minutes:
    for (i=2; i<15; i++)                              
    {
      if (tmpCharArray[i])
        currentLat += String(tmpCharArray[i]);
      else
        break;
    }
    dataString += currentLat;  // add to log record
    dataString += ",";
(etc.  lon is the same except that the first three chars are degrees)

No need to send. I was just pointing towards issues I had seen elsewhere. A good way to check is to log the NMEA GGA/RMC sentences along with your converted log and check whether the numbers match up.  

BTW, you don't get 7 digits after the radix. MT3339 sends xxxMM.MMMM, 6 digits. But not really full digits, as the MM. only goes to 59, not to 99 ... That means somewhere along the way you have to round ... You can scale by 1e7 for the final result, which is what ublox is doing in their binary protocol ...

 

I see lots of folks seem to like the ublox.  Will need to try one, but won't have time for this project.  Why is PPS critical?  They all seem to have a PPS output.  Sounds like I need to learn a bunch more about gps to really know what is going on.

There is a latency between when the position measurement is taken (which is the UTC time in the GGA/RMC sentence) and when you see it over the serial port. I have seen 220ms for a 5Hz config on MT3329. The PPS pulse is aligned to the full UTC second. This way you can compute/track the latency. 

Or you simply can measure the latency via a scope and then estimate it in your code for the MCU. 

[Thomas Roell]

It would be nice if I could edit my response ...

> BTW, you don't get 7 digits after the radix. MT3339 sends xxxMM.MMMM, 6 digits. But not really full digits, as the MM. only goes to 59, not to 99 ... That means  somewhere along the way you have to round ... You can scale by 1e7 for the final result, which is what ublox is doing in their binary protocol ...

That is a piss-pour way of saying that you accumulate first your MMMMMM (without the decimal point), then divide by 0.6 to compensate for the 0..59 range, and then scale by 10 to get your 7 digits after the radix. To compute that using integers one would do:

      (MMMMMM * 100 + 3) / 6;

That however does not change the fact that you have less than 6 digits of precision after the radix point, more like 5.778 ;-) But I guess that is nitpicking.

- Thomas

[Jon Watte]

In my (admittedly limited) experience:

GPS is great when you're at one waypoint, and need to make your way to another waypoint 10-100 meters away. Calculate a bearing, and off you go!

You'd need to use a compass or other mechanism to actually steer to that bearing.

Also, slow drift over seconds is pretty typical because the satellites move, and the atmosphere moves, and a GPS receiver isn't great at compensating for all the changes. WAAS makes it better, if you can get that to kick in. And, of course, RTK-style correction feeds, if you can afford them.

I'd be interested in hearing how well the lego-sprocket-with-magnets sensor holds up in real usage. Are you trying this outdoors? On grass, gravel, etc?

I saw someone paint black/white stripes on their drive shaft, and multiply by the gearing/wheel circumference to get distance traveled.

Finally, depending on what your goals are, would you want ultrasonic (ping) sensors? Great for indoors maze-type navigation.

Another sensor might be a MPU6050, which lets you get gyroscope and accelerometer. If you read them fast enough and integrate over time, they can be very good short-to-medium-time relative position, velocity, and orientation sources.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/39536f84-ecf4-4ed3-8b20-d8aeed740e72%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Gil S]

Hi Jon:

We are thinking of a course on a concrete basketball court, but if that is too small for the resolution we can get, we will likely move to an empty parking lot.  In either event, for this project, we will run on a hard surface (even though the truck can handle pretty rough terrain).  Some pics attached -- correction, I need to edit them down in photoshop apparently, so I will post in a little bit (sheesh google, ya can't just tweak them on the fly?).

The lego distance sensor is kinda crude, only having two magnets at 180 for about 3.5" (0.0878m) resolution, but looks like it works pretty well.  An interrupter with a dozen holes would have been better, but this was easy and I think enough resolution.  One wheel would have been adequate, but my son thought two made it look more like funny car wheelie bars.  Both are on the ground when level, and as the chassis squats in turns, one wheel is still on the ground at all times.  We thought we would need a little weight added to keep it down, but it looks like it tracks very well.  We count positive edges in forward, and negative edges in reverse, and swallow the first pulse after a direction change (you need to draw it out to make sense of that).  I doubt we need to account for much backing up, but it was easy to add in.

The driveshaft stripe idea is interesting, and completely inboard and averaged.  We did not want to add anything to truck wheels, and using just one outbound wheel will introduce some error when turning, so we just went with the wheelie bars.

I have a couple of ultrasonic sensors for possible obstacle use, and various other magna/gyro/accel/imu breakouts with which to play.  I don't really see a need for velocity (and could get that from the distance sensor and 200ms heartbeat).  I can see how compass heading is invaluable, of course, but how does a gyro or accelerometer assist in (not particularly fast) nav?

thx,  gil

[Gil S]

Just a few pics intended to be attached to my previous post.  Apparently google does not mind a 100GB pic, as long as the res is less than or equal to 2000x2000.

[Jon Watte]

Glad to hear the wheelie bar tracks well! Slipping or snagging were the things I was wondering about.

how does a gyro or accelerometer assist in (not particularly fast) nav

It gives you another independent source of input into your pose estimation filter. It often responds faster and with less short-term error than the magnet (no change when driving over a manhole cover or a rusty nail or a neighboring 'bot, for example.)

Anyway, it sounds like you're already well on your way. Are you going to try some robo-magellan with this? (flat course only, then)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/e0c86179-a83e-4390-9e68-d6fa1e4c31ea%40googlegroups.com.

[Jon Watte]

Also -- does the copper tape ground plane help? Was it a cure for some specific problem, or "just" based on good practice?

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

On Mon, Nov 17, 2014 at 7:36 PM, Gil S <google...@surlee.com> wrote:

Just a few pics intended to be attached to my previous post.  Apparently google does not mind a 100GB pic, as long as the res is less than or equal to 2000x2000.

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/cbd1a6c6-72cb-4986-902e-abcd25b98dc6%40googlegroups.com.

[Gil S]

Hi Jon:

Regarding your question about the groundplane: it is just an electrostatic shield so does nothing really for what I presume is the biggest problem, the magnetic field from motor (and now distance-sensor) magnets.  But it is always good practice imho, as I am a bit of an em nut from years of pcb design.  It may keep some motor noise out (it is a brushed motor), and it may help the gps patch antenna.  Hard to say, but easy to add.

As for the course and nav algorithms, that is up to my son.  I am acting as a mentor and providing the base hardware with the sensor/logging/servo stuff done to a reasonable degree, which is essentially one checkoff item on his materials list.  He had some nav ideas based on gps, but we currently don't have faith in those measurements.  He is talking now about trying some things using just distance and direction.  It will be a start-point to stop-point simple sort of run.

It was originally going to be a low-power rf beacon (uhf or higher) at the stop point, and we were going to mount a directional yagi or helical antenna on a servo to triangulate and RDF on the target (we are both hams and wanted to pull radio into it).  But no time for that now after the teacher moved up the deadline.

Then it was going to be a gps lat/long as the target -- the target location known to a function in the code, but not to the nav algorithm.  The nav routine could call the function to request distance from target (distance only, no bearing), and would need to get around obstacles as well.  This could have been interesting, but our gps data seems all over the place, so that seems out.  I still don't understand how you avc guys are able to use gps on those fast runs, but it likely is a matter of a better gps device, and more knowledge on my part.

Anyway, my son is now talking about some simple driving to compare different ways of getting from start to finish and avoid obstacles.  It will not likely be as interesting as we hoped at first, but it is a start.  After we crank out this project to fulfill the science fair need, we want to do some more interesting things with the truck.

I would like to learn more about the closed-loop control you guys are doing and how to integrate multiple sensors into a nav algorithm.  Can you point me to any sites that have decent explanations of this, or is it all rather proprietary?  I have a good handle on feedback systems from analog circuitry, still recall control system theory, dsp and such from a ways back, and would like to learn more about this whole field.

thx,  gil

[Gil S]

Hi folks:

Well, I got WAAS working on the adafruit ultimate gps, and now the path is much improved, as you can see from the attached before and after pictures.

We can likely get a gps nav run going now.

thx, gil

[Thomas Roell]

Looking way better. I do like your idea of walking the edges of an area which markings can be seen on google maps.

It is also interesting to see how the trees on the left affect the performance (I am assuming you walked a straight line there).

Have you turned on AIC ? MediaTek seems to be very proud of this technique.

- Thomas

--
You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/HZnFWfNStGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/2993845d-c830-452e-8391-c209171fcedb%40googlegroups.com.

[Gil S]

Hi Thomas:

Yes, I was walking straight around the court perimeter on the line, and then straight up the center.  Path still a bit distorted but looks usable so we will try some gps waypoint driving, use the compass for heading, and see how the distance compares to the expected gps point differences.  Baby steps.

Though I have used these adafruit (GlobalTop MT3339-based) ultimate gps units before, I have never needed to dig into the setup commands much until now.  So who exactly is MediaTek?  Do they provide the gps core and companies like GlobalTop wrap a controller around it?  It seems like multiple vendors use the mediatek parts, but only expose a subset of the commands based on what they want to provide, as I have found that the manual for the globaltop unit (adafuit) does not have commands I have found in other manuals such as from Linx, Sanav, and Quectel. 

A lot of misinformation out there as well, such as folks sending DT commands that will be ignored (which I now realize are query message responses as you pointed out), and sending commands that work for gps unit X but not on Y.  Anyway, I think I have the adafruit unit set up correctly now.  I added the AIC command, though it is said to be enabled by default (not all the defaults are defined, so I wanted to send everything that I may need).  I disabled the nav speed, though I believe that was the default anyway.  For WAAS, it indeed needs both PMTK301 and PMTK313, and may indeed need to be limited to 5Hz max rate, but 5Hz works for me anyway.  I set PMTK319 to "integrity mode" -- do you know what that does and if it is necessary or advantageous?  So here is my adafruit setup:

  // ----- set the gps fix/update rate to 5 Hz:
  GPS.sendCommand("$PMTK220,200*2C\r\n");
 
  // --- to get WAAS (Wide Area Augmentation System):
  GPS.sendCommand("$PMTK301,2*2E\r\n");  // PMTK_API_SET_DGPS_MODE to enable WAAS as DGPS Source (not RTCM)
  //
  // also need to enable SBAS (Satellite-based Augmentation System):

  GPS.sendCommand("$PMTK313,1*2E\r\n");  // PMTK_API_SET_SBAS_ENABLED to enable search for SBAS satellite

  //
  // really have no idea what this does or if it is necessary:
  GPS.sendCommand("$PMTK319,1*24\r\n");  // PMTK_API_SET_SBAS_Mode to integrity mode
 
  // ----- disable nav speed threshold:
  GPS.sendCommand("$PMTK386,0*23\r\n");   // PMTK_SET_Nav Speed threshold (set to 0 to disable)
 
  // ----- Active Interference Cancellation (AIC):
  GPS.sendCommand("$PMTK286,1*23\r\n");   // PMTK_CMD_AIC_MODE set to enabled

And just for completeness (to any other noobs like me) a quick summary on resolution:  This gps (like many others) returns degrees plus MM.MMMM.  That means the smallest resolvable minute is 00.0001, which is 00.0001/60 = 0.000001666666... degrees, which is, to the seven decimal places that the adafruit lib gives me (using the long ints GPS.latitude_fixed/GPS.longitude_fixed, not the floats that are normally used), ~ 0.0000017.  As Thomas pointed out, this is not seven- or even six-digit precision, but the seven digits should kept for accuracy, even though the min resolution is actually 0.0000017.  FWIW.

Thanks for your help,

gil

[Thomas Roell]

Comments embedded.

- Thomas

On Thursday, November 20, 2014 10:33:42 AM UTC-7, Gil S wrote:

Hi Thomas:

Yes, I was walking straight around the court perimeter on the line, and then straight up the center.  Path still a bit distorted but looks usable so we will try some gps waypoint driving, use the compass for heading, and see how the distance compares to the expected gps point differences.  Baby steps.

I'd try to find a GPS reference point close to you, get the coordinates your GPS returns at that position, and then compare it to what it should be, and where google maps puts the respective points.

 

Though I have used these adafruit (GlobalTop MT3339-based) ultimate gps units before, I have never needed to dig into the setup commands much until now.  So who exactly is MediaTek?  Do they provide the gps core and companies like GlobalTop wrap a controller around it?  It seems like multiple vendors use the mediatek parts, but only expose a subset of the commands based on what they want to provide, as I have found that the manual for the globaltop unit (adafuit) does not have commands I have found in other manuals such as from Linx, Sanav, and Quectel. 

MediaTek makes the SOCs that folks like GlobalTop and Quectel build then modules around. 

The subsetting ... I do not think that vendors actively subset the protocol, but they just do a very bad job of documenting. Sometimes it's also simply a different revision of the firmware. MT3339 can support QZSS for some markets, so there you'd have those commands exposed. MT3333 does GPS + GLONASS, and with some special firmware it does also BEIDOU, and perhaps GALILEO. So again special commands added for those.

 

A lot of misinformation out there as well, such as folks sending DT commands that will be ignored (which I now realize are query message responses as you pointed out), and sending commands that work for gps unit X but not on Y.  Anyway, I think I have the adafruit unit set up correctly now.  I added the AIC command, though it is said to be enabled by default (not all the defaults are defined, so I wanted to send everything that I may need).  I disabled the nav speed, though I believe that was the default anyway.  For WAAS, it indeed needs both PMTK301 and PMTK313, and may indeed need to be limited to 5Hz max rate, but 5Hz works for me anyway.  I set PMTK319 to "integrity mode" -- do you know what that does and if it is necessary or advantageous?  So here is my adafruit setup:

"Integrity mode". I think I understand what it does but not the right nomenclature. Some WAAS Satellites may be in a test phase, which they signal in the data they send out. I suppose with PMTK319 you can disable the ones that are in this test state. I had not run across this one on any MediatTek device though ;-)

The defaults. I tend to set up my GPSes from scratch. Never trust a default (especially in such lousy documentation). Also some units do have PMTK390, which allows you to save some default options. So no telling what had been set before. 

http://www.u-blox.com/images/downloads/Product_Docs/NMEA-CommandManual_%28FTX-HW-13002%29.pdf.

Ah, and here yet another reference, which seems to come directly from the source:

http://www.zhiwucom.com/wp-content/download/GX601/%E8%87%B4%E7%89%A9%E9%80%9A%E4%BF%A1GNSS%E6%A8%A1%E5%9D%97NMEA%20%E5%8D%8F%E8%AE%AE%E6%8C%87%E4%BB%A4%E9%9B%86.pdf

[wholder]

Yes, GPS can be maddeningly frustrating.  The problem is that consumer grade, L1 GPS receivers are only accurate to a few meters or so under the best conditions.  And, true differential GPS is hard to do.  You can't simply use one receivers coords as a reference for another because each receiver may be picking up a different set of satellites.  The correct way to do differential GPS requires a receives that can output RAW messages of the sats psuedo-range and carrier phase measurements.  These can then be fed into software, such as RTKLIB, to compute and broadcast corrections messages (at the base) and then apply them at the rover.  But, both ends needs to be running RTKLIB which requires a bit of compute power to work.  However, there are now several projects that are working on to mastered this approach using either custom hardware (Piksi), the Beagle Bone, or the Raspberry Pi. 

There are a few things you can do to marginally improve your results with consumer GPS modules.  Other than using true RTK differential corrections, there's not much you can do about the "wandering" problem, as I call it.  This is the drunk's walk the reported location seems to do around a fixed position in response to changing atmospheric conditions and movement of the sats. The other enemy is multi path, which causes larger jumps due to reflected signals.  And, you have to consider trees and buildings that can blocking signals, or cause them to fade in strength.  A better antenna, such as the http://www.tallysman.com/TW2105.php can help, but you'll need a receiver that supports connecting an external antenna as well as one that can supply power to its built-in preamp.  If your receiver supports it, you can also fiddle with settings that tell the GPS receiver how high a sat has to be above the horizon before it can use it to computer a solution as a way to mitigate interference from trees and buildings.  However, this can backfire situations where there are not enough sats in view to compute a good solution.

Wayne

[Jon Watte]

You can get RTK data from the NS-RAW: http://navspark.mybigcommerce.com/ns-raw-carrier-phase-raw-measurement-output-gps-receiver/

I have two of those, and they work, if you have good antennas. I have a quad-core Intel on my rover, and a dual-core Intel in my laptop/tablet, which is way overkill for RTKLib alone :-) (A Raspberry Pi A+ would be quite sufficient I think.)

Second, L1 + L2 reception can be had for $25 or so from the NS-GL: http://navspark.mybigcommerce.com/navspark-gl-arduino-compatible-development-board-with-gps-glonass/

Still, the quality of your antenna and the amount of shrouding buildings/trees will significantly impact the performance.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/a7658fff-e78e-4b94-8f63-5fba7a6c5af7%40googlegroups.com.

[Gil S]

Hi Wayne and Jon:

Sheesh.  I was just getting comfortable with the new things I learned about gps, and you guys had to add extra stuff about diff-gps/rtk to make my brain hurt :)  I had originally thought that a stationary station could be used to send lat/long to a moving station to cancel out propagation effects, but it is apparently quite a bit more complicated than that.  For the moment I am just going to be happy with the improvement that waas added to my single gps, and see what we can do with that. 

Good point on an external antenna though -- that adafruit module has a uFL connector for an active antenna.  I have one sitting on my window ledge that I connect for faster acquisition when I am working inside.  Probably worth mounting that antenna on the truck, as it is a negligible amount of weight and power.

We won't have buildings with which to contend, but some adjacent trees could affect low sats, I suppose.  Just have to live with that.

Hopefully we have enough sensor info to do a first nav test soon.  Still lots to do...

thx,  gil

[Thomas Roell]

Wayne,

the GPS is question is a MediaTek. It's CEP is reported by u-blox (which had used them for the acquired Fastrax units) as 3.0m with SBAS. They don't have the fine tuning options that a UBLOX6/UBLOX7/UBLOX8 has. The filtering is geared toward a driving car (read asset tracking). So they are not really optimal for the fast at had, but they are cheap (a Quectel L80 POT module can be bought for $10).

It's however an interesting thought of putting say a MAX-7Q and a MPU9150 onto a combine PCB and just use an external antenna.

- Thomas

[Ted Meyers]

Heh, GPS is so frustrating.  There sure is a lot to learn and experiment with when using it, but nothing about it seems intuitive.  One day it will be working great and the next day it will fall apart, with no obvious reason why.  And, it would be so much more useful if it were just a bit more accurate and reliable!

I second the use of an external antenna (with a ground plane).  It really does help, a lot.

[Gil S]

Hmm. Lat/Long so big, and distances so small.

In ruminating over distance/bearing calcs, I had an idea to avoid the nasty calculations somewhat.  I also only have single-precision floats avail, and it sounds like doubles are needed to do things with enough accuracy for short distances.  But that is just the thing:  these calcs are more for aircraft nav distances, spherical Earth model and all that.  Why bother?

The flat-Earth model obviously applies on a small course, so that helps.  I want to take the seven-decimal-place long-integer latitude MMDDDDDDD and longitude MMMDDDDDDD from my adafruit gps lib, extract the lower five digits from latitude and lower four digits from longitude, convert to an XY coordinate system wrt the SW corner of a pre-determined bounding box with simple integer math, and then use easy math to get distance and bearing between points.  No double-floats or nasty equations needed.

First, manually determine a rectangular bounding box around the course:
----------------------------------------------------
- I used http://www.mapcoordinates.net/en to zoom into area of interest, click on points and get lat/long as decimal degrees to 8 decimal places (round to 7) -- try to get four bounding corners oriented N-S and E-W.

- use https://maps.yahoo.com to test and refined coords (yahoo still has good sat view, but std google maps is forcing crappy Earth on me)

- test plot that with http://www.gpsvisualizer.com/map_input?form=google (just paste it into the box and draw)

- we now have a rectangular bounding area with knowm lat/long to seven decimal places that is oriented to the path-drawing
  program we have been using (gpsvisualizer).

- so my basketball court corners (see attached pic):
latitude, longitude
33.2809465,-111.8687895  (SW)
33.2811845,-111.8687895  (NW)
33.2811845,-111.8686345  (NE)
33.2809465,-111.8686345  (SE)

- now strip off the the lower five digits of latitude and lower four digits of longitude:
trim-lat, trimmed_long
09465,7895  (SW)
11845,7895  (NW)
11845,6345  (NE)
09465,6345  (SE)

- reverse lat,long to long,lat so it is a more-logical x,y, and make lower-left corner (SW) the 0,0 datum (reverse long calc for pos number):
horiz = 7895-trim-long, vert = trim-lat-9465
   0,0     (SW)
   0,2380  (NW)
1550,2380  (NE)
1550,0     (SE)

>>> no code yet -- this is just manually-hard-coded into program as my bounding box for the run (car can still exceed this box)


Second, while the car is running a nav algorithm inside (or even outside) the bounding box:
-----------------------------------------------------------------------------------
- in real-time we calc current horiz point:  get long-integer longitude from gps lib as, for example: current_long = 1118687210, so
  trimmed_long = current_long - ( (current_long/10000) * 10000 );  // want lower four digits from longitude
    which will be 7210 after simple integer arithmetic, then:
  horiz = 7895 - trimmed_long;
    which is 685 horizontal in our new coord system (wrt 0,0 in SW corner)

- and also calc current vert point:  get long-integer latitude from gps lib as, for example: current_lat = 332810165, so
  trimmed_lat = current_lat - ( (current_lat/100000) * 100000 );  // want lower five digits from latitude
    which will be 10165 after simple integer arithmetic, then:
  vert = trimmed_lat - 9465;
    which is 700 vertical in our new coord system (wrt 0,0 in SW corner)

>>> very fast integer calculations, easy-peasy XY coordinate system, small numbers.


Distance and bearing between two XY pairs:
------------------------------------------
- flat-earth distance is simple:
  SQRT ( (0.0095*delta_X)^2 + (0.01109*delta_Y)^2 ) ;
   where delta_X (long) and delta_Y (lat) is multiplied by meters/degree^-7 (shown for my 33 degree lat from an faa chart)

- bearing is now just simple trig using the two XY pairs

Am I just crazy, or is this nice and simple for a small course, using small numbers and fast calcs?
gil

[Thomas Roell]

Why not using the FLAT Earth model directly ?

I mean it's then down to (lat - home_lat) * scale_lat. If you stay within +/- 100m of the home location, then the delta will be less than 16bit. You you can express scale_lat using fixed point ...

For flat earth, I also have been seeing this in OpenPilot:

			// Compute matrix to convert deltaLLA to NED
			float lat, alt;
			lat = homeLocation.Latitude / 10.0e6f * DEG2RAD;
			alt = homeLocation.Altitude;

			T[0] = alt+6.378137E6f;
			T[1] = cosf(lat)*(alt+6.378137E6f);
			T[2] = -1.0f;

And then:

/**
 * @brief Convert the GPS LLA position into NED coordinates
 * @note this method uses a taylor expansion around the home coordinates
 * to convert to NED which allows it to be done with all floating
 * calculations
 * @param[in] Current lat-lon coordinates on WGS84 ellipsoid, altitude referenced to MSL geoid (likely EGM 1996, but no guarantees)
 * @param[out] NED frame coordinates
 * @returns 0 for success, -1 for failure
 */
float T[3];
static int32_t getNED(GPSPositionData * gpsPosition, float * NED)
{
	float dL[3] = {(gpsPosition->Latitude - homeLocation.Latitude) / 10.0e6f * DEG2RAD,
                   (gpsPosition->Longitude - homeLocation.Longitude) / 10.0e6f * DEG2RAD,
                   (gpsPosition->Altitude - homeLocation.Altitude)};

	NED[0] = T[0] * dL[0];
	NED[1] = T[1] * dL[1];
	NED[2] = T[2] * dL[2];

	return 0;
}

Worked nicely for me before I switched to a more precise computation of T[].

- Thomas 

[Jon Watte]

Flat earth (using lat/lon directly) can work very well for small areas, if you compensate for the stretch of latitude over longitude.

If you don't compensate for the stretch, the four cardinal directions will still be calculated correctly, but diagonal bearings will be many degrees off.

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/fc13eee0-4c44-44f1-85ce-16b1468ca685%40googlegroups.com.

[Andy Sloane]

My GPS (using a SiRF GPS in binary mode) can output ECEF xyz coordinates to cm precision (but pretty far from cm accuracy!), so my idea was to project them onto the local WGS84 tangent plane and use that as my flat earth coordinates. That seems a bit simpler than worrying about angular conversions to me. Anyone else doing that?

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAJgyHGOT_-miDbERFvDXz7-ucg82x8ujF1Jy%2BzvMBeCgbbDbiw%40mail.gmail.com.

[Thomas Roell]

SiRF binary has a 1m resolution in ECEF for position and 0.125m for velocity (if you use "Measure Navigation Data Out"). Not sure this is too usable to begin with.

There is also "Geodetic Navigation Data" (Message ID 41), which will give you LLA in the usual 1e7 scale for Longitude & Latitude, and 1e2 for altitude. So that seems to be more precise, 1cm resolution.

Anyway to convert from ECEF to a Local Tangent Plane or Flat Earth model, IMHO you need "double" precision at every single position conversion.  LLA to Flat Earth can be done using a simple "single" precision scaling operation. LLA to Local Tangent Plane is also not that tricky, but also required "double" precision floats. The thing is that a lot of lowend system (read Arduino) do not seem to have proper "double" precision support. And higher end MCUs like Cortex-M4F have only FPU support for "single" precision.

 - Thomas

[Jon Watte]

higher end MCUs like Cortex-M4F have only FPU support for "single" precision

True. That FPU can still be used to accelerate the software support for 64-bit doubles.

Given that you'll only be doing a dozen of those double operations per sample, and only sample a handful of times per second, spread across the hundred megahertz clock frequency, the cost in CPU cycles isn't particularly taxing..

Then again, an Intel Quark, with full Pentium instruction set (thus including x87,) is < $10 in singles. And the Edison even contains a full dual-core Atom, plus a Quark...

If you can pay the slightly higher power draw (2-3 watts) these chips seem very nice for math :-)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/d4e2bd3c-a50d-4832-a38e-db0879f1f27e%40googlegroups.com.

[Thomas Roell]

oComments embedded.

On Saturday, November 22, 2014 12:22:51 PM UTC-7, Jon Watte wrote:

higher end MCUs like Cortex-M4F have only FPU support for "single" precision

True. That FPU can still be used to accelerate the software support for 64-bit doubles.

I don't think so. The FPU in the Cortex-M4F is just the FPU, no NEON. So to do 64 bit doubles you have to go back and use integer arithmetic, and a lot of shifting ;-) 

 

Given that you'll only be doing a dozen of those double operations per sample, and only sample a handful of times per second, spread across the hundred megahertz clock frequency, the cost in CPU cycles isn't particularly taxing..

I honestly have no idea of how big the impact would be. Here an excerpt from a paper where somebody bolted a FPU onto a Cortex-M1 (so it's not really apples to apples):

Performance results show speedups from 8.8x up 17.6x for

single precision and 13.4x to 53.2x for double precision as

compared against a software FP emulation library, depending

on the FP operation

However my point really was more geared towards the notion that if it could be done in single precision, why not just use single precision ?

 

Then again, an Intel Quark, with full Pentium instruction set (thus including x87,) is < $10 in singles. And the Edison even contains a full dual-core Atom, plus a Quark...

If you can pay the slightly higher power draw (2-3 watts) these chips seem very nice for math :-)

You can always throw more CPU horsepower at the problem. I personally find it more fun to get a 80MHz Cortex-M4F do the same thing. 

[Jon Watte]

if it could be done in single precision, why not just use single precision

If you get the data out in a format that has suitable precision, then that's great!

Single precision, at the surface of the earth, has a quantium size of about a meter and a half, though.

If you get 32 bits of resolution (rather than 32) because of integral values, then that should be sufficient.

(Or was that 75 centimeters? I forget -- I did GIS and rendering software 10 years ago.)

 I personally find it more fun to get a 80MHz Cortex-M4F do the same thing

Absolutely! Any hobby is a careful balance of what kinds of problems you really want to be working on, how much money you want to spend, and how much time you have :-)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/d913bb17-2df7-4341-978a-a601f0f73b80%40googlegroups.com.

[Thomas Roell]

Jon,

it all depends upon which coordinate system you are using. If you use either Flat Earth or a Local Tangent Plane system, then you have a local reference point. Using single precision that would give you a 16km radius where you still had 1mm resolution (or as you said quantum). If you use a global coordinate system, like ECEF that of course will require either double precision representation, or tricky 32 bit integer arithmetic.

If you think about it, ECEF is a local coordinate system as well, it just has it's reference point in the center of the earth. Same goes for the WGS84, which has it's reference point in Greenwich (well 0,0 is really in the sea somewhere off Africa ;-)). So a Flat Earth or Local Tangent Plane system is just a cordinate system transformation that rotates the origin, taking the elliptic shade of the earth into consideration.

- Thomas

PS: I like your statement about hobbies. For me sadly the priority order is somewhat different. Time seems to be the critical path ;-) 

[Thomas Roell]

I forgot to add a reference to yet another transformation. ECEF to LTP (or ecef2ned as it's called sometimes):

http://psas.pdx.edu/CoordinateSystem/Latitude_to_LocalTangent.pdf

The assumption is that you have a reference point in LLA notation. The conversion produces a matrix R and a ECEF reference point Xo, so that you can use Xt = R * (Xe - Xo), whereby Xe is the ECEF coordinate you want to convert. Xe and Xo could be expressed in 32 bit integers, like in the UBX binary protocol, with 1cm precision. Hence R can be a 3x3 matrix with single precision. The only downside is that in reality you'd start with Xo, which means you also need to transform Xo first into LLA form. 

Is this more precise than lla2fat ? No idea. LLA with 32 bit integers and a 1e7 scaling has a resolution of 1.1cm at the equator, or 0.96cm where I live. Guess it depends on the conversion that the GPS in question does. It seems logical that a GPS uses internally ECEF ...

[Andy Sloane]

I was using a uBlox GPS prior to grabbing a cheapo SiRF one for testing; IIRC that one had (_had_ because I accidentally plugged power/ground in backwards, now it's a heater instead) cm precision in its binary protocol, and you're right, this SiRF thing is basically not usable except as a rough location estimate.

Anyway, I dispute that you need double-precision floats. You can subtract your 3D center from the 32-bit integer ECEF coordinates first, and then apply the local tangent plane dot products.

To do the WGS84 conversion to get the local normal vector, you only need to stretch Z: it's ultimately defined as z += z * 1/(298.257223563 - 1); so the conversion would be pretty damn close if you just use z += z/297 and used fixed point math. But anyway, once you have that, the rest is a few cross productions and normalizations, and you only need to do it once and you can save a transformation matrix to use from then on.

Admittedly, not nearly as simple as using the angles coming right off the GPS. But the whole thing can definitely be done with integer math on an AVR.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/fd412a26-5e1b-4703-8e1a-659863909f7e%40googlegroups.com.

[Thomas Roell]

Yes, you are right. 

I had corrected myself and posted that to do ECEF to LTP you only need a 3x3 matrix which can be floats (or probable fixed point as well). I had not seen that before, only the more direct way using a variant of Haversine. The setup of the matrix does not really concern me that much as to it's complexity or use of doubles. 

Would be time to compare the output of the results LLA -> Flat and ECEF -> LTP ;-)

- Thomas

[Jon Watte]

You can subtract your 3D center from the 32-bit integer ECEF coordinates first

Right -- that can't be done in floating point, so you'd need /something/ higher resolution than float.

If you get data in 32-bit int, then use that :-)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CA%2Bm0WZ%2B%3DZC6bnA%2BwLmOCokvwtFCwRUsMVUEZJcdL%3D3YTou3vVg%40mail.gmail.com.

[Thomas Roell]

Looks like my reply got lost.

First off the SiRF. It should not be that bad if you can use the "Geodetic Navigation Data" message (http://www.usglobalsat.com/downloads/SiRF_Binary_Protocol.pdf, page 3-40. I found here some code that uses this packet, so it must be available ... http://svn.umnaem.webfactional.com/branches/Sensor%20Integration/GPS_Test/gps_sirf.c.

In any case a NMEA 183 parser might just as well give the same resolution.

You are also right about the ECEF to LTP conversion. I had not seen the approach via a 3x3 matrix and the offsetting from a reference point. So yes, that can be done using single precision, or perhaps even integers. Maybe I'll get the time to try out what is more accurate (LLA -> Flat Earth, or ECEF -> LTP).

- Thomas

On Monday, November 24, 2014 8:52:10 AM UTC-7, Andy Sloane wrote:

[Gil S]

Hi folks:

An update on my son's science fair rover project.  We ended up taking the simplest approach to using the gps data, with no matrices, some single-prec floating point math and 32-bit integer math.  The attached pics will give you a comparison of simple dead-reckoning runs vs the gps runs.

We are using the adafruit ultimate gps, with a ground plane, and just the built-in patch antenna.  The unit is configured for 5Hz, WAAS mode and we are reading the 32-bit integer lat/long (not the default floats).  These ints have 7 decimal places of degrees (which, as per previous discussions is technically under 6 places of accuracy), so we have degrees*1e7 (lon is DDDddddddd, lat is DDddddddd).

Before running, we monitor an lcd display that shows number of sats, wass or std mode, and hdop.  Within ten minutes or so of cold-start we were generally getting 8 or 9 sats, wass mode, and an hdop of 0.8 to 1.0. 

The compass is a standard HMC5883, mounted 12"up on a wood dowel, with I2C lines appropriately twisted (scl/gnd, sda/pwr).  Even 12" up, and with declination correction, the compass was off more than 10 degrees at spots, in a non-linear way.  We manually took readings at 0/90/180/270 and did linear-interpolation in each of the four quadrants, and it became quite accurate.  We used degrees instead of radians.  The pole looks kinda goofy -- maybe a flag would help that :)

The steering on the truck is a bit sloppy, and we just use steering rules with a 4-degree deadband, full-lock steering over 25 degrees bearing error, and proportional steering in between.  The deadband is likely the main source of error on the dead-reckoning runs, but we could not change many variables (and did not have time to).  Distance sensing was a little trailing wheel/two-neodyn-mags/hall-sensor.

We were running in a high school parking lot that was wide open and clear of buildings and trees, and with nice painted lines so we could find our previously-planned waypoints.  It was a simple rectangular path 45 x 35 meters.

The nav routine was dead simple, and running every 200ms along with the gps updates (pseudo code here):

    if at waypoint, get_distance_and_bearing_to_next_gps_waypoint(waypoint)
    if (not at waypoint yet, which is within a meter)
    {
       get bearing error (wpBearingError = wpBearing - compassHeading, and then correct for -180 to +180)
       update steering servo with rules
    }

The lat/lon simplification is a result of simply subtracting the gps and waypoint integers for a difference (in degrees*1e7).

void get_distance_and_bearing_to_next_gps_waypoint(uint8_t waypoint)
{
  // --- calc deltas from current location to next waypoint (in degrees*1e7):
  deltaH = GPS.longitude_fixed - gpsWaypoint[waypoint].lon32;   // positive = east (we don't have negative signs included)
  deltaV = gpsWaypoint[waypoint].lat32 - GPS.latitude_fixed;    // positive = north  
  //
  // --- calc distance to next waypoint (in meters):
  // deltas are multiplied by meters/degree*1e7 (horiz and vert conversion is specific to local latitude)
  wpDistance = sqrt ( sq(METERS_PER_DEG7_HORIZ * (float)(deltaH)) + sq(METERS_PER_DEG7_VERT * (float)(deltaV)) ) ;
  //
  // --- calc bearing to next waypoint (in degrees):
  wpBearing = (uint16_t)( atan2 ( deltaV, deltaH ) * 57.296 );  // 180/pi = 57.296, so now is -180 to 180 deg
  wpBearing = 90 - wpBearing;                                   // now -90 to 270 (NE, SE, and SW quadrants ok)
  if (wpBearing < 0)                                            // correct for NW quadrant
    wpBearing += 360;
}

The easiest next improvement would be to let the unit sit on the start point, watch for lat/lon to stabilize, and then store that lat/lon when the go button is pressed, and using the deltas of the start point vs the theoretical as an offset to correct subsequent gps readings.  But once wass was enabled, it didn't really seem necessary.

Anyway, just thought I would share results of our experiment.  Thanks to all who helped me understand some of the details of how it is done in the AVC world.  I would like to try some of the more complicated algorithms, and a better gps some day.

thx, gil

[Gil S]

oops, small error on my last post.  I implied that we only calc distance/bearing to next waypoint when at a waypoint, but that is not true.  When at a waypoint, we do indeed get data for the next one, but inside the 200ms nav loop we are constantly refining distance/bearing to current waypoint with a call to the same function.

gil

[Jon Watte]

Nice!

What is the value you actually plotted? As in, did you plot the GPS output position, or did you have some other way of tying car-location to earth?

Or, put another way: I believe these pictures tell you where the GPS "thought" it was, so is there a way to tell what the actual error is?

(You could put a GoPro on a tethered balloon, for example :-)

Sincerely,

jw

Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/d75aa6c7-dd21-4d93-bb86-e653c45ebf2e%40googlegroups.com.

[Thomas Roell]

Jon,

that is a nagging problem for me. Other than a hot-air-ballon with a camera, what feasable approaches are there ?

Is there perhaps a beacon commercially available that could be use for simple triangulation ?

- Thomaa

You received this message because you are subscribed to a topic in the Google Groups "diyrovers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/diyrovers/HZnFWfNStGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to diyrovers+...@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/CAJgyHGOtyAakXcS00CJiAFrWPbdieoEPFaMChwB8oFGU4sk4ig%40mail.gmail.com.

[Gil S]

Hi Jon:

GPS and other data is saved on an sd card as a csv file.  Need to clean it up in excel as there are not-that-infrequent bogus lats or lons -- initial plots often show the truck going straight west from AZ into the middle of the Pacific and back, north into a mountain and back, etc :)  A bit of a pain to edit, but not too bad. I would just paste the previous lat/lon (200 ms earlier) data in the bogus spot.

The plots are using gpsvisualizer.com with google maps (not earth).  It is easy to just import multiple xls files with stored lat/lon data, and/or a text file with waypoints, and plot it all together.  I first refined the waypoints and plotted them so they appeared exactly where they should be on the plot (we had nice painted line intersections on the ground).

As to how accurate the plots are, well, we videoed and watched the turns and they were quite good.  I let my son do the running after it to watch.  A decent indicator is the plotted start and stop points.  While the start points (the run started on the west side, going north) are a bit spread out, the stop points are almost exactly at the initial/finish waypoint -- indeed on eight runs the car stopped within a meter of my feet as I stood at the start/stop point.

I'm sure there is some error, but the plots were perfectly good for this project, and pretty indicative of just how the truck drove the course.

I have a balloon, and a tank of helium, but that is saved for a 100K-ft trip, hopefully next month.  Our 5th, and probably final hab flight.  Should have gotten some of my ham buddies out for the truck runs, as they sometimes use a tethered balloon to lift an HF antenna wire to work Europe, and we could have added my little mobius cam.  Next time.

gil