[joint_state_controller] Allow to publish joints not present in RobotHW

[adolfo-rt]

Inspired by ros-simulation/gazebo_ros_pkgs#141.

Robots sometimes have joints that can't be controlled, or don't even have sensing devices like encoders. A typical example would be a non-driven caster wheel.

In simulated scenarios the state of such joints can be reconstructed as one can add sensors for free, but this can be a problem with real hardware. If no state is available for these joints, ROS tools like tf and the Rviz plugins that depend on it will fail to reconstruct parts of the robot.

One possibility to address this issue would be to extend the joint_state_controller to publish additional joints with a predefined constant value. A controller configuration file could look like so:

joint_state_controller:
  type: joint_state_controller/JointStateController
  publish_rate: 50

  # This is the new part that this ticket would address. It's optional
  extra_joints:
    foo_joint: 0.0 # Name: position
    bar_joint: 0.5

Implementation-wise, one would have to take care that there is no overlap between the robot joints and the extra ones.

[davetcoleman]

Its not clear to me why one would want to publish simulated joints that do not have sensing in the actual hardware. Is this just for visualization in Rviz?

Also, the proposed Gazebo plugin allows for non-fixed joints to be published, even if they are uncontrollable. Seems to me like this feature is already covered with the joint_state_controller.

[adolfo-rt]

Its not clear to me why one would want to publish simulated joints that do not have sensing in the actual hardware. Is this just for visualization in Rviz?

An unactuated and unsesorized caster is a good example. In simulation you don't want the caster joints to be fixed, as they are important to properly simulate a mobile base's dynamics, so you model the joints as revolute in your URDF. Gazebo-wise, you can get their state if you want, but in real hardware, you don't have this info.

Example scenario where this is bad (I'm sure there are more): Rviz plugins like RobotModel parse the URDF and know about the caster joints and links, but can't position them wrt the robot, because there is no joint_states, hence no tf information for them. You end up seeing white caster geometries piled up at the Rviz fixed frame origin. Not nice.

[davetcoleman]

There seem to be two features being discussed, correct me if I'm wrong:

• In simulation with Gazebo, publish the simulated joint values of non-sensed joints
• In hardware, publish dummy joint values of non-sensed joints

This seems to create a discontinuity between available information in simulation and hardware, so I'm not sure why we'd want Gazebo to publish non-sensed joints.

[adolfo-rt]

The actual reason why you would want to to publish dummy joints are many, and we've only discussed a few. Another one might be that you're assembling a robot, which is not yet complete, or an existing robot where a subassembly (an arm) has been temporarily removed.

These usecases don't necessarily have to be solved with dummy joints in the joint_state_publisher, but it's a valid option. We've faced all of the examples mentioned in this thread, and so far we've gone about them by configuring our custom RobotHW implementation in one way or another.

Coming back to simulation, I agree that many cases would benefit from consistency between hardware and simulation; but having a simulation with extra sensing can allow you to compute and monitor metrics that you would otherwise be unable to. Still, when simulation and hardware are consistent with each other, this means that you would use the dummy joints in both deployment scenarios.

[davetcoleman]

I shall capitulate.

[maxbader]

Hi
I actually wrote the gazebo plug-in because there where no alternatives, please correct me if I am wrong. If data is available I like to use it, and if it is just for visualization and visualization is important it gives me also a feedback about the simulation, e.g I can see the caster wheel is working correct.
If the Simulation has only an interface to data which is available in real live, I don't need that simulator.
I am not going to capitulate :-) because, if Adolfo is happy with fixed joint values he can still use a static plubisher or even a rostopic pub command like:
rostopic pub joint_states sensor_msgs/JointState '{header: {stamp: now, frame_id: ""}, name: ["a", "b"], position: [0, 0], velocity:[], effort: []}'

Greetings

[mikepurvis]

Did anything come of this? I'm coming to a situation where it would be really appreciated to have joint state published for a non-driven joint.

[maxbader]

Hi Mike
Have a look at the pioneer3dx_plugins.xml.
My non-driven joint state publisher was integrated and it is working.

Greetings

[mikepurvis]

I believe that's only publishing the joint state in simulation— in my case, I actually already have a plugin providing simulated behaviour to the plugin, what I want is for the joint state to be published as fixed on the real robot, for visualization purposes.

As above, I can just spawn a rostopic pub (or equivalent) which supplies the zero joint state on the real robot, but that seems like a hack, when the rest of the joint states are coming from joint_state_controller.

[maxbader]

Hi Mike
So what you like to have has nothing do do with gazebo? You want non actuated joint states of a real robot published for rviz?
For that you can use "tf static_transform_publisher" or a simple python script.
Sorry if I misunderstood your question.

[bmagyar]

Your solution provides the transforms in tf, while Mike seems to have a need for the joint-wise info in the joint_states too.

[adolfo-rt]

@mikepurvis. If you want to publish dummy state information for joints that have no sensors in real hardware, I see two solutions that would yield a single joint_states topic:

• Add custom logic in your (real robot) RobotHW implementation for creating raw data and registering handles for the sensorless joints. This is a hardcoded, robot-specific approach.
• Address this issue by extending the joint_state_controller. This is a more general approach that will work for all robots, and is less intrusive, as it only involves modifying configuration files (apart from a modified controller implementation, of course).

On this last alternative, an interesting feature would be that if the specified joints turn out to be in RobotHW, then those values would be used. In this way, you don't need to write two separate configuration files for simulation and reality. The same file would work for both scenarios.

[UltronDestroyer]

@adolfo-rt

Did anything ever come from this? I am interested in using ROS control for casters which will publish the joint state of the casters. An alternative is to use static transforms, but would prefer to keep the code elegant.

[adolfo-rt]

It's something in the TODO list, but has low priority. I believe this feature is not hard to implement and test, so if you want to give it a go I can help review the design and implementation.

[adolfo-rt]

Please review #87. I had need of this enhancement and implemented it. A nice side-effect is that the JointStateController, likely the most used controller in all of ros_controllers is now fully tested.

[carlosjoserg]

It is optional, but in any case, I would expect that anything coming from a state controller is measured (reading from gazebo is a measure to me, and I wouldn't mind discrepancy between reality and simulation since they might serve different purposes), and the added feature allows to override that idea.

Out of curiosity, what's wrong with the rostopic pub and the non-driven joint state publisher plugin in the real and simulated scenario, respectively?

I don't see it as a hack but as a solution due to the lack of sensors in a movable part, and benefit from the simulation where sensors are free. I would also be glad to not waste resources in fast publishing something that has a fixed value and have a clear separation of topics containing measured (RT freq), fixed (low freq) and merged values, where the merge values can be used for visualization at any other freq.

[adolfo-rt]

It is optional, but in any case, I would expect that anything coming from a state controller is measured (reading from gazebo is a measure to me, and I wouldn't mind discrepancy between reality and simulation since they might serve different purposes), and the added feature allows to override that idea.

You can have different joint_state_controller configurations for real and simulated deployments. In simulation, you would have the additional 'free sensors', and no extra_joints, while in real deployments you would use the extra_joints.

Out of curiosity, what's wrong with the rostopic pub and the non-driven joint state publisher plugin in the real and simulated scenario, respectively?

You mean publish an additional sensor_msgs/JointState topic with only the extra joints?. Not all tooling in ROS is ready to work with multiple joint state sources, which typically requires some sort of multiplexing node, which aggregates all sources into a single output topic. So, when multiplexing is required, you end up throttling all messages to a single output frequency (and have to decide on which timestamps to use).

I don't see it as a hack but as a solution due to the lack of sensors in a movable part, and benefit from the simulation where sensors are free. I would also be glad to not waste resources in fast publishing something that has a fixed value and have a clear separation of topics containing measured (RT freq), fixed (low freq) and merged values, where the merge values can be used for visualization at any other freq.

I get your point, which is why this is an optional feature. Having multiple joint state streams:

1. A slow one with all joints
2. A fast one lacking the extra joints, and
3. Another slow one with only extra joints

is harder to set up and understand, but still perfectly valid. I'd have to run some numbers, but publishing a few extra joints on an existing topic is likely not expensive (system resources, bandwidth) compared to one extra node for aggregation and two additional topics in your system.