Running an APP on crazyFlie generated using MATLAB's Embedded Coder

[deepparikh]

Hello,

I want to validate an MPC (custom controller) on crazyFlie. Following is my workflow,

• I have designed, simulated and tuned the controller in MATLAB.
• I then generated C files for my code using MATLAB's Embedded coder. I specified hardware target as ARM CORTEX M type and provided a few additional configurations that I felt aligns with the crazyFlie hardware.
• I verified this code with webbots simulator. I was able to build executable of my custom controller using gcc and fly the simulated crazyFlie as intended.
• I proceeded with the hardware validation. I created a new APP and then added the same source and header files to crazyFlie firmware, built it and flashed it to the drone.
• I am using crazyswarm2 with VICON motion capture, independently validated the working of crazyswarm2 and motion capture system.

The issue that I am facing is the crazyFlie boots fine with the custom controller on-board, but when I start running my controller, the drone either reboots or goes into states which are not documented, for example solid red LEDs, just solid blue LEDs etc. I know that the custom controller meets the RAM (~83%) and flash (~30%) and CCM(~95%) requirements.

I figured that there is something in my code which makes the hardware reboot or stall, however, the same code works perfectly fine with webbots. Also the code is like 4000 lines, so manual debugging is very painful. Hence my questions are,

1. What are main differences between developments process for webbots and the hardware?
2. What are the good practices and standards that I need to follow while creating an APP?
3. I suspect that the crazyFlie rebooting is a sign of memory allocation issue. If that is the case, are there any ways to free up more memory for external stuff : for example, since I am providing the pose externally, can we tell crazyFlie to not run the estimator and free up some resources??

Thank you so much for any insights.

[gemenerik]

The differences between a Webots simulation and flying the real Crazyflie can be significant, depending on your implementation. Using the Python bindings can help bridge this gap, but even then, the simulator isn't running software-in-the-loop, so notable differences remain.

Your approach with the app seems correct, but now you need to debug. Since the drone is rebooting (asserting), you should connect to the cfclient and check where it asserted—that will give you a clue about what’s going wrong.

As for best practices, this situation isn't primarily about coding standards; it's about identifying and resolving a critical failure. I think that focusing on debugging will be more productive than refining practices at this stage.

If you suspect a memory issue, you can disable features in Kconfig, or otherwise manually modify the firmware to save resources.

---

For those starting with new sim->real projects, employing a software-in-the-loop simulator like CrazySim can be beneficial. CrazySim runs (a modified version of) the Crazyflie firmware in a simulated environment.

[deepparikh]

Thank you Rik for your insights, I will keep this thread updated as I have more observations or need more help.

[gemenerik]

You´re welcome. On our end we will try to clarify what users can expect from the simulation repository and what alternatives there are.