-
Notifications
You must be signed in to change notification settings - Fork 171
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
Issue 29: reload robot_model via Trigger-Service #31
Conversation
…hat allows another node to trigger a reload of the robot model (e.g. after an calibration that changed the urdf-model)
void callbackJointState(const JointStateConstPtr& state); | ||
void callbackFixedJoint(const ros::TimerEvent& e); | ||
|
||
/// used as mutex |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use a boost::mutex
here instead of a bool, since getting/setting a bool may not be atomic?
I'm currently in the process of fixing up the existing tests for this package so that they run again. In the meantime, can you write a test for this feature and make it available, in this branch or another? |
Some really good points. Thank you! |
Any news on this pull request, is there any branch with this change. I am interested in using this functionality, it looks pretty useful to me. @NikolasE did you get to test this change successfully. |
would be really great to see this PR revived |
This PR is targeting an EOL ROS distro, closing this. Feel free to reopen this PR in an active ROS distro if the PR is relevant |
Node now advertises a reload_robot_model (std_srvs/Trigger) service that allows another node to trigger a reload of the robot model (e.g. after an calibration that changed the urdf-model).
So far, the robot_state_publisher had to be restarted, which is not suitable for an automated process. With the new adaption, the server can be restarted by calling the service:
If the reload failed (e.g. due to a wrong urdf-model (rosparam set /robot_description "InvalidFooBar"), the publisher stops and no tf-frames are published anymore so that no one is working with the deprecated model. If the /robot_description is corrected and the service called again, the publisher continues to publish frames.
Publication of frames is stopped before loading the model, so that reading and writing does not happen at the same time.
Discussion in Issue 29:
#29