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
Added extra documentation and clarifications. #651
Added extra documentation and clarifications. #651
Conversation
Signed-off-by: Johan Rutgeerts <johan.rutgeerts@lancewood.eu>
I gave it a try and I think the answer is 'yes'. In its current form, it is possible to set incompatible parameter values. In case the callbacks are registered first, and incompatible values are specified, then an exception is thrown:
|
Yes, I think you are right, but with a caveat. In particular, the
Yes, otherwise they will be immediately unregistered. The documentation for it states as much: http://docs.ros.org/en/rolling/p/rclcpp/generated/classrclcpp_1_1Node.html#_CPPv4NK6rclcpp4Node15list_parametersERKNSt6vectorINSt6stringEEE8uint64_t (I can't link to it directly because of some bug in the generated API documentation, but it is the three functions following this).
Yes, correct. Maybe we should update the documentation for that.
This is also in the documentation for the function:
However, I don't think users should rely on any particular ordering, and hence I don't think we should explicitly call it out in the demos. This is part of the reason why it is important not to change state during
Yes, correct. |
Oh my! If there were a contest for 'most scattered and well-hidden documentation', then ROS 2 would be a worthy contender! 😜 No seriously: you can't expect the typical ROS 2 end users to read about callbacks here and realize that there are caveats that are only mentioned in the API docs. Not to mention: if they even know where to find the API docs. API docs cannot be considered as documentation, unless the necessary effort is spent to educate the ROS 2 users about the API docs. Imo tutorials should be comprehensive. And at least if not they should mention that they are not and point to the relevant sources of information.
Well, this isn't strictly true as the However, the But apart from that: it turns out that the
This is indeed a similar issue as reading node parameters from the CASE 1:
And following order:
Then upon e.g.
The correct value 3.3 is displayed in the info log message. In other words: before entry of the However CASE 2:
This throws the It is not consistent that in case 1 the node parameter is updated before the Also, according to the API doc the So I assume that also in case 2 the parameter is available but the exception is thrown unintentionally. |
Does that mean that calling
could be replaced by:
|
What could be a use case to add multiple pre/on/post callbacks? |
We are trying our best. Pull requests accepted.
Yes, the API docs are there to be used. If you have specific suggestions on how to educate ROS 2 users about the docs, we are happy to listen.
Hence this PR.
This isn't quite true. Because the pre-callback can modify the passed in
Ah, OK. Thanks, I missed that part when I read it yesterday.
Yes, this one is operating exactly as I expect.
Hm, I don't see that behavior. For me, this seems to be operating exactly the same as CASE 1. What version of ROS 2 are you testing with?
Possibly. I don't know if we properly do the weak_ptr thing with callbacks here. It's worth a test, though it is somewhat orthogonal to this PR.
Right, it is a good question. For a single node, you really don't need to have multiple of them. However, a common pattern in ROS 1 days was to create a single node handle, and then pass it around to multiple components. While that isn't quite our best practice in ROS 2, it is still commonly used, particularly in pieces of code that were ported from ROS 1 (and even in a few places in the core). So it is entirely possible that another piece of code adds a parameter callback handler that you are completely unaware of. |
I tried again with a fresh ROS 2 rolling install: Source code here: set_parameters_callback.zip The 'callback registration first' version leads to following output:
If 'param1' is declared before registering the callbacks, then there is no exception:
And upon:
the expected output:
|
Thanks for the examples. That helped a lot. I see the behavior you are seeing as well. Looking closer at the code, it looks like I was mistaken; the "post" callback is called before the parameter database is updated by Regardless, I think we should move forward with the rest of this. We can certainly make a note of the current state of affairs, and then (optionally) file another issue to see if we should change the "post" semantics. Does that make sense? Is there anything else preventing progress on this? |
Signed-off-by: Johan Rutgeerts <johan.rutgeerts@lancewood.eu>
@clalancette I further cleaned up the code and comments, should be ok now. |
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.
I've left one more really minor thing to change, then this looks good to me. Thank you for iterating on this.
Co-authored-by: Chris Lalancette <clalancette@gmail.com> Signed-off-by: jrutgeer <johan.rutgeerts@lancewood.eu>
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.
Looks good. I'll run full CI on it next.
Closes ros2/rclcpp#2317
Some points that are not clear to me:
The example declares
param1
andparam2
as well as reads their values into member variables before the callbacks are registered.on_set_parameters_callback
,Is it mandatory to keep the
shared_ptr
to the callback handles for the callbacks to work?Or is this only necessary in case you need to call
this->remove_on_set_parameters_callback(callback_handle_.get());
lateron?The documentation states: "Since multiple 'set parameter' callbacks can be chained, there is no way for an individual callback to know if a later callback will reject the update."
remove_on_set_parameters()
, I assume that it is possible to calladd_X_set_parameters_callback()
multiple times, and hence "chain" multiple callbacks. Correct?pre_set
callbacks, then allon_set
callbacks and then allpost_set
callbacks, correct?