support RTK for emlid reach GPS receiver

[moreba1]

we will use emlid reach gps with pixhawk in rtk mode but we can't use qgroundcontrol for sending correction from base station to UAV .

[DonLakeFlyer]

@bkueng ?

[bkueng]

I don't know how the emlid reach works internally. But if someone wants to add support I'd much appreciate it, and I can help out.

[kikislater]

I have one, if you want some info, I could tell you. It runs a linux yocto system. Wiring is detail here : https://docs.emlid.com/reach/ardupilot-integration/

[GlidLov]

i have it, i can do testing if it can help

[moreba1]

https://docs.emlid.com/edge/tutorials/reach-integration/

[GlidLov]

still no development on this..?

[bkueng]

@barchstien started to work on this (https://github.com/PX4/GpsDrivers/pull/38).

[barchstien]

@bkueng I gonna drive tests in april. The topology I use is with a custom mavlink router (called mavlink-hub), that puts RTCM data into mavlink and allow to connect GCS to rover:

|rover|---rf@2.4GHz---|mavlink-hub|---TCP/UDP---|QGC or UgCS|
                                  |---TCP/UDP---|Emlid-Base|

The Emlid Base is stand alone, and uses a web interface to configure it, so driving it directly from QGC is probably out of context ? From early test I've done, there's no need for more dev in the Firmware, because payload of Mavlink message of RTCM types is just written to the serial. Can you confirm that ?

The problem I see with our current topology, is that it is adding an extra piece of software, that is of now closed source (this can changed, it's quite little), so it may not be that appealing for other users. What do you suggest to improve that ? Any ideas on main streaming this ? The aim is to be compliant to PX4 environment, so community can use it

[bkueng]

The Emlid Base is stand alone, and uses a web interface to configure it, so driving it directly from QGC is probably out of context ?

Yes, I don't see that we should replicate that.

From early test I've done, there's no need for more dev in the Firmware, because payload of Mavlink message of RTCM types is just written to the serial. Can you confirm that ?

Correct.

The problem I see with our current topology, is that it is adding an extra piece of software, that is of now closed source (this can changed, it's quite little), so it may not be that appealing for other users. What do you suggest to improve that ? Any ideas on main streaming this ?

I would split that out of mavlink-router to keep that generic. You could do that:

|rover|---rf@2.4GHz---|mavlink-router|---TCP/UDP---|QGC or UgCS|
                                     |---TCP/UDP---|Emlid-Mavlink-Converter|---TCP/UDP---|Emlid-Base|

Or if you say that component is not doing much, even better would be to do the integration directly in the GCS:

|rover|---rf@2.4GHz---|QGC or UgCS|---TCP/UDP---|Emlid-Base|

That would considerably simplify the setup required for a user. Slight drawback is that each GCS needs to implement that (you know better how much effort that is, maybe a library makes sense?).

[Ahmad-Drak]

Hey @DonLakeFlyer @bkueng, now that @barchstien has since moved from working on this to something else, will Emlid still be supported?

[barchstien]

Unfortunately I have no resources at the moment for both dev and tests. My team has moved to using ardupilot, so I don't think I'll be able to test any PX4 in the coming future Thought the part of code that is missing, is quite small QGC already connects or accept TCP/UDP connections The idea would be to add a checkbox in the Connection config, so that data received is not directly routed as mavlink, but is inserted (cut if needed) into mavlink RTCM packets

That is what I call above the extra piece of SW. It works very fine with ardupilot on field, so should be fine with PX4 (providing you use the right mavlink header). I did not directly add that feature in QGC but in a stand-alone SW, because we use QGC mostly for config, and UgCS for operation and mission waypoint creation, and we wanted to be GCS agnostic too for RTK

Alternatively, if you don't mind having a 2nd radio link only for RTCM data, it's just about plugging a radio modem between rover and base, and you don't need any extra SW

[Ahmad-Drak]

@barchstien unfortunately i do not have the needed expertise to easily whip up what you just described. I do offer my help in testing, should anyone need it. If I understood correctly, you wrote a small piece of standalone SW which works for this purpose? care to share it? unrelated question, why the move to ardupilot?

[barchstien]

The team moved to ardupilot for the on flight behaviour, which they estimate better with ardupilot than with PX4, especially for bigger drones. That area is not mine, and I comply with their decisions I cannot share the code sorry, but it's quite straight forward (it follows mavlink protocol). I think it is already present in QGC and friends, named as RTK inject. Except that current implementation only works on serial, as far as I know, and emlid is on TCP/UDP Most pf the work is not about putting RTCM data into mavlink, but about everything that is around (get mavlink from/to serial/UDP/TCP)

In our case, we like TCP/UDP, it makes the setup on field easy

[barchstien]

@Ahmad-Drak have you consider using a second telemetry link ? Just plug one end to the base serial, and the other end to the rover serial, and you're good to go All that I mentioned earlier make sense only if you want to use the same telemetry module for FC telemetry and RTCM

[Ahmad-Drak]

@barchstien thanks for sharing the info.

have you consider using a second telemetry link ?

Yes it crossed my mind but having redundant HW for just one purpose seems unnecessary. Implementing it with SW would be optimal for my application. Hopefully the contributors would help with this

[moreba1]

https://github.com/PX4/PX4-GPSDrivers/pull/58

[DonLakeFlyer]

The firmware folks are in charge of updating QGC to new driver support. You'll need to get them to do it.

[GlidLov]

+1 for RTK inject. We switched over EMLID products (which we didn't got to work properly) to the arducopter integrated RTK workflow, which is quite straightforward. It still miss a proper QGroundControl support, though, especially in Android version, as far as i know

[HTRamsey]

@julianoes what would it take to get this resolved? I noticed there was originally a plan for RTK in the driver but it appears that never made it in here.

[julianoes]

I'm not sure because I don't have an Emlid GPS and I have never used it.