Hey Guys,
I’ve been fighting this issue for months with no success.
The environment is as follows: DIY '450 and/or IRIS+, both with identical hardware configurations and 3DR IRIS+ controllers. Both running Copter 4.2.2. Both exhibit the identical problem. FCs are identical IRIS PX4 (with memory limitation).
So, the ALTITUDE and DISTANCE reported to the remote are bogus. Altitude is roughly my ASL and distance is a meaningless huge number, like 3671’.
Sat #, battery voltage and current drawn, as well as speed are always correct. Flight modes and RX quality % are correct as displayed
Can someone shed some light here, I’m totally out of options to try, and have asked this question in several forms without even a suggestion. There is some blip in the docs stating that “sometimes” ASL instead of AGL can be “initially” indicated…??
Shawn suggested setting DEV_OPTION to ‘2’ for some OSD issue; doing the same had no effect.
Is it possible the 3DR firmware in the 3DR FS-TH9X, obviously dated, is any issue? Personally I doubt this as the other telemetry data is correct.
A .bin of a short flight last night is attached. MP is the current version.
Thanks! I’m almost ready to shelve this and move on. I don’t care about missions or FPV, etc… but would like to have that data.
I believe the altitude and distance problems are related to arming and flying before there’s a valid GPS 3D fix. Happy to be corrected if my theory is wrong.
You can prevent this in two ways, one is almost foolproof, the other is easily circumvented and less safe
FENCE_ENABLE,1 and check your other fence params
Set the flight mode to Loiter and wait for arming to be possible, switch to your desired flight mode
In either case there should be LED indication or telemetry. I know in the yaapu telemetry (mavlink messages) you first hear “3D fix acquired” but you have to wait for “Home position set”.
The fence option has multiple benefits but the down-side is it forces you to wait. You quickly get used to the wait and if you frequently fly the waiting is very short.
You might be able to adjust GPS_GNSS_MODE a bit more to improve the time to fix, like take out either GLONASS or Galileo (or both)
I noticed a drop off in battery voltage at the end of that flight, like the battery is just starting to be over discharged. I would check the accuracy of you voltage monitor, particularly at lower voltages. It’s not very important for the voltage reading to be highly accurate at the fully changed battery voltage.
Also set BATT_LOW_VOLT,14.4 (was 14.3) not much of a difference but might as well be exact
GM Shawn,
I highly appreciate your response!
You may have hit it. I typically do arm prior to full GPS lock, then wait for GREEN to launch.
I’ll be able to fly today and will exercise patience. I have experimented extensively with GPS
settings. I do a lot of not-drone-related GPS work and usually run with GPS SBAS and Galileo
with no SBAS - baseline too long. I had just enabled GLONASS on that flight as a test.
With the full GNSS in play it will absolutely loiter within a few inches in all dimensions.
I’ll address the fence parameters, and check the low end accuracy of the 3DR voltage sensor.
Again, thanks for your time. I follow all the UAV forums and have not seen my issue mentioned,
thus assuming it was my setup.
Shawn @xfacta , CASE CLOSED. Many thanks for the effort!
Details:
No, I was not waiting long enough to arm after the controller indicated LOCK and
displayed the sat count. On average, it required an additional minute or so.
HDOP is an issue on the ground, as we know. Even after waiting a few minutes, the
telemetry altitude would often snap from correct AGL → ASL . So, I started the
process
from a table about 4’ off the ground and it essentially solved the issue 98% of the
time. “Hurry up and wait”. I believe the GPS glitches at a critical time during startup
are an issue.
I found that increasing GPS_MIN_ELEV from the default → 20 degrees made a
significant difference in reducing GPS glitches - my horizon is not the best, with
distant mountains and foliage … not an urban canyon, but not great. In unrelated-to-
drones GPS work, I know the effect of a satellite ‘just’ appearing and disappearing at
the horizon…
Again, TU to all developers, and even tho @amilcarlucas would probably disagree, it’s doing OK now…(that’s a LOL). Onward. Now I’ll autotune this creature.
Thanks for reminding us about GPS_MIN_ELEV - it’s quite an important parameter in some situations.
I was about to suggest starting from a table or something similar - small craft are so close to the ground it’s just about guaranteed that GPS will give trouble if it even works at all.
Bigger multirotors with long legs and taller GPS masts have an easier life in that regard.
Most definitely Shawn. The problematic quad sits right on the grass, and I had shortened the IRIS+
legs to 1.5" - I don’t run a gimbal and those original long legs caused vibes. Additionally, the GPS mast
and added ground plane are only an inch or so above the FC on the quad. Onward.
