I am having bad problems with my 2 CUAV F9P GPS modules attached to my Cube Orange autopilot with ArduPlane v.4.3.5 (official) firmware. The two GPS modules are configured as “moving baseline” (GPS_TYPE1 = 17 , GPS_TYPE2 = 18) and I am using GPS for Yaw / heading thanks to the RTK.
In the attached document, I have described the problem in depth. The document contains all the logs, parameters and details etc…
I would appreciate help, as this is an urgent problem for us and caused some dangerous situations. Thanks! CUAV F9P GPS Problem Description.pdf (198.1 KB)
Your problem appears very correlated to maneuvering. Satellite count remains high while in QLOITER, but as soon as maneuvering in pitch and roll begins, the satellite count plummets. You may be able to improve reception by using a higher antenna position that does not get masked by fuselage/airframe elements during maneuvering, and/or changing to a different antenna type. What antennas are you using?
You are also quite behind on F9P firmware version. The latest is 1.32, which is compatible with ArduPilot and contains some fixes that certainly won’t hurt.
EDIT: Ignore what I said about GPS rate params. 200 is the proper setting.
Usually when flying this drone we are using RTK (moving baseline) with the two CUAV F9P GPS modules, and we use the GPS yaw/heading. Under good conditions, the GPS statuses are 3D dgps and RTK-fixed.
Here is the configuration onboard the Cube Orange autopilot in ArduPlane parameters:
GPS_TYPE = 17 , GPS_TYPE2 = 18, EK3_SRC1_YAW = 3 .
I conducted a series of 10 consecutive 5 minute tests on the ground (propellers removed, arm the drone, switch into AUTO mode) during which the problem would’ve occurred with the previous parameters, except now with the parameters adjusted as follows so that the drone does not use RTK.
GPS_TYPE = 1 , GPS_TYPE2 = 1, EK3_SRC1_YAW = 1 . The GPS statuses were now both 3D dgps (so no RTK used). RESULTS:
Arm test 1 - GPS fine, no problems
Arm test 2 - GPS fine, no problems
Arm test 3 - GPS fine, no problems
Arm test 4 - GPS fine, no problems
Arm test 5 - GPS fine, no problems
Arm test 6 - GPS fine, no problems
Arm test 7 - GPS fine, no problems
Arm test 8 - GPS fine, no problems
Arm test 9 - GPS fine, no problems
Arm test 10 - GPS fine, no problems
The problem did not happen during these tests when RTK was not used.
This leads me to believe that there is a compatibility issue between Ublox F9P receivers with 1.13 firmware and ArduPlane v4.3.5 / Cube Orange. This appears to be a similar problem to this one, which was resolved by upgrading the firmware on the F9Ps from 1.12 to 1.32.
How do you draw that conclusion? I clearly showed the problem is related to satellite reception during maneuvering.
A more interesting test would be to mount the vehicle on a swiveling/rotating base (like a camera tripod) and move it through various attitudes to see how satellite reception changes and potentially determine a max pitch/roll angle.
Connecting to uCenter for such a test would be very interesting as well to note which constellations (GPS, GLONASS, Beidou, etc) are most affected by attitude changes.
I don’t have an answer to your problem - but here are a few thoughts:
For moving baseline implementations, the antenna are typically placed further apart than it appears in your photo.
The problem I had when implementing RTK on ublox F9P GNSS was that the latest firmware has a known problem (it’s in the ublox firmware release notes) that the receiver can only support two constellations when operating over 7hz.
The solution I implemented was to use the ArduPilot parameters to limit the constellations to just two, and to set the receiver refresh rate to 10hz.
Good luck on your project - I look forward to hearing about your success!
Well, although maneuvering seems to be linked I think it is correlation not causation. We also did 8 hover tests (takeoff in VTOL mode, 1 min hover, VTOL land) and none of them had any GPS problems. We also flew in QHOVER for 5 min (right after this GPS problem happened in flight, just after transition from VTOL to fixed-wing in AUTO mode) and this had no GPS problems.
I think that moving / flying worsens the problem, but only if the drone has been armed AND is in AUTO mode. So I believe the trigger related to what happens when the drone is armed AND switched to AUTO mode. Maybe that is when the EKF starts using GPS for Yaw? Maybe that is when the RTK starts to be used?
Which latest firmware had the known problem? And what firmware version do you recommend using when I want to implement RTK / moving baseline / GPS for Yaw using these two F9P GPS with my Cube Orange and ArduPlane v.4.3.5?
So @jstroup1986 , do you think this is the same problem as you expreienced?
And @Yuri_Rage , would you now agree with me that it is unlikely that the maneuvering itself is the cause of the problem, but rather arming AND AUTO mode?
I use 1.32 on all of my vehicles at 10Hz with RTK corrections enabled, moving baseline on several, and most (if not all) constellations enabled. I have no issues with it.
The core GPS libraries do not differ between Rover, Plane, and Copter, so I am highly suspect of any firmware incompatibility. Full disclosure, I use Copter and Rover, primarily.
I disagree with your conclusion. Please specifically test how changes in attitude affect satellite reception.
Your second flight shows similar reception issues as pitch/roll become more dynamic.
RTK does not “get used” differently when flight mode changes. As soon as the GCS messages show “EKF IMUx Yaw Aligned,” RTCM3 is actively in use for yaw, regardless of flight mode.
@tridge, is there something else I could be missing that is contributing to any correlation/causation error on either my or Jan’s part?
Therefore, I believe that the problem is not caused by roll / pitch behavior of the drone and I believe that it must be something about AUTO mode that is different.
I will take a look at the logs a bit later. I still think that flight mode is inconsequential, and the issue is satellite reception, whether correlated to maneuvering or not.
Perhaps the antennas are close to high current wiring or other sources of interference? Maybe it’s possible to temporarily move them up higher off of the fuselage, just to further isolate the root cause?
I tagged Tridge, as he is the primary developer for the GPS libraries, and his insight is often invaluable when it comes to confusing issues like this one.
My problem was GPS glitches that caused the GPS fail.
I’m sorry - but because I haven’t done the moving base implementation, I haven’t looked at your problem closely. I’ll see if I can find time. I saw that you uploaded some bin files - that’s a good place for me to start.
If I recall correctly, Joe’s problem had more to do with data rates and throughput than reception. I don’t think he was experiencing loss of satellite data.
I agree that the issue is satellite reception - the question is what triggers a rapid loss of it.
Whatever it is that triggers it, here are the facts about it:
It only occurs after the drone is armed.
It can occur both when the drone is stationary and when the drone is flying. However, it occurs a lot sooner and more frequently (now effectively 100% of the time) in flight than on the ground.
It can occur both during VTOL (quadplane) and fixed-wing (airplane) flight.
It has only ever occurred in AUTO flight mode, never in QHOVER flight mode.
It is consistent / identical across both of the two pairs of CUAV F9P GPS modules I have.
Secondly, it is highly unlikely that the issue is caused by interference, which suggests the problem is something internal to the GPS / ArduPilot (and I highly doubt that its ArduPilot)
Here is my reasoning for that: External interference: the problem happened at 2 different locations ( ~ 30 km away from each other) in the same way. One of these locations (the flying location) is far away from any infrastructure / city, and it is in the middle of a farm in a rural area in West Africa. There is very unlikely to be any GPS jamming or radio devices around. Therefore, external interference is unlikely to be the cause of the problem. Internal interference (onboard the drone): the problem happens when the VTOL motors have no power as well as when they have power. There is little correlation between high current and the problem occurring. The problem occurs both when the drone is not moving, motors off and on the ground as well as in flight. The problem occurs both in VTOL and fixed-wing flight. After the installation environment was improved (GPS antenna cables moved away from power cables, both GPS modules moved away from each other) the logs show that the GPS noise is reduced, but the problem happens anyway. Therefore, internal interference is unlikely to be the problem.
