You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a3e718d
Browse filesBrowse the repository at this point in the historyBrowse files
refactor(autoware_radar_objects_adapter): align the README and the default_* parameters with what the node does (#13538)
* docs(autoware_radar_objects_adapter): document what the node expects of its input
The README now says what the conversion assumes rather than leaving it
to the code: positions and their covariances are taken in the header
frame and published as they are, velocities and accelerations are
absolute and rotated into the object's frame, the absolute_dynamics
flag is not checked, and which object fields are required and which
fall back to the default_* parameters.
The classification_remap section states that the probabilities are
treated as independent confidences and are not merged when two labels
map to the same one, in place of the note that only observed the
duplicates.
None of this changes with the refactoring under way; it is what the
node has done since the characterization tests pinned it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Kentaro NAGATOMO <kentaro.nagatomo@tier4.jp>
* refactor(autoware_radar_objects_adapter): read the default_* parameters as double
The six default_* parameters were declared as float and stored as
float in RadarObjectsAdapterParams, although rclcpp parameters are
double and every field they end up in (a position, a twist, a shape
dimension) is double. They are now double end to end, and so is the
value update_radar_info() reports for a defaulted field. The test
parameters lose their casts.
Values that a float represents exactly, such as the shipped
configuration (0.0, 5.0, 2.0), come out the same; any other value
changes the output at the 1e-8 level. The existing cases use only
exactly representable values and so could not tell the two apart;
two new cases use values a float cannot represent (0.1, 4.1, ...)
and check that they reach the output as written, one through the
adapter (every defaulted field) and one through the node and its
parameter declaration. Both fail on the float code.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Kentaro NAGATOMO <kentaro.nagatomo@tier4.jp>
---------
Signed-off-by: Kentaro NAGATOMO <kentaro.nagatomo@tier4.jp>
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: sensing/autoware_radar_objects_adapter/README.md
+10-2Lines changed: 10 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,14 +8,22 @@ This package converts `autoware_sensing_msgs::msg::RadarObjects` into `autoware_
8
8
9
9
A node that converts radar objects from the sensing definition into a perception friendly format with no filtering involved.
10
10
11
+
### What the input is expected to be
12
+
13
+
The node converts the message format; it does not transform coordinates, compensate the ego motion, or synchronize anything. It therefore expects the radar driver to publish `RadarObjects` in the form the perception pipeline uses:
14
+
15
+
- Positions, orientations, sizes and their covariances are expressed in the frame named in `header.frame_id`, which is the frame the output objects are published in (typically `base_link`).
16
+
- Velocities and accelerations are absolute (ground-relative) and expressed in that same frame, as the driver reports them; the node rotates them by the object's orientation so that the output twist and acceleration are expressed in the object's own frame, as Autoware's object messages require. The `absolute_dynamics` flag of `RadarInfo` is not checked.
17
+
- The `RadarInfo` message declares the object fields the radar provides. The following fields are required, and objects are dropped until a `RadarInfo` that declares all of them has arrived: `existence_probability`, `position_x`, `position_y`, `velocity_x`, `velocity_y`, `acceleration_x`, `acceleration_y`, `orientation`.
18
+
- Fields the `RadarInfo` does not declare are filled from the `default_*` parameters: `position_z`, `velocity_z`, `acceleration_z`, `size_x`, `size_y`, `size_z`. The yaw variances of the pose and the twist are set only when `orientation_std` and `orientation_rate_std` are declared.
19
+
11
20
### Parameter: classification_remap
12
21
13
22
This parameter allows remapping of classification labels from `autoware_sensing_msgs::msg::RadarClassification` to `autoware_perception_msgs::msg::ObjectClassification`. It should be provided as a flat list of strings, where each pair of strings represents an input label and the corresponding output label.
14
23
15
24
For example, the current default configuration remaps `MOTORCYCLE` and `BICYCLE` from radar classification to `CAR` in the perception classification, while keeping other labels unchanged.
16
25
17
-
**Note**: If multiple radar labels are remapped to the same perception label, multiple probabilities may appear for that label.
18
-
This does not violate any logic in Autoware but may be worth monitoring.
26
+
The `probability` of each radar classification is treated as an independent confidence for that label, not as a share of a distribution, and is copied as it is. Consequently, if multiple radar labels are remapped to the same perception label, multiple entries with that label and their own probabilities appear in the output; the probabilities are not merged. This does not violate any logic in Autoware but may be worth monitoring.
0 commit comments