How to use this repositories to implement a mc_MPC_attitude_controller in ROS2 ?

[EchoSongguangyi]

I aim to implement a Model Predictive Control (MPC) attitude controller (including angular rate control) for a multicopter. The controller will be deployed on a companion computer running ROS2, where it will compute torque and thrust commands and transmit them to the Pixhawk flight controller. The Pixhawk will then handle the mixer logic to generate motor signals.

Within the ROS2 framework, the controller’s inputs will include:

• Current attitude and angular rates (measured states)
• Desired attitude and angular rates (reference commands)

After computation by the MPC controller, the outputs (torque and thrust) will be sent to the Pixhawk.

In this architecture, the Pixhawk operates in its stabilized mode (i.e., without an outer position control loop), allowing me to evaluate the performance of the custom attitude controller in isolation.

Questions:

1. Is this approach feasible for testing and validating a standalone attitude controller?
2. How to use this repositories to implement a mc_MPC_attitude_controller in ROS2 ?

[bkueng]

Hi

Replacing a controller with an external one on ROS isn't directly possible yet. However if you create the setpoints yourself as well (e.g. by listening to the RC input or generating some pattern that you can use to compare), you can implement the controller as a mode which outputs the torque and thrust. You will have to create a setpoint class that publishes these messages:

• https://github.com/PX4/PX4-Autopilot/blob/main/msg/VehicleThrustSetpoint.msg
• https://github.com/PX4/PX4-Autopilot/blob/main/msg/VehicleTorqueSetpoint.msg

Note that if you want to send such low-level commands to an MC, the latency and update rates will be very important. You will have to evaluate that first. When I briefly tested that a while ago, I got to a round-trip time of ~10ms. Unless you have a big vehicle this will likely be too high for good performance.

[EchoSongguangyi]

Hi

Replacing a controller with an external one on ROS isn't directly possible yet. However if you create the setpoints yourself as well (e.g. by listening to the RC input or generating some pattern that you can use to compare), you can implement the controller as a mode which outputs the torque and thrust. You will have to create a setpoint class that publishes these messages:

• https://github.com/PX4/PX4-Autopilot/blob/main/msg/VehicleThrustSetpoint.msg
• https://github.com/PX4/PX4-Autopilot/blob/main/msg/VehicleTorqueSetpoint.msg

Note that if you want to send such low-level commands to an MC, the latency and update rates will be very important. You will have to evaluate that first. When I briefly tested that a while ago, I got to a round-trip time of ~10ms. Unless you have a big vehicle this will likely be too high for good performance.

Thank you very much for your response. You're absolutely right; when sending low-level commands via ROS, it’s important to consider the impact of latency, which is indeed the biggest issue with this method.

[EchoSongguangyi]

Hi

Replacing a controller with an external one on ROS isn't directly possible yet. However if you create the setpoints yourself as well (e.g. by listening to the RC input or generating some pattern that you can use to compare), you can implement the controller as a mode which outputs the torque and thrust. You will have to create a setpoint class that publishes these messages:

• https://github.com/PX4/PX4-Autopilot/blob/main/msg/VehicleThrustSetpoint.msg
• https://github.com/PX4/PX4-Autopilot/blob/main/msg/VehicleTorqueSetpoint.msg

Note that if you want to send such low-level commands to an MC, the latency and update rates will be very important. You will have to evaluate that first. When I briefly tested that a while ago, I got to a round-trip time of ~10ms. Unless you have a big vehicle this will likely be too high for good performance.

Hi,
Sorry to bother you again.
I'd like to know how you conducted your previous tests—what was the operating frequency of the onboard computer?
What was the data transmission method between the onboard computer and the Pixhawk?
How did you measure the output latency?
And was your onboard computer running ROS during the tests?

[bkueng]

I measured the time it takes to send a VehicleCommand from a ROS application to PX4, where I added some code to immediately reply the command, and then checked the arrival in the ROS app. It used an ethernet connection. The onboard computer was an IMX-8, but that should not matter much if not under load.
The PX4 uxrce dds bridge client adds some latency by how it is implemented. I can give you some pointers if you want to look into that.
What numbers do you get?

[EchoSongguangyi]

I measured the time it takes to send a VehicleCommand from a ROS application to PX4, where I added some code to immediately reply the command, and then checked the arrival in the ROS app. It used an ethernet connection. The onboard computer was an IMX-8, but that should not matter much if not under load. The PX4 uxrce dds bridge client adds some latency by how it is implemented. I can give you some pointers if you want to look into that. What numbers do you get?

Thank you very much for your reply.
I still want to try running the attitude control algorithm on a Raspberry Pi 4B and sending torque commands to the Pixhawk 6X (Rev3) via Ethernet. I’ve just completed the basic setup and successfully run the offboard control example from the PX4 User Guide.

From what I understand, Ethernet communication should be fast (100 Mbps), and the onboard computer’s processing speed should be sufficient (since PX4’s attitude control typically runs at 250 Hz?). So why is there still noticeable latency in transmission? Are there any ways to mitigate this issue now?

Could you provide specific guidance on how to implement the attitude controller on the onboard computer and send torque commands to the Pixhawk?

[bkueng]

From what I understand, Ethernet communication should be fast (100 Mbps), and the onboard computer’s processing speed should be sufficient (since PX4’s attitude control typically runs at 250 Hz?). So why is there still noticeable latency in transmission? Are there any ways to mitigate this issue now?

Yes it's less of a CPU/processing limitation rather than implementation factors. Mainly these 2:

• buffering
• scheduling (at fixed frequency)

This is generally done to reduce CPU load. But as I wrote, I have not gone through the details. I'm sure it can be improved but it will require some effort.

Could you provide specific guidance on how to implement the attitude controller on the onboard computer and send torque commands to the Pixhawk?

It should be enough from the documentation and the links I shared above to get you started. If you have specific questions, you can always ask, but I'm afraid I don't have time to do much more than that.