Vertical Take off in STEVAL FCU001

[mmdave1]

Hi All,

I am beginner to drones. We assembled one drone using STEVAL FCU. 002. board ,  recommended set. of motors and. propellers along with battery. 

We Chose different. frame.  than. one recommended . It is smaller in size. 

While flying , vertical take. off. could. not be achieved.

Can someone guide please ?

Motor connections , Clock wise. ,  anti clock wise in reference. to alignment. of. the boards are checked. already.

It is ST board. so. come equipped with all driver , frimware etc.

Thanks in advance.

Early and accurate response is. appreciated.

Regards,

[Elektronvolt]

Hi, I'm in the same situation. I bought the official drone kit and FCU board as a school study project for a custom flight controller stabilization code. The hardware is as follows:

- steval-FCU001V2 board
- steval-drone02 drone kit

I used the UM3117 https://www.st.com/resource/en/user_manual/um3117-how-to-build-your-own-minidrone-with-the-stevaldrone02-and-stevalfcu001v2-stmicroelectronics.pdf  manual as a reference. Compared to the materials and manuals available for version V1 of the drone kit and the steval fcu001V1, this V2 resources and manuals seems less comprehensive to me, and some of the connection diagrams aren’t very clear. Some resources for V1 will certainly still be valid for V2, but this isn't guaranteed, and in that case it would have been better to include them in the official documentation for V2.

My main issues now are as follows: I can’t get it to fly with the factory-loaded firmware, and I can’t even flash a new firmware or erase prev flash contents.

1) When I connected the motors according to the manual, I found that the motors with white and black wires (I believe the ones that are supposed to rotate CCW) are reversed compared to the manual; if wired as per the manual, the propellers push air upward instead of downward… so I inserted the motor connectors with the white and black wires reversed from what was indicated. (I saw a correction sheet mentioning something like this, but only for a specific batch of version V1 years ago; nothing for v2)

2) The board already had the factory firmware, and with that I couldn’t get it to take off or stay stable in flight with ST_BLE_DRONE app; it only rises about 2 cm, spins in place, or sometimes accidentally hovers at a height of 2 cm but spins wildly in yaw, making circles, and then crashes into something (with initial calibration done and battery fully charged)

I downloaded the reference firmware from the STM website, “STSW-FCU001 Reference Design Firmware for Mini Drones,” at the link https://www.st.com/en/embedded-software/stsw-fcu001.html

This appears to be the firmware on the device, as when I connect a UART-USB adapter to the FCU’s P7 connector and view the serial terminal, I see printf debug output that exactly matches the version and date in the printf code line in main.c

Thinking it might be a PID or parameter issue, I connected an H7 Nucleo board to use solely as an STLink and debugger via STM32CubeProgrammer (after I removed the nucleo MCU power supply and reset jumpers). The programmer connects successfully and correctly detects the FCU’s STM32F401 MCU target, but when attempting to read the flash to save an existing program, it reads all 0x00000. Furthermore, upon checking, it appears that the control bytes are incorrect, enabling a flash read/write protection that shouldn’t be present.
Furthermore, when manually setting the read protection to “disabled” and clicking “Apply,” the programmer freezes and the program stops responding, so I can’t even modify those settings… I can’t even perform a full flash erase; the sector erase always fails.

This makes me suspect that the option bytes might be corrupted in the default firmware that was loaded, or that they have been modified in some way I can’t explain—simply connecting a programmer doesn’t alter them on its own. At this point, I’m not sure how to recover the device if they cannot be reset or modified through the programmer. This could potentially mean the MCU is effectively locked, and the only workaround might be replacing it with a fresh, non-compromised one—which is obviously not ideal.

I have a few questions:

1. Were you able to successfully import the project into the STM32 Cube IDE? I was able to, but only using a version prior to 2.xxx. Furthermore, if I open the IOC settings, the project no longer compiles; the middleware folders get altered, and if you try to add a peripheral or change any settings in the IOC, the project and necessary includes get corrupted, and a large number of compilation errors are generated…
2. Also, regarding the reference FW, I don’t understand which modules or folders are auto-generated by the IDE used by the FW developer, or if it’s custom code imported or copied from another project and manually adapted without auto-generated drivers.
3. Is there a proper procedure for correctly importing the reference project and being able to modify IOC settings without corrupting it?
4. Has anyone managed to get it flying with the default firmware, or can anyone provide their wiring diagrams or modifications made to the firmware and hardware so I can program it and get it flying properly?

It’s a bit of a shame because it’s a beautiful kit with everything you need, open fw and hw, but getting it up and running seems very laborious… especially if there are already these initial issues.
And I've seen several discussions about this kit with similar issues, but it's unclear whether they've been resolved or not. I'd like to figure out if it's a problem affecting only a few people, if it's just me.