Support for Ardusimple's simpleRTK2B+heading kit

[fdtank81]

Feature request to support direct connection of simpleRTK2B+heading kit to GPS 1

Although Ardupilot 4.1 supports GPS heading with two separate ublox F9P boards, Ardusimple is a popular kit, the simpleRTK2B+heading kit which has a small F9P Xbee board (the moving base) on top of another carrier F9P board (the rover) where the Rover outputs centimeter accurate PVT and Relposned data to pixhawk connector. Unfortunately Pixhawk's software currently expects this on separate connections. It doesn't seem that anyone has been able to make this work yet (perhaps csomy, but not clear) See this link

Describe the solution you'd like A clear and concise description of what you want to happen.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Platform [ ] All [ ] AntennaTracker [ ] Copter [ ] Plane [ X ] Rover [ ] Submarine

Additional context This is for rover but perhaps also a good option for plane and copter, as this hardware package is considerable tighter and lighter.

[rmackay9]

Here's the shop link for the ArduSimple RTK2B https://www.ardusimple.com/product/simplertk2b-basic-starter-kit-ip65/

[cturvey]

For completeness https://portal.u-blox.com/s/question/0D52p0000AF3YSjCQN/not-receiving-rtcm-on-uart2-ardusimple-f9p

On the full size board the RTCM output from the "Moving Base" is ZED UART#2 and comes out of the RX2 / D8 pin. Pick a high baud rate, the ceiling here is pretty high, and it drops the latency.

Use the 1.13 FW, I've run this on extensive soak tests, the 1.12 abends occasionally and the receiver resets. Also tested with HPG/HDG on the F9P/F9H pairs. Multi-constellation, runs up to 8 Hz. Watch that the two units are in pseudo-sync (two unique local clocks, integration slews based on accumulated clock bias), there will be ebb/flow as to which reports first. I pull position from the primary, orientation from the secondary.

[fdtank81]

Thanks, I’ve made this mistake before thinking output would be on TX... Can you elaborate on the pseudo-sync? Which parameters am I actually checking. I noticed sometimes the relposned numbers are referencing the fixed base instead of the moving base.

Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10

---

From: cturvey notifications@github.com Sent: Friday, January 1, 2021 9:59:41 PM To: ArduPilot/ardupilot ardupilot@noreply.github.com Cc: fdtank81 francismolloy@hotmail.com; Author author@noreply.github.com Subject: Re: [ArduPilot/ardupilot] Support for Ardusimple's simpleRTK2B+heading kit (#16151)

For completeness https://portal.u-blox.com/s/question/0D52p0000AF3YSjCQN/not-receiving-rtcm-on-uart2-ardusimple-f9p

On the full size board the RTCM output from the "Moving Base" is ZED UART#2 and comes out of the RX2 / D8 pin. Pick a high baud rate, the ceiling here is pretty high, and it drops the latency.

Use the 1.13 FW, I've run this on extensive soak tests, the 1.12 abends occasionally and the receiver resets. Also tested with HPG/HDG on the F9P/F9H pairs. Multi-constellation, runs up to 8 Hz. Watch that the two units are in pseudo-sync (two unique local clocks, integration slews based on accumulated clock bias), there will be ebb/flow as to which reports first. I pull position from the primary, orientation from the secondary.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/ArduPilot/ardupilot/issues/16151#issuecomment-753431808, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASI5VY3DTPDWC6GLONNLSD3SX2R33ANCNFSM4VLKBPJQ.

[cturvey]

So you have two units with independent clock sources, they will be their nature diverge. Pretty sure the granularity for the correlators is 1 ms, so the clocks will slew when enough clock drift has accumulated (bias), it will add/subtract a ms from the integration time to keep things in check. They are chasing the top-of-second, but they do this by slewing rather than actively disciplining the clock sources into the ppb/ppt.

The time-of-measurement is reported, there is computational latency in solving, and this is variable and dependent on number of satellites. I've always wondered why a lot of UAV / motion systems seem to ignore the 1PPS. There is delivery latency based on the size of messages, and baud rate.

The two units will report at slightly different times, with different measurement times, sometimes they will be timely, other times one will be early/late, try to be conscious of this when acting on the data and pulling into current time.

You can get absolute position from the secondary unit, but it's twice removed from the fixed base. The position reported by the primary unit is likely to be more robust/reliable. If you use an F9H as the secondary it won't provide a position solution (via UBX or NMEA) at all.

Not sure I've seen the secondary unit report base relative position, I'm definitely not bleeding through RTCM3 from the fixed base (I push RTCM3 into the primary unit via UART1), so I think it would be difficult for that to happen. If you have compelling data showing this occurring I will get it into the bug list. Set the fixed base Station ID to something unique so the evidence will be stronger.