Hi,
I did a brief test flight after adding a Maxbotic I2C Sonar Rangefinder, started in Stabilise, switched over to Altititude Hold and Loiter and then issued LAND from GCS (Tower app). It came down a bit, hovered a second, then went sideways, hovered again before shooting off quickly. I tried to stop it using break mode, but too late and it crashed.
I'm still fairly new and can't really see much going on in the logs. The sonar doesn't seem to show up at all, although I could see good readings through Mission Planner before.
Any help would be much appreciated :)
Here's a link to the video https://youtu.be/YR-FWMRtvso
Cheers,
Oliver
Replies
From the logs you went from AltHold to Loiter mode and it looks like some trees may have interfered with one of the Satellites as there is large movements in the GPS position. It looks like the GPS veered East suddenly before the crash which would have caused the copter to move West.
Plot the GPS trail too see for yourself. If you click on a spot on the plot it will show where that was in the log and during the flight if you have a plot of GPS Glitch on the graph. This will never show up as a GPS Glitch.
Thanks Michael for looking into this.
I reckon the fly away happened around the 99k line in the logs. The number of GPS sats fluctuates between 9 and 8 and goes up to 10 after having been at bit more stable at 9. HDOP is slightly above 1m. It was a fine day with a clear sky, albeit some hills to the East and West.
Please excuse my limited knowledge of how the control algorithms work. My understanding of how the EKF works was that it will looks at the different sensor data in relation to each other. So when the GPS signals a sudden move (as it did), shouldn't the EKF balance that against the other sensor input, particularly the gyro, and reduce the weight of the GPS data?
Also realistically the quad cannot move around as suddenly as the GPS position suggests, so maybe there should be something to detect that and limit the correctional move or put more weight into the gyro data? (how does the system detect GPS glitches when it does?)
It felt like the quad moved about 20m away before crashing at speed. With the HDOP sitting around 1m, even if the GPS location is off, why would it go such a long distance compared to a much lower error indicated by HDOP?
What I also do not understand is why it first started to descent normally after issuing LAND and the stopped descending before it shot off. I cannot find the LAND command in the logs (probably because I don't know what to look for) and I can't find a tlog either on my Android device (does Tower normally create tlogs?).
Sorry for all these questions. I'm still trying to find sense in this and at this stage simply can't find it.
I believe they are working on how to detect this type of GPS error but at this time there is not a solution.
The GPS glitch usually happens while the copter is coming down as the Satellites become blocked.
I did not see a Land command either just a switch to Loiter which does rely on GPS...
I just posted on another thread to this. I had problems with that too, and noticed when it happened I was near a hillside, building or other obstacle blocking a satellite or two on landing. It makes it to hover, then darts off to crash out of nowhere. In tighter spots, I put it in loiter to guide it and manual. Always check how many satellites you have on the controller, that will help your decision making.
Sorry for the late reply. It was a pretty nice day with clear skies and no obstructions other than some hills in the East and West, so I wasn't expecting the GPS signal to be dodgy. I did check the number of sattelites and the HDOP nd both looked good to me before I took off.
I definitively took away as a learning to fall back into Stabilise when I suspect funny behaviour At the time I put it in brake, but for obvious reasons that hasn't helped.
I'm a little concerned because LAND is used as a failsafe method, e.g. when it looses the transmitter signal. It should really work as reliably as possible because of that and I'l lost some trust into it after this event.
Ok, I did some more reading on the logging parameters.
GPS looks good with a range of sats and low HDOP (1-1.3).
The altitude is jumping around a bit and I have now actually found the rangefinder data, but it's very noisy and blacks out at times
The EKF1 velocity and position jumps around quite a bit, esecially right before it shoots off
Same for the innovations (which is probably a result of the above??)
And here the EKF4 inconsistency graphs
So, the GPS altitude and baro altitude seem ok looking at the first graph. Is it likely that the noisy rangefinder measurements screwed the combined altitude reading? But that doesn't explain why it suddenly went sideways, does it?
no you are right it doesnt explain why it would go sideways...you should also look at your ATT and NTUN figures graphs, that should tell you more if it was a mechanical issue or the autopilot commanded it
See below. I'm not sure if I read it correctly, but it seems that the actual movements are following the intended movements?
yes pretty much you are correct, it was doing what it was told....I think we both are in the same boat...copters suddenly flew off in one direction during a LAND and it was commanded by the autopilot, doesnt look like an external or mechanical issue to me, and I could be wrong but I dont see a GPS issue in neither of our cases
hopefully one of the developers (Randy, Leonard, etc) are able to shed some light on this, mine is grounded until its figured out, what I saw happen with mine was dangerous and could have easily injured someone nearby or the pilot himself. I never had any issue like this in over 50 auto missions prior to 3.3.1 , am not blaming the release just stating my situation
Hmm, are you suggesting that it would be related to v3.3? Have you filed a defect?
-
1
-
2
of 2 Next