I had my 3.6 quadplane flying so nicely tonight, but it ended in a crash that totaled the plane. I was flying around at about 30m in FBWA when the controls became ineffective. Looking at the logs it appears that the problem started first at line 598
I checked the power and it doesn’t look like a brown out. I was flying at a safe airspeed. Post mortem shows the servos and linkages operational. The Pixhawk boots up normally, and FBWA provides normal responses. The RSSI on the RC looks normal.
What the heck happened!!
This is exactly what happened to me 2 days ago. All servos stopped working but I just managed recover by going back into Qloiter mode and brought it home. I have also posted about this and have made my logs available, hope to hear from someone soon.
Update from my side: I have a feeling I did not power up the servo rail (doh!). After 30 years of flying RC I should know better and should have just checked the controls! Just lucky in my case that I managed to save the model. Iskess, sorry for your loss, hope you get another QP up and flying soon!
@iskess, darn, so sorry you lost your plane!
I’ve had a look at the log and it looks like a stall. How did you estimate the stall speed with the extra weight and drag of the quad motors? The loss of control happens when the plane is at an airspeed of 10m/s, at a bank angle of 15 degrees. An AERO would normally fly at below 10m/s (although not much below), but with the extra weight and drag impact of the quad motors the stall speed could be higher.
I also notice that the airspeed sensor calibration in the log, but that is probably because it was done before logging started. Was there much wind? I notice the airspeed sensor showing about 3m/s before takeoff. Is that offset error in the sensor or is that just a bit of wind?
I note that the quad motors did kick in, but only after there was already total loss of control and the plane was too close to the ground for it to recover. If Q_ASSIST_SPEED had been one m/s higher then I think it would have kicked in with sufficient time to recover.
I’m very happy to look into the log some more if the above doesn’t match what you saw.
I wonder if we should have a parameter to make the quad motors kick in above Q_ASSIST_SPEED if there seems to be loss of attitude control? For example, a Q_CONTROL_LOSS parameter, which would be an angle in degrees. If the desired versus achieved attitude is off by more than that angle and we are above Q_ASSIST_SPEED then the quad motors could kick in to add stability. With it set to 30 it would have stabilised and saved your aircraft I think.
What do you think?
Thank you for taking the time to look into my crash. When I first looked at the logs it appeared that I was well above 10 m/s at the time of the event, but I see that the event actually started a bit sooner than than that, and there was indeed a point where the airspeed dropped to 10.6 m/s. I was about 500g heavier than I have historically flown this plane. On the maiden flight with the quadplane, I did several stalls to test the Q_ASSIST_SPEED, and it the quad would fire up prior to stall. So the more I look at this the more I agree that it looks like the result of the nasty tip stall tendency of the Skywalker 1880 wing. Perhaps I was just too close to the stall margin and within the airspeed sensor margin of error at this unlucky moment. These was a ~10 mph wind that day, so the airspeed sensor reading on the ground does make sense.
I think a Q_CONTROL_LOSS parameter is a great idea. I have this Issue open that is somewhat related https://github.com/ArduPilot/ardupilot/issues/4414
I don’t want to Q_ASSIST to help with vertical navigation like it says in the wiki:
> "If you are flying in an autonomous or semi-autonomous mode then the quad motors will try to assist with whatever climb rate and turn rate the autonomous flight mode wants. In a manually navigated mode the quad will try to provide assistance that fits with the pilot inputs."
I just want the quad motors for take-off, landing, and in case of a loss of control or loss of power to the horizontal motor.
There are several parameters that I can attribute to my crashes. They are like my consolation prizes
Thank you for your dedication to improving the code.
I’ve been thinking about Q_CONTROL_LOSS some more today, and the key is to not get too many false positives, as they would drain the battery very quickly. I’m thinking of this:
control_loss is true if the roll or pitch is both outside the LIM_ROLL_CD/LIM_PITCH_MAX/LIM_PITCH_MIN by at least 5 degrees and more than Q_CONTROL_LOSS degrees from the desired attitude for more than 1 second. The airspeed must also be above ARSPD_FBW_MIN.
How does that sound? I’m particularly concerned about false positives when the pilot puts in sudden attitude demand changes. So imagine the pilot goes from full right roll suddenly to full left roll. The attitude error will for a short time be quite large, but the attitude should be within the range given by LIM_ROLL_CD, so the control loss shouldn’t trigger.
Also, should it be on by default? Or should it be like Q_ASSIST_SPEED and you have to enable it by setting it non-zero?
That sounds too strict to me. I set my LIM_ROLL to 60 deg so I can get tight mapping turns. So with that criteria, the plane would have to exceed 65 deg of bank for more than 1 sec. At this point I’m probably knife edge or inverted and the quad can’t help much. Some aircraft can roll several times in a sec, so this shouldn’t be a fixed number.
Isn’t it safe to assume that the attitude limits should never be exceeded by 5 degrees? So why do we even need a degrees error value for Q_CONTROL_LOSS? I think we might be able to make those criterion an OR rather than an AND, where the Q_CONTROL_LOSS value is the time that we allow the error for. So while tuning, we slam the stick side to side and if the quad engages we increase the value until we can aggressively maneuver without activating the quad.
Or maybe it should look at the attitude trend. If the attitude is diverging from the nav command the quad activates. Even a slow responding poorly tuned aircraft should not be moving in the opposite direction from the command.
Why must the airspeed be above ARSPD_FBW_MIN? If the plane is unintentionally stalled in FBWA, and Q_ASSIST is turned off, wouldn’t we want the CONTROL_LOSS code to kick in?
I think it should be enabled by default since it is a safety feature. The cost is efficiency, and users can adjust the parameter to be optimum for their aircraft and operational need. At least it will provide protection during the risky initial testing phases of a new build.
Is there an easy way to identify when the Quad motors have engaged during flight? Is there a MAVLINK message that can be sent to the GCS to alert the operator. If the Q_CONTROL_LOSS and/or Q_ASSIST keep engaging during a flight something maybe wrong and the operator needs to know.
I nearly had another crash today due to loss of control.
I rebuilt the Quadplane, and after 15 hours of repair work I was ready for a re-maiden. I put it in a traditional RTL to calibrate the airspeed. After a few nice orbits, I glanced down to adjust some parameters. When I looked up the plane was in a descent heading straight towards me! I pulled back on the stick back but Stick Mixing wasn’t working. I quickly switched to Manual mode, but the elevator was not responding. I got it turned into the wind and it leveled out. I switched to QHover and landed it safely at my feet. Doing another control check on the ground I saw that the elevator servo was intermittently unresponsive. I had replaced it during the rebuild.
@Tridge, Please work on Q_CONTROL_LOSS, it might have prevented an accident today. I actually prefer the name Q_ASS_SAVE, but its your call.
@iskess, yes, I will work on it as soon as I can.
I’ve decided to call it Q_ASSIST_ANGLE, to go along with Q_ASSIST_SPEED.
Today I want to build the ArduPlane V3.6.0 on Win7 using px4_toolchain_installer_v14_win, but I failed.
The building tool what I used is from website
The problem is
c:/TriCopter/ardupilot/libraries/AP_Common/missing/byteswap.h: In function ‘uint16_t __bswap_16(uint16_t)’:
make: Leaving directory
/c/TriCopter/ardupilot/modules/PX4Firmware/Build/px4fmu-v2_APM.build' make: Leaving directory/c/TriCopter/ardupilot’
c:/TriCopter/ardupilot/libraries/AP_Common/missing/byteswap.h:11:42: error: ‘__builtin_bswap16’ was not declared in this scope
compilation terminated due to -Wfatal-errors.
make: *** [libraries/AP_ADC/AP_ADC_ADS1115.cpp.o] Error 1
make: *** [/c/TriCopter/ardupilot/modules/PX4Firmware/Build/px4fmu-v2_APM.build//c/TriCopter/ardupilot/module.pre.o] Error 2
make: *** [/c/TriCopter/ardupilot/modules/PX4Firmware/Build/px4fmu-v2_APM.build/firmware.px4] Error 2
make: *** [px4-v2] Error 2
it is no problem when I build the old ArduPlane V3.6.0 beta1 version using the same complier tool. I found it has no byteswap.h file in this old vesion.
I want to know how to deal with this bug!
Hope to a quick reply!
Hi Tridge and Iskess
I’m a bit late to the conversation but I think that Q_ASSIST_ANGLE is a good idea in general. (I just joined here from DIYD)
I’m thinking one way to limit quad intervention in forward flight to maintain forward efficiency, is to limit it from activating over a certain airspeed (like typical airplane cruise - say under 20m/s) and/or only have it active under a certain altitude above ground.
Typically, the aircraft should not require quad assistance in forward flight if significantly over it’s stall speed. Likewise if it is over “2-3 mistakes high” it will likely have enough time to recover before hitting the ground, potentially even without quad assistance, and a stall will trigger the low speed assistance anyway. Although this could be left off as default (so assistance is on by default) I think it would help to tune the airframe for higher speed and altitude, forward flight efficiency.
Another addition could also be to use the forward motor to increase forward speed as a form of “stall prevention” using the Q_ASSIST_ANGLE, as this could help in even non-quadplane craft as well.
Can you check the code to confirm that Q_ASSIST will not engage above the Q_ASSIST speed in any circumstance?
The wiki article is ambiguous saying:
If you are flying in an autonomous or semi-autonomous mode then the quad motors will try to assist with whatever climb rate and turn rate the autonomous flight mode wants.
Thanks for the links Magicrub
Sorry I posted the wrong word in that sentence, it should of been under not over: It should have read:
I’m thinking one way to limit quad intervention in forward flight to maintain forward efficiency, is to limit it from activating UNDER a certain airspeed (like typical airplane cruise - say under 20m/s) and/or only have it active under a certain altitude above ground.
This was in relation to the behavior of the proposed Q_ASSIST_ANGLE feature; to my understanding this uses quad assistance if the wings tip stall etc, which in turn would reduce forward battery efficiency, if it kicked in to often or early in normal forward flight. By limiting Q_ASSIST_ANGLE to only be active under a specific airspeed it would not affect higher cruise speeds, where stall is less likely anyway.