Hi Igor,
Yep, though I haven't got the APM side of it upstream (I should try
and get around to that..). If you load the firmware from [1] then the
APM will forward the payload of a GPS_INJECT_DATA message to the GPS.
If you 'module load DGPS' inside MAVProxy then it will listen on a UDP
port (I forget which one), package any data on that port inside the
right message and send it to the rover (that component is upstream).
Finally, pyUblox [2] has two scripts: local_to_udp.py and
ntrip_to_udp.py, both of which publish RTCMv2.3 messages on the right
UDP port to plug in to the above. In the first case, you should plug a
raw-capable ublox module with known position in to the ground station
and it will generate DGPS corrections from that. In the second case,
it will unpack RTCMv3 messages from an NTRIP stream and convert them
to RTCMv2.3 suitable for input to the GPS modules.
If you have your own source, just publish them on UDP using the above
as a reference.
A quick note:
> to RTCM enabled receivers (like the LEA-6T).
In my testing, older versions of the 6T module cannot accept RTCM,
even though the documentation says they can. Newer versions can accept
RTCM, but only if the output is 1Hz. I don't know whether there's a
working version in the middle somewhere, but pretty much you're better
off just using the normal LEA-6H, 6S etc modules for the roving side
as their RTCM support seems to actually work reliably.
Second note: Don't expect the result to be that good. If you're trying
to generate your own DGPS corrections (local_to_udp.py) then you
actually end up with /heaps/ more random position error, even if the
position is on /average/ moved closer to truth. This is for two
reasons:
1) you're adding all the non-correlated noise from the DGPS base to
the roving position. This is true of every DGPS system, but using a
rubbish LEA-6T and tiny antenna means that this effect is pretty big
2) The uBlox modules seem to turn off a large amount of internal
filtering as soon as they start receiving RTCM.
The second point is true even for 'good' sources of corrections, such
as a proper expensive base station or your local geospatial reference
service. In my tests you /might/ get sub-metre performance in 2
dimensions with an excellent source of corrections. Altitude is the
same or worse, as the common-mode noise couples more strongly in to
that.
For more info, see [3], [4].
HTH.
Ben.
[1]
https://github.com/benizl/ardupilot/dgps-wip
[2]
https://github.com/benizl/pyUblox
[3]
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6878299&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6878299
[4]
https://www.youtube.com/watch?v=sl8aJlG52PE
> To unsubscribe from this group and stop receiving emails from it, send an email to
drones-discus...@googlegroups.com.