I would like to try my own high-level controller on the Crazyflie. This controller outputs reference values for (roll, pitch, yaw rate, thrust) that should be sent to the Crazyflie as a setpoint. I saw that in the Commander.py class in the crazyflie_lib there are functions for sending setpoints of the form (roll, pitch, yaw, thrust) or (roll, pitch, yawrate, zdistance), but not the one I need. However, given that the reference values are controlled by different functions, I believe that I can easily modify the firmware according to my system.
The question is, where are the setpoints handled in the CF firmware and what do I need to change there?
Cheers
Setpoint handling in Crazyflie firmware
Re: Setpoint handling in Crazyflie firmware
Maybe a bit more precise, where in the firmware does the type of setpoint sent to the Crazyflie get classified and how are the setpoints processed differently according to the setpoint type?
Re: Setpoint handling in Crazyflie firmware
The setpoint architecture is a bit messy (because of backward compatibility) but adding a setpoint type is quite straight forward in crtp_commander_generic.c.
Re: Setpoint handling in Crazyflie firmware
We have a similar question.
We are using lighthouse positioning, ROS Kinetic and CrazySwarm ROS. We would like to write a publisher that publishes zDistance type of setpoints (roll/pitch/yawrate/z_positon). How do we accomplish this? What are the necessary firmware changes? Have you got an example of a similar project?
One of the alternatives is using cmdFullState, but we are not sure how to modify it so it doesn't require setpoints we are not generating.
Thank you!
We are using lighthouse positioning, ROS Kinetic and CrazySwarm ROS. We would like to write a publisher that publishes zDistance type of setpoints (roll/pitch/yawrate/z_positon). How do we accomplish this? What are the necessary firmware changes? Have you got an example of a similar project?
One of the alternatives is using cmdFullState, but we are not sure how to modify it so it doesn't require setpoints we are not generating.
Thank you!
Re: Setpoint handling in Crazyflie firmware
There should be no modification needed in Firmware since this setpoint is already handled by the Crazyflie firmware.
You need to add the serpoint to the Crazyflie ROS driver if it is not handled yet. I have never done so but a quick look shows that a function should be added in Crazyflie-cpp: https://github.com/whoenig/crazyflie_cp ... #L169-L219 and the functionality needs to be added to the crazyflie_server part of the ROS crazyflie driver: https://github.com/whoenig/crazyflie_ro ... r.cpp#L219 and https://github.com/whoenig/crazyflie_ro ... r.cpp#L379.
You need to add the serpoint to the Crazyflie ROS driver if it is not handled yet. I have never done so but a quick look shows that a function should be added in Crazyflie-cpp: https://github.com/whoenig/crazyflie_cp ... #L169-L219 and the functionality needs to be added to the crazyflie_server part of the ROS crazyflie driver: https://github.com/whoenig/crazyflie_ro ... r.cpp#L219 and https://github.com/whoenig/crazyflie_ro ... r.cpp#L379.
Re: Setpoint handling in Crazyflie firmware
Thank you Arnaud, adding these changes to crazyswarm server solved our problem. There is just one thing.. it seems to work with PID but not with Mellinger controller. Do you know does the implementation of the Mellinger controller allow zDistance type of setpoints (roll/pitch/yawrate/z_positon)?
Re: Setpoint handling in Crazyflie firmware
I am not surprised it does not work with mellinger: I do not know much details about the Melinger controller but my understanding is that you need to provide much more data to get it to work (ie. wanted position/velocity/acceleration). When using the zDistance setpoint you are only providing for x/y velocity and Z position. I think Mellinger can work with the full state setpoint: https://github.com/bitcraze/crazyflie-f ... ric.c#L299
Re: Setpoint handling in Crazyflie firmware
Yeah, that's what we thought.
Thank you for your help!
Thank you for your help!