You do understand that the climb would have stopped if you had switched to stabilize though?
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.
See this (V3.6.8/NuttX):
Ā·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.
Well yea. AtlHold controller modes are influenced by Z-axis acceleration.
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.
We had two continuous climb experiences when using Optical Flow Sensors + Rangefinders.
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.
Case 1, we used Hex HereFlow Optical Flow Sensor + LightWare SF20 / LW20
Case 2, we used PX4FLOW Optical Flow Camera Board without sonar + LightWare SF20 / LW20
However, we can Off the flow sensor and only enable the rangefinder. we do not experience uncontrolled climb.
It concluded to us that once the flow sensor is enabled, we cannot disable the range finder including the onboard rangefinder. Can someone confirm?
It is confirmed that a height sensor MUST be installed and here.
therefore, the document must update to include (To use the onboard lidar (not recommended):) or change to MUST (should also be attached to the vehicle). And I am not the only one and this has happened for many years.
FW: 4.0.7
FCU: CubeOrange
propeller size: 9 inch
weight: 2.0Kg
I have encountered this problem recently, but I think the record seems to have solved it. Later friends can see the relevant information of this linkļ¼
EKF3: Fix covariance matrix stability issues by priseborough Ā· Pull Request #16842 Ā· ArduPilot/ardupilot (github.com)
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