Commander send_setpoint()

[AkashJohnSubash]

Hi, I'm trying to get the CF2.1 to follow an off-board generated trajectory by feeding it the thrust at 100ms intervals (the control vector defined in my problem formulation).

The most intuitively appropriate cflib API I see is the send_setpoint(roll, pitch, yawRate, thrust), to which I have some questions

• Does this API define the set-points in the absolute / velocity mode documented in the commander module ?
• The API documentation for set_client_xmode() indicates a recalculation that I could also see in commander.py. What does it achieve ?
• I see that the pitch is inverted in the send_setpoint implementation in commander.py. Should I offset this by calling the function with an inverted value myself ?
• Does this API directly inject these set-points into the cascaded PID attitude, attitude rate controllers ?
  If yes, is it more stable to inject position set-points than attitude set-points at 100ms, since the inner attitude PIDs run at 500hz ?
• In some tests, the logged motor PWM values (eg. motor.m1) were set to 0 despite my set-point being non-zero.
  Can I attribute this solely to the motorsCompensateBatteryVoltage() function implemented in motor.c (i.e low battery voltage), or is something else going wrong ? attached is a logfile to describe the issue
  log_sendSetpoint.txt

[hmllr]

Hi :)
First of all, I think to follow a predefined trajectory it might be a good idea to use the high level commander: https://www.bitcraze.io/documentation/repository/crazyflie-firmware/master/functional-areas/sensor-to-control/commanders_setpoints/

But to also answer your questions:

1. yes, but there are different possible modes which will lead to different configurations. Check out the c code here: https://github.com/bitcraze/crazyflie-firmware/blob/2022.12/src/modules/src/crtp_commander_rpyt.c#L120
2. x mode should be the Crazyflie 2, the Crazyflie 1 was 45 degree rotated - however, this code seems to be outdated (the firmware by now expects the values in x mode).
3. this is for historical reasons. I guess, yes, you need to invert as well ,but if you use the high level commander you don't need to worry about it.
4. yes, see the answer to 1), and yes, I'd expect a position setpoint to be more stable.
5. there seems to be another problem - like an emergency landing or similar.

Hope this helps,
Hanna

[AkashJohnSubash]

Hi Hanna,

Thanks for your response. I'm not clear how to use the HighLevelCommander with thrust set-points. I'd prefer to issue the optimized thrust commands (from an off-board control algorithm ) to the CF2.1, since this is a direct mapping between my controls and the drone.
Secondly ,my problem statement involves generating an optimal thrusts off-board on the fly, so I don't have a predefined trajectory.

1. Thanks for pointing me to this ! (:
   A follow up question would be if and how the send_setpoint() API implicitly defines roll, pitch, yaw modes ?

2. That clarifies X mode. I can skip this API, since my drone model is inline with this definition

Warm regards,
Akash

[hmllr]

Hi Akash,
Then sure, go for the send_setpoint() option :)
What do you exactly mean by roll, pitch, yaw modes? I am not sure if i understand correctly what you mean. In the cfclient you can enter some assisted modes which define in which case you end up in the c code I pointed you to. Per default your pitch/yaw/roll commands will be interpreted as angles.
Hope this helps,
Hanna