Writing custom on-board controller in firmware

Firmware/software/electronics/mechanics
Post Reply
asr
Beginner
Posts: 8
Joined: Sun May 31, 2020 3:07 am

Writing custom on-board controller in firmware

Post by asr » Sun Jun 07, 2020 11:47 pm

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!



kimberly
Bitcraze
Posts: 373
Joined: Fri Jul 06, 2018 11:13 am

Re: Writing custom on-board controller in firmware

Post by kimberly » Mon Jun 08, 2020 11:30 am

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

asr
Beginner
Posts: 8
Joined: Sun May 31, 2020 3:07 am

Re: Writing custom on-board controller in firmware

Post by asr » Sun Jul 05, 2020 11:24 pm

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!

kimberly
Bitcraze
Posts: 373
Joined: Fri Jul 06, 2018 11:13 am

Re: Writing custom on-board controller in firmware

Post by kimberly » Mon Jul 06, 2020 8:39 am

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.

Post Reply