Open Ryanf55 opened 8 months ago
And, the CLI also supports it on humble
:
ros2 topic pub /ap/cmd_vel geometry_msgs/msg/TwistStamped "{header: {frame_id: base_link}, twist: {linear: {x: .nan, y: .nan, z: .nan}, angular: {z: 0.01}}}"
Yeah, I think that is a reasonable thing to document; I'd enhance the table in https://docs.ros.org/en/humble/Concepts/Basic/About-Interfaces.html#field-types to add a "Note" column, or something like that. If you'd like to open a PR to add that, I'd be happy to review it.
Yeah, I think that is a reasonable thing to document; I'd enhance the table in https://docs.ros.org/en/humble/Concepts/Basic/About-Interfaces.html#field-types to add a "Note" column, or something like that. If you'd like to open a PR to add that, I'd be happy to review it.
It doesn't look like it's actually supported.
In a .msg
:
# NaN (IEE-754 quiet NaN) signifies no data is available at the location.
float64 my_value NaN
c
: error: ‘nanl’ undeclared (first use in this function)
276 | msg->my_value = nanl;
c++
: error: ‘nan’ was not declared in this scope
198 | this->my_value= nan;
Relates to https://github.com/ros2/rosidl/issues/705
Huh, in the IDL 4.2 spec, it says nothing about special floating point values: https://www.omg.org/spec/IDL/4.2/PDF
See section 7.2.6.4
.
Then in the DDS Consolidated JSON 1.0 spec, it says that NaN is supported.
https://www.omg.org/spec/DDS-JSON/1.0/PDF
See section 7.3.7.4.8
Numeric values, such as Infinity, -Infinity, and NaN, which as stated in [ECMA-404] cannot be represented as
sequences of digits, shall be represented using the following JSON strings: "inf", "-inf", and "nan".
Hello,
Would it be possible to document in Interfaces that you can set constants or default values to special values like NaN? It's not clear what's supported, and whether NAN, NaN, and whether it would be quiet or signaling NaN.
https://en.cppreference.com/w/cpp/types/numeric_limits
I am writing messages that have values that can fail. Rather than add
is_X_valid
booleans for every field in the message, I would prefer to have support for NaN. This results in significantly less application code and reduces bandwidth when messages are sent over wireless networks using DDS compared to dedicated booleans.While doing this, it would also be good to document whether infinity is supported.
Related: