I wanted to write my own low-level controller in the Crazyflie firmware but thought it would be good if a few questions can be clarified before I get started.
It seems like stabilizer.c is where I should be looking to understand how state estimates and desired states are used to directly control the Crazyflie's motor speeds. Looking at the stabilizerTask() function, it seems like the current state estimate is computed using the stateEstimator() function, which modifies the global state variable by taking it in as an output argument. Once we have the current state estimate, commanderGetSetpoint() is called to get the current desired state, by modifying the global setpoint variable. Once we have our estimated state and desired state, the controller() function is called which computes the desired control (in the form of roll, pitch, yaw and thrust values), by modifying the global control variable. Finally, the desired control is passed into the powerDistribution() function which is used to directly control the RPM of each of the Crazyflie's motors. Does this rough workflow understanding look correct?
So if I'd like to write my own controller, it looks like I could keep the stabilizerTask() function as it is, but would need to write my own controller() function, and possibly a modified powerDistribution() function as well, which would replace the calls made in stabilizerTask()? As a final question, does the commanderGetSetpoint() function allow me to give, for example, desired waypoints or trajectories that are computed off-board, and sent to the Crazyflie via the Crazyradio PA?
Any help or guidance would be great, thanks!
Writing custom on-board controller in firmware
Re: Writing custom on-board controller in firmware
Hi!
There is some highlevel documentation about the sensor to control framework to be found here: https://www.bitcraze.io/documentation/r ... o_control/
You can look at these recent pull request how the new INDI controller was implemented: So technically, your controller should have as input the state estimates & setpoints and should output the control commands. You should not need to change the stabilizer.c and powerdistribution as they are separate.
Please have a close look to those links I posted before to investigate how this can be implemented
There is some highlevel documentation about the sensor to control framework to be found here: https://www.bitcraze.io/documentation/r ... o_control/
You can look at these recent pull request how the new INDI controller was implemented: So technically, your controller should have as input the state estimates & setpoints and should output the control commands. You should not need to change the stabilizer.c and powerdistribution as they are separate.
Please have a close look to those links I posted before to investigate how this can be implemented
Re: Writing custom on-board controller in firmware
Thanks for those links Kimberly, very useful. The INDI controller, and similarly the Mellinger controller, look like they use the same control output format as the default PID controller, where their output is given by control->thrust, control->roll, control->pitch, and control->yaw, which is then passed into the powerDistribution() function to perform "motor mixing" and set the PWM ratios. However, the LQI controller implementation that I'm working on outputs desired motor speeds instead of the above mentioned control output (i.e. the "motor mixing" is done implicitly in the LQI controller). As such, it looks like I could either try and get the LQI controller to output its controls in a similar fashion to the current Crazyflie controllers (this would be ideal as it would be clean and could be slotted in easily as an additional controller), or I could take the easy/untidy route and make some modifications to powerDistribution() to take in desired motor speeds instead of thrust, roll, pitch and yaw commands, which would then be passed into motorsSetRatio() to deal with setting the correct PWM ratios.
Regarding the units of motorPower found in power_distribution_stock.c (https://github.com/bitcraze/crazyflie-f ... .c#L83-L86), after the motor mixing is done, are these equivalent to desired motor speeds (RPM or rad/s), or do they represent something else?
As an aside, do you know why the decision was made to have the CF controllers output thrust, roll, pitch and yaw commands instead of desired motor speeds? Thanks!
Regarding the units of motorPower found in power_distribution_stock.c (https://github.com/bitcraze/crazyflie-f ... .c#L83-L86), after the motor mixing is done, are these equivalent to desired motor speeds (RPM or rad/s), or do they represent something else?
As an aside, do you know why the decision was made to have the CF controllers output thrust, roll, pitch and yaw commands instead of desired motor speeds? Thanks!
Re: Writing custom on-board controller in firmware
So first of all, the reason for this motor mixing layer was to be flexible in terms of quadrotor configurations. The crazyflie 1 had a + configuration and the CF 2.X has an x configuration. In that sense you can stay flexible with the configuration (which is also important with the Bolt).
If you have intention to merge your code eventually with our firmware in the future, I would actually advise you to make an controller that outputs it in the attitude sense as the controller framework is doing now. That would make it easier for us to accept it officially into the firmware and maintain it in the future. If you do not have the intention to do that, then in that case, do whatever you seem fit
. You can also start a discussion on github to express your thoughts if you think it is better to control the motors directly.
The unit is for what you set the motors is more of a 'thrust percentage' which is in motorsSetRatio()(in motors.c) converted to PWM, at least that is what I believe it is looking fro the code.
If you have intention to merge your code eventually with our firmware in the future, I would actually advise you to make an controller that outputs it in the attitude sense as the controller framework is doing now. That would make it easier for us to accept it officially into the firmware and maintain it in the future. If you do not have the intention to do that, then in that case, do whatever you seem fit
. You can also start a discussion on github to express your thoughts if you think it is better to control the motors directly.The unit is for what you set the motors is more of a 'thrust percentage' which is in motorsSetRatio()(in motors.c) converted to PWM, at least that is what I believe it is looking fro the code.
Re: Writing custom on-board controller in firmware
Thanks Kimberly, appreciate the detailed explanations. I had some more time to work on the on-board controller this weekend, and since I'll be using a gamepad to control the Crazyflie via the cfclient I wanted to ask if you know which parts of the firmware deal with taking the gamepad's inputs, and then using those inputs to call the on-board controller to manipulate the Crazyflie's attitude and position. Is there maybe some documentation or a blog post on this workflow that's available to read? Alternatively, pointing me to the parts of the source code that deal with this would be equally helpful.
Re: Writing custom on-board controller in firmware
Hi,
Have you seen this tutorial already ? https://www.bitcraze.io/documentation/t ... flow-deck/
So technically, if you are controlling it manually, you are sending attitude setpoints through the crazyflie python library (doc is here, this is read out by the crtp_commander_rpyt.c in the firmware.
If you are flying in assist hover mode in the cfclient, you are sending velocity setpoints (see here in the cflib, which is read out in crtp_commander_generic.c.
The python library cflib is the backbone of the cfclient by the way. Also the commander framework is explained here as well (the link in the previous forumpost has changed recently).
Have you seen this tutorial already ? https://www.bitcraze.io/documentation/t ... flow-deck/
So technically, if you are controlling it manually, you are sending attitude setpoints through the crazyflie python library (doc is here, this is read out by the crtp_commander_rpyt.c in the firmware.
If you are flying in assist hover mode in the cfclient, you are sending velocity setpoints (see here in the cflib, which is read out in crtp_commander_generic.c.
The python library cflib is the backbone of the cfclient by the way. Also the commander framework is explained here as well (the link in the previous forumpost has changed recently).