I don’t see anything wrong with that accelerometer. It did correctly show the accelerations when the vehicle took off, accelerating upwards, also when it changed from climbing to falling.
Keep in mind that an accelerometer does NOT measure speed, nor position. ONLY acceleration, including G force. When a vehicle is moving at any speed in any direction (and that includes climbing), but at constant speed and in levelled attitude, the acccelerometer should show zero in X and Y, and -9.8m/s² in Z. Even if it’s shooting up like crazy, but at constant velocity, the accelerometer should still read -9.8m/s². And this one did. So the problem must lie elsewhere.
Even if it’s not my place, as a newcomer, I will attempt a general explanation of these unexplained climb-aways, that seem to be unnervingly common. It’s highly speculative, since I don’t know the detailed internal working of the software, so take it for what little it might be worth.
Let’s assume that we have a drone that suffers from high vibration at a frequency above the lowpass filters (propeller rotation frequency). Based on my own experience with my quad, it seems that the vibe measurement, including clipping testing, doesn’t properly report this. It seems to report only the vibration that falls below the lowpass filter cutoff. If that is true (please, can someone tell if it’s true or not?), then it could very easily happen that the accelerometer is clipping from the high frequency vibration, and since the Z axis normally is at -9.8m/s², it will clip on the negative side long before it does so on the positive side. Instead in X and Y, which are normally at zero, any moderate clipping will typically be symmetrical, and thus cause no big error in the low-pass-filtered values.
If Z does clip, then the negative peaks will be shaved off, while the positive ones will not. So after the lowpass filter we get a more positive value than correct. And a more positive Z acceleration value normally means that the vehicle is accelerating downwards, which would obviously make the EKF calculate an altitude that drops ever faster (and indeed the CTUN.ALT shows that behaviour, in this case!), and trigger a throttle increase that makes the vehicle climb away.
I think that it would be important to make sure that accelerometer clipping is checked BEFORE lowpass filtering, sample per sample. That includes any lowpass filtering done in hardware - and this could be a limitation with any specific accelerometers implementing some lowpass filtering on-chip.
Also I think that it would be very important for the software to NOT trust the accelerometer above everything else. I mean, in this case the baro was correctly saying that the vehicle was climbing away, the GPS was saying the same, the climb rate determined by baro and GPS agreed very well, but still the software decided to disregard all that and say that the vehicle was descending and needed more throttle, apparently only based on very slightly wrong accelerometer data caused by high-frequency vibration and undetected accelerometer clipping, integrated over several minutes! That’s crazy. The correct data was available, from two independent sources, and the flight control software didn’t use it.
Mallikarjun, in this case the baro was correct and the EKF calculated totally wrong data.
A slow baro drift of 10 to 20m during a flight is perfectly normal, due to temperature changes. And if you are flying in the wake of a building when there is strong wind, the turbulence can easily cause the baro to show fast variations of a few meters. Prop wash also does. So you can’t trust a baro for precision altitude measurement and control. But in this fly-away the vehicle climbed to over 600m! For that magnitude of signal, baros are highly reliable.
In the region of interest CTUN.Alt and CTUN.Dalt are close and negative, but there are reliable data from the barometer and GPS. This is hard to admit.
In the vibration levels change mentioned above after second 100 (without explanation, but also causing a sudden climb) suddenly they appear more less four times greater (x4):
Pixhawk accelerometers have scales up to ±2g, ±4g, ±8g, and ±16g, so imagine mistaking as instant scaling ±2g<>±8g or ±4g<>±16g.
I have implemented most of the arming checks now, backported this PR (https://github.com/ArduPilot/ardupilot/pull/15092) from master to stable version (arducopter 4.0.4) which i am using, still after all this, what are the chances of this issue arising during the flight ? Cause i doubt any failsafe (land, RTL etc) going to help me in that case, i don’t think copter will stop climbing
If there gonna be any slight chances of this issue getting reproduce during the flight then i will better place a flight termination timeout condition too depending upon difference between baro/gps altitudes vs ekf altitude, i also know that with this PR (https://github.com/ArduPilot/ardupilot/pull/15092) i can able to get control on quadcopter ascent and descent but in case where i probably fly multiple quadcopters together then this can make things messy
I fly several quadcopters and an hexacopter (possibly overpowered, but waiting full reliability for placing a camera). When above happened on the hexacopter, and it was not the first time, (never in quadcopters) I decided to wait to fly it again. I see that other people have had the same problem (unexpected climbs). I wonder if 4.1.0 will improve this, or may be I try PX4.
@Notorious7 With your flight mode parameter and rc_options parameters, how do you select stabilize mode? It looks like you were almost never in stabilize mode (with manual throttle control) during the uncommanded climb.
you are right, i was not able to stay in stabilize mode cause i panicked when i saw the quadcopter keep climbing up, i tried to switched in stabilize but i also keep giving land command at same time, since both land and stabilize was set on different RC switch, i got confused, but i really don’t intend to switch to stabilize again cause i have mulitple quadcopters connected to same RC transmitter at same time in air
yeah, i was really not prepared for this event, but i do regret it when i saw the log, i guessed the same, it probably be different scenario if i managed to stay in stabilize for quite a while
can there be any other way to deal with that scenario if i customize the firmware or use lua scripting feature ? like if firmware can know things not going right with ekf estimations then it can safely take control of the drone directly without using RC transmitter and using something like RC_override feature from my custom code or lua scripting to set throttle pwm value to something around 1400 in poshold mode
Interesting but difficult. How many? I have done three quadcopters and three quadcopters and one rover with 3/4 transmitters and 3/4 MP instances (3/4 voices), and things were in the limit of being controllable.
Those scenes of hundredths of drones seem to be other thing.
Well, thats the motivation moving ahead, right now having 6 quadcopters connected to RC transmitter but not connecting any quadcopter with GCS, i am just using RC switches to start a pre-programmed mission on multiple quadcopters in guided mode similar to running missions in auto mode
You can run one MP instance with a connection list to the six quadcopters. You will get six .tlog files and see the six quadcopters moving on the MP screen, although voice and purple trace will correspond to the selected one on the upright box.
The main reason for running 3/4 MP instances was for having the 3/4 voices; for example, every 30 seconds you hear the battery voltage message of all.
This is interesting. Do you mean and confirm that in any situation with altitude automatically controlled (AltHold, PosHold, Loiter, Auto, brake…), including Autotune on or Vibration Compensation on, moving transmitter switch or switches to select Stabilize mode (or Acro may be) altitude control will be controlled by the pilot, and any sudden climb for whatever the reason will be stopped?
If so and fearing a sudden climb, be prepared to change rapidly to Stabilize if it happens, not lowering throttle.
·Uncontrolled ascent at 8m30s (6m/s).
·Throttle down (RCIN.C3=1000).
·At 8m40s Loiter->Stabilize.
·Ascent continues briefly, peaks and descent begins.
.Possibly pilot (in panic) accelerates briefly, which makes CTUN.ThO grow, but strangely vibration levels increase drastically.
Since STABILIZE mode uses manual throttle control (not altitude control), it doesn’t matter if the EKF altitude estimate is wrong. It is my primary fallback mode, and will allow you to fly the copter as long as the attitude estimate remains reasonably good.
It’s also normal for vibration levels to increase with throttle, since this results in higher motor and prop RPM, and could expose additional problems related to frame resonances, etc.
When we disable the rangefinder while keeping the flow sensor on, the barometer is not disabled, under alt-hold, it climbs continuously. Both cases happened in the same scenario.
yes, as @Awesome mentioned this patch has resolved my issue, but it is not backported yet to any stable Copter release, you need to use master or check if it has been included in recent beta release
@Notorious7
In fact, this patch should be applied to the latest stable version. This kind of problem in flight is often fatal. The latest version is currently only a test version. For fear of other unknown problems, I have to try to transplant this part of the code myself. To 4.0.7
