QoS for Joint State Monitoring

[acbuynak]

Not really an Issue, but a discussion question.

I noticed that the joint_state monitoring is coded in as SensorData (best effort & volatile) which I think makes sense with it being a hardware sensor.. versus say the default QoS. But I can also see the case where it would be advantageous to let the subscriber QoS be automatically picked based on the upstream or at least parameterize this for dev's.

tesseract_ros2/tesseract_monitoring/src/current_state_monitor.cpp

Lines 112 to 116 in b16609c

	joint_state_subscriber_ = node_->create_subscription<sensor_msgs::msg::JointState>(
	joint_states_topic,
	rclcpp::SensorDataQoS(),
	std::bind(&CurrentStateMonitor::jointStateCallback, this, std::placeholders::_1));
	}

I found myself manually changing this today to work with a joint_state publisher I had set to a Reliable durability, hence the note. Obligatory link to QoS Concepts in the ROS docs.

Feel free to let me know if I'm totally off base here.

[gavanderhoorn]

at least parameterize this for dev's.

I can't find the API / docs for it right now, but ROS 2 has support for QoS overrides which don't require source-level changes.

The subscriber should be created with a special, sentinel, QoS profile and the rest (ie: CLA parsing, forwarding the settings to the subscriber ctor, etc) should be taken care of.