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?
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.
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.
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
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
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.
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.
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…
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
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