I was excited to try out Ardupilot for the first time! Sadly it didn’t end great. I did a write up @ Ardupilot Postmortem - Scott O'Brien with my log file attached and have some questions:
the altitude is all over the place. Is this bad hardware?
when fbwa mode was selected. Why do you suppose it did a sudden nose dive?
ultimately, this looks like a servo failure to me. Does it look the same to you?
I’d love when you’re looking, if you could share any interesting screens or techniques you’re using. I’d love to use this more as a learning exercise too!
In two moments of the flight (12:26 and 12:52) your current consumption (BAT.Curr) goes to practically zero, this is a consequence of the fact that you took the throttle to the minimum (RCIN.C3).
On the first occasion except for a significant loss of altitude (GPS.Alt) there was no major problem, but on the second occasion there is a loss of lift. This loss of lift causes the crash.
As you don’t have airspeed data I can’t tell you more. What is clear is the divergence between the desired pitch (ATT.DesPitch) and the executed pitch (ATT.Pitch); that is the evidence of the loss of lift.
I haven’t looked closely at your log but here’s some general comments from your statements
Double check the C of G. If you are new to controllers make sure you aren’t using any of the radio trims. Set SERVO_AUTO_TRIM,1 and once you fly in FBWA that will automatically adjust the servo trims for you.
99% of the time this is because the stabilization correction was backwards. Even though the manual mode worked, the correction was going in the wrong direction. To test this, check the control movements in FBWA first. Correct any controls going the wrong way by reversing the servo on the servo output tab in MP. Second, test control movements in manual mode. Correct any incorrect movements by reversing the RC channel on the RC input tab in MP. No corrections need to be made in the radio.
After the first dive (with ATT.Pitch=-89.65) is it possible that the battery has moved forward?
The PIDP.I in stationary flight is a good indicator of the correct position of the center of gravity. It can be seen how there is a different PIDP.I behavior after the first dive.
Hard to be sure, but I very highly doubt anything shifted after that first dive. Things are pretty heavily in place.
The most scary thing for me is why when this enters a FBWA, the AETR.Elev would go “Up” when the pitch is going “down”. Shouldn’t it also be going down to lift the nose?
In manual mode there is correlation between the servo command (RCOU.C2) and the pitch of the plane. Make sense. When you switched to FBWA, the servo starts driving the nose down, (increasing PWM value as the pitch goes down) and it becomes worse as the plane pitch goes down. This because the stabilization correction is backwards. I don’t doubt that your RC wasn’t reversed, in fact I know it wasn’t. But that doesn’t mean it was correct. when you switched back to manual mode the PWM value goes low as you pulled the nose back up.
The setup must be done by checking FBWA movements first. Don’t pay any attention to what the RC commands are doing, as long as the correct stick is moving the correct control, don’t pay any attention to the direction until you have the FBWA movements correct first. In FBWA, when you lift the nose up the elevator should go down. When you move the nose down, the elevator should move up. Reverse the servo (example: SERVO3_REVERSED,1) as needed.
Once that’s sorted, then test the RC link.
Obviously you know how the RC controls should move, so if one of them is backwards after setting the FBWA controls now you reverse the RC input by either using the check box in MP or by setting RC2_REVERSED,1.
In the case of your plane I would expect that you would have to reverse both the elevator servo (SERVO2_REVERSED,1) and the RC link (RC2_REVERSED,1). On the surface it sounds counter intuitive to have to reverse two function on the same system, but if you chew on it long enough it will make sense.
Lol! Thanks, Allister! I am definitely struggling to get my head around this part! I wish I had read this wiki page before flying. I’m still struggling to understand why you’d ever need to set the RCn_REVERSED though to anything other than the default (unless I reversed it on the controller, doesn’t pulling down on the right stick in mode 2 always translate to an intent in the elevator going down?) so why the need of having to set anything here but defaults here does my head in.
It sounds like I definitely had two problems here. (bad default RCn_REVERSED with a non-default SERVOn_REVERSED that still blows my mind), and some form of mechanical failure that caused the plane not to be able to pitch up leading to the crash towards the end of the flight (and switching to RTL last minute decided to pitch the nose directly into the ground with a bad SERVOn_REVERSED).
Also to the altitude being terribly incorrect, this would mean it’d be impossible for the RTL mode to figure out the correct altitude to be circling at? Is this a sign of a bad barometer?
It depends on what direction you installed the physical servo, and what side of the control surface the servo horn is mounted to. Consider this: many simple RC airplanes will have one aileron output on the receiver, however it is driving two servos through a y-connection. One aileron goes up and the other goes down simple because the servos are physically reversed relative to one another. There’s no standard to what is “right”. So the fact that ArduPlane let’s you change the direction of both the servo and the RC input is just a simple way to account for all the variables of layout and design. Rather than thinking of it as “reverse”, just consider it the alternative.
Check that your FC and barometer are properly vented. I’ve run into this before when I got over zealous with conformal coating and accidentally covered the sense-port on a barometer. You can see in the graph your barometer is moving directly with temperature.
Makes sense. Pretty sure this is the Baro on this board. Also pretty sure there’s some hot glue and Velcro over this component on my build. That would explain that!
I thought all of that was on the top of the board. Should have looked closer
This may have already been said, but I can tell you why mine suddenly pitched down and crashed when switched to FBWA. While the controls responded correctly to my transmitter, the elevator was backwards when controlled by the Pixhawk (orange).
I didn’t check elevator controls when switched to FBWA on the ground and this was my mistake and I paid for it with the loss of an aircraft.
I ended up having to change the direction of the elevator in my transmitter and then inverse the elevator direction in Ardupilot. That fixed it and the new bird flies like a dream.
The tuning guides specifically caution you to check stabilization control directions. If you do not, you will have these problems. We see similar misunderstandings in the Rover branch.
It is CRUCIAL that the autopilot be correctly configured for assisted modes rather than just forcing manual modes to work by reversing channels or servos and then assuming all is well.
