Add setpoint functionality to attitude rate and motor speeds

[knmcguire]

In order to work on off-board control design, it is good to have more direct control for the desired attitude rate or even motor speeds. Some have tried to do this through the parameter setup, but since the parameters framework is not on a high priority in the freertos scheduler, this is too slow for that purpose. Therefore, it should be possible to set the desired attitude rate or motors from the setpoint functionality directly.

[duembgen]

I agree this would be a really useful feature to have. In fact we are working on a study for which we would like to set the speed of each motor independently. I came across this Bachelor thesis from ETH Zurich, which I think you might be familiar with, where the student has done something similar: http://mikehamer.info/assets/papers/Crazyflie%20Modelling.pdf

Something along these lines would be perfect for us. If we have time to try it out we will share our experiences here.

[krichardsson]

Just a reminder: let us use SI units if possible. At some point we should convert all set points to SI units and it would be nice if this is already OK

[eduardo-del]

Hi guys

I come here because the last days i had a question

my question is if i can control everything (x, y, z, theta, phi, and yaw) in one Controller
https://forum.bitcraze.io/viewtopic.php?f=6&t=4277

I will like to know how can i do an off-board controller?, maybe using ROS.

What happens with the firmware if I do an off-board controller that control all the states??
I think use the optitrack and the IMU to read all the states (x, y, z, theta, phi, and yaw).

And with the parameters of the crazyflie you know which ones are correct?
I have read some documents where it seems that they are only approximations.

Thank you!!

[knmcguire]

A little update here. I was investigating the setpoints and controllers a little bit, and it IS possible to set the attitude directly from the setpoints directly (see

crazyflie-firmware/src/modules/interface/stabilizer_types.h

Line 178 in 6d75b4e

attitude_t attitudeRate; // deg/s

).
If the modes of roll pitch and yaw are set to modeVelocity, that is exactly what we want already.

I guess we have to find out how to set that setpoint from the python library, which I would guess just requires another send_setpoint function. Also I think that the python api documentation (https://www.bitcraze.io/documentation/repository/crazyflie-lib-python/master/) should also be extended.

[ataffanel]

Yes it is possible, you linked to the internal commander struct that "supports everything" internally, there needs to be a radio commander packet that fills up the rate modes.

The 'old' way of controlling with attitude rate seems to be still active:

crazyflie-firmware/src/modules/src/crtp_commander_rpyt.c

Lines 179 to 181 in 6d75b4e

	if (stabilizationModeRoll == RATE) {
	setpoint->mode.roll = modeVelocity;
	setpoint->attitudeRate.roll = values->roll;

The modes are set by parameters, and when they are set to rate the normal setpoint packet can be interpreted as rate instead of absolute attitude:

crazyflie-firmware/src/modules/src/crtp_commander_rpyt.c

Lines 226 to 228 in 6d75b4e

	PARAM_ADD(PARAM_UINT8, stabModeRoll, &stabilizationModeRoll)
	PARAM_ADD(PARAM_UINT8, stabModePitch, &stabilizationModePitch)
	PARAM_ADD(PARAM_UINT8, stabModeYaw, &stabilizationModeYaw)

If this functionality is useful and we want to make it more clearly available the best might be to implement a generic commander packet for it and to add it to commander.py in the python lib.

[knmcguire]

yeah exactly :) I think it would be useful for the ones that want to design an off-board controller, since there is still 2 cascaded PID 'layers' between the absolute attitude set-point and the motor controls. This will reduce it to 1 layer, which probably will provide enough stability but is not as extreme as controlling the motor controls directly.

[knmcguire]

anyway, since this is already possible firmware wise and there is an issue about this in bitcraze/crazyflie-lib-python#152, I will close this issue

[duembgen]

Thank you for the update on this. We managed to go around this issue by setting the motor speeds through the mPowerSet parameter, which is not usable for realtime but we were able to record the data we needed that way. In realtime, we ended up wanting to control the attitude since we wanted the drone to hover in a stable way. Therefore it was enough for us to use the thrust/roll/pitch/yaw setpoints.

However it is good to know the workaround for the future.

[knmcguire]

Ah happy you found a solution in the end anyway. Are you experiencing a lot of delay when controlling attitude instead of the attitude rate? I think I probably will still go ahead to add this functionality to the python library since more people requested this :) this summer is going to be clean up all the way anyway!

[EceChaik]

Hi, sorry for intruding, but is there going to be functionality added to the api for controlling the motors directly? I was about to clone the firmware and start tweaking with it to make it work for a project, when I found this discussion.

[knmcguire]

Like @duembgen, you can set the motor speed through the parameter frame work with mPowerSet.

[EceChaik]

Oh yeah, but I understand that these cannot be set in realtime right? It can't be used for flight control

[knmcguire]

Yes I would suspect that it might be difficult to do that in real time, also considering the delay in communication in general. We probably would need to make a separate CRTP group for this in order to get this through as quickly as possible. But that is maybe something for which we would need to make a different ticket/issue for maybe

[hazar-boughanmi]

Hi, im looking to control each motor of crazyflie 2.1, so is there any python script for controlling the motors directly?

[EceChaik]

The way I did it was by affecting the firmware.
I chose to add a new boolean and a 4-element vector in both the control struct and setpoint struct in stabilizer_types.h.
Then you also need to add a new packet definition in crtp_commander_generic.c with the appropriate decoding functions that add the received motor commands to the setpoint and set the boolean to true.
Then you can simply check for that boolean in the controller_pid and if true, pass the motor values to the control struct's 4-element vector.
Finally check for the boolean in the power distribution module, to assign the motor values saved in the control struct directly.

There are possibly more elegant ways, but the above should work pretty easily

[HazarBoughanmi]

Thank you so much you really give me hope, i'll try it today.
You affected the firmware to make it accept commands for the motors , but how did you send the commands?

[EceChaik]

I use crazyflie-ros so I had to create ros publishers. If you're using the crazyflie-python libs, I think you just go there and create a message type.
You can see how the already implemented messages are created (position commands, rpyt commands, alt-hold commands etc) to figure out what you have to replicate

[hazar-boughanmi]

Thank you very much, sorry to ask a lot of questions, but since I don't code in C often i have faced some problems
here you are some screenshots of what I did. Can you please take a look and tell me if it's ok. I'll appreciate that a lot.

About the function in power distribution stock I haven't been able to figure out how to write it (ex how should I assign the values ​​of the motors, should I define a structure containing these values).

thank you so much.
**crtp_commander_generic

**crtp_commander_generic2

***stabilizer_types

[EceChaik]

I think you're on the right track. In order to avoid flooding this issue with answers, you can check my implementation at
https://github.com/EceChaik/direct-motor-cf-firmware
I think I based this on the firmware of Sept. 2021 and there may be some other additions there, but you will find the ones relevant to direct motor control.

[hazar-boughanmi]

Thank you so much.For my last question i had sent you an email.