Hi, despite my long experience with Arduplane, yesterday I damn destroyed my brand new Vtail plane for its maiden flight…It is the first time I configured a Vtail, so I took lot of time checking control surfaces, as per this page: V-Tail Planes — Plane documentation and everything was ok, in stabilized or manual mode. Also, as for my every maiden, I took my time to perfectly align CG. Well, this beautifull plane climbed well up to 15m, so I though yeah everything is ok, but then it rapidly lost pitch and start to go down at full throttle…and crashed violently.
Well that’s life in RC world and I already had disappointments like that in this hobby, but as my children say, dad never give up 
So now I am trying to troubleshoot what happened, and sadly cannot find any reason why it happens. I only have few direction…like MIXING_GAIN that I left unchanged to 0.5 despite I noticed that vtail control surfaces had low travel size. But if it crash was due to that, why does the plane initially climbed well ? Another is that my FC is oriented upside down, so I set AHRS_ORIENTATION to 8. Maybe it could come from it ?
So I’m lost at this point and every help is welcome
Thanks
log and parameter.conf:
Archive.zip (482.4 KB)
Well, after a few hours of work and an entire tube of uhu-por glue, I finally get this bad boy to the sky…It seems that the responsible for my initial crash was this parameter as I presented: MIXING_GAIN I fixed it to 1 instead of default 0.5 value and now my plane is flying. It’s a shame that this parameter is not by default at 1…it would have saved me from destroying my plane and would have saved me many hours of repairs
MIXING_GAIN set to 1 will cause loss of pitch authority when any rudder input is given. 0.5 is safe default value as no control input will cause excessive control surface demand. I would recommend setting MIXING_GAIN a bit lower like 0.8 to have some (25%) rudder authority at full up elevator demand, otherwise you will potentially lose altitude when rudder is deflected especially when flying at a low speed.
PS please post the .bin file of the flight. I am curious why it dropped after climbing to 15 m instead of failing instantly.
Thanks @LupusTheCanine. I will try with 0.8 and see what happen with tail control surface at bench before using auto take-off…I don’t think that this plane will support another crash ;-). The log file is in my first post (sorry it is .log file not a .bin due to anonymization). Also putted the parameter.conf int the zip file.
Another parameter that could also help is MIXING_OFFSET. Maybe I should let MIXING_GAIN to 0.5 and use MIXING_OFFSET to compensate the low amplitude of tail control surfaces ?
Thanks, I missed that sneaky zip 
Just tried with MIXING_GAIN=0.8 and plane still fly, and probably safer now thanks to you 
I noticed a little overshoot at takeoff between first and second stage but I have to confirm as it is very windy today and it could be due to that.
I don’t think mixing gain was responsible for the issue.
- Don’t do inaugural flight in highly automated modes.
- Have manual mode ready during testing. IMHO situation was salvageable if you switched to manual
- Your airspeed is miscalibrated if I am reading correctly, it consistently reads ~20% too high
- ARSPD_FBW_MAX could be a bit higher, like 25. Best to check after calibrating airspeed sensor.
-
I don’t think the plane was tuned. I would go through tuning procedure before using any assisted flight modes.It looks like it has default parameters by AtomRC. Still I would check how it flies before trusting automation, looking especially for elevator trim.
PS Please enable TECS logging.
PSS I am not sure if your pitch trim is correct. Also your plane wasn’t climbing well, it couldn’t maintain demanded pitch but instead it kept getting higher.
Hi, thanks to take time to look into logs.
- You’re 100% right but as I always had success in auto-takeoff with my previous planes, it tend to be overconfident…
- I did…but in panic I used the wrong switch (activated unused one)
- This plane does not have Airspeed sensor, so values are derived from synthetic airspeed. Don’t know why values are wrong then.
- As explained in documentations, ARSPD_FBW_MAX is not used for airspeed limiting when not airspeed sensor is present. This parameter is used only for Stall prevention then.
- I’m not very good in manual takeoff maneuver, that’s why I prefer to use auto-takeoff but again you’re 100% right about the fact that I have to try manual takeoff at maiden as it should cause less damage in case of fail
PSS. I did pitch trim with plane laid on a flat surface, aligning Vtail control surface with tail. Not sure it is the best way as I don’t know if the plane is at the right pitch when on a flat ground, notably because of the front wheel.
- Happens to the best of us
- See 1. Panic is a killer in aviation. It helps to have consistent control schemes.
- Curiously there was a high discrepancy between SAs and As with the later being significantly higher. To me control scaling looked like it followed As not SAs.
- IIRC you had ARSPD_TYPE set to 1, set it to 0 so it knows not to look for an airspeed sensor, please also check TECS_SYNAIRSPEED is disabled.
- It would be good to practice manual flying in general if you don’t feel confident with that yet. Especially takeoffs and landings. Flying in manual you would also have avoided failure to go to manual flight mode
Reg. PSS you should trim servos when in manual flight mode with sticks centered. This way if the plane is balanced at design CG and it was designed correctly it should have neutral elevator at cruise speed. DO NOT USE radio trim.
Hi, you’re right about ARSPD_TYPE but to me it does not matter as long as ARSPD_USE is set to zero. But I could be wrong.
I have similar takeoff problems with an XUAV MiniTalon without airspeed sensor. The plane is quite heavy with 75g/dm2 wing loading. I noticed similar differences between the SAs and As airspeed estimations during the takeoff phase. Plane: Bad EKF3 wind and airspeed estimation during takeoff with synthetic airspeed - Takeoff problems These test flights were with TECS_SYNAIRSPEED=1.
Hi, after several new flights and another crash in the same condition, here are my observations after log analysis:
1- I blamed too quickly the MIXING_GAIN parameter. I can now fly this plane very well with value of 0.6 So it not responsible of the crashes
2- I have now enough logs of crashed and good flights to compare and despite I cannot point the exact reason of crashes I can say that:
2.1- Crashes are not due to synthetic airspeed estimation. In every cases for me, this value seems good and at least constant in every cases (crash or good flights)
2.2- One thing seems “bad” in logs: height management. As you can see in following screenshots, during crashed takeoffs, it looks like demanded height (and so demanded delta-height) does not behave correctly
Takeoff crash 1 (log on first post)
Takeoff crash 2 (switched to FBWA at the trying to save my plane without success
)
Successful takeoff:
Yesterday: 3 good flights with perfect takeoff
Today: Same wind condition, same place to launch, same plane, same configuration…and another takeoff crash with same behavior. Plane totally destroyed this time, no way to rebuild.
I give up with Ardupilot
Thanks for all.
EDIT: after a long analysis of the logs I come to the conclusion that there should be a problem with Auto-Takeoff procedure in Arduplane 4.3. I am not skilled enough to understand why but I can clearly see that sometimes the TakeOff procedure does not goes into step 2, when reaching TKOFF_LVL_ALT. Instead, TECS demanded height goes down to zero and force the plane to crash at full speed
In Auto Takeoff, both pitch angle and throttle are set to the specified values (TKOFF_LVL_PITCH, TKOFF_THR_MAX), so TECS is not involved in this case.
In TAKEOFF MODE, the demanded hight is only tracked to the actual altitude. This allows the demanded height to change seamlessly when Takeoff is completed and the mode is changed to Auto.
My concern is the PID gain on the pitch controller, it appears that the PID gain remains at the default value. Have you tuned the PID?
My observations are as follows.
First of all, the FF component is too large and the pitch angle is much exceeded the target pitch angle (DesPitch). In addition, since the integral gain is also large, the I component is heavily negatively skewed. As the pitch turned downward, the I component began to increase, but the pitch remained downward while the I component was negative.
You said that AutoTakeoff has worked on some cases, and it may work depending on the conditions of hand launching. I would like to see a log of when it worked.
Hi, thanks @hatnac to take your time trying to help me. Here are two flights made 2 days apart. As you can see below each has been launched from the exact same point and direction and I certify that wind conditions were the same.
Crash trakeoff (not the same as previous log on first post):
log
Good takeoff
log
As you said the plane is not tuned because it flew and took off very well from the start. That said, I also did an autotuning session and despite that I had a failed takeoff that almost ended in a crash. I miraculously saved the plane by switching to manual mode just before impact, as you can see in this log. I then preferred to take off in FBWA mode 
.
Sorry to provide anonymized logs only but consider I have a good reason for that. Please just don’t bother about this.
crashtakeofflog:
I believe the cause is the same as the first crash. The pitch was too high and the integral component pulled back excessively, leading to the crash without recovery of the down pitch.
goodtakeofflog:
The behavior was basically the same for the success as for the failure.
However, the initial overshoot of the pitch angle was not so great and the I-component did not drop so much that the recovery after the pitch became negative was successful, resulting in a just barely successful takeoff. This is not a success, but rather a takeoff that just barely avoided failure. The fate of the aircraft seems to depend on whether the initial pitch angle exceeds 30 degrees or not.
Since the aircraft does not have sufficient speed immediately after takeoff, I think it is good to tune the pitch controller so that the pitch angle is less than DesPitch during takeoff.
Once the plane moves into level flight, the deviation between DesPitch and Pitch seems to be slightly large, but the flight is generally stable.
The risk of a crash is greatest at takeoff because of the large deviation between the target pitch angle and the actual pitch angle. I strongly recommend tuning the pitching controller (and of course the roll controller).
failedtakeofflog:
This log appears to be a record of a takeoff at FBW, and I don’t see any particular problem; I think the Pitch tracks well with DesPitch.
Impressive. I didn’t think that too much I on Pitch controller could cause an automatic takeoff to fail. I had noticed that the plane was taking off on a very vertical slope, far from the 15deg of TKOFF_LVL_PITCH, but I was far from imagining that this could cause the crash. What I don’t understand is why after an Autotune session, the PTCH_RATE_FF has been set to 0.428 which is above the 0.345 default value, that seems, according to you, already too high. Also, the I term has been raised to 0.428 against 0.15 by default. I’m a bit lost because your explanations seems very good on one side and on the other side Autotune take the opposite direction.
Thanks to you, I re-motivated myself and rebuilt that plane…It looks like a Frankenstein plane now but this bad boy should fly Thad said, I will wait your response before trying a new AutoTakeOff 
EDIT: As soon as repaired…As soon as destroyed 
Reverted to default Pitch PID and taking Off in FBWA this time. But you probably could predict that FBW is responding to the same logic as TakeOff…What I don’t understand is that AtomRC gives Arduplane Parameters for this plane with default Pitch PIDs.
Here is AtomRC parameters:
SF1200NAVIAP20221205_f61ff4d8-df71-4003-a085-6f564e89e530.param (22.1 KB)
Here is my today crash…: https://shares.s3.par01.cloud-object-storage.appdomain.cloud/FBWA_TKOFF_crash.log
And Here is a little video of today disaster 
https://shares.s3.par01.cloud-object-storage.appdomain.cloud/FBWA_TKOFF_crash.mp4
Well this time it went to the trash…
I am ashamed to say that I was wrong due to my lack of understanding. I re-read the documentation and code, and the target value of PID is not the “pitch angle” but the “pitch angular rate” calculated from the deviation of the actual pitch angle from the target value of the pitch angle.
It was a mistake to say that the overshoot was caused by a large FF. The correct answer is that because the FF is small, the aircraft follows the target pitch angular rate too slowly, and even if the aircraft reaches the pitch angle target, it takes time to recover its attitude, causing it to overshoot. As a result, the amplitude of the deviation is increased and diverges, not only because of the FF, but also because the gains of all the PIDs are not properly adjusted.
In any case, I think there is no doubt that the pitch controller not being properly tuned is the cause of the takeoff failure.
I hope you will perform a good tuning and achieve a perfect takeoff.Good luck.