-
Notifications
You must be signed in to change notification settings - Fork 527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[joint_state_controller] Allow to publish joints not present in RobotHW #87
Comments
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 |
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 |
There seem to be two features being discussed, correct me if I'm wrong:
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. |
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 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. |
I shall capitulate. |
Hi Greetings |
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. |
Hi Mike Greetings |
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 |
Hi Mike |
Your solution provides the transforms in |
@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
On this last alternative, an interesting feature would be that if the specified joints turn out to be in |
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. |
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. |
Please review #87. I had need of this enhancement and implemented it. A nice side-effect is that the |
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 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. |
You can have different
You mean publish an additional
I get your point, which is why this is an optional feature. Having multiple joint state streams:
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. |
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:Implementation-wise, one would have to take care that there is no overlap between the robot joints and the extra ones.
The text was updated successfully, but these errors were encountered: