Should thermocouple package use sensor_msgs/Temperature instead of float64? about phidgets_drivers

[clalancette]

For ROS2 rolling, we could even directly remove the old topic, right? My understanding is that breaking changes in rolling are okay, that's what it's for, correct?

That is an option, yes. Though if we do that directly, it doesn't give downstream users any time to make the transition; they'll just break when they update next.

My suggestion for ROS 2 is to do the following:

1. Create a new branch for Rolling. Leave the foxy and galactic branches as-is.
2. Develop a patch for Rolling where we add in the new topic, publishing sensor_msgs/msg/Temperature. Make sure to document it, and that the old topic is deprecated.
3. Review and merge that patch into Rolling.
4. Release that code into Rolling.
5. Backport the patch from step 2 into Galactic and Foxy (this is an addition, so it should be fine for those).
6. When Humble branches off (in about two weeks), make a new humble branch.
7. At that point, we can remove the old float64 topic from Rolling, since everyone on Foxy, Galactic, and Humble have both the old and new topic available.

Does that make sense?

[mintar]

Yes, sensor_msgs/Temperature is a much better message type, and we should absolutely use it. The sensor doesn't output variance, so we don't have any use for that field, but timestamping is very useful and one should always use specific message types if possible.

You are right about the breaking change however. ROS uses a Tick-Tock model, so the proper way would be to add a new output topic of type sensor_msgs/Temperature while keeping the float64 topic, and deprecate the float64 topic. Then on the next ROS release the float64 topic can be removed.

This is a bit problematic for ROS1 noetic, because there won't be a next ROS release (at least not from OSRF, it would have to be community-supported). But I guess we should still stick to the Tick-Tock model. @clalancette , any thoughts?

[clalancette]

This is a bit problematic for ROS1 noetic, because there won't be a next ROS release (at least not from OSRF, it would have to be community-supported). But I guess we should still stick to the Tick-Tock model. @clalancette , any thoughts?

Agreed with everything you've said. For Noetic, my suggestion is to just add a new topic that publishes the new sensor_msgs/Temperature; that will just live forever. For ROS 2, we can add the same new topic, with the view towards eventually removing the old topic.

[mintar]

For ROS2 rolling, we could even directly remove the old topic, right? My understanding is that breaking changes in rolling are okay, that's what it's for, correct?

[mintar]

Yeah, it's not nice to sneak in breaking changes so close to the Humble release, so I agree.

Now all we need is somebody to do it! @J-C-Haley, are you up for it? It's okay if you only do the Noetic part if you are not a ROS2 user yet.

[J-C-Haley]

Thanks for explaining @clalancette! I don't use ROS 2 yet, I can add a the topic into the noetic.

As part of this, I'm want to make it to read & publish from all four thermocouples on a TMP1101_1, can anyone can test against a single thermocouple phidget?

[mintar]

Unfortunately, I don't have any thermocouple phidgets, so I can't test this.

[J-C-Haley]

Ok, added a PR for the noetic branch! There will now be a temperature_{channel} topic, which takes a channel parameter from launch and now allows for multiple thermocouples on the same reader.

If it's fine with you, I'll leave the patching & merging on other branches to someone with more git experience?