When RTK is being lost, the GPS altitude jumps very quickly, leading to abrupt motions of the drone, which is not desirable.
First, the telemetry radio was used for sending RTCM, but obstructed signal when drone went behind a house was problemetic. Then, tried Internet connection for correction, but connectivity isn’t guaranteed at all times.
Proposition: keep the RTK correction, even when the RTK correction data is not being received, instead of removing the correction immediately.
Discussion
Using Barometer as primary source didn’t improve so much. Will try again.
GPS is the one doing the correction, based on the RTCM data (with phase shift information), so computing the offset itself within PX4 isn’t so simple.
As quick solution, we could sense when RTCM message is lost, and use barometer for height source, then apply back the correction when the RTCM is regained.
We could also check more on GPS velocity for detecting the GPS altitude jumps that’s invalid
For DJI, when RTK is lost drone hovers and needs to land. But ideal case would be to handle the RTCM loss invisible to the operator.
Check F9P module documentation, it talks about the time sensitivity of corrections.
Summary: We can have the issue for the safer
Another issue (secondary GPS didn’t take over when primary one failed):
Q.2: ADSB workings under QGC
Should the ADSB sensor reading indicate itself under QGC ----> Mavlink inspector menu as the mavlink start command( mavlink start -d /dev/ttyS4 -b 57600 -m minimal) is provided for the ADSB to commence.
Can we check anything about adsb in mavlink inspector?
Answer: Yes, enable MAVLink forwarding for the port wanted. And it should be visible in MAVLink inspector.
Also, if ADSB is working, it should show on https://flightaware.com/, if you want to check whether it’s working.
Q.1:
For a crop spraying drone for vineyards, we integrated RTK stream to improve GPS accuracy to centimeter level and improve the quality and safety of the application. Only issue is that with PX4, the drone is shifting its position when it losses/regains the RTK correction according to xyz correction it had before. In our case, flying 2-3 meters above vineyards, this is a problem and we needed to disable RTK capability after we had two crashes of our drones going down when PX4 switched from RTK to non-RTK states, …
I open an issue here and I would like to discuss what should be the right behavior in this case and find people capable of applying the correction if it needs to be done on PX4 side
As per Github issue # 21315 **ADSB-IN configuration for Orange Cube Pixhawk under QGC
This was fixed and tested by Dev team member. Wanted to understand how it is working under QGC . Should the ADSB sensor reading indicate itself under QGC ----> Mavlink inspector menu as the mavlink start command( mavlink start -d /dev/ttyS4 -b 57600 -m minimal) is provided for the ADSB to commence.
More context not in the PR:
The ESC’s we are using are Currowong’s Velocity HS. During their power-on sequence they short the CANH and CANL lines, causing the can bus to experience a CANBUS off state. This results in the our FMU (cuav v6x) to be dropped from the canbus since the driver does not handle this interrupt.
We have also tested on the cuav v5, and this does not occur.
I will be traveling during the call, and would just like to get some eyes on the PR. Since one reviewer accepted it, I felt it would be okay just to since this might be an easy accept and merge
Community Announcement
Community Q&A (No deep technical discussions)
Guideline for asking a Question
General Discussions
since this might be an easy accept and merge 