My current understanding is the following:

- For the various set point modes available (position, velocity, attitude), the commanderGetSetpoint(&setpoint, &state) computes the necessary
*setpoint*needed to execute a flight behavior.

- The underlying controller (PID/Mellinger) then generates necessary control inputs called
*control*using controller(&control, &setpoint, &sensorData, &state, tick) to track the*setpoint*above.

- Whether one uses high-level mode or low-level mode, the
*setpoint*is always computed for the underlying controller to track using*control*.

If so, I am using the high-level commander mode (using crazyflie_ros), to takeOff, goTo, land etc. I am interested in seeing what setpoints are generated that the underlying controller is tracking.

For doing so, I added the following in the firmware:

Code: Select all

```
LOG_GROUP_START(stabilizer)
LOG_ADD(LOG_FLOAT, roll, &state.attitude.roll)
LOG_ADD(LOG_FLOAT, pitch, &state.attitude.pitch)
LOG_ADD(LOG_FLOAT, yaw, &state.attitude.yaw)
LOG_ADD(LOG_FLOAT, thrust, &control.thrust)
LOG_ADD(LOG_FLOAT, rollSetpoint, &setpoint.attitude.roll)
LOG_ADD(LOG_FLOAT, pitchSetpoint, &setpoint.attitude.pitch)
LOG_ADD(LOG_FLOAT, yawSetpoint, &setpoint.attitude.yaw)
LOG_ADD(LOG_FLOAT, thrustSetpoint, &setpoint.thrust)
LOG_GROUP_STOP(stabilizer)
```

The thrustSetpoint is zero. Why would that be? Shouldn't it be around 30000-45000 thrust units? What log should I pulling to see non-zero thrust?

The roll/pitchSetpoints are zero. That is also strange, because I tell the drone to go forward, hence a non-zero pitch setpoint should be induced for enabling forward flight.

I am ultimately interested in logging the setpoint (roll/pitch/yaw/thrust) that the drone is acting upon.