Migration from RTPS to DDS for multiple drones on SITL_gazebo

[mohamed1915]

Hello,

I have to migrate this code that used to run the old version of PX4 using RTPS to the new version using DDS. I made changes to the topics and paths names to accommodate the change which permits the spawning the drones in the simulation. However, I can't get the drones to arm, I think because the communication is not established. The important parts of the code are as follows:

Launch the PX4 for each drone: ../bin/px4 -i $N -d "$build_path/etc" -s etc/init.d-posix/rcS >out.log 2>err.log &

Connect the PX4 to the gazebo model python3 ${src\_path}/Tools/simulation/gazebo-classic/sitl\_gazebo-classic/scripts/jinja\_gen.py ${src\_path}/Tools/simulation/gazebo-classic/sitl\_gazebo-classic/models/${MODEL}/${MODEL}.sdf.jinja ${src\_path}/Tools/simulation/gazebo-classic/sitl\_gazebo-classic --mavlink\_tcp\_port $((4560+${N})) --mavlink\_udp\_port $((14560+${N})) --mavlink\_id $((1+${N})) --gst\_udp\_port $((5600+${N})) --video\_uri $((5600+${N})) --mavlink\_cam\_udp\_port $((14530+${N})) --output-file /tmp/${MODEL}\_${N}.sdf >> /dev/null

Launching the Micro ros agent: ExecuteProcess(cmd=['micro-ros-agent', 'udp4' , '--port','8888']))

Here is the list of topics for one drone: /cancel_goal /clock /exploration_finished /fmu/in/offboard_control_mode /fmu/in/timesync /fmu/in/trajectory_setpoint /fmu/in/vehicle_command /fmu/out/timesync /fmu/out/vehicle_control_mode /fmu/out/vehicle_status /goal_reached /map_sharing /metrics /next_waypoint /parameter_events /performance_metrics /rosout /uav_0/camera/camera_info /uav_0/camera/image_raw /uav_0/debugger/trajectory /uav_0/gps /uav_0/imu /uav_0/p3d /uav_0/twist /uav_0/uav_exploration_pause_topic /uav_0/uav_exploration_resume_topic The issue is I don't get an error but the drones don't arm, and the the /fmu/out/ topics don't publish anything.

Is there a way to debug the communication between the PX4 and gazebo/ROS2? do you have an idea of what might have cause this issue or things I can try to understand more? @Jaeyoung-Lim ?

Thanks,

[mohamed1915]

Thank you @beniaminopozzan for your response, the solution you propose has helped create multiple drones in the Offboard example. However in my code I tried with just one drone, and the the topics /fmu/out/.. are all silent. Do you have a proposition on what can be the issue or a way to debug the communication? Thank you,

[erisevve]

I'm also having issues using multiple UAVs in offboard mode for SITL using dds. Per the pull request from @beniaminopozzan I have made changes to the rcS file so that each agent receives a unique _XRCE_DDSKEY and namespace.

Using a configuration with a single bridge and two agents, I'm able to see unique and namespaced topics from them, with correct information (i.e _/px41/.. and _/px42/..) . However, I'm only able to arm the first agent (does not matter in which order I send the arm commands, only the agent with the lowest instance number arms). Thus, I'm able to namespace and run a single agent correctly, but any additional ones do not listen to any of the data published over the bridge (although, as I said, they do publish the correct data over it, such as odometry data). Both agents have separate namespaced Offboard controllers running and continuously publishing the required information to enter offboard mode and arm.

Note that I am not using the sitl_multiple_run.sh script since I'd like a little bit more control over the process (with the obvious drawback that it is more difficult to get working ;) ).

I have tried both using different and the same UDP-ports on the agents without any difference. Is there anything obvious that I am missing?

[beniaminopozzan]

@erisevve thanks for your feedback! I'll look into that!

@mohamed1915 as I wrote in the PR, it you apply it you have to use the namespace /px4_0/fmu/ even for single agent simulation

[beniaminopozzan]

@erisevve

At first I thought it was some issue with not having manual control / QGC active, ecc. But it was not that (nevertheless, make sure that everything is OK on that side).

The issue is related instead with the hardcoded target_system=1 and target_component=1 in the vehicle_command message:

https://github.com/PX4/px4_ros_com/blob/af846cbeecdb147d4062f7c928ea3fc19ae60263/src/examples/offboard/offboard_control.cpp#L175-L177

PX4 will accept only

• commands directed to the right target and target component, or
• broadcasted commands.

https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/Commander.cpp#L679-L685 . Therefore, only the first vehicle responds to the arming and mode change message.

You can set target_system=0 and mark the message as broadcast message. This is not a problem as the message will be sent only to the right vehicle thanks to the namespaces. Or, you can make target_system a variable / parameter and set it when you start the ros node.

This is the patch I used to fix the issue. It also changes the topic names such that they don't use the global namespace. multi_vehicle.patch.txt

Just to be precise, regarding

Using a configuration with a single bridge and two agents,

You are referring to single bridge, two clients as the agent is the one on the companion computer / ROS side.

[erisevve]

@beniaminopozzan

Thank you for your thorough answer! You were absolutely correct, changing __target_system=0__ solved the problem. You are truly a lifesaver!

You are referring to single bridge, two clients as the agent is the one on the companion computer / ROS side.

Yes, you are correct! Still haven't familiarized myself properly with the terminology!

[beniaminopozzan]

After discussing it in discord https://discord.com/channels/1022170275984457759/1073439624665518120/1073638714615537665 broadcast commands should be used only when true broadcast is wanted. The correct solution is to specify the right target_system depending on the vehicle ID.