Hey All,
A couple of days ago we experienced a strange fly away.
We’re flying Ardupilot over Cube Orange, with uBlox GPS unit.
We did have some GPS glitches, but I treated them as normal GPS glitches as I remembered this area prone to GPS issues.
We had 2 flight:
First was relatively ok, other than a weird moment when the drone suddenly ascended a few feet without a pilot input to do so.
After that, we thought this might be an issue with the filters\vibrations so we tweaked them a bit.
Then in the second flight, after a few moments the drone took a distinct left-backward attitude. The pilot eventually reduced the throttle to avoid loosing the aircraft or hitting anything resulting a hard landing and a few broken pieces.
So far I’ve noticed that just before the fly away the estimated altitude of the vehicle changed, though the barometric altitude remained the same. Also prior to that, there was an input from the pilot to roll right.
I’m having a hard time understanding the complete EKF and attitude estimations.
I’m suspecting that we have EMI glitching our sensors. Both GPS and Cube are relatively close to the motor phases (not signals), though the phases run inside a carbon fiber tube.
I’m also aware that we should update our ArduCopter to the newer release version, on my To Do list.
If anyone can advise on the what cause the flyaway, help will be appreciated! Log File
When vibrations are anything but ideal, filters wont help much.
In you case the non-damped IMU is showing bad vibrations and clipping.
So you’ll have to check everything is secure and not touching the flight controller, wires are not pulled too tight. You might even have to add some damping. But just generally go over the vibrations section in the documentation first.
Messages show multiples of these:
GPS Glitch
Vibration compensation ON
The GPS Glitch message is not actually indicating any issue with the GPS position or signal quality in this case. That all looks good.
The Glitch comes about because the IMU calculated position differs so much from the GPS reported position that Arducopter knows something is wrong and is having trouble deciding which is correct. You can see in messages there is multiple lane switches while Arducopter tries everything it can.
This is all because of vibrations.
I would put back any filter settings you changed, and these
ARMING_CHECK,1
INS_ACCEL_FILTER,10 ← the new default value
INS_GYRO_FILTER ← was it 32 before?
FFT_ENABLE,0 ← it’s not helping you
EK3_PRIMARY,1 ← use the second IMU as default, the new Cube Orange setting
INS_FAST_SAMPLE,3 ← only fast sampling on the damped IMUs
Optionally you can set
FENCE_ENABLE,1
to ensure a good GPS 3D fix before you can arm
Once you are sure that vibrations are fixed you can set
ATC_THR_MIX_MAN,0.5
but definitely not until then.
If the vibrations in the non-damped IMU can NEVER go away by any means, then you can set this to stop using it
EK3_IMU_MASK,3
but this should be a last resort as it reduces your redundancy.
Send another log when you have all that sorted out.
And use Loiter instead of PosHold
Thanks.
I also see that the clipping did not reset in between flights, interesting.
We say that the GPS glitches come from a mismatch between position estimations. If we see good satellite count (>12) and good accuracy (<1m) we assume the GPS is OK. Vibe compensation is active, together with relatively high vibrations in IMU[2] and accumulated clipping, we can be pretty sure to say the GPS Glitches are not caused by the GPS, correct? (just to make sure I get your line of thought).
A few questions:
What are ‘good’ vibration levels for the non dampened IMU 3?
Why does it take that affect on the flight? Since its a different sensor and undumpened (isn’t it there for filtering rather than redundancy?)
As you see it, IMUs 1 and 2 vibrations seems OK, correct?
Parameters - we’ll do mostly as you suggested (I’m not sure about the filters, I’ll have to look what was changed).
We’ve gone through different mounting options to reduce vibrations - hard mounting and a few different types of dampeners. Hopefully we can find another solution to reduce vibrations.
I just searched that and found that PosHold was “superseded” by Loiter… good to know!
Clipping doesnt reset, it’s a count for the entirety of the log file.
There was no problem with your GPS reception, the problems are all because of vibrations.
Acceptable levels of vibration are often said to be below 30 on that graph. In reality anything above 15 to 20 could give you trouble.
Down around 10 is nice, but not always achievable.
You probably only need to change the parameters I listed - I think everything else looked OK.
Have you got a photo of the flight controller and mounting?
The only parameter I see that might take affect on the vibration issue is INS_FAST_SAMPLE, correct?
So according to The Cube documentation, its IMU1 that is non-isolated, not IMU3 as I thought.
That means that the IMU that I keep getting high vibrations on is actually isolated internally.
Any idea if what just I said is true?
With that in mind, and with the fact that IMU[0],IMU[1] show reasonable vibration levels, is it possible we have a hardware issue similar to this one?
Anyways, another question is why IMU[2] was taken into account even though it had such high vibrations and continuously rising clipping count. Probably the dev team can answer that.
Is it possible to priorities the IMUs / EKF lanes?
Here’s how we ended up mounting the cube (a bit odd):
In the logging the non-damped IMU is [2] when counting from 0, and the damped ones are 0 and 1
I’m fairly certain I’ve given the correct params already. I’m not sure why the doco says something else. That discussion is pretty old too, and maybe something changed in the hwdef files and logging since then.
EK3_IMU_MASK,3 is a bitmask, so this is selecting IMU 0 and 1 (1 + 2 = 3) and leaving out IMU 2 (value 4)
If the Cube is not mount close to being central then you’ll probably should adjust these, make them all the same values for each IMU
NS_POS1_X,0
INS_POS1_Y,0
INS_POS1_Z,0
INS_POS2_X,0
INS_POS2_Y,0
INS_POS2_Z,0
INS_POS3_X,0
INS_POS3_Y,0
INS_POS3_Z,0
distance is in meters! (think of mounting a flight controller or IMU out on the tail boom of a helicopter)
Check the link to get the positives and negatives correct too.
The CubeOrange hwdef.inc comments do say that the 3rd one IMU is the non isolated one. Strange.
We have another vehicle that’s mounted on a jig, for testing. But its IMUs show similar relations between IMU1-2 and IMU3, with number 3 being higher.
We might try ignoring IMU3 and see where it takes us.
IMU3 is the non-isolated one per hwdef. You will not fix vibration issues via parameter settings. It’s indicative of a physical problem.
Balance your props. Ensure the motors are installed symmetrically (not tilted at differing angles). Make sure your frame arms are securely mounted. Consider a small amount of foam tape under the autopilot (but not much - the Cube should have a fairly firm mount to the frame for best results).
