Sudden tilt after takeoff in GUIDED

Hello,
I was experiencing some problems with takeoff after a recent upgrade to 4.3.2, I don’t know if the problem was because of me not knowing how to properly set the parameters since the code for takeoff was changed in 4.3 or some bug.

So I decided to change back to a prior version that flew sucessfully, 4.2.2. Everything was exactly the same, parameters, firmware, hardware, position of devices, but the same effect happened again, as soon the command of takeoff is received while in guided mode, the motors abruptly start and tilts to the side, causing a crash.

I am studying the log, but can’t find a specific reason, I am leaning towards a possible problem with the accelerometer. Can someone please help me identify the cause with the log below?

https://drive.google.com/file/d/1_gqAUOqHkCft2wpn2S_FKwEbPA7bnscM/view?usp=share_link

These seem unusual
MOT_SPIN_ARM 0.15
MOT_SPIN_MIN 0.18
And this is most likely wrong
MOT_THST_EXPO 0

A flip over is usually because the motor order is wrong. Spin direction is critical too.

There’s no evidence of tuning, does this fly with RC control?
Progress to GUIDED and other advanced functions only after the copter is verified working perfectly with RC control.

Why do these seem unusual? It flew with with these exacts parameters before multiple times.

If by that you mean there is a controller sending the inputs via sbus protocol over radio, then yes.

Those MOT_SPIN values are just a bit higher than usual, but fine if they work.
I think MOT_THST_EXPO should not be zero - you should set this correctly based on the prop size, then retest the MOT_SPIN values using MissionPlanner motor test.

Do you mean it flies OK with RC control? It is possible for some copters to fly OK without any tuning, but it’s unusual because of near-infinite variations between builds.

I did check the RC inputs and they are not perfectly centered but I think they are near their trim values and within the deadzones, so RC inputs shouldnt be interfering.

The other thing that would make it tip over is if it’s trying to fly to a position laterally before the copter has had a chance to clear contact with the ground.
It appears to have Desired Velocity in PSCE and PSCN so that could be a problem.

Hm, that’s weird, because after arming and going straight to guided, it should only do a takeoff to 1 meter above home, then change mode. Since guided doesn’t allow user input and there isn’t other command, it shouldn’t try to do anything else.

Could you please explain this?

The position controller East and North - if there’s desired velocities and accelerations then the copter is being instructed to move.
There are target positions too, but I’m no Guided mode expert, so I’m not positive about whether this is the cause or an effect.

After trying a takeoff (or something) in Guided, you switch to Circle mode…

Is it possible the vehicle would be instructed to move if the board position and orientation were different than the vehicle is expecting, to correct itself?Like, it is expecting at the center of gravity, but is displaced by an offset in one of the axis by a distance and an angle?Because, it is possible that this happened

Do you mean if the flight controller has been moved since initial configuration and calibration?
Then definitely YES that would be a cause.

If it was calibrated in the current position, and it flies OK under RC Control, then it should be fine.

I would suggest starting over with the Initial Setup parameters and advance along the normal tuning process path.

I mean, even with calibration, if the vehicle thinks the flight controller is in the center of gravity, but it’s not, and the parameters that are meant to inform these offsets were not set, if that would explain

The FC does not have to be in the center of gravity.

what about the orientation of the board?

That doesn’t matter either. Of course you need to set the board orientation accordingly.

Hello,
About your replies regarding some values, in the past I successfully flew with these parameters, that’s why I think these “unusual” parameters are not to blame.

I was interested about the position and orientation of the board because I had changed the board location from the center to 4 cm towards the front of the copter and orientation, that is now 90º degrees clockwise or YAW90. I went and checked that I had not changed the orientation because I thought it would caught that during the accelerometer calibration.Having caught this, I changed the parameter.

I tried flying again, but the same thing happened, I change to guided, send MAV_CMD_NAV_TAKEOFF with a low altitude, like 1 meters, some motors have higher output than the others, and the copter tilts itself.

It seems it is always the same side, towards the front of the vehicle, that receives more throttle during the takeoff. It is strange because other than the position and orientation of the board, the only thing that has changed is that I am now using a better version of cube.

here is the log of the new flight:
https://drive.google.com/file/d/1T2LQuqkz2761OnwuDFBhjo9TPm5fD2D_/view?usp=share_link

I see you’ve got AHRS_ORIENTATION,2 which may not be enough by itself.
First try the Calibrate Level after accurately leveling the whole frame.
Or you could try the Accel calibration again, based on the “front” direction being that of the copter instead of the arrow printed on the flight controller.

Hello,
Before the last test I did those steps.

  • Upgrade firmware to latest stable, 4.3.3 at this point in time.
  • Go outside, wait for a GPS 3D fix and do the compass calibration
  • Do the RC calibration, it’s very noisy and may need some extra attention (connections??)
  • Set up the voltage and current monitoring, at least voltage
  • Do the Initial Parameters and accept everything it offers plus the “Suggested” settings
  • Use the Motor Test to check the order of motors - A will be motor 5, B will be motor 1, C will be Motor 4 and so on…
    image
  • Set these
    BRD_SAFETYENABLE,0 (stop using the “safety” switch)
    INS_ACCEL_FILTER,10
    INS_HNTCH_ENABLE,1
    INS_LOG_BAT_MASK,1
    INS_LOG_BAT_OPT,4

Now go outside, wait for GPS 3D fix (you have Fence enabled so that’s great) and use RC control to test in Stabilise to get off the ground, and if that’s OK use AltHold and Loiter

Describe what happens and send the next log.

Before I made these steps, about the main outs, are they matched with the servon_function? By that I mean if SERVO1_FUNCTION controls main out 1?

Yes, SERVO1 in parameters is labelled Main Out 1 on the flight controller and in MP Motor Test it would be “B”
Normally SERVO1_FUNCTION = 33 (for Motor1)

MissionPlanner motor test order starts at Front/Right with A (regardless of what motor number that is) and goes around the arms clockwise to B, C and so on