-
Notifications
You must be signed in to change notification settings - Fork 202
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
Demo 14 crashing when using description from topic #455
Comments
I can't reproduce it with a clean build of |
Thanks for checking. Then I'll look around locally. |
I can't reproduce it as well. It works for me :) |
OK, the problems seems indeed to come from my change in #456. Looks like when using the description topic it tries to send commands to the hardware before it is activated.
vs. using the description parameter:
I didn't consider this at first, as I merely changed the way the description was fed and the node ended up with the correct description. However, using the description from the topic completely changes initialization. I'll update the title accordingly. However, the question is: Where's the fault? It seems weird that This demo example is an interesting special case since the Or is it a requirement that So my main question would be: Is this behavior to be expected and the requirements for the Edit: I think, I understand now why this happens. During initialization, the hw interface sets the buffer command to
Then, in ros2_control_demos/example_14/hardware/rrbot_actuator_without_feedback.cpp Lines 147 to 151 in 044db05
Since urdf loading and activating the hardware isn't blocking the So, one way of "fixing" this short term would be a check in the |
Thanks for analyzing this.
I just checked the docs about that, (here or here). It seems that this should be real-time safe:
Is there a difference from controllers and hardware components regarding this?
I'm fine with the fix, and agree for the need for the "final" solution upstream. |
Short term solution now included in #456 |
Hello! I'd rather go with a proper fix, because if this happened in the demos, this might happen in reality, we would need to check why it is happening and find a proper solution for upstream. What do you guys think? |
Yes, I think a proper fix would be better. That's why I didn't mark this issue to be resolved by #456. I just like this issue to not block migrating towards the topic inside the demos. |
After looking at the code, I believe this is happening because we call the The only fix I can think of is how @fmauch has handled it in the hardware itself. I'm wondering why this is not happening with the parameter. I would like to check this part. If we need to properly fix it, I think we might need a new method called |
@saikishor should we open an issue in ros2_control and close this one here? |
Sure, let's open an issue in ros2_control and leave this open still. What do you think? |
Demos fixed with #456 -> I created a new issue in ros2_control repo. |
@fmauch @saikishor should we remove the |
I would say yes. this way we can be aware if this breaks again |
Describe the bug
Without further investigating this it seems that demo14 is currently broken at least on the master branch.
To Reproduce
Run demo 14 as described in the docs
Update: To reproduce use the version from #456.
Output:
Expected behavior
I would expect things not to crash ;-)
Environment (please complete the following information):
ROS 2 rolling with ros2_control workspace with current master everywhere:
Additional context
I didn't investigate this all too much but did not want that to get lost on the way.
The text was updated successfully, but these errors were encountered: