More convinent one time parameter access#107
Merged
m-dahl merged 5 commits intosequenceplanner:masterfrom Oct 13, 2024
Merged
Conversation
Collaborator
|
Thanks for you contribution! This is a nice improvement in usability and I am happy to merge it. Before that, can I ask you to add one or two examples based on your writeup to examples/paramters.rs? |
Contributor
Author
|
Hopefully that explains it well. I tried to make the comments match the styling of the ones already there. |
d966d2a to
0577a2e
Compare
Collaborator
|
Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TLDR: If you just want to read a single ROS parameter and not receive updates for it in the future, it's now this easy:
I write a lot of ROS drivers. The usual way I configure the drivers is to load their settings from ROS params.
The current method to access a ROS parameter once is quite tedious and I wanted to make it easy.
The following is an explanation of my development process and why each commit was made.
The current way to read a parameter just once on startup looks something like this:
That's usable but ugly, so I set out to try and make it less ugly.
My first step was to generalize converting the type of a value.
That resulted in this:
Next was to add a "get_parameter" method to the node, simplifying to this:
Now that looks pretty good, except for when you want to give a parameter a default value.
To fix that issue, I decided to not make
ParameterNotSetits own error and instead make it a type error. "I was expecting an Integer but got a NotSet" instead of "Expected parameter is not set". By doing this, I could then have atry_intofor Option types, enabling the following patern: