Implementing an app-layer in the Crazyflie firmware

[ataffanel]

Now that we have OOT build (#485), it is time to think about building an easy-to-use API to write app on top of the Crazyflie.

The current idea is to start by implementing and documenting APIs that looks like the python lib api for:

• log
• param
• Commander

This work as already been started since these 3 modules are used to drive the multiranger push demo. But they need to be cleaned-up to look more like what is used on the python side (I am mostly thinking about the commander there, every existing commander packet should be made accessible as a function) and they need to be documented.

[wydmynd]

hi! great initiative!
I would implement SD R/W functionality.
but mainly document the api in a way that allows people to do expectation management on developing using the API - what flight control modes are implemented (and documented) , processing and memory capacity, etc.

[pablogs9]

We have implemented some features about memory configuration from app layer: selecting alternative memory manager and optional heap size modification. Please check #513

[wydmynd]

Hi, I can code but know little about memory configuration. I posted a request for clarification and got this answer from arnaud . I think when people start developing interesting applications for CF I expect methods to increase available memory to "app" tasks will need to be made clear to the developers.

[wydmynd]

also , I'm not sure if writing reading/params from within the C code is implemented/documented. it can be useful, for example, for emergency stop (stabilizer/stop param) , or starting/stopping recording to SD card, among many others

[ataffanel]

For the stack for apps, there is a documented parameter that allows to set it (APP_STACKSIZE). The default heap size should likely be increased though.

As for the parameters, there already exists an API to read them (https://github.com/bitcraze/crazyflie-firmware/blob/eaea53d/src/modules/interface/param.h#L38-L45). The API should indeed be documented. The main use case for reading param is to detect what deck has been initialized

As for writing params, it requires a bit more thinking/work: as of today the PCs connected to a Crazyflie will cache the param values and assume that they never change. An API to change params from within the Crazyflie will likely need to send packets to inform a connected PC that the param value has changed.