I had very strange behaviour during auto take-off on Arduplane 4.1.6 running on a Matek F405Wing.
The airframe is a Sonicmodell binary.
The First start
The first start of the day was performed in (auto) TakeOff mode.
This start went completely as expected: shake to start, motors started, airplane gained speed, pitched up and levelled out at the set altitude of 50 Meters. Then I flew the some waypoints and performed some tests for approximately 40 Minutes before landing. The landing was a bit rough but no visible damage, I did a deflection and servo test which also seemed completely fine.
The second failed take-off
After uploading a new mission I performed a shake to start, the engines started, I threw the airplane and the plane flew away gaining speed. But the aircraft did not pitch up but continued to fly in a straight line no real pitch up or down but just straight until it finally hit some bushes about 50Meters away.
The Logs
Looking at the logs I checked for the most obvious data:
Comparing all these factors both take-offs look pretty much identical. So I cant really explain the lack of pitching up during the second start. Also the power to the motors was almost identical and the recorded gps speed (confirmed visually) was more then sufficient for the airplane to climb.
What am I missing, please help
Hopefully there is somebody here who can examine the logfiles as well and maybe point me in the right direction so I can take care of it so it wont happen again. At the moment Iam still not sure if it is a mistake or a bug.
What that tells me, is the FC was trying to do the same thing with the elevator each time, but on the second attempt it just didn’t get the result. Could be linkage to the elevator, or the servo itself. Or perhaps during the landing something shifted and the C of G changed.
A couple of things I noticed in the log that may or may not have contributed.
Battery voltage on the second attempt was low. 3.4 V/Cell. If you’re using a lipo battery that’s too low. This is something I often look at first but the plane was accelerating, it just wasn’t climbing.
On the graph I noticed a few very marked changes in your RC2 (elevator) input. This suggests that the radio trim was used. It is not advisable to use RC trim with ArduPlane. These adjustments were inside the RC2_DZ so I don’t think it changed much. I would also suggest you set SERVO_AUTO_TRIM,1.
When comparing both take offs, I noticed that during the first attempt the plane did not reach it’s target attitude. The take off was requesting 20 degrees, but the plane only reached about 10. Perhaps the C of G of the plane is too far forward? The trim value for the elevator was set to 1560, however for the duration of the first flight the elevator was sitting closer to 1400. This could be physical setup of the elevator, or C of G.
It is good to read that your analysis is very close to mine, I also compared the elevator deflection vs speed and that seemed to be fine and would in normal conditions cause the plane to pitch-up.
So my thought was as well: Broken servo or CG moved during landing (Battery).
Regarding your attention points:
Battery Voltage, It would indeed be quite low for LIPO but it is a 4S2P 21700, 9800mAh Ion pack.
Regarding RC elevator input, That is really strange, I have disabled the trims but somebody was holding the transmitter and trying to get the plane out of the automode to recover it, he must have nudged the stick I guess? or the hall sensor sticks are wandering which would be bad.
Thanks for the tip for enabling SERVO_AUTO_TRIM, I was still used to TRIM_AUTO but I just read that I can leave auto trim on now so I will do that.
Regarding the pitch only being 10 degrees, I am not sure if this is CG related but it can indeed be the issue. I will try to fly it manually after repairing it (again) to check how it is performing. The CG is at the marked spots as the manual tells but with allot of planes these days the manual is not right about the CG, looking at it I think it is indeed a bit far forward.
But then today, after repairing the Binary I tried the same thing again:
Autostart, throw, climb to altitude, fly some waypoints, perform autolanding.
This time the landing did go much smoother even with a slight crosswind seconds before touchdown AP managed to keep the plane level and safe on the ground.
Then some rain came in so I paused and unplugged the battery waiting for the rain to go away.
Then I wanted to try the second flight in exactly the same way as yesterday, another autolaunch and autolanding, and then directly followed by a third flight with auto take-off without replugging the battery. The only difference between today and yesterday was that the battery was still almost fully charged. And guess what! the same thing happened! the Binary just continued to fly straight gaining speed but it never pitched up just flew right into a tree (I was able to throw it in another direction with some more room this time because the wind turned a bit, but I still was not able to manually override in time so more glueing to do.
I have attached the logfiles and the comparison charts of desired pitch vs actual pitch and RCOUT4 below. and it looks exactly the same as the 2 flights before. Since the Autolanding was quite soft I did not check if the battery was misplaced (Yes very very stupid) so what could have happened is that the CG already was on the limit in the first place since the plane never reached it 20degrees take-off pitch, and the landing caused the battery to slightly move forward causing an even more nose heavy situation which then could not be compensated for by the FC/elevator.
For now I will repair the Binary and perform this same test one more time but now I will check the CG for the first flight and also before the second and reply here with the outcome. I really hope the CG was indeed the issue.
But just a quick thought, between the second and third flight (same battery, not unplugged or reset) did you reset the mission? Either by uploading a new mission, or pressing the Mission Planner “reset mission” button on the data page, or by using the RC switch (RC_OPTION, 24)
Hi Allister, the logfile is in the same googledrive location as the first one.
Sadly, I have another one since this morning and Iam really puzzled now. What did I do in the mean time:
Repaired the plane
Moved the CG a bit back (1/3 from the LE of the wing)
Ran trough all settings but did not find anything obviously wrong
Enabled Servo_auto_trim as you suggested
Checked all servo`s linkages and hinges
Did a clear mission from FC in QGC to make sure all old wpts where gone.
What happened this morning:
I wanted to make a quick testflight before work, and since auto take-off only suffered issues at the second take-off without replugging the battery so far I did not really expect any issues.
I started everything, made a take-off waypoint, several other waypoints and a landing sequence in QGC and uploaded it to the FC which seemed to be succesfull. Then I switched the plane to Take-off flightmode and confirmed that the elevator indeed moved up, I armed the plane did the shake to wake and threw it. And then the same thing happened again the plane just kept flying forward with no intention of climbing. It made a slight bank to the left which caused it to to drop its nose a bit and plummit into the bushes again at full throttle.
There must be something I am doing wrong or a wrong setting since it goes so well one time and completely fails another time. I have uploaded the log again into the same folder the name is 0005.BIN
And here is what I have found so far:
Looking at the logs I found something that I don`t really understand
If I look at the data on the line at 8min40, this is just after the shake to wake. You can see RC1 is set to 2000us Full throttle and RC4 (Elevator) was at 1200 (full UP) but goes back to almost neutral after throwing the plane.
If I compare the RC out vs Pitch and desired pitch I can relate why the plane wont climb, because 1400us means the elevator is only deflected a little bit up.
On the other hand ATT Roll is way of from Desired ROLL but there is no obvious correction from Arduplane to level the airplane.
The plane again suffered some damage but I will again repair it because I want to find out what is going wrong before moving to another new airframe.
As the CoG is also related to the angle of attack difference between your main wing and the elevator, I can only recommend to test it in flight. Take off in manual flight mode to a height where you are comfortable to take the nose down for a few second by pitching down. Now release the pitch and see how the plane reacts. If it pitches up steep, it is nose heavy, if it remains nose down over even increases the dive,it is tail heavy. If the CoG is correct, the plane should pitch up in a shallow curve.
I hope this information will help you to improve the flight performance of your plane.
Hi Maarten, I’ve heard of this process before and I always need to think it through as it seems counter intuitive. This is probably obvious, but I think relevant to the OP, so please correct me if I’m wrong: for this test to be effect the pitch trim must be perfect before you try it. So before you pitch down the plane must be flying level without pilot input.
Hi Allister,
yes it is counter intuitive but if your plane is nose heavy it needs a higher level of pitch up in order to fly level without further pilot input. This pitch level would pull the plane up steep as you gain speed during the dive which makes your elevator more responsive.
@Lano Yes it is, it easily does even more then 20 degrees in manual mode, throttle in takeoff should not be limited to 70% because TKOFF_THR_MAX is set to 100%. Also the plane accelerates way over 20m/s but still does not pitch up a degree since the elevator not deflected upwards. And in the logs when I look at RC_OUT 1 and 2 you can see that indeed 100% throttle is applied to the ESC`s.
@Turf1975 Thanks for you reply! The CG is allright, I already tested it in flight allot of times. I do have quite some experience in designing and building my own airplanes and wings as well so Iam pretty sure this is not the cause of the issue.
The plane is quite an easy flier with the current wing loading and is also very mild at low speed, no sudden stall behaviour.
And indeed that sounds counter intuitive but it is the right way to check it.
You do need to make sure the plane is trimmed for level flight before you dive though.
You wont see the roll correction in the desired roll. The desired roll angle is still 0. What you need to look at is the output to the ailerons. I can see the controller trying to correct, so it is reacting. This correction for roll will be limited by TKOFF_LVL_ALT, 30. It won’t command significant roll inputs until after 30m. You could lower that value as the intent is to keep the plane from rolling too close to the ground. More important on rolling takeoffs.
Can you do a flight in FBWA, including the take off? Or if your comfortable in manual and perform the test that @Turf1975 has suggested? I’d like to have some kind of base line log to compare and FBWA from start to finish.
I just noticed there’s a noticeable Y vibration. This could be a few things, especially since it’s a twin. Probably won’t change much, but have a look at your props and make sure none of the blades are bent or out of track. Also, after all this abuse, check your motor mounts to make sure they are secure. The vibration is more likely a result of the issues, rather than the cause.
The plane is accelerating just fine, and it is commanding a pitch up. It should be climbing. It wont’ go to full deflection during take off because the FC doesn’t want to stall the plane.
I’m sure you’ve checked this but on that off chance, have you checked that the elevator servo doesn’t have a stripped or damaged gear? Do you know if they are plastic or metal servos?
I checked the servo for movement and also tried to “load” it a little to be sure it doesn`t fail when it needs to push the elevator when it is in the airflow. This seems to be all fine.
I did discover another strange thing right now. Connecting to the FC Iam not able to see the mission I uploaded this morning. I tried to upload a new mission but it won`t not accept the new mission as well?!?
So finally after being floored for some time due to covid I had some time to repair and test again last weekend.
And again with succes (crash)… What I did was:
Started everything and made sure I had a connection with the plane over 4G.
Checked control deflections both on sticks and also on stabilize to make sure everything was moving in the right direction.
Checked horizon on QGCS if the level was correct which looked fine.
Armed the plane in Assisted flight mode and took off
The plane was now flying and reacting to control inputs as expected, I climbed out to approximately 70-80 Meter altitude and then switched into “Cruise” flightmode since everything seemed to be working fine. But from the moment of switching into cruise the plane made a sudden left roll (did not look like stall) and it just dived straight into the ground without any moment of pitching up whatsoever.
Unfortunately I gave the remote to a friend of mine who tried to recover but he was not fast enough to switch back to manual mode and recover the airplane.
so more glueing to do.
