@zouyonghao thank you for posting PR and contribution ❗

is this related to #1743? could you describe a bit about what the actual problem is, i think it is better to discuss on what we are trying to fix as 1st.

best,

Hi @fujitatomoya , actually I didn't see #1743 before, I just want to use unsigned int for myself.
It seems this PR fix part of #1743 because currently I just add unsigned int and uint64_t support for now.

Hi, @fujitatomoya .
I read #1743 again, I think this pr fix it for supporting uint32 and uint64.

I think this only fixes construction of ParameterValue, but i believe that there are other things to be considered.

• unsigned integer types are intentionally avoided for interpretation from configuration file.
• design needs to be updated. (https://design.ros2.org/articles/ros_parameters.html#supported-datatypes, https://docs.ros.org/en/foxy/Concepts/About-ROS-2-Parameters.html)
• ros2param for get/set/describe parameters.

i might be missing something else.

I agree with you @fujitatomoya .
This PR is just a simple fix for current parameter architecture.
If we want a more complete solution, we should redesign the rcl first.
For example, we can add type support for yaml parser with tags:

unsigned_parameter: !uint32 123

If instead you wanted to introduce a new parameter type, where the storage is uint64_t then we could consider doing that, though we explicitly avoided that as we thought that int64_t would be sufficient for pretty much any use case as it could store anything that a uint32_t could anyway.

So there would need to be a compelling case for adding the unsigned type to the parameter system.

I'm going to close this as we don't want to include this feature, but please continue the conversation if you would like, and I can re-open the pull request if something changes during the discussion.

Thanks for opening the pull request to begin with!

Also, as I mentioned here:

#1743 (comment)

We might be able to support uint32_t explicitly as it could be assigned (I think) into an int64_t without any additional checks or failure cases (needs to be verified). Certainly for uint16_t and lower we could do it. But just unsigned int isn't a good type to take as it can vary in size.

Here's a concrete example: I'm currently trying to use an ODrive motor controller for a robotics application. Many of the parameters on the ODrive are either uint32 or uint64 so I cannot use ROS parameters to configure these?