Blogs

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Lew Payne April 8, 2010 at 9:18am
    Notice I made it a point, for the most part, to add quotes when I used the word "average." The reason for that is because I concur that, as pointed out by Scott Plunkett, some GPS units (particularly those with faster and more capable micros) are performing higher-order statistical calculations as their form of "averaging." It's a mixed bag, and short of writing your own processing engine (decoding, correlation, etc)... you simply don't know what you're getting.

    Regardless of, as Mark Psiaki of Cornell points out in his paper (referenced above), we can all agree that each output (post-processed reading delivered to the consumer) is a straight-line vector (assuming there's motion of the body). Furthermore, that straight-line vector is "averaged" (note use of quotes), yielding multiple line segments that lag in the case of any non-vector movements of the body. Thus, over a short period of time, turns and such are much better integrated by IMU/AHRS than by GPS.

    Again, that leads to a situation in which a higher refresh rate "feels good" but produces possibly worse results than simply allowing IMU/AHRS readings to prevail for that tenth of a second.
  • T Shaw April 8, 2010 at 6:06am
    If the n-period averaging performed by the GPS is indeed fixed, surely that means that all position estimates should have statistically similar standard errors? In which case, I'll take the higher rate.

    I'm pretty sure that the GPS doesn't just take an average though. Did we not used to be able to get data sheets that show the standard error as a function of velocity? If I remember correctly (which is unlikely), the standard error appears relatively high when stationary or near stationary (and hence differential correction becomes necessary) however it drops off very quickly ie. well below the flying speed of most model aircraft.

    As to whether or not my model's transfer function can actually convert this increase in postion rate into an increase in accuracy when following a track - I just don't know. In which case any benefits from the higher rate will be lost, in additional I have the massive additional computational load on my micro.

    Perhaps someone in the community has some track plots with 1Hz, 4Hz and 10Hz modules connected to their autopilots. Some empirical results might point the way.....
  • Lew Payne April 7, 2010 at 10:55pm
    By the same token, the GPS unit is continually receiving (assuming PLL lock) and "averaging" the GPS signals, regardless of the actual output rate to the consumer. The decay period for such "averaging" is fixed, regardless of output rate. Thus, faster (output) is not necessarily better, as each output does not "reset" the averaging! If you take raw satellite output data (including stratum and quantum correction data) and run it through a RINEX2 format conversion so you can see what's going on before processing, you can observe the location stratas jumping all over the place while you remain still. That's what's being averaged (or processed), regardless of your "output" rate.

    From another perspective, most quality IMU/AHRS units (including hobbyist ones) can easily track for several seconds (if not minutes) without egregious accumulated errors. As a result, a high GPS refresh rate is simply unnecessary and of no benefit.

    Please correct me if I'm wrong.
  • Scott Plunkett April 7, 2010 at 8:36pm
    Ground speed really has nothing to do with the equation...each GPS module has a minimum speed at which it can "accurately" estimate the heading...once that threshold is reached, it very quickly trends toward its highest capable degree of accuracy...so that said (some of the spec sheets will even have this listed as a number in feet or meters per second) it does seem logical that if the GPS unit is updating at a higher rate, it is calculating its position at a higher rate...so those averages are including more data points - the assumption being made is that if you have a choice between having one calculation per second - which as you point out is made up of several smoothed (rarely simply averaged - some even weight the calculations based upon geometry and or signal strength) readings (really calculations) - and ten calculations {which would be made up of ten times as many smoothed "readings"} you would want the higher number if only because it gives you MORE data with which to "correct" the AHRS heading information.

    Think of it like this...if you are driving your car at 100 mph down the road and I say you can only change the direction once a second and you come to a curve you might well make the curve, but it would look more like two or three jerky turns to a new heading...then if I say you can change heading ten times per second...it would smooth out quite a bit...SO then you say well, what if I take it at 10 mph instead {your premise that we use relatively slow moving drones}...then I cover less distance in each second and I have a smoother curve than I did at 100 mph, which is accurate - but then at 10mph AND with changing heading ten times per second, the path would be a pretty smooth line through the curve - THAT is what people are looking for...at any speed, a smoother line.

    I guess the thing that always bothers me when we discuss the "inaccuracies" of GPS is that we are ignoring the fact that these devices are receiving AND tracking a signal that is pumped out at only 50 watts or less from over a dozen satellites simultaneously that are over 11,000 miles up and moving at just over 7,000 miles per hour through more than half a dozen different tracks....then calculating (based upon very simple almanac and ephemeris data) a position several times, smoothing it using the same data - then outputting it several times PER SECOND! ((Sorry got off on a little rant there))

    Anyway...it's not like being a sniper where "Slow is smooth, smooth is fast, slow is fast" - it is more like being a machine gunner where "the only thing better than a larger caliber is more rounds per minute."
  • Lew Payne April 7, 2010 at 2:12pm
    "I just know that if this thin was relatively easy to configure, it would be pretty sweet to have a GPS on a drone with a 10hz update rate."

    Why would a higher GPS update rate be desirable on a relatively slow-flying drone? I fail to understand why people keep saying that. Considering the error margin that GPS exhibits, and the fact that it averages several readings (which, when taken individually, are quite jumpy), especially for still or slow-moving craft, I can see the desire for the exact opposite - a slower GPS refresh rate (1 Hz) to dead-reckon IMU/AHRS data.

    Ideally, I can see how varying the GPS update rate according to ground speed might be beneficial... the slower updates (1 Hz) taking place at slow speeds, and the faster (up to around 4Hz) taking place at higher speeds. The more distance that's covered, the less significant the inherent GPS error.

    If there's something I'm missing in the above theoretical analysis, I'd sure love to learn about it.
  • Scott Plunkett April 7, 2010 at 9:31am
    @All - This IS a Venus chipset which is designed by SkyTraq (a fabless company similar to MediaTek) It DOES have a Binary mode...called SkyTraq Binary (similar to SiRF Binary and or uBlox binary) It is pretty easy to configure...just send it some commands over the port, so both the baud rate and the update rate can be configured. A pre-production unit of this module in a chip was tested and it fared pretty well, but because it only has 14 channel tracking (versus as many as 22 on some other models / brands) it was only a middle of the pack performer on SNR tests with a patch antenna configured as shown, especially with essentially no ground plane.

    @Marc - it is not just that it is "faster" it is that the Atmel family of chips (AVRs) used in the ArduPilot are pretty slow and it takes a bunch of cycles to parse this data versus the binary. On a processor like an ARM that runs at several hundred MHz vs 16 - it is usually not an issue, but for us it just is a fact. The interesting thing is that it must be only putting out some of the sentences, because otherwise it may have to be greater than 9600 to output all the structure 10 times per second. If it is ONLY pushing GGA, GLL. GSA, GSV, RMC and VTG as it appears to state in the specification then it is possible. The newer 4.00 specification includes an HS sub-spec. that delineates 38400 as the speed.
  • Wayne April 7, 2010 at 7:41am
    I just know that if this thin was relatively easy to configure, it would be pretty sweet to have a GPS on a drone with a 10hz update rate.
  • Marc Daniels April 7, 2010 at 7:40am
    Is binary mode 'faster' than NMEA , or is it more efficient to parse binary vs strings? I don't see how it is 'faster' since the NMEA messages provide the same data and even at 9600bps it can transmit messages at 10hz.
  • Curt Olson April 7, 2010 at 7:38am
    The data sheet says it can run at a variety of update rates (1hz is the default) but can be configured for up to 10hz. However, the datasheet says nothing about how the gps is commanded to change rates. Perhaps if you can change the update rate, you could also change the baud rate? It's been a while since I've seen a gps that does NMEA only. It would be interesting to see the full docs ... maybe this thing is more capable than what the sparkfun web page would lead us to believe ... or maybe not?
  • Rana April 7, 2010 at 7:28am
    Though this GPS looks prety good but it is of very very les use with autopilots like ArduPilot & UDB they require the GPS to be configured in Binary mode for fast processing, which it does not have.

    It seems from the datasheet of this GPS that it is hard configured at 9600 baud, again Ardupilot & UDB works a much higher bauds to make the processing fast which is required for navigation.
This reply was deleted.