I test the range of the VTX and fly in Loiter mode. I then choose to fly back in RTL and switch back to Loiter before landing. When switching flight mode, the machine loses stability and I switch over to Stabilize. Machine tumbles around at a height of 20 meters and crashes in the field.
I can see from the flight log a violent oscillation of the RCOUT. The same instability has happened once before during a strong descent, but then at a height of a few meters without major damage.
//YB
When you switched to Stabilise mode throttle was up at about 1650PWM causing a sudden ramp-up of motor outputs and equally sudden voltage drop. The current spiked from 12 or 13 amps to up around 30amps and 25amps. That current spike could be expected and is not indicating a fault, but does indicate the level of demand.
Previous Loiter behaviour in the log is good and there’s no signs of instability. I believe is no reason to suspect that switching from RTL to Stabilise to Loiter would be a cause
My guess is the ESCs didnt like that voltage drop - since you are using a 6S LiIon pack and usually ESCs voltage cutoffs are expecting LiPo voltages. The ESCs could have easily decided your reasonably acceptable Liion voltage was unacceptable (as if it was a LiPo pack) and started cutting output.
Ensure your ESCs have their voltage cutout feature turned off or minimised.
Happy to be corrected if I’m wrong - that’s a possibility.
Hi Shawn and thanks for yor patience
I have some questions
Ensure your ESCs have their voltage cutout feature turned off
Do you mean that the BATT_FS_LOW_ACT should be 0 ?
I saw on googles that when I switch the flight mode to Loiter the machine starts wobble in the air. Can you imagine that the PID.s are too high?
Could it be that Throttle was at max when I switched flight mode? I see CTUN.ThO going straight up ?.
I can also imagine that I need a LI-ion battery that can deliver more current, 6S5 or 6S6?
Regards from a rainy Sweden//YB
I think he means the esc’s own parameters not the Batt failsafe parameter you mentioned which is a flight controller parameter to drive an RTL etc?
I could be way off here, I’m just suggesting
Yeah - the ESCs themselves usually have a low battery level setting where they shut down (entirely) or reduce output, interfering with flight. There is usually a way to disable this feature, or set the voltage level to as low as possible, like 3.0 volts per cell.
This may still be unsuitable for use with LiIon cells, since they can go lower than 3.0v per cell, and they ESC just tries to make some guess at the number of cells based on the voltage when first powered up.
I looked around at your posts and could not see where you mentioned exactly what ESCs you have, but I might have missed it.
What ESCs are they?
ok, so they are BLHELI_S and there’s no voltage settings available.
Here’s a fairly comprehensive guide to everything BLHELI_S
which amounts to “use passthrough to connect to the ESCs” (like we do with BLHELI32) and install the Bluejay firmware.
BLHELI_S ESCs are a compromise to use smaller cheaper ESC with a little 16bit processor.
Something a bit more robust in BLHELI32 might be a good choice since you are using Liion cells. You will be able to disable the low voltage cutoff with BLHELI32 and better use DHSOT and data from the ESC.
I use these BLHELI32 settings in the ESCs, which is very standard for arducopter:
Hi Shawn
These ESCs have been in service since 2019 and I intend to replace them with something else just to be safe. Could you recommend an alternative?
I allso find that my ESC.s are a bit to small, the motors are Gart ML5008
//YB
I’ve personally used the Holybro Tekko32 45A 4in1 and the Tekko32 65A Metal 4in1. There are a couple of 50A models now too.
Any of those will do your job.
I know others have been successfully using the T-Motor F55A Pro (or similar) and Aikon AK32 55A - there will be plenty more too that I cant rememeber.
The important things to check are BLHELI_32 and a connector with the “Telem” wire.
They will all have a “Vbat” wire too - ensure you DO NOT connect that to anything unless you have a device or flight controller that specifically accepts raw battery voltage.
Thanks Shawn.
Now waiting for the Tekko
//YB
I will replace the frame to 650 INNLOI and BLHELI_S to TEKKO32 4 to 1. I have set up an Arduino Nano to access settings on BLHELI_S with Blhelisuite so it should also work with BLHELI32 ?
Can I use previous parameters or set everything up again?.
Regards //YB
So the motors and props and battery are the same?
You should be able to leave the flight controller with all the same parameters and we adjust a few things.
Post a .param file, or even better → set LOG_DISARMED = 1 and reboot , this will generate a .bin log file.
Set LOG_DISARMED = 0 after a while , send the .bin log file.
From the battery connector the cables should go straight to the 4in1 power inputs (or could be via the existing voltage/current sensor) so the ESCs have full voltage and current available with not extra connectors.
From the ESC signal connector you should have M1,2,3,4, Ground wires going to “FMU PWM OUT” pins 2 to 5 and a ground pin 10 on the Pixhawk 6C.
The Telem wire should go to a spare RX pin in Telem2 or Telem3, whichever serial port is spare and suits your wiring.
It’s handy to have an arduino to do BLHELI work for multiple copters - this copter should be fine with passthrough too.
When you get it ready for tests, send a screenshot of your BLHELI settings (from in BLHELI Suite)
Here comes the Log_disarmed file
Thanks for your help //YB
This will be a wall of text, so just work through it slowly and methodically, especially the motor test stuff after all the easy changes.
1. Ensure your BLHELI settings in all the ESCs are good and ready
2. Wiring changes and adjust params
Physically make the wiring changes like I mentioned before, changing to use the FMU outputs, and let me know if you have any doubts.
Then copy/paste these into a notepad text file and save as “enable_DSHOT.param”
Adjust the serial port number to suit your wiring, I’ve assumed serial port 4 as an example.
INS_HNTCH_MODE,3
INS_HNTCH_FREQ,40
INS_HNTCH_BW,20
INS_HNTCH_REF,1
INS_HNTCH_FM_RAT,1
INS_HNTCH_OPTS,2
MOT_PWM_TYPE,6
SERIAL4_BAUD,115
SERIAL4_PROTOCOL,16
SERVO_BLH_AUTO,1
SERVO_DSHOT_ESC,1
SERVO1_FUNCTION,0
SERVO2_FUNCTION,0
SERVO3_FUNCTION,0
SERVO4_FUNCTION,0
SERVO9_FUNCTION,33
SERVO10_FUNCTION,34
SERVO11_FUNCTION,35
SERVO12_FUNCTION,36
Now use the full parameter list to “load from file” and write all those adjusted params.
You will have to reboot the flight controller, then “Compare Params” or just load it again to see if all of them are set correctly.
3. Get the motor order correct
Use MissionPlanner motor test to verify the motor order - some will be wrong!
You can use the Setup / Mandatory / Servo Output screen to move the motor functions around.
You have to always reboot the flight controller after every time you change any of those servo functions for them to take effect.
Motor test diagram below
4. Get the motors spinning in the correct directions
You can use this parameter to reverse the spin of a particular motor
SERVO_BLH_RVMASK
It’s a bitmask with easy selection, you will be interested in Channel9 onwards.
NO soldering or even connecting to BLHELI Suite! 
5. Check and set MOT_SPIN
While you are in the Motor Test section recheck and set MOT_SPIN_ARM and MOT_SPIN_MIN - they might be different with the new ESCs.
MOT_SPIN_ARM can be very low provided the startup is reliable - it’s useful to have a really low ARM speed so you can easily see if all the props are spinning in the correct direction every time you arm - and it looks very cool.
MOT_SPIN_MIN might still be up around 0.12
6. Testing
To see if everything is working as expected, in messages you should have something like:
RCOut: PWM:1-8 DS600:9-12 PWM:13-16
and in the Status tab there should be a whole lot of
esc1_curr
esc1_rpm
esc1_temp
esc1_volt
esc2_ // and so on
They should show actual data when you operate each motor with the motor test.
You can set a motor to run for a few seconds, then quickly swap over to the Data / Status tab and see the actual esc data.
More time spent in MissionPlanner motor test is less time spent picking up a flipped-over copter
Hi Shawn.
Now the TEKKO32 is connected and the settings are done, the motor test is done and motor directions have been set with SERVO_BLH_RVMASK, very convient. Now waiting for better weather to come, rain, rain and more rain…
regards YB
Cool - good to hear from you YB
Hi Shawn
No rain today so I could do some test flights. With the previous PIDs, the machine started to vibrate and I reduced them by about 15%. There is still some nervousness in regulation so I probably need to lower the PIDs a bit. I think the notch filter is working correctly. What do you think about the result?.
Regards//YB
[image]
Sorry - tlog instead of .bin log
Hard to get much from that.
Sorry Shawn, here comes the bin.log
//YB
There is a physical yaw bias - counter-clockwise motors are working harder than clockwise motors. So most likely a motor mount or two is slightly twisted. It’s quite easy to align them when props are on by rotating the props so they are tip-to-tip and you will see which ones line up.
Vibrations are low enough, but X axis vibrations are higher than Y axis, which might be related to prop balance, but more likely some wiring touching or pulling on the flight controller. Z axis is OK.
Send a photo of the flight controller and wiring if you are not sure.
Let’s just make a couple of tweaks to the filter:
INS_HNTCH_BW,10
INS_HNTCH_HMNCS,3
this will help to ensure the filter is not over-active and interfering, leading to lag.
Adjust these for better altitude control and a bit extra logging.
LOG_BITMASK,180222
PSC_ACCZ_I,0.44
PSC_ACCZ_P,0.22
Let’s see a new set of flight data before we start changing more things.