If someone could help I will appreciate. I fly a mission today and excepting the landing everything was ok.
So I changed the landing trying to see what could happen, but after the takeoff I look at the gcs(qgroundcontrol) and I saw the plane ignoring the first waypoint, I wait a little to see and the plane was going straight line. So I see was something wrong. I tried to manually change the fly mode from Auto to RTL, and when I select RTL I received a message of Unable to start landing sequence.
The Aircraft was crazy and crashed.
I look at logs and I couldn’t find any erro message or error or something.
I do not know how you managed that, but the AP was at mission item 83 (ID=21 = Land) long before takeoff, most likely you commanded it on GCS. - there are safeguards against “landing again” during a landing - you need a MAV_CMD_DO_LAND_START , usually a place where landing pattern starts.
As for the “crazy and crashed” , I did not spend time checking it out, as the altitude dropped smoohtly over 8.5 seconds , and you just left it in RTL mode, I consider that almost as a willful flight into terrain
the land point was because a watering hole.
I used in the past the DO_LAND_START but after talking with magicrub the DO_LAND_START for my kind of flight is not necessary.
I really trying to figure out what happen because the plane just ignore the mission and go in a straight line.
The reason the airplane kept going in a straight line is that it was still in takeoff mode. In takeoff mode, the aircraft holds its heading and pitch angle until it reaches the target altitude. In your case, the target altitude was set to 120 meters and the aircraft was having difficulty reaching that altitude.
My recommendation is to make the takeoff waypoint altitude much lower. Usually, it should be high enough to clear any obstructions near the takeoff route, but lower than your first waypoint. In this case, 30 or 40 meters would probably have been a good number.
You might also want to increase your target pitch attitude for takeoff. The aircraft readily held the 15 degree pitch angle and target airspeed through the climbout, but was not climbing very quickly. I’d try 18 or 20 degree climb angle (assuming your autopilot level is already properly calibrated, if not, do that first).
It looks like when you tried to change modes to recover, it caused an aerodynamic or structural issue with the aircraft, causing it to spin out of control. In this case, if you would have left the aircraft alone, it probably would have been OK, it would have eventually gotten to 120 meters and started towards waypoint 2. There’s a secondary issue with the autoland that @Andre-K mentioned, perhaps because it was still in takeoff mode. I’m not familiar enough with the depths of Arduplane code to answer that one.
really thanks for your help. I know this appear to be a excuse but I always end the takeoff procedure with 50 meters and takeoff angle in 20 degrees but in this case I didn’t made that - and why in the first flight the altitude was achieved and in the second not is a mysterious. But really thanks for you time and analysis in my case.
I will review the land.
Hello @juvinski,
the crash at the end of this fligth could be related to the “reset integrator bug” that is fixed in ArduPlane 3.8 but not yet in 3.7.1. This was the cause of several crashes with my planes, so I know it well When changing modes (i.e. to RTL), an internal value of the integral part of the PIDs is incorrectly reset, so the attitude control does not work properly. That could explain why you plane in RTL have a roll of +100 degrees when the maximum should be 50. You can see in your dataflash log plotting PIDP.I and PIDR.I, the value goes to zero on mode changes, then increase slowly. Thats exactly what happened in my crashes, roll was +90deg and plane entered an “spiral of death”.
Being said that, it seems that having an integral value in the PIDs is a symtomp that the plane is not well tuned, that is, it is not well trimmed in manual mode, so the autopilot is constantly applying a correction in roll, pitch or yaw and that increases the integral part; a well trimmed plane should have a very low value of I and therefore the bug should not produce any effect. For me, it is very difficult to fly in manual so I left all the work to the autopilot, that works perfectly not that I have upgraded to Arduplane 3.8beta.
Good luck,
Adolfo.
It’s sad to say that but thanks for the information - sad because you had to pass for several crashed to discover this problem.
I have the same problem with manual mode - it’s really hard to me but will be necessary
Thanks again for the clarification - I had in another flight on month ago a problem changing to RTL flight mode, I will check the logs to see if the behavior was the same.
I used in the past the DO_LAND_START but after talking with magicrub the DO_LAND_START for my kind of flight is not necessary.
I recommend everyone use DO_LAND_START because it allows for safer RTLs and better aborted landings. Just keep in mind that it is not a navigation point, the lat/lng is never flown to. It’s only used if there are multiple DO_LAND_STARTs then it will jump the mission to the nearest one (allowing multiple RTL landing sites for full AUTOnomy).
“A nose heavy plane flies badly, a tail heavy plane flies once”. You were extremely tail heavy. You maxxed out the pitch integrator that was trying to compensate the weight imbalance.
TRIM_ARSPD_CM=1200 which means your cruise speed was changed to 12m/s. Default is 15. Are you sure your value
TECS_LAND_THR=5 so if you triggered a land you would have commanded a stall… except ARSPD_MIN=9 (default) so it would have constrained you inhibiting the stall (if that value is accurate for your aircraft).
you did not have an airspeed sensor. It flies better with it, I highly recommend them. Without it then the system has to estimate it so you should raise your speeds to be more conservative (you did the opposite).
MISSION:
you have TAKEOFF at 120m and then the fly back home with a WAYPOINT at 50m and then back to the next waypoint at 120m. That’s odd but not related to the crash.
You set DO_CHANGE_SPEED to 2m/s for your landing!!! You’ll be constrained to 9 by the stall prevention logic… but come on, what are you doing!!! If you want a lower speed for your landing, please use TECS_LAND_ARSPD and use a real value.
the “Unable to start landing sequence” message was because you had a LAND but no DO_LAND_START. That’s OK but the wording looks scary, we should change that wording.
THE TAKEOFF:
The aircraft is not able to maintain the pitch very well. CTUN.Pitch vs CTUN.NavPitch. It does reach it, but it’s only occasionally and the average is always below it. This is typical for tail heavy and slow aircraft.
Your throttle demand was pegged at 62%, that’s low. I don’t understand that, but I can see it happening in the TECS.F[lag]=8 which means “reached_speed_takeoff”. That logic may have been improved in v3.8 for non-airspeed_sensors… Do yourself a favor and get an airspeed sensor.
LATER ON…
As mentioned, v3.7.1 suffers from the PID integrator reset which is fixed in 3.8 and it mostly effects aircraft that have incredibly bad balance. That didn’t cause the crash though.
When you switched to LOITER it held it’s altitude fairly well while the integrator relearned the balance and things were still OK. In fact, it performed a quarter turn holding a relatively stable 45deg right turn before you switched to MANUAL…
You were not in this mode for very long, just a few seconds, but it was a few seconds too long. Since your balance was so bad the autopilot was applying a lot of up elevator to keep you in the air so when you switched to MANUAL you immediately did a nose-dive. Also, since you were in the process of performing a loiter turn you were performing a 45deg right roll when you switched, you may not have been able to see that from that distance and you rolled over further in MANUAL causing a death dive.
By the time you hit RTL you were 45deg pitch-down and 90deg rolled (which quickly continued to 125) while dropping altitude at 20m/s (GPS.VZ). Your roll quickly continued to 125deg which means it was inverted. None of the auto modes like to be “surprised” as inverted per this open issue. Your CTUN.Roll/CTUN.NavRoll had diverged while in MANUAL (which is normal) but it was not converging back while in RTL which means it was having a really hard time taking over control while in it’s current scenario. The dive was definitely not commanded by RTL, you were a gonner before RTL started. In this case if you had switched from LOITER → RTL you would have flown home just fine. The fact that it wasn’t able to recover was either a structural failure from the roll/dive or your aircraft just doesn’t fly well in that orientation or RTL didn’t like being upsidedown. The autopilot tried “normal” things to save it but “extraordinary” piloting was needed.
…and you just left it in RTL mode, I consider that almost as a willful flight into terrain
I disagree. It was getting pretty far away and at the time it was his best option. RTL should bring you back no matter what. Besides, in this case flying in MANUAL is what started the death spiral
Conclusion:
you were flying too slow and without an airspeed sensor that is very dangerous
very tail heavy (biggest contributor to the crash)
possible bug v3.7.1 in TECS throttle logic for no-airspeed systems which is already fixed in v3.8. Not confirmed.
When changing modes (i.e. to RTL), an internal value of the integral part of the PIDs is incorrectly reset, so the attitude control does not work properly. That could explain why you plane in RTL have a roll of +100 degrees when the maximum should be 50. You can see in your dataflash log plotting PIDP.I and PIDR.I, the value goes to zero on mode changes, then increase slowly. Thats exactly what happened in my crashes, roll was +90deg and plane entered an “spiral of death”.