Kakute F7 6 inch - Flip & Crash - Need help with logs

ArduCopter Copter 3.6
1

Hi all,

I just migrated a 6 inch Kakute F7 quad from Inav to ardurpilot. The frame was flyable using Inav and I didn’t change any components (Kakute F7, Tekko 4 in 1, 2205 motors).

I believe I made all configurations right, although I’m not experienced at all with ardupilot (Actually this is my first time :slight_smile: ).

During first testing flights , quad flipped and crashed after 1 minute of flight ( First crash testing poshold mode, second using stabilize). Till then the only problem I had was that quad needed a little trimming and I had to lower PIDs a lot due to vibrations.

I suspect Motors / RC callibration (currently using Dshot) , but I don’t have the experience to understand the log files.

Can you please have a look and tell me your opinion?
I also post my param file if it helps.

Thank you all in advance.

18052019.param (15.5 KB)
2019-05-18 12-09-37.bin (695.1 KB)

2

I’ve successfully used the Kakute F7 stack on several builds. I’m curious why the log only shows telemetry for ESC 1 and 2, given that you’re using the 4-in-1 ESCs.

The battery voltage reported by ESC2 drops to zero around the time things went bad.

35%20AM
Screen Shot 2019-05-18 at 7.57.35 AM.png2522×774 13.4 KB

1 Like
3

@Anthony_Short Thanks for your time. I also noticed this . Also have no answer. Maybe Dshot related problem (communication between FC <-> ESC)?
If it was a power failure, I suppose logs would have shown it .

The same happens in the next flight log (again flip & crash after 1 minute flight). ESC1 & ESC2 show voltage drop to zero.

2019-05-18 12-19-31.bin (556.7 KB)

In your builds using Kakute F7 have you managed ever to get current from BLHeli telemetry? I’m taking back voltage metrics but never managed to get back current (I use Tekko32 4 in 1) . If yes, do you mind to share a working params file to compare with mine?

Thank you for your help.

4

Yes, I get voltage and current from all four ESCs.

param file

5

i had 2 issues with kakute f7, well, realistically only 1 was a serious enough issue - it was related to random loss of dshot data packets that looked like a loss of the power on one of the motors, so, drone would be fine in the air for a while, and at random spot it would either flip around or crash or just jerk as if it lost one of motors temporarily. it was correlated in the logs with the loss of telemetry data from that esc.

the fix was to set a NODMA clause in the build file on the UARTs. it was not confirmed, it is not the fact, and is not in the official master build, but i used this workaround in all my files and did not have any issues since that.
if you have same issue or not - i cannot say.

also, if drone flips immediately after startup - then most likely the PWMs are not mapped correctly to motors. the file i had done wa done for F7 AIO kakute, a regular F7 hs slightly different mapping usually, of what pwm goes to what motor.
it does not let me to attach that hwdef file - here it is, with the NODMA fix.

hw definition file for processing by chibios_pins.py

for Holybro KakuteF7 hardware.

@ thanks to betaflight for pin information

MCU class and specific type

MCU STM32F7xx STM32F745xx

board ID for firmware load

APJ_BOARD_ID 123

crystal frequency, setup to use external oscillator

OSCILLATOR_HZ 8000000

define STM32_LSECLK 32768U
define STM32_LSEDRV (3U << 3U)

define STM32_PLLSRC STM32_PLLSRC_HSE
define STM32_PLLM_VALUE 8
define STM32_PLLN_VALUE 432
define STM32_PLLP_VALUE 2
define STM32_PLLQ_VALUE 9

FLASH_SIZE_KB 1024

leave 2 sectors free

FLASH_RESERVE_START_KB 96

board voltage

STM32_VDD 330U

only one I2C bus

I2C_ORDER I2C1

order of UARTs (and USB), USART3 should be in second place to map order with the board’s silk screen

UART_ORDER OTG1 USART3 USART1 USART2 UART4 UART7 USART6

buzzer

PD15 TIM4_CH4 TIM4 GPIO(77) ALARM

PA10 IO-debug-console

PA11 OTG_FS_DM OTG1
PA12 OTG_FS_DP OTG1

PA13 JTMS-SWDIO SWD
PA14 JTCK-SWCLK SWD

SPI1 for SDCard

PA4 SDCARD_CS CS
PA5 SPI1_SCK SPI1
PA6 SPI1_MISO SPI1
PA7 SPI1_MOSI SPI1

SPI2 for MAX7456 OSD

PB12 MAX7456_CS CS
PB13 SPI2_SCK SPI2
PB14 SPI2_MISO SPI2
PB15 SPI2_MOSI SPI2

SPI4 for ICM20689

PE4 ICM20689_CS CS
PE2 SPI4_SCK SPI4
PE5 SPI4_MISO SPI4
PE6 SPI4_MOSI SPI4

I2C1 for baro

PB6 I2C1_SCL I2C1
PB7 I2C1_SDA I2C1

PC3 BATT_VOLTAGE_SENS ADC1 SCALE(1)
PC2 BATT_CURRENT_SENS ADC1 SCALE(1)

define default battery setup

define HAL_BATT_VOLT_PIN 13
define HAL_BATT_CURR_PIN 12
define HAL_BATT_VOLT_SCALE 10.1
define HAL_BATT_CURR_SCALE 17.0

PC5 RSSI_ADC ADC1

PA2 LED0 OUTPUT LOW

USART1

PA10 USART1_RX USART1 NODMA
PA9 USART1_TX USART1 NODMA

USART2

PD5 USART2_TX USART2 NODMA
PD6 USART2_RX USART2 NODMA

USART3 (GPS)

PB11 USART3_RX USART3 NODMA
PB10 USART3_TX USART3 NODMA

UART4 (GPS2)

PA0 UART4_TX UART4 NODMA
PA1 UART4_RX UART4 NODMA

USART6, RX only for RCIN

PC7 TIM8_CH2 TIM8 RCININT FLOAT LOW
PC6 USART6_TX USART6 NODMA LOW

UART7 USED BY ESC FROM ORIGINAL DESIGN

PE7 UART7_RX UART7 NODMA
PE8 UART7_TX UART7 NODMA

Motors

PB1 TIM1_CH3N TIM1 PWM(1) GPIO(50)
PE9 TIM1_CH1 TIM1 PWM(2) GPIO(51)
PE11 TIM1_CH2 TIM1 PWM(3) GPIO(52)
PB0 TIM3_CH3 TIM3 PWM(4) GPIO(53)
PC9 TIM3_CH4 TIM3 PWM(5) GPIO(54)
PA3 TIM5_CH4 TIM5 PWM(6) GPIO(55)

PD12 TIM4_CH1 TIM4 PWM(7) GPIO(56) NODMA
#PD12 is repurposed for 7th PWM, originally intended as a LED strip pin

DMA_PRIORITY S*

define HAL_STORAGE_SIZE 16384
define STORAGE_FLASH_PAGE 1

spi devices

SPIDEV mpu6000 SPI4 DEVID1 ICM20689_CS MODE3 1MHZ 4MHZ
SPIDEV sdcard SPI1 DEVID1 SDCARD_CS MODE0 400KHZ 25MHZ
SPIDEV osd SPI2 DEVID4 MAX7456_CS MODE0 10MHZ 10MHZ

define HAL_BARO_DEFAULT HAL_BARO_BMP280_I2C
define HAL_BARO_BMP280_BUS 0
define HAL_BARO_BMP280_I2C_ADDR 0x76

no built-in compass, but probe the i2c bus for all possible

external compass types

define ALLOW_ARM_NO_COMPASS
define HAL_COMPASS_DEFAULT HAL_COMPASS_NONE
define HAL_PROBE_EXTERNAL_I2C_COMPASSES
define HAL_I2C_INTERNAL_MASK 0
define HAL_COMPASS_AUTO_ROT_DEFAULT 2

probe for an invensense IMU

define HAL_INS_DEFAULT HAL_INS_MPU60XX_SPI
define HAL_INS_DEFAULT_ROTATION ROTATION_YAW_180

define HAL_OS_FATFS_IO 1
define HAL_BOARD_LOG_DIRECTORY “/APM/LOGS”
define HAL_BOARD_TERRAIN_DIRECTORY “/APM/TERRAIN”

setup for OSD

define OSD_ENABLED ENABLED
define HAL_OSD_TYPE_DEFAULT 1
ROMFS_WILDCARD libraries/AP_OSD/fonts/font*.bin

define BOARD_PWM_COUNT_DEFAULT 7
define STM32_PWM_USE_ADVANCED TRUE

1 Like
6

@Anthony_Short @Paul_Atkin

Thank you both for your help.

Let me share some “findings” as a reference for others may have similar problems

  • I managed to get ESC telemetry for all 4 ESCs after upgrading tekko32 firmware to latest (32.6)
  • I reverted to oneshot and had an excellent 3 minute test flight (stabilize only)

I will setup my development environment and try to compile using NODMA option in UARTs and then I will test again using Dshot, although I don’t have the knowledge to understand why UART DMA access may cause dshot packet loss.

7

hi, i am also not sure what was the issue behind NODMA effect on dshot, but, i definitely saw it on 2 my different models. we could not replicate it on a bench test, as it is very random and happens sporadically. on one model it was more pronounced, on other it would almost never happen, but i would see it as a random odd ‘twitch’ during a middle of the autotune process, for an example.

it may be something related to a defect on my kakutes, as they all were from the same batch. not sure. if it works with oneshot - it should also work with a dshot, obviously.

also, on the model with issues i had all uarts/usarts utilized - so it had a lot of serial protocol load. it could also been a factor.

8

Hi @Paul_Atkin,

I also have most of Uarts utilized.
I compiled the code and tried a 15 minute flight without any problem (2x4s batteries). Actually it worked great (Stabilize & pos hold).

Before come in conclusion (I’ll make more test flights in weekend), do you believe that dshot/esc failure may be related to cable interference?
Dshot is first time used to this quad ( Inav was also configured to use oneshot), so I cannot compare .

By the way what is the proper way to make a pull request (or raise a bug / change request) to developers? I suppose I have to replicate this thread to github?

Thank you all for your help.

9

it can absolutely be interference, it was what devs told me right away, but, i had the issue on a relatively small model, where dshot signal wire was barely 5cm long. i first re-soldered it all using coax shielded wires, and still had that issue with twitches that was attributed to a loss of dshot data packets. after using NODMA clause on uarts it all healed.

what was it and why i had it - no idea. devs cannot replicate it. if it was a defect of my FCs only - who knows. i only give this info as one of possible reasons, so, if you have the same issue you can try it, but, it is not a guarantee that your issue was the same.

this NODMA scenario was discussed with @tridge - but, as we could not replicate it nor prove it, it was left as is.

10

hi, just getting back to this NODMA topic - i recompiled code yesterday from the recent master, and tried to use my model without NODMA clauses on UARTs - and got same issues - one unexpected flip and what seemed like issues with GPS not properly communicating. i have no idea if it is an issue with all the kakute chips i got, or something in my builds specifically, buy when i recompiled code again setting NODMA again on all UARTs and USARTs - it all got back to normal. FYI.

11

Hi Paul,

Since I compiled with nodma as you suggested (Thank you !!! :slight_smile: ) I haven’t experienced any problem at all ( over 20 flights). I cannot blame Ardupilot or developers . Unexpected flips I had, may be specific related to my build (many uarts utilized, interference or something else …)
I’m preparing a new build (Kakute F7 AIO) . I will try to user master release without nodma and let you know about the results

12

yep, makes sense. just be careful while testing. what i had looked like if suddenly one of motors was off power, so drone would try to compensate and either twist or drop one corner, or dart to the side and then recover, or, in a worst case, flip completely. it was also notable with error messages about lidar health - it was on serial, or gps health. all in all, it was the only difference i was able to notice, but, what is behind it - no clue.

13

Hi ALL!
Could it be the same problem?
Kakute F7 AIO


https://drive.google.com/open?id=1pdWrYL4d65U6M9wXvD9QKFc2H47eI_Ty - log

P.S. I know that this quad is a way overpowered, i already decided to switch to 3s battery…

14

I am having this exact same issue with Kakute F7 and Tekko32 - recently purchased, built big quad (17" props). Totally confusing me because I’ve tried everything, but the behavior sounds exactly identical. It flies perfectly for a bit - 2-3 minutes, then randomly it drops one corner of the quad like a super short desync or loss of signal. The quad rallies and recovers - but then I see more and more behavior like this. If I just fly it around, it doesn’t happen as much, but definitely during hover - and at times while turning, the front left motor drops.

I see very little in the .bin logs that would indicate this failure, I am seeing that setting bit 8 and bit 9 turns on NODMA, but I’m not sure what “number” this would be for the SERIALX_OPTIONS? Any help here?

15

I just propose https://github.com/ArduPilot/ardupilot/pull/14995 to fix this problem. Would you be able to help testing it? Thank you very much