Received 0 of 0 parameters. Requesting missing parameters...

[DaneSlattery]

Issue Guidelines:

Please only create issues regarding bug reports, feature requests, and anything which would cause direct change to code. Questions, general discussion and other discussion topics should be redirected to discuss.rosflight.org

Bug reports should include all information related to reproducing the bug. This includes:

1. OS Version
2. git tag (master, stable, v1.0, etc..)
3. parameter file (rosservice call /param_save_to_file)
4. Compiler version (arm-none-eabi-gcc --version)
5. Hardware configuration (MAV type, flight controller version, connected sensors)

Hi.

I have an STM32F405 board on the MATEKSYS F405-CTR Board.

I am trying to follow this guide to build and flash the firmware: http://docs.rosflight.org/en/latest/developer-guide/building-flashing/

I think I successfully write the firmware onto the board, but when I run (after rebooting):

rosrun rosflight rosflight_io _port:=/dev/ttyACM2

I get the following error, forever: [ERROR] [1556111879.397211205]: Received 0 of 0 parameters. Requesting missing parameters...

In an attempt to solve it, I open a different terminal and type:

rosservice call /param_get FIXED_WING

which returns:

exists: False value: 0.0

I try to set the parameters (since they're non-existant), which returns:

rosservice call /param_set FIXED_WING 0

exists: False

I suspect that the firmware is not properly flashed.

For my hardware setup, I don't have any peripherals/motors/RC connected to the FC. I'm only connecting via the USB cable to my laptop (running Ubuntu 16.04 LTS) Is this a problem?

I was on branch master.

I couldn't get the parameters.yml file to write. It always wrote an empty .yml file: []

My ARM compiler version is: arm-none-eabi-gcc --version

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496] Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Please tell me if you need any more info. Dane

[DaneSlattery]

Hi, pulling hair out over this. Is this related to this info from the Docs?

"The firmware runs a number of error checks before allowing the flight controller to arm. Completing the configuration checklist on the Getting Started page should avoid these errors. In addition to a few internal health checks, the following conditions are checked:

Mixer: Valid mixer must have been selected (see the hardware setup documentation page) IMU calibration: The IMU must have been calibrated since firmware was flashed (it is recommended that you recalibrate often) RC: There must be an active RC connection"

I don't have an active RC connection...

[superjax]

Sorry about this,

I'm not familiar with that particular board schematic. If you were to flash betaflight to this board, what version of firmware would you flash?

I'm wondering because there may be a slightly different hardware configuration that we are missing which would also be required by betaflight.

[superjax]

By the way, your procedure sounds correct. One thing I might make sure is that rosflight_io isn't looking for a udp connection (from a potentially stale ros configuration)

rosrun rosflight rosflight_io _port:=/dev/ttyACM2 _udp:=false

also, if you don't have RC, then you should see a light flashing on the board at about 1 Hz. That's not absolutely certain though, because some board configurations are missing one of the LEDs present on the REVO (our reference board)

[superjax]

finally, (sorry about the spamming, I keep coming up with ideas as I'm writing my response).

Could you watch the output of sudo dmesg -w as you plug or unplug the device? If you see something with STM Bootloader then you've got bad firmware. If you see something related to ROSflight, then at least the USB peripheral in the firmware is working properly and the problem lies somewhere else.

[DaneSlattery]

By the way, your procedure sounds correct. One thing I might make sure is that rosflight_io isn't looking for a udp connection (from a potentially stale ros configuration)

rosrun rosflight rosflight_io _port:=/dev/ttyACM2 _udp:=false

also, if you don't have RC, then you should see a light flashing on the board at about 1 Hz. That's not absolutely certain though, because some board configurations are missing one of the LEDs present on the REVO (our reference board)

This is the hardware on the MATEKF405: Hardware MCU: 168MHz STM32F405RGT6 IMU: 32K ICM20602 gyro/accelerometer (SPI) Baro: BMP280 (I2C) OSD: BetaFlight OSD w/ AT7456E chip Blackbox: MicroSD card slot (SD/SDHC) VCP, UART1, UART2, UART3, UART4, UART5 Built in inverter for SBUS input (UART2-RX) PPM/UART Shared: UART2-RX SoftSerial on TX2, S5 or S6 optional Camera control on S6 or DAC optional Smartaudio & Tramp VTX protocol supported Battery Voltage Sensor: 1:10 Current Sensor: No (FCHUB-6S, FCHUB-VTX, FCHUB-W option) BEC 5V: No (FCHUB-6S, FCHUB-VTX, FCHUB-W option) LDO 3.3V: Max.300mA I2C1 SDA & SCL: Yes WS2812 Led Strip : Yes Beeper : Yes RSSI: Yes

As far as I can tell, it's very similar to the REVO.

BetaFlight has firmware support for the Matek405 in their latest release, version 4. (https://github.com/betaflight/betaflight/releases/download/4.0.0/betaflight_4.0.0_MATEKF405.hex)

By the way, your procedure sounds correct. One thing I might make sure is that rosflight_io isn't looking for a udp connection (from a potentially stale ros configuration)

rosrun rosflight rosflight_io _port:=/dev/ttyACM2 _udp:=false

also, if you don't have RC, then you should see a light flashing on the board at about 1 Hz. That's not absolutely certain though, because some board configurations are missing one of the LEDs present on the REVO (our reference board)

The board does flash at 1Hz. I will certainly try the rosrun with the udp parameter set to false and report back here.

finally, (sorry about the spamming, I keep coming up with ideas as I'm writing my response).

Could you watch the output of sudo dmesg -w as you plug or unplug the device? If you see something with STM Bootloader then you've got bad firmware. If you see something related to ROSflight, then at least the USB peripheral in the firmware is working properly and the problem lies somewhere else.

I have been wondering how to ensure that the firmware is successfully flashed. I'll try this as well and report.

Also going to fetch an RC to connect today. According to the wiki, rosflight_io should throw an error if no RC is connected. Do you know if this is the error I'm getting?

Also going to try with a naze32 (we thought that newer technology would be better, having attempted autonomy before on a naze32 with an Arduino- what a horror that was).

[DaneSlattery]

Would there be any benefit in me going through the following files:

How ROSFLIGHT abstracts the Revo: https://github.com/rosflight/firmware/blob/master/boards/airbourne/airbourne_board.cpp

How Betaflight abstracts the Revo: https://github.com/betaflight/betaflight/blob/master/src/main/target/REVO/target.h

How Betaflight abstracts the Matek405: https://github.com/betaflight/betaflight/blob/master/src/main/target/MATEKF405/target.h

and looking for commonalities/pin definitions/port assignments? The betaflight HAL is quite a bit more complex, but at the base level, it might give us some clues about the hardware configuration (since it seems to be closed-hardware).

Might take a while to Reverse Engineer it, but if it's valuable then I can try find time between my research.

Hopefully, there's a better way of doing it!

[DaneSlattery]

Hi, this is the output of dmesg -w when plugging in the flight controller a number of times:

`[ 117.154347] usb 1-1: new full-speed USB device number 8 using xhci_hcd [ 117.303801] usb 1-1: New USB device found, idVendor=0483, idProduct=5740 [ 117.303808] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 117.303812] usb 1-1: Product: MatekF4 [ 117.303816] usb 1-1: Manufacturer: Cleanflight [ 117.303819] usb 1-1: SerialNumber: 0x8000000 [ 117.304906] cdc_acm 1-1:1.0: ttyACM1: USB ACM device

first plug-in, with cleanflight ^

[ 159.481459] usb 1-1: USB disconnect, device number 8 [ 159.481669] cdc_acm 1-1:1.0: failed to set dtr/rts [ 162.128805] usb 1-1: new full-speed USB device number 9 using xhci_hcd [ 162.277836] usb 1-1: New USB device found, idVendor=0483, idProduct=df11 [ 162.277841] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 162.277845] usb 1-1: Product: STM32 BOOTLOADER [ 162.277848] usb 1-1: Manufacturer: STMicroelectronics [ 162.277852] usb 1-1: SerialNumber: 206E3270354B

Second plug-in, in flashing mode ^

[ 189.484865] usb 1-1: USB disconnect, device number 9 [ 190.146615] usb 1-1: new full-speed USB device number 10 using xhci_hcd [ 190.296002] usb 1-1: New USB device found, idVendor=0483, idProduct=5740 [ 190.296004] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 190.296005] usb 1-1: Product: STM32 Virtual ComPort in FS Mode [ 190.296007] usb 1-1: Manufacturer: JAMES JACKSON [ 190.296008] usb 1-1: SerialNumber: 0x8000000 [ 190.296865] cdc_acm 1-1:1.0: ttyACM1: USB ACM device

after flashing rosflight ^

[ 213.690345] usb 1-1: USB disconnect, device number 10 [ 216.029724] usb 1-1: new full-speed USB device number 11 using xhci_hcd [ 216.180717] usb 1-1: New USB device found, idVendor=0483, idProduct=5740 [ 216.180719] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 216.180720] usb 1-1: Product: STM32 Virtual ComPort in FS Mode [ 216.180721] usb 1-1: Manufacturer: JAMES JACKSON [ 216.180722] usb 1-1: SerialNumber: 0x8000000 [ 216.181618] cdc_acm 1-1:1.0: ttyACM1: USB ACM device [ 248.488544] usb 1-1: USB disconnect, device number 11 [ 253.705225] usb 1-1: new full-speed USB device number 12 using xhci_hcd [ 253.854913] usb 1-1: New USB device found, idVendor=0483, idProduct=5740 [ 253.854919] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 253.854923] usb 1-1: Product: STM32 Virtual ComPort in FS Mode [ 253.854927] usb 1-1: Manufacturer: JAMES JACKSON [ 253.854931] usb 1-1: SerialNumber: 0x8000000 [ 253.856158] cdc_acm 1-1:1.0: ttyACM1: USB ACM device [ 379.486252] cdc_acm 1-1:1.0: failed to set dtr/rts [ 472.820671] cdc_acm 1-1:1.0: failed to set dtr/rts [ 475.388201] cdc_acm 1-1:1.0: failed to set dtr/rts [ 613.543981] cdc_acm 1-1:1.0: failed to set dtr/rts [ 616.599054] cdc_acm 1-1:1.0: failed to set dtr/rts [ 695.046540] usb 1-1: USB disconnect, device number 12 [ 697.576966] usb 1-1: new full-speed USB device number 13 using xhci_hcd [ 697.726482] usb 1-1: New USB device found, idVendor=0483, idProduct=5740 [ 697.726488] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 697.726492] usb 1-1: Product: STM32 Virtual ComPort in FS Mode [ 697.726496] usb 1-1: Manufacturer: JAMES JACKSON [ 697.726499] usb 1-1: SerialNumber: 0x8000000 [ 697.727625] cdc_acm 1-1:1.0: ttyACM1: USB ACM device [ 712.413234] cdc_acm 1-1:1.0: failed to set dtr/rts [ 776.521003] usb 1-1: USB disconnect, device number 13 [ 782.676275] usb 1-1: new full-speed USB device number 14 using xhci_hcd [ 782.826036] usb 1-1: New USB device found, idVendor=0483, idProduct=5740 [ 782.826042] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 782.826046] usb 1-1: Product: STM32 Virtual ComPort in FS Mode [ 782.826049] usb 1-1: Manufacturer: JAMES JACKSON [ 782.826053] usb 1-1: SerialNumber: 0x8000000 [ 782.827061] cdc_acm 1-1:1.0: ttyACM1: USB ACM device ` I started with cleanflight flashed on (which is the first section). I then used cleanflight software to flash the rosflight .hex file from earlier on (in DFU mode, the STM bootloader shows up (section 2).

I encountered this

[ 475.388201] cdc_acm 1-1:1.0: failed to set dtr/rts

whenever I run

rosrun rosflight rosflight_io _port:=/dev/ttyACM2 _udp:=false

To fix it, I found this script online:

`#!/bin/sh sudo sh -c 'cat > /etc/udev/rules.d/49-stm32.rules' <<EOF

0483:5740 - STM32F4 Dsicovery in USB Serial Mode (CN5)

ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", ENV{ID_MM_DEVICE_IGNORE}="1" ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", ENV{MTP_NO_PROBE}="1" SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", MODE:="0666" KERNEL=="ttyACM*", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", MODE:="0666"

0483:df11 - STM32F4 Discovery in DFU mode (CN5)

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE:="0666" EOF

sudo udevadm control --reload-rules`

which sets some more rules (including DFU mode rules) for udev.

However, I'm still getting failed to set dtr/rts.

Maybe this has something to do with it?

TL;DR : dmesg -w doesn't show "rosflight" anywhere after flashing the hex file. Running rosflight with the udp parameter set to false also doesn't change it.

Will try the naze32 next...

[DaneSlattery]

Final report of the evening. The naze32 works as expected, no dice for the STM32F4 device, maybe you can see something obvious in my earlier musings.

[plusk01]

What was the exact rosrun rosflight ... command you ran for the naze32?

From dmesg it looks like your device is showing up as /dev/ttyACM1, not /dev/ttyACM2. Have you tried running rosrun rosflight rosflight_io _port:=/dev/ttyACM1?

[DaneSlattery]

In an earlier run my system opened the port as /dev/ttyACM2. In the latest run, it was listed as /dev/ttyACM1. I was careful with the ports, using ls /dev/ | grep ttyACM to see which one was to be used.

The command I used varied between ACM1 and ACM2, depending on which one my system chose for that day.

NB: I'm not having this problem with a naze32, only with an STM32F4 target. The naze32 works exactly as expected.

[superjax]

Interesting.

First off, I had forgotten that the manufacturer was still JAMES JACKSON. I should probably change that. It looks right to me, although I don't have an F4 handy to check against. I'll have time next week.

There is a 5V pin connected to the USB-OTG that I use to detect whether the USB is connected. If that moved then you might see the behaviour you're talking about.

Makekf405 USB Detect pin: PB12 Airbourne USB Detect pin: PC5

There's our problem:

I don't have time to fix this right now, but it shouldn't be too hard to fix. Unfortunately, the pin mapping in airbourne isn't as abstracted as I would like it to be.

The betaflight pin mappings: (copied from above) https://github.com/betaflight/betaflight/blob/master/src/main/target/MATEKF405/target.h

and here is the airbourne pin mappings we use https://github.com/rosflight/airbourne_f4/blob/master/include/revo_f4.h

[DaneSlattery]

Should I try changing the pins in this file: https://github.com/rosflight/airbourne_f4/blob/master/src/vcp.cpp#L29

locally to reflect the following changes:

PIN | MATEK | REVO RX | PA10 | PA11 TX | PA9 | PA12 DETECT | PB12 | PA5

and try to compile and flash the fresh firmware. Or is there more to it than that?

If that works, I can start thinking of ways to achieve more abstraction (even if just for F4 targets for now) I'm a big fan of declarative programming, but I'm not sure that I'm ready to stick my fingers in this pie until I get some STM32 programming experience.

[rafaelmaeuer]

Hey I have to report a strange issue. I was recently moving from a flip32 to a naze32, as I could order the naze with angled connectors which is necessary due to space limitations in my project. The flip32 is working fine when connected via microUSB or Serial/UART connectors (with tty-to-usb-adapter). The naze32 works fine when using microUSB, but shows strange behaviors when connecting via UART1 (with tty-to-usb-adapter): The usual print of the firmware version is missing and it doesn't stop to complain about missing parameters. The interesting thing is, when dis- and reconnecting from power-source or arming via RC everything works as expected: Due to space limitations I need to avoid connection with microUSB, therefore this needs to work properly. Additionally I read in the how-to that microUSB can disconnect by vibrations. I would use another serial port if SERIAL_DEVICE parameter wouldn't return exists: False.

[rafaelmaeuer]

Is there any option to use UART2 instead? This also would give a better pin output direction.

[Georacer]

I am facing the same issue on an OpenPilot Revo board, with airplane parameters installed.

On my laptop it works like a charm. But when I try to hook the FC on an Odroid XU4 get the ''0 of 0 parameters'' error. Cycling FC power while the companion is on seems to solve the problem. Arming does not.

I will try more power combinations and try to report if I find anything more.

[bsutherland333]

Since we aren't expecting anyone to use F4's going forward, I'm closing this issue.