Unexpected topic ID on publishing CommanderState and VehicleCommand

ROS / MAVROS / MicroDDS
1

Hi!

Currently I am trying to switch the state of the px4 to offboard. I do so by activating the CommanderState receive: true in the uorb_rtps_message_idl.yaml. Then I use this script to publish the message over fastRTPS:

   auto timer_callback =	[this]()->void
    		{
    			if(i_setpoint_ < 100)
    			{
    				auto position_setpoint = px4_msgs::msg::PositionSetpoint();
    				position_setpoint.timestamp = timestamp_;
    				position_setpoint.x = 0.0;
    				position_setpoint.y = 0.0;
    				position_setpoint.z = 0.0;

				std::cout << "setpoint iteration: " << i_setpoint_ << std::endl;
				this->setpoint_publisher_->publish(position_setpoint);
				i_setpoint_++;
			}
			else
			{
				if (!switched_to_offboard)
				{
					auto commander_state = px4_msgs::msg::CommanderState();
					commander_state.timestamp = timestamp_;
					commander_state.main_state = px4_msgs::msg::CommanderState::MAIN_STATE_OFFBOARD;
					this->commander_state_publisher_->publish(commander_state);
					std::cout << "Switched to offboard control mode." << std::endl;
					switched_to_offboard = true;
				}
				else
				{
					std::cout << "nothing to do" << std::endl;
				}
			}
		};

However the mavlink shell (sometimes) gives me the following warning:

nsh> WARN [micrortps_client] Unexpected topic ID

If I can listen to the message through ros2 topic echo, I see:

$ ros2 topic echo /CommanderState_PubSubTopic
timestamp: 0
main_state: 7

If I use the listener in the mavlink shell I get the following result:

nsh> listener commander_state

TOPIC: commander_state
commander_state_s
timestamp: 1104099513 (0.225175 seconds ago)
main_state: 0

Could somebody please elaborate why the topic ID is unexpected (this doesn’t always happen, sometimes it doesn’t give any feedback at all) and why it is not reacting? Since MAVROS uses the same topic (commander_state for mode switching and vehicle_command for arming) I am unsure why the micrortps_client is rejecting the input of this topic. I have the same problem for arming the px4.

Cheers!

2

Did you solve this issue?

3

No. I heard they have to update the way to publish setpoints inside the uorb trees since currently it is not working as expected for me. There are some bugs in the setpoint triplet and eventually when those are fixed the system is still not listening to the setpoints given. I decided to use mavros instead and to give this another go in half a year.

4

@EdwinvanEmmerik in both sides of the bridge? You need to do that also on the Firmware side, otherwise you will get that unknown ID warning - check https://github.com/PX4/PX4-Autopilot/blob/master/msg/tools/uorb_rtps_message_ids.yaml.

Different subjects - MAVROS uses MAVLink, while with this bridge you directly communicate with uORB. Which also means you need to understand a bit better of how the internals of PX4 work (which in the other hand MAVROS already takes care of because it uses MAVLink). This is starting to be covered though - Restructure offboard control example to make it functional by TSC21 · Pull Request #62 · PX4/px4_ros_com · GitHub

1 Like
5

I am running into a similar issue, when trying to run the simple offboard_control.cpp file found here: http://docs.px4.io/master/en/ros/ros2_offboard_control.html : I can run sensor_combined_listener with no issues, but when I attempt to run offboard_control, i get : WARN [micrortps_client] Unexpected Topic ID
I have checked that both the firmware and px4_ros_com yaml files and both have offboard_control_mode & position_setpoint_triplet to be received as true. How else can i verify which ID’s are unexpected, and why?