Compatibility of flight controllers (Mateksys F405-CTR)

adrianradian · June 6, 2020, 3:21pm

Hello,

I am trying to get rosflight to work on my flight controller, Mateksys F405-CTR. I am using Ubuntu 18.04 and downloaded the latest version of rosflight today (06/06/2020). When I try to run :

rosrun rosflight rosflight_io _port:=/dev/ttyACM0

I get the following output:

[ INFO] [1591454910.420267946]: Connecting to serial port "/dev/ttyACM0", at 921600 baud
[ERROR] [1591454913.421457993]: Received 0 of 0 parameters. Requesting missing parameters...

I am wondering what the cause of this might be or if the board is even compatible at all? I tried following the guide listed here [1]. As I understood it the F405 boards should be compatible or am I mistaken?

When I call:

rosservice call /param_get PID_ROLL_ANG_P

I get the following output:

exists: False
value: 0.0

I suspect that I have misunderstood something. Any clearifications or feedback would be greatly appreciated.

PS: When I call lsusb, the port with the board gives the following output, which I find odd as the board should be F405.

Bus 001 Device 024: ID 0483:5740 STMicroelectronics STM32F407

I don’t know if that is relevant, but I thought it was worth mentioning.

[1] https://docs.rosflight.org/developer-guide/building-flashing/#f4

superjax · June 13, 2020, 6:14pm

Hey adrian,

I’m sorry, I never got an email of your post. @dpkoch, is there any way that I can change my settings so that I’m notified when people post?

Two things.

1 - I’m surprised by your lsusb output. That is indeed concerning. I assume that the print on the top of the chips says 405?

2 - Have you been able to flash new firmware to the device? If I remember, ROSflight firmware will override the lsusb output (or at least, dmesg will print something about ROSflight` if it’s been successfully flashed).

At a high level, we haven’t tried every configuration of F4. We have primarily used F4 chips based on the CC3D Revo. This tends to be a pretty good bet, since most F4 flight controllers can trace their heritage back through this board. However, sometimes developers will move certain pins around, and we need to take care of that.

github.com

rosflight/airbourne_f4/blob/1009867d7e6d9b5730b4d58d238a276782769f8c/src/vcp.cpp#L29


    volatile int debug = 1;
    (void)debug;
  }
}


void VCP::init()
{
  // Initialize the GPIOs for the pins
  rx_pin_.init(GPIOA, GPIO_Pin_11, GPIO::PERIPH_IN_OUT);
  tx_pin_.init(GPIOA, GPIO_Pin_12, GPIO::PERIPH_IN_OUT);
  vbus_sens_.init(GPIOC, GPIO_Pin_5, GPIO::INPUT);


  send_disconnect_signal();
  connected_ = false;
  USBD_Init(&USB_OTG_dev, USB_OTG_FS_CORE_ID, &USR_desc, &USBD_CDC_cb, &USR_cb);
  vcpPtr = this;


  CDC_SetCtrlLineStateCb(&vcp_ls_callback, NULL);
}


void VCP::write(const uint8_t* ch, uint8_t len)

I know of some boards that have moved the VBUS_SENS pin somewhere else. This isn’t abstracted very well in our code, but the Revo boards have it on PC5.

looking at https://github.com/cleanflight/unified-targets/blob/7ceb2aa098ee5d3490d27663377e5eb49573bc0a/configs/default/MTKS-MATEKF405CTR.config#L51, it appears that the matek board uses PB12.

To test, you could replace vcp.cpp:29 with
vbus_sens_.init(GPIOB, GPIO_Pin_12, GPIO::INPUT);
build, and flash.

adrianradian · June 20, 2020, 11:31am

Hello James,

Thank you for the tips. I am currently working on a different platform, but I will get back to this problem in a few weeks and try to implement the changes you suggested. I will let you know how it works out regardless of the result. Thanks again for helping out.

Sincelery,
Adrian