State published by EGM is unitialized until EGM is started

[BenArtes]

joint_states are published by RWS and EGM. EGM is preferable because it is published significantly more often than RWS, but EGM isn't updated unless EGM is started on the robot.

I tried remapping both /rws/joint_states and /egm/joint_states to a single topic but A) there might be inconsistencies between the published joint_states related to latency and B) EGM is uninitialized until EGM is started on the robot.

I can easily write a node for my robot that pulls in both topics and uses /egm/egm_states to determine which topic to use or forward, but maybe this functionality should be part of egm_state_controller or abb_robot_driver?

[gavanderhoorn]

Merging those states was not made part of the driver, as the regular joint_state_publisher supports the functionality you describe.

By setting the source_list parameter to the topics you mention you should be able to get it to merge those into a single message which contains the latest state it has received. Refer to the documentation. I haven't checked recently, but IIRC, it should be able to deal with out-of-order messages.

And personally I prefer to avoid using RWS for anything other than coordination type tasks. The retrieval of the joint state was only added because it is possible, and, as you noticed, you would not have any info otherwise unless EGM is started.

That's unfortunately just how EGM works; it doesn't really have a read-only mode, or at least not one that can be used without explicitly starting an EGM session on the controller.

Note also btw that "there might be inconsistencies due to latency" is technically not really a 'problem' for this driver. Downstream consumers should not assume messages over different topics are totally ordered (ie: chronologically across different channels). That's not an opinion held by the developers of abb_robot_driver btw, but a characteristic of ROS/JointState topics.

While most systems are small, and include only a single JointState publisher on a single topic where consumers can just assume "the latest received JointState message is the current state of the system", conceptually that's not correct.

Similar to TF, consumers are expected to build up their own internal representation of whatever "the current state" means for them. TF has a client library which takes care of that for you. Unfortunately no such convenience exists for JointState topics.

The joint_state_publisher can do it (see the mentioned source_list), but it's a separate node.