Before calling it a bug, I would like to hear some comments from the devs.
Situation is the following:
After upgrading to 3.1 from 3.0 my quad [i]sometimes[/i] (approx. once per 10 flights) started to experience sudden and very quick side movements (fly-aways, if you wish) to the random horizontal direction (some 20-30 meters), altitude also usually increases by some 5-10 meters. It happens in Loiter and Auto modes (i.e. when GPS is in use).
During telemetry analysis I noticed that fused position reported by copter (GLOBAL_POSITION_INT) was exactly the opposite to the direction of the actual movement. I.e. reported position moved 10 meters to the South, but copter physically moved 10 meters to the North, i.e. trying to compensate the difference to stay in the same position as before. Also I noticed, that GPS satellite count dropped from 8-9 to 6-7 during this time.
So the position glitch was likely caused by GPS, which is OK as such (GPS is unreliable or maybe my copter is vibrating too much, or interference, whatever) and could happen sometimes.
But questions are the following:
Copter tried to compensate the position difference using full throttle! It pitched almost to 45 degrees and pushed some real power to the props accelerating my quad like a rocket, while my maximum Loiter and Auto navigation speeds are very moderate. So question is - why copter is doing full-throttle to compensate GPS position glitches? This is so dangerous, because user does not expect the copter to fly so fast. Why not just compensate the position using usual navigation speed?
I understand, that final copter position is filtered (fused) from GPS and IMU data (Kallman filters and so on). Assuming that IMU based position wasn’t changed, why sudden GPS position glitches (20-30 meters as I said) affect the fused position so much? As I said, copter literally jumped some 20 meters away in 1-2 seconds using full throttle. Shouldn’t software filter out such unreasonably big position jumps induced by GPS while IMU says that coper does not move?
I want to add, that I didn’t experience such behavior in 3.0 firmware. My hardware is 3DR quad, APM 2.5, Taoglass GPS from 3DR. Copter generally flies very good (I’ve done 300 or so flights on it purely in auto mode, I don’t fly in stabilize almost at all ). Fly aways described above are qute rare as I said, loiter is close to ideal also. So at least generally, there seems to be no major problems in my setup, so I consider blaming the autpilot software also, sorry for that . Unfortunately, I don’t have dataflash logs at this time. I analyzed purely Mavlink telemetry received during flights. But I think, my questions are generic. I can definitely collect dataflash logs if necessary.
I know about rules, but as I already said, my questions are generic and does not depend on logs as such. I just want to hear theoretical answer from developers based on the information I provided. Thank you!
This is not how this forum works! This is a support forum. Either you have a specific problem or you don’t. If you have a specific problem, provide all the required information. The support in this forum is provided by volunteers who sacrifice their own time which they could spend with their families or their hobby. Take this into account when asking questions.
I am really surprised my post yesterday was delete from this forum.
In my post I said I had the same issue as ahanin and expect answers from people.
But as result, post was removed.
[quote=“criro1999”]I am really surprised my post yesterday was delete from this forum.
In my post I said I had the same issue as ahanin and expect answers from people.
But as result, post was removed. [/quote]
[color=#00BF00]You are supposed to open a new topic for every issue. Without log files, you cannot be sure that it’s the same problem. This forum is not as much about answering questions as it is to be for people to find solutions without having to ask. For that reason, the rule of thumb is, one question, one topic. And no DIYD-style mega-discussion-threads.[/color]
I know about rules, but as I already said, my questions are generic and does not depend on logs as such. I just want to hear theoretical answer from developers based on the information I provided. Thank you![/quote]
Well, in this case, you’re taking about something for which there is specific protection in the code introduced in 3.1 - a log would have allowed us to see if that was activating or not.
Hi,
Here is the dataflash log from the fly-away flight and crash into the tree on some 17 meters altitude. The abnormal behavior starts at X-axis value 700 when opened in Mission Planner log viewer (not sure what kind of time it is).
The problem is with a throttle level after the first GPS glitch is cleared (see the picture). The throttle goes up to 1000 and stays there for a second or so. Can it be caused by baro altitude going down? Unfortunately, INAV logging was disabled in this flight so quite hard to understand the full picture.
So the reason that the copter takes off when it hits a glitch is because the large position jump also affects the estimated velocity and acceleration. So the filter is trying to keep an estimate of it’s velocity and acceleration that all “makes sense” based on the acceleration and positions it’s seeing. So if it sees a sudden position drop it say, “oh shoot, if I moved that far then my velocity estimate must be wrong”. Then it says, “oh shoot, my velocity is much higher than I want so I’d better slow down” so it leans back against the glitch. From an objective point of view the pilot says it’s acting crazy but from the “blind” copter it thinks it must have been pushed by a heck of a gust of wind and so it compensates aggressively.
AC3.1 include GPS Glitch detection. copter.ardupilot.com/wiki/gps-failsafe/
So you’ll see on that page that there are some parameters that can be adjusted to tighten up on the detection. GPSGLITCH_ACCEL is set to 10m/s/s maximum (i.e. 1000), the GPSGLITCH_RADIUS is set to 2m (i.e. 200). The GPSGLITCH_RADIUS is probably the most important, you could try reducing it to 100 or 150. If it’s set too low though it will cause false positives which will trigger lands.
BTW there are no changes in the inertial nav, loiter or waypoint navigation between AC3.0.1 and AC3.1 (with the exception of the glitch detection) so if it wasn’t happening before it’s more likely that it’s some environment or copter set-up change that is making it more common. FPV equipment too close to the GPS is one common cause.
Hi, sorry for late reply, there were no notification to email…
Thank you, I understand your explanations in general and agree with this:
But what is still suspicious is why this “leaning” happens so fast, i.e. almost on a full throttle? I’m again risking to be punished for “theoretical discussion” on this forum (sorry), but still want to share my thoughts about what I personally consider a bug or a space for improvement, namely the inadequate reactions to big GPS positions jumps. The main source of position and velocity estimation should be inertial and mag units, only they affect the real-time stabilization of the copter, right? GPS position in turn, is more like a background-lazy source which is much less reliable compared to inertial/mag units and definitely should not affect any real-time stabilization/behavior. So, I think, when copter sees big GPS position jumps, it should behave like “Oh gosh, GPS position jumped too far, but according to my inertial unit I’m standing still, let’s lean slowly to the new GPS position”. So the GPS position effect should be gentle.
But I faced more specific problem. I have disabled GPS glitch protection and flyway happened again during the first minute after the takeoff (I managed to recover in stabilize mode). I noticed that right before the flyway the number of satellites dropped from 6 to 5 and even 4, this nicely explains GPS glitches. But what worries me is HDOP value which was almost 2.9 during first few minutes of the flight, despite the fact that GPS_HDOP_GOOD param on my copter is 200 (HDOP=2). So why I was able to arm my copter having HDOP of 2.9 while maximum allowed is 2? I have a feeling, that GPS glitch probability could be significantly reduced by allowing GPS unit to grab a better HDOP before taking of. Notice, that during the flight the number of satellites jumped to 9 and even 10 which reduced HDOP below 2, which is very good value.
As I see from parameters, there is no such which controls the minimum number of acquired satellites for arm check, right? Only GPS_HDOP_GOOD which is my case didn’t work as I expected.
). Fly aways described above are qute rare as I said, loiter is close to ideal also. So at least generally, there seems to be no major problems in my setup, so I consider blaming the autpilot software also, sorry for that 
. Unfortunately, I don’t have dataflash logs at this time. I analyzed purely Mavlink telemetry received during flights. But I think, my questions are generic. I can definitely collect dataflash logs if necessary.