zenoh: fix default config topic type to use actual uORB topic name

[Luka-Filipovic]

Solved Problem

The zenoh bridge maps incoming ROS2 data to the wrong uORB topics when the topic name differs from the message type name.

For example:

  - topic: /fmu/in/aux_global_position
    type: px4_msgs::msg::VehicleGlobalPosition

Will publish on topic vehicle_global_position instead of aux_global_position.

Solution

In default_topics.c.em, use topic_simple (the actual uORB topic name) instead of simple_base_type (the message type name). Both are already computed by generate_dds_topics.py. For topics where the name matches the type, these are identical.

[Luka-Filipovic]

Could you have a look? @PetervdPerk-NXP

[PetervdPerk-NXP]

Could you have a look? @PetervdPerk-NXP

The config follows the following convention

topic;type;instance

This PR changes the type not the topic, could you share the pub.csv output before the patch and after?

[Luka-Filipovic]

I see your point.
I guess my problem then occurs in

PX4-Autopilot/src/modules/zenoh/zenoh_config.cpp

Line 119 in 4a0e257

strcmp(meta->o_name, datatype) == 0) {

where it searches existing uORB topics using the type name.

[PetervdPerk-NXP]

I see your point. I guess my problem then occurs in

PX4-Autopilot/src/modules/zenoh/zenoh_config.cpp

Line 119 in 4a0e257

strcmp(meta->o_name, datatype) == 0) {

where it searches existing uORB topics using the type name.

That's needed to match the type otherwise it doesn't know how serialize.
Regarding the topic you show in the original PR it seems that aux_global_position got it's own type now before it was the vehicle_global_position see #26306. So most probably when upgrading your pub.csv config didn't work because it was using the old mapping.

Easiest is to share your pub.csv config, but I think the issue you're facing is because #26306 changed the topic type and thus pub.csv would need to be regenerated to use the right topic type.

[Luka-Filipovic]

That's needed to match the type otherwise it doesn't know how serialize.

But it looks like it matches it using the topic name (meta->o_name), not the type.

aux_global_position is just an example, and with the change you linked it would work properly as it will have its own type.

I encountered the problem when I tried to add a new topic using the existing uORB message type. Here is a list of other such cases in the current yaml that I think do not work properly:

px4_msgs::msg::ConfigOverrides	config_overrides_request
px4_msgs::msg::VehicleControlMode	config_control_setpoints
px4_msgs::msg::ManualControlSetpoint	manual_control_input
px4_msgs::msg::VehicleOdometry	vehicle_mocap_odometry
px4_msgs::msg::VehicleOdometry	vehicle_visual_odometry
px4_msgs::msg::VehicleCommand	vehicle_command_mode_executor

So publishing on the ROS side on a topic /fmu/in/vehicle_command_mode_executor will publish on vehicle_command in px4 uorb instead of vehicle_command_mode_executor that is expected in commander.
There are more topics that are not named as their message type that are not in the yaml, they are easy to find by searching # TOPICS in uORB message definitions.

My pub and sub csvs are trivial, with the change they are just:
/fmu/out/topic_name;topic_name;0
And without the change:
/fmu/out/topic_name;type_name;0

[PetervdPerk-NXP]

That's needed to match the type otherwise it doesn't know how serialize.

But it looks like it matches it using the topic name (meta->o_name), not the type.

aux_global_position is just an example, and with the change you linked it would work properly as it will have its own type.

I encountered the problem when I tried to add a new topic using the existing uORB message type. Here is a list of other such cases in the current yaml that I think do not work properly:

px4_msgs::msg::ConfigOverrides	config_overrides_request
px4_msgs::msg::VehicleControlMode	config_control_setpoints
px4_msgs::msg::ManualControlSetpoint	manual_control_input
px4_msgs::msg::VehicleOdometry	vehicle_mocap_odometry
px4_msgs::msg::VehicleOdometry	vehicle_visual_odometry
px4_msgs::msg::VehicleCommand	vehicle_command_mode_executor

So publishing on the ROS side on a topic /fmu/in/vehicle_command_mode_executor will publish on vehicle_command in px4 uorb instead of vehicle_command_mode_executor that is expected in commander. There are more topics that are not named as their message type that are not in the yaml, they are easy to find by searching # TOPICS in uORB message definitions.

My pub and sub csvs are trivial, with the change they are just: /fmu/out/topic_name;topic_name;0 And without the change: /fmu/out/topic_name;type_name;0

Okay but can you just share the output to confirm it's okay with the patch.
The yaml becomes csv, which gets parsed by zenoh config that you can inspect using zenoh config. Can you just share the actual output of that so I can confirm this patch fixes it.

[Luka-Filipovic]

before:
pub.csv
sub.csv
zenoh_config.txt

---

after:
pub.csv
sub.csv
zenoh_config.txt

[PetervdPerk-NXP]

before: pub.csv sub.csv zenoh_config.txt

after: pub.csv sub.csv zenoh_config.txt

Thanks LGTM