jhu-cisst / cisst-ros Goto Github PK

Would it be possible to add the 'companion' feature to Addtf2BroadcasterFromCommandRead? Anton and I discussed this in a meeting.

This would have a name such as: Addtf2ListenerToCommandWrite
You would input the frame names as they appear in ROS, and if they exist, the tf2 Transform would be converted to into a prmPositionCartesianGet

The goal is to make it clear how to connect to a provided vs a required interface. Maybe add an illustration/graph to illustrate all examples.

In general, most ROS to cisstParameterTypes don't update the extra data:

• Valid flag
• Timestamp if the ROS payload has a header

We do update the timestamps the other way around, i.e. from cisst to ROS. See quick fix for specific case: 2eefd8d

Based on @brendanburkhart pull request, we should use modern C++ to automatically determine how to convert the header part of cisst and ROS data types. In general, cisst potentially has:

• timestamp
• valid flag
• reference frame
• moving frame
  ROS potentially has:
• header/timestamp
• header/frame_id
• child_id
  Since the conversion for these fields can be performed automatically, it should be done outside mtsROSToCISST and mtsCISSTToROS. Note that the mtsCISSTToROS should return a boolean based or the value of IsValid or absence of method IsValid. Once implemented, this approach should be ported to the ROS 2 bridge.

It would be useful to extend the crtk_cisst_ros_bridge to also allow for easy bridging of required interfaces, similar to the current one-liners for provided interfaces we have currently: (bridge_interface_provided and bridge_all_interface_provided)

I would be able to use this immediately in my work (though I can work without it just fine for now), and would be willing to help with testing and development to the extent that I would be useful. I think it would greatly increase the usability of the cisst-ros bridge for a lot of users and encourage the use of CRTK conventions, both of which are really good things from my perspective.

I understand there would be some challenges regarding handling 'optional' items in cisst required interfaces (i.e. do you try to connect to a ROS topic if optional?, Do you check to see if it exists first?, Do you need a configuration file for the user to tell you what optional ones should be included?, etc.). I'm happy to participate in any brainstorming regarding how to handle these issues.

I spoke with @adeguet1 regarding this, tagging you here for your visibility.

Thanks!

For state topics, we should use latching mode enabled.
Use Case:
Lets say the robot is already up and running and has been homed already, we now run the user application in ROS. In the user application if we subscribe to topic /current_state, we wouldn't know what state is in as this topic is active only when the state changes. Having latched information would be helpful in case we want to know what the last state was.