Best way to get full state estimate when running offboard closed loop control

[Cafolkes]

Thank you for your great work with the platform!

I am planning to do offboard control and sending commands to the crazyflie using the cmdVel method in the Python API, i.e. doing position control by sending desired roll, pitch, yaw rate, thrust. Some of the controllers I am working with require the current full state at evaluation (position, attitude, linear velocity, angular velocity). I want to run the controllers at 50-100 hz.

What is the best way to get the full state estimate on the offboard computer using the Python API? Currently, I am using the log interface by setting up variables to log in the launch file (as outlined in hover_swarm.launch) and then subscribing to the log topic to get the current fused state estimate. However, I suspect that I am having some delay issues and wanted to ask the community if there is another way of doing this that might work better.

[jpreiss]

I don't think there is a better way (see #397 for a possibly related issue). The uncompressed full state estimate takes up more than one radio packet, how are you dealing with that?

I think it will be hard to get good performance from offboard control, especially with multiple CFs per radio. Have you considered implementing your controller in the firmware?

[Cafolkes]

Thank you for the quick response!

I have tried both using the compressed state, and by using 2 different log topics and having the callback update the part of the state whenever a package is received on either topic. I do not observe a noticeable difference in the behavior.

I am running one cf per radio and I don't think implementing the controller onboard in the firmware is really feasible for what we are planning unfortunately. I will try to work on additional improvements and see how good performance we can get.

[jpreiss]

Disregard my compression comment, I forgot compressed state logging was already implemented.

ROS overhead might be a factor. I have not tried to measure that before. You could do it by changing the cmdVel topic from geometry_msgs/Twist to geometry_msgs/TwistStamped but instead of the current time, use the stamp of the tf pose to which the controller is responding. Then you can measure the round trip time in crazyswarm_server. This will also include the overhead from executing your control algorithm.

[jpreiss]

The radio round trip is also a latency source, but it shouldn't be more than a few milliseconds (see the Crazyswarm paper for experiments).

[zhoukeheng]

@Cafolkes
Hi, I am working for the same thing as you. My PID offboard position controller works at about 75HZ. However, when I send the desired roll, pitch, yaw rate, thrust to the attitude controller, the Crazyflie cannot be stabled even my reference target is only a simple specific altitude. The parameter of the PID is copied from the PID parameter in the firmware. The position and velocity information is obtained by subscribing the log1 topic.
I wonder currently whether your offboard controller can work properly. If it can work, could you tell me how to achieve it. Thanks

[Cafolkes]

@zhoukeheng
Hi, I am sorry for the late reply. I have been busy with a different project and didn't get to test my final setup until now. Have you managed to make your controller work?

I have a PID position controller that works well. I have been running it at 50hz and it has reliably stabilized the system when running a single crazyflie on each radio. I get the position and velocity as you describe at 100hz and changed the parameters #397 to make sure the state is updated frequently enough. I have a slightly different controller structure so had to tune the gains but other than that the setup is fairly out of the box I believe.

Let me know if you are still having issues and I can try to give more detailed explanations.