Sending roll/pitch/yaw/thrust in High-Level Mode

[mouhyemen]

I am interested in using the CF firmware logic for calculating setpoints and the roll/pitch/yaw/thrust computed by the controller to be passed back to the CF as send_setpoint(roll, pitch, yaw, thrust).

Basically, the same roll/pitch/yaw/thrust computed by the firmware is sent back to the drone from the remote/PC side.

1. I already made firmware changes where I have 2 setpoint_t and control_t structs. One pair of setpoint_t and control_t is responsible for calculating the setpoint and controller inputs. The other pair is used for actuation.
2. I have a client script that reads roll/pitch/yaw/thrust in callback routine over a ROS topic using crazyflie_ros.
3. I then send the roll/pitch/yaw/thrust in /cmd_vel topic using crazyflie_ros to the drone.

Point 3 is where things get sketchy for me.

Since send_setpoint(roll, pitch, yaw/yawRate, thrust) is taken in a setPointQueue, I want to make sure that the setpoint_t used for calculating in high-level mode does not interfere with the setpoint_t struct used for actuation. How can I do that? Does my logic make sense?

[kristoffer]

If I understand correctly you want to break the information flow after the controller, send it to your PC (for processing?), send it back to the Crazyflie to be used by the powerDistribution() function?

You want two flows of information from your PC to the Crazyflie: one for the normal set points and a second one for controlling the motors.
I see two ways of doing this, one quick and dirty, and a cleaner one.

Let's start by looking at how the information is routed in the Crazyflie. The CRTP protocol has a feature called ports that is used for coarse grained routing. There is a list of ports here https://github.com/bitcraze/crazyflie-f ... .h#L39-L50. If you search for the port names in the firmware you will find examples of how to register a callback and where the set points are handled.

As you can see there are a couple of different ports for set points already, and if you want to you can add a new one for your second flow, this is the clean solution.
The quick and dirty option is to use one type of set point for your first flow and re-use another existing one for your second. This way you will end up in two different branches in the firmware code and it should be possible to populate your structs like you want to.

I think you might run into issues with latency in the control loop, but why not try?