differential GPS update

[Andrew Tridgell]

Hi All,

As I've mentioned previously on the dev calls I've been working with Ben
Nizette from ANU on a low cost DGPS system for APM. Up until yesterday
we had been working on static tests, using a couple of GPS setups at two
places on Canberra (one on my roof, one on a farm near Mt Stromlo).

We started doing 'live' tests with the APM code yesterday, initially
with APM:Rover. We added support for a 2nd GPS on Pixhawk (using the
spare UART on the extra pins of the debug console DF13 port), and added
MAVLink packets for transporting RTCMv2 correction data from the ground
station to the aircraft at 1Hz. We also added SD card and mavlink
logging of DGPS status and the GPS position details from the 2nd GPS.

The 2nd GPS support will be useful even without DGPS, as it would give
us redundency in case one GPS fails (we hope that GPS glitches often
don't happen at the same time on two GPS modules on the same aircraft),
plus it will give us a much better way to properly evaluate new GPS
modules.

I've also modified MAVProxy to add a DGPS module for relaying the RTCMv2
data to the aircraft, and to allow both vehicle positions (corrected and
uncorrected) to be displayed on the map.

We generated the RTCMv2 messages in two ways:

- using a local raw capable GPS (we're using a uBlox 6P) to calculate
differences against a reference position

- using a NTRIP RTCMv3 stream from Geoscience Australia broadcast live
on the internet (GA kindly gave us access to their live data)

We tested using the rover yesterday and today. We had planned to fly a
senior telemaster with the setup today, but a total fire ban means we
can't fly today.

The results so far aren't great - nothing that would make me want to
always run with DGPS enabled, but we have gathered a lot of data and we
now have all the pieces in place to make it easier to test.

We are presenting a conference paper in Perth at LCA2014 in a couple of
weeks on the system.

Some photos here: https://plus.google.com/101060755643904546707/posts/8CxYVgBL5qr

Cheers, Tridge

[MB]

Hi Tridge,

i am trying to get more precise GPS-Coordinates too.
Your solution with the use of a base station, a reference station (ntrip) and a moving rover is exactly the same setup that i am using.
Here i have some notes about your and my solution.

- Basestation:
Due to the measurement of the carrier-phase you need a receiver with a very precise onboard time-source. For this i recommend a LEA-6T (can deliver RAW Data). Because the LEA-6T is using a TCXO instead of a normal crystal.
The Antenna should be a good active Antenna placed on a Choke Ring, to minimize multipath Signals as height as possible.
Your RAW-Data and Data from your Reference Station should be processed in realtime, and send as a RTCMv2 or RTCMv3 Stream to a NTRIP Caster, or to your Radio Modem.

- Rover:
I recommend the use of a NV08C-CSM Receiver. It can deliver RAW Data with 10 Hz and can use GPS, Glonass and SBAS at same Time.
Realtime processing of the Data on the Rover should be made by a additional CPU running RTKRCV. RTKRCV needs to be extend, to give us a lightweight Protocol withe needed information.

I think with this System you can get precision in sub decimeter range, but there a lot of big stones in the way.
- Not easy to use
- Base should be placed near Rover (moving Base). You need mobile Internet access.
- Not Plug and Play.

As a alternate, why not give the new Neo-7P Module a Chance ? With a active Antenna onboard the MAV, and the use of GPS and Glonass, it should deliver really good Data for us. By the way, the Neo-7P can deliver data with 10Hz.

Whatever you want to use DGPS, PPP or PPP-Kinematic it is always not Plug and Play like our current Setups.

Cheers,
Marco

[Ben Nizette]

On 22 Dec 2013, at 7:55 pm, MB <ma...@wtns.de> wrote:

> Hi Tridge,

Hi Marco, I’m working with Tridge on this at the moment, thanks for the input!

>
> - Basestation:
> Due to the measurement of the carrier-phase you need a receiver with a very precise onboard time-source. For this i recommend a LEA-6T (can deliver RAW Data). Because the LEA-6T is using a TCXO instead of a normal crystal.
> The Antenna should be a good active Antenna placed on a Choke Ring, to minimize multipath Signals as height as possible.

We’ve used 6T and 6P parts that can both supply raw output. You’re right, the P only has an internal crystal rather than a TCXO, we’ve got a bunch of 6T but haven’t flown them yet (we should!).

The antennas we’re using don’t have a choke but once again, it’s something we’ve talked about.

> Your RAW-Data and Data from your Reference Station should be processed in realtime, and send as a RTCMv2 or RTCMv3 Stream to a NTRIP Caster, or to your Radio Modem.

Yup, see github.com/benizl/pyUblox if you wish! There are scripts there to real-time process raw obs to RTCMv2 and send straight to a serial link or over UDP. The same output can also come from an RTCMv3 NTRIP stream, transcoded.

We’ve then got a MAVProxy module that injects the RTCMv2 packets in to the MAVLink telemetry stream.

>
> - Rover:
> I recommend the use of a NV08C-CSM Receiver. It can deliver RAW Data with 10 Hz and can use GPS, Glonass and SBAS at same Time.

We’re actually using the standard LEA-6H as rover because it’s the unit everyone has and can take RTCMv2 corrections natively, no extra processing required. As you say below, a separate processing system may lead to better results but isn’t for everyone.

Haven’t used the part you recommend there, I’ll check it out.

> Realtime processing of the Data on the Rover should be made by a additional CPU running RTKRCV. RTKRCV needs to be extend, to give us a lightweight Protocol withe needed information.

This is on the todo list, passing the data from the rover through a BBB or something, forwarding on corrected GPS measurements from there. We’re most careful about limiting the induced latency as the GPS velocity is used in the AHRS to correct heading and anything longer than half or 0.75 seconds is bad juju (and it takes ~0.4 seconds just for the data to leave the GPS).

>
> I think with this System you can get precision in sub decimeter range, but there a lot of big stones in the way.
> - Not easy to use
> - Base should be placed near Rover (moving Base). You need mobile Internet access.

What do you need internet access for (if you’re using a local set of obs at least)?

> - Not Plug and Play.

Our solution above is p&p really as the corrections are processed as part of the GCS, transmitted using the telemetry radio and passed to the existing GPS. But it isn’t decimetre, not really even sub-meter for reasons I’m currently investigating..

>
> As a alternate, why not give the new Neo-7P Module a Chance ? With a active Antenna onboard the MAV, and the use of GPS and Glonass, it should deliver really good Data for us. By the way, the Neo-7P can deliver data with 10Hz.

We’re playing with these at the moment as well. Can you point to any literature that states that the P mode actually makes a difference for a roving receiver? I’ve only seen references to its action improving static mode positioning (and it does that). Also interested to see whether the output rate reduces latency, I’m not holding my breath there, and that’s probably more important to us that update rate at the moment.

Annoyingly the P doesn’t actually accept RTCM corrections (a fact you may not find in the literature) so if you do use these then you close that door.


Cheers,
—Ben.

>
> Whatever you want to use DGPS, PPP or PPP-Kinematic it is always not Plug and Play like our current Setups.


>
> Cheers,
> Marco
>

> --
> You received this message because you are subscribed to the Google Groups "drones-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Gary McCray]

Hi Ben,

I'm kind of shooting in the dark here, but!

Ive been reading a bit about GPS / GLONASS combo receivers and it was my understanding from what I ave read that the improvements are in tow parts at least according to the Agricultural use group (including tractors I think) that is actively using them.

Namely that If GPS (or GLONASS) for example is either currently at a suboptimal number of satellites the alternate technology can (and does) act to fill in satellites from that group effectively increasing both resolution and reliability.

And also that the combination of all available satellites is used to continuously increase both resolution and signal reliability.

They are using these currently on ground vehicles that move (and need to go very accurately down straight or even curved crop rows, so that seems a roving technology to me.

It seems to me that if the Neo7P which claims a continuous update rate of 10hz can't accomplish this within those time frame boundaries it is severely limited in comparison to what is already commonplace in the AG industry and for us at least would provide no value at all.

Best Regards,

Gary

[Marco Bauer]

Hi Ben,

> We’ve used 6T and 6P parts that can both supply raw output. You’re right, the P only has an internal crystal rather than a TCXO, we’ve got a bunch of 6T but haven’t flown them yet (we should!).
>
> The antennas we’re using don’t have a choke but once again, it’s something we’ve talked about.

I really think that the 6T is a small Piece better then the other Module for a fixed Base Station.
But there are some Limitations on the Base Station.
- Distance to Rover should not exceed 25 Km
- Base Station needs a RTCM Signal from a Broadcaster (permanent Online)
- The Position of the Base Station must be known very precise, if you did not want to use a RTCM Signal.
- Setup is not easy for most Users

> Yup, see github.com/benizl/pyUblox if you wish! There are scripts there to real-time process raw obs to RTCMv2 and send straight to a serial link or over UDP. The same output can also come from an RTCMv3 NTRIP stream, transcoded.

I will take a look on that. On what this should be run ? Any special plans ?

> We’re actually using the standard LEA-6H as rover because it’s the unit everyone has and can take RTCMv2 corrections natively, no extra processing required. As you say below, a separate processing system may lead to better results but isn’t for everyone.

That is right. The System must be very easy to use.

> This is on the todo list, passing the data from the rover through a BBB or something, forwarding on corrected GPS measurements from there. We’re most careful about limiting the induced latency as the GPS velocity is used in the AHRS to correct heading and anything longer than half or 0.75 seconds is bad juju (and it takes ~0.4 seconds just for the data to leave the GPS).

The BBB should be fine. Currently i do my tests with a Raspaberry PI

> We’re playing with these at the moment as well. Can you point to any literature that states that the P mode actually makes a difference for a roving receiver? I’ve only seen references to its action improving static mode positioning (and it does that). Also interested to see whether the output rate reduces latency, I’m not holding my breath there, and that’s probably more important to us that update rate at the moment.

Corrently i dod not know any literature abou this - sorry.

> Annoyingly the P doesn’t actually accept RTCM corrections (a fact you may not find in the literature) so if you do use these then you close that door.

The Neo-7P is able to use RTCM v2.3 messages provided over every interface. So thats the fact, why i recommend it. With this receiver you can cover four solutions:

- Stand alone PPP-Kinematic with the use of GPS and Glonass. I think this would be the most used solutions by the user.

- Aided with RTCM Messages provided by the Base Station at home (over Air or Cellphone)

- Local Base Station (Portable on the Field) which is calibrated with RTCM stream over Cellphone. (Distance to rover is much closer)

- Local Base Station (Portable on the Field) which is calibrated with PPP-Static by the Neo-7P itself (needs longer Time, and not yet tested by me)

You can see, that the Neo-7P is the most usual receiver for us.
Only the Hardware (CPU) for the Base Station should be failproof and easy to use. (BBB, Odroid or even a custom made STM32F04 embedded solution - i recommend this for realtime processing).

I hope i can provide some measured data from a Neo-7P at next weekend.

Cheers,
Marco

[Ben Nizette]

On 23 Dec 2013, at 4:47 am, Gary McCray <garyr...@gmail.com> wrote:

>
> It seems to me that if the Neo7P which claims a continuous update rate of 10hz can't accomplish this within those time frame boundaries it is severely limited in comparison to what is already commonplace in the AG industry and for us at least would provide no value at all.
>

I’d assume so too, yeah, though best to test! It’s on my to-do, will report back!

—Ben.

[Ben Nizette]

On 23 Dec 2013, at 6:48 am, Marco Bauer <ma...@wtns.de> wrote:

> Hi Ben,
>
>> We’ve used 6T and 6P parts that can both supply raw output. You’re right, the P only has an internal crystal rather than a TCXO, we’ve got a bunch of 6T but haven’t flown them yet (we should!).
>>
>> The antennas we’re using don’t have a choke but once again, it’s something we’ve talked about.
>
> I really think that the 6T is a small Piece better then the other Module for a fixed Base Station.

Agree entirely, as I say I’ve got some 6Ts that I do use for base sometimes but haven’t done a back-to-back against the P. I agree they should come out ahead

> But there are some Limitations on the Base Station.
> - Distance to Rover should not exceed 25 Km

Our plan is that the base station is the craft’s GCS so the baseline is unlikely to exceed a few hundred metres

> - Base Station needs a RTCM Signal from a Broadcaster (permanent Online)

Not necessarily. If the base station knows its own position well enough then there’s no further use for an external RTCM stream

> - The Position of the Base Station must be known very precise, if you did not want to use a RTCM Signal.
> - Setup is not easy for most Users

The current setup is very easy from a software point of view, the only hard bit is accurately positioning the base station receiver (see below)

>
>> Yup, see github.com/benizl/pyUblox if you wish! There are scripts there to real-time process raw obs to RTCMv2 and send straight to a serial link or over UDP. The same output can also come from an RTCMv3 NTRIP stream, transcoded.
>
> I will take a look on that. On what this should be run ? Any special plans ?

Not really, install prereqs (pyserial, bitstring, might be about it) then run one of “dgps_test” or “local_to_udp” with a raw-capable receiver attached to generate RTCMv2 and push to serial or UDP respectively; or “dgps_ntrip” or “ ntrip_to_udp” to transcode RTCMv3 to v3 and push to a serial receiver or UDP port respectively. Should really write up some docco, it’s coming I promise :)

>
>> We’re actually using the standard LEA-6H as rover because it’s the unit everyone has and can take RTCMv2 corrections natively, no extra processing required. As you say below, a separate processing system may lead to better results but isn’t for everyone.
>
> That is right. The System must be very easy to use.
>
>> This is on the todo list, passing the data from the rover through a BBB or something, forwarding on corrected GPS measurements from there. We’re most careful about limiting the induced latency as the GPS velocity is used in the AHRS to correct heading and anything longer than half or 0.75 seconds is bad juju (and it takes ~0.4 seconds just for the data to leave the GPS).
>
> The BBB should be fine. Currently i do my tests with a Raspaberry PI
>
>> We’re playing with these at the moment as well. Can you point to any literature that states that the P mode actually makes a difference for a roving receiver? I’ve only seen references to its action improving static mode positioning (and it does that). Also interested to see whether the output rate reduces latency, I’m not holding my breath there, and that’s probably more important to us that update rate at the moment.
>
> Corrently i dod not know any literature abou this - sorry.
>
>> Annoyingly the P doesn’t actually accept RTCM corrections (a fact you may not find in the literature) so if you do use these then you close that door.
>
> The Neo-7P is able to use RTCM v2.3 messages provided over every interface. So thats the fact, why i recommend it.

The Neo-6P /said/ it could but definitely couldn’t; it simply would ignore the RTCM messages. If you can confirm through experiment that the 7P has this bug/limitation rectified then that’s great! I’ll have to look in to it

> With this receiver you can cover four solutions:
>
> - Stand alone PPP-Kinematic with the use of GPS and Glonass. I think this would be the most used solutions by the user.

Once a few more people fly BBBs, either running APM directly or connected by USB then I agree, this is a good option.

>
> - Aided with RTCM Messages provided by the Base Station at home (over Air or Cellphone)
>
> - Local Base Station (Portable on the Field) which is calibrated with RTCM stream over Cellphone. (Distance to rover is much closer)
>
> - Local Base Station (Portable on the Field) which is calibrated with PPP-Static by the Neo-7P itself (needs longer Time, and not yet tested by me)

This is what we do, the PPP generally converges within ~5min which is usually well within the setup time of the rest of your flight gear. It’s also about the same time taken for the PPP static RTKRECV solution to converge.

The other option here, given that most people have their preferred flight field, is to survey in a point once and replace the base station antenna on the mark each time you go out. As I’m sure you know, for short baselines, if the base station is off be 1m east then the solution will be off 1m east, the error propagates straight through. As such so long as the antenna is within ~10cm each time then it’s going to be good enough.

>
> You can see, that the Neo-7P is the most usual receiver for us.
> Only the Hardware (CPU) for the Base Station should be failproof and easy to use. (BBB, Odroid or even a custom made STM32F04 embedded solution - i recommend this for realtime processing).
>
> I hope i can provide some measured data from a Neo-7P at next weekend.

Please! So the interesting things here for me:
1) Does 7P /actually/ accept RTCMv2? Turn on the MSG_DGPS and see whether numCh becomes non-zero (or check the DGPS bit in the solution but make sure SBAS is off)
2) Does 10Hz affect the latency? Best way I know to check this is to use mavgraph to graph the difference in successive GPS velocities vs the earth-frame accelerations, see for example http://uav.tridgell.net/GPS/NEO-7N/skywalker-NEO-7N.png
3) Does PPP mode improve the solution quality for dynamic receivers? Does it affect latency? Hard test to run, probably best to get two GPS, with and without PPP and run back to back if you can.

Thanks!

—Ben.