Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]
Messages
Services
Plugins
Recent questions tagged autoware_lidar_centerpoint at Robotics Stack Exchange
Package Summary
| Version | 0.53.0 |
| License | Apache License 2.0 |
| Build type | AMENT_CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Description | |
| Checkout URI | https://github.com/autowarefoundation/autoware_universe.git |
| VCS Type | git |
| VCS Version | main |
| Last Updated | 2026-10-27 |
| Dev Status | UNKNOWN |
| Released | UNRELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Maintainers
- Kenzo Lobos-Tsunekawa
- Amadeusz Szymko
- Kotaro Uetake
- Masato Saeki
- Taekjin Lee
- Kok Seang Tan
Authors
autoware_lidar_centerpoint
Purpose
autoware_lidar_centerpoint is a package for detecting dynamic 3D objects.
Inner-workings / Algorithms
In this implementation, CenterPoint [1] uses a PointPillars-based [2] network to inference with TensorRT.
We trained the models using https://github.com/open-mmlab/mmdetection3d.
Inputs / Outputs
Input
| Name | Type | Description |
|---|---|---|
~/input/pointcloud |
sensor_msgs::msg::PointCloud2 |
input pointcloud |
Output
| Name | Type | Description |
|---|---|---|
~/output/objects |
autoware_perception_msgs::msg::DetectedObjects |
detected objects |
debug/cyclic_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
cyclic time (msg) |
debug/processing_time_ms |
autoware_internal_debug_msgs::msg::Float64Stamped |
processing time (ms) |
Parameters
ML Model Parameters
Note that these parameters are associated with ONNX file, predefined during the training phase. Be careful to change ONNX file as well when changing this parameter. Also, whenever you update the ONNX file, do NOT forget to check these values.
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/ml_package.schema.json”) }}
Core Parameters
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/centerpoint_common.schema.json”) }}
Detection Class Remapper
{{ json_to_markdown(“perception/autoware_lidar_centerpoint/schema/detection_class_remapper.schema.json”) }}
Launch Parameters
These are given by the launch file and are not part of any parameter file.
| Name | Type | Default Value | Description |
|---|---|---|---|
model_path |
string | $(var data_path)/lidar_centerpoint/base |
directory containing the model artifacts; relative manifest entries resolve against it |
build_only |
bool | false |
shutdown the node after TensorRT engine file is built |
logger_name |
string | lidar_centerpoint |
logger name used for the node logs and debug topics |
The build_only option
The autoware_lidar_centerpoint node has build_only option to build the TensorRT engine file from the ONNX file.
Although it is preferred to move all the ROS parameters in .param.yaml file in Autoware Universe, the build_only option is not moved to the .param.yaml file for now, because it may be used as a flag to execute the build as a pre-task. You can execute with the following command:
ros2 launch autoware_lidar_centerpoint lidar_centerpoint.launch.xml model_path:=/home/autoware/autoware_data/ml_models/lidar_centerpoint/base build_only:=true
model_path points at the variant folder (base/tiny/sigma/short_range) of the model bundle; the engine files are written there.
Assumptions / Known limits
- The
object.existence_probabilityis stored the value of classification confidence of a DNN, not probability.
Trained Models
Trained models are hosted on Hugging Face at AutowareFoundation/lidar_centerpoint and downloaded to ~/autoware_data/ml_models/lidar_centerpoint/ by the ansible artifacts role (pinned to tag v4.1).
The bundle holds one self-contained folder per variant; the perception launcher (lidar_dnn_detector.launch.xml) selects the folder from the model name, and lidar_centerpoint.launch.xml takes the folder directly as model_path:
lidar_centerpoint/
├── base/ # model_name: centerpoint
├── tiny/ # model_name: centerpoint_tiny
├── sigma/ # model_name: centerpoint_sigma
└── short_range/ # model_name: centerpoint_short_range
Every variant folder contains the same file set: pts_voxel_encoder.onnx, pts_backbone_neck_head.onnx, ml_package.param.yaml and detection_class_remapper.param.yaml. TensorRT engine files are built locally into the variant folder on first launch (or via build_only:=true).
ml_package.param.yaml declares the bundle version. The node reads major version 4 from minor version 1 upward and aborts otherwise, so a version error means the bundle has to be refreshed with the ansible artifacts role of the autoware repository. A minor bump can add manifest entries the node requires.
Centerpoint was trained in nuScenes (~28k lidar frames) [8] and TIER IV’s internal database (~11k lidar frames) for 60 epochs.
Centerpoint tiny was trained in Argoverse 2 (~110k lidar frames) [9] and TIER IV’s internal database (~11k lidar frames) for 20 epochs.
Training CenterPoint Model and Deploying to the Autoware
Overview
This guide provides instructions on training a CenterPoint model using the mmdetection3d repository and seamlessly deploying it within Autoware.
Installation
Install prerequisites
File truncated at 100 lines see the full file
Changelog for package autoware_lidar_centerpoint
0.53.0 (2026-09-29)
-
Merge remote-tracking branch 'origin/main' into prepare-0.53.0-changelog
-
fix(autoware_lidar_centerpoint): reject point clouds with an unexpected point_step (#13313) The voxel generator reinterpret_casts the cloud to a 16-byte InputPointType but nothing validated the layout, so any other point type was read at the wrong stride, producing detections from misread data with no error. Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
-
fix(autoware_lidar_centerpoint): use voxel_size_y when scaling y position variance (#12992)
-
refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version (#13211)
* refactor(autoware_lidar_centerpoint)!: scope model params to the manifest and check its version yaw_norm_thresholds is indexed by the predicted class in the postprocess kernel, so its length and order follow model_params.class_names. It moves from centerpoint_common.param.yaml into the model manifest and is now checked against the class list. The manifest declares its version, and the node accepts major version 4 from minor version 1 upward, so a bundle that predates the manifest layout fails with an actionable message instead of an uninitialized parameter. Also adds a schema for detection_class_remapper.param.yaml, renders the common and remapper parameter tables from the schemas, and makes the launch file default to the base variant. Co-Authored-By: Claude Opus 5 (1M context) <<noreply@anthropic.com>>
- remove copied ml package config
- style(pre-commit): autofix
* refactor(lidar_centerpoint): enhance version checking with model path context and update documentation ---------Co-authored-by: Claude Opus 5 (1M context) <<noreply@anthropic.com>> Co-authored-by: pre-commit-ci-lite[bot] <117423508+pre-commit-ci-lite[bot]@users.noreply.github.com>
-
refactor(lidar_centerpoint): replace NMS with perception_utils::IouBevNms (#13177) refactor: replace NMS with perception_utils::IouBevNms
-
docs: replace retired model hosting URLs with Hugging Face links (#13204)
* docs: replace retired model hosting URLs with Hugging Face links The model artifacts moved from awf.ml.dev.web.auto and the autoware-files S3 bucket to Hugging Face repositories under the AutowareFoundation org (autowarefoundation/autoware#7223). The READMEs still pointed manual downloads at the old hosts, and the yabloc README still gave wget instructions for the retired archive. The two dataset links on the S3 bucket stay: the bucket keeps serving datasets, maps and rosbags. Only the model objects are retired. The centerpoint v0 and v1 files were never migrated and stop being distributed, so their changelog rows lose the download links.
* docs: name the ML package configs in the model download notes The launch files read transfusion_ml_package.param.yaml and ml_package_camera_streampetr.param.yaml from the model directory. The download notes did not name them, so a manual download missed two required files. ---------
-
refactor(autoware_lidar_centerpoint)!: consume per-variant model folders via a model manifest (#13087)
-
refactor(autoware_universe): use autoware_ament_auto_package in perception DNN packages (#12277) Co-authored-by: github-actions <<github-actions@github.com>> Co-authored-by: Taekjin LEE <<taekjin.lee@tier4.jp>>
-
fix(autoware_lidar_centerpoint): sync parameter schemas with actual node parameters (#12949)
- fix(autoware_lidar_centerpoint): fix schema filename and sync with current parameters
* fix(autoware_lidar_centerpoint): keep centerpoint schema excluded from CI due to basename collision ---------
-
Contributors: Gabriel Manalu, Kotaro Uetake, Max Schmeller, Mete Fatih Cırıt, Ryohsuke Mitsudome, Taekjin LEE, Vishal Chauhan
0.52.0 (2026-06-30)
File truncated at 100 lines see the full file
Package Dependencies
System Dependencies
Dependant Packages
Launch files
- launch/lidar_centerpoint.launch.xml
-
- input/pointcloud [default: /sensing/lidar/pointcloud]
- output/objects [default: objects]
- data_path [default: $(env HOME)/autoware_data/ml_models]
- node_name [default: lidar_centerpoint]
- model_path [default: $(var data_path)/lidar_centerpoint/base]
- common_param_path [default: $(find-pkg-share autoware_lidar_centerpoint)/config/centerpoint_common.param.yaml]
- build_only [default: false]
- use_pointcloud_container [default: false]
- pointcloud_container_name [default: pointcloud_container]