What is the message processing pipeline on the Crazyflie firmware?

[Oukami]

Hello!

I'm a PhD student in Engineering working on implementing an onboard sliding mode controller using Crazyflie 2.

On the server side, I'm using Whoenig's Crazyflie ROS package, and I'm looking to modify the official firmware.

Here are the details:

• I have figured out what data the ROS code sents, and where. (Specifically, it sends a crtpSetpointRequest using roll, pitch, yawrate, and thrust; packs it; and sends it step by step.)
• For the sliding mode controller to work, it needs an extra 6 or 9 variables (obtained from motion capture and derived), depending on the amount of calculation done locally.
• I should be able to modify creating the data on the ROS side on my own.
• I have no idea where the Crazyflie firmware access the data that is sent by ROS, and what process it goes through in order for the controller to be able to read it.

What do I need to understand in order to be able to make the changes and implement a custom controller? (Bonus question: Will using a new controller with new names cause many issues? Is it better to keep the PID function signature and modify the contents?)

I couldn't find other forum posts regarding people who had issues with a similar situation. (Many people had already modified the firmware and were having other trouble...) I have no experience in coding beyond basic projects and assignments, so I feel out of my depth here. Please let me know if there's any extra information you need.

[arnaud]

Hi,

The ROS crazyflie client is implementing the CRTP protocol: https://wiki.bitcraze.io/doc:crazyflie:crtp:index. Basically in the Crazyflie the communication is multiplexed so that you can talk to different part of the system easily.

I think what you will need to do is:
- Write your algorithm in the Crazyflie, registering a new communication port to receive packets containing the 6 to 9 extra variables (we have a limitation in packet size, but we also have 16bit floating point implemented that helps keeping packet small).
- Implement your new port in the ROS crazyflie client, making it accessible as a ROS topic. This will be similar to the way the current commander packet is implemented.

The extra variables you want to push in the Crazyflie, are they synchronous with the setpoint or are they coming at a different rate? There has been plan to make a new more flexible commander packet (the commander is the subsystem that receives setpoint from the ground and make it available for the controller). Maybe this can be used for your use-case as well. The issue is there: https://github.com/bitcraze/crazyflie-f ... issues/113.

As for the implementation, if you can stick to the current interface you will just need to create a controler_sliding.c file and to add CONTROLER=sliding in the build configuration (tools/make/config.mk). The project is currently setup to allow for changing the sensors/estimator/controler/power_distribution easily that way. You will have to implement these functions: https://github.com/bitcraze/crazyflie-f ... .h#L31-L36.

[Oukami]

Thank you for the details, arnaud. I think I understand most of the procedure. However, I don't know where to start with this:

registering a new communication port to receive packets

Let's say I want to register port 7 as the new port. What would I have to change in order to register the port, how do I decode the data, and how do I get the data to my controller_sliding.c? Would I need to modify, say, state_t? If you can point me to a guide on how to register and use new ports, I would really appreciate that.

The extra variables you want to push in the Crazyflie, are they synchronous with the setpoint or are they coming at a different rate?

They can be synchronous with the setpoint. If I need to send them at a faster rate, I might be able to resend the same setpoints.

[arnaud]

Unfortunately for this part of the code, the documentation is the code (we have been thinking of documenting with Doxygen for this kind of things ...).

To register a port you need to call this function: https://github.com/bitcraze/crazyflie-f ... vice.c#L52
The callback function is called when a packet is received.

The data at this point is an array of bytes, we usually decode it by mapping the data as a packed struct: https://github.com/bitcraze/crazyflie-f ... der.c#L174

Then you have to push the data in the right structure for the other algorithm, depending on what you are doing it could be state_t or setpoint_t for example.

For the new setpoint, I am hopping to get more time for it next week so stay tuned on the ticket .