centerpoint-p150 on Tenstorrent p150
Derived from AutowareFoundation/lidar_centerpoint (tag
v4.1), the CenterPoint and CenterPoint-tiny networks that TIER IV trained for Autoware'sautoware_lidar_centerpointLiDAR detector, with unmodified weights. CenterPoint: Yin et al., arXiv:2006.11275. See the original model card for training details.
CenterPoint, the LiDAR 3D object detector Autoware runs by default, and its CenterPoint-tiny variant: a PointPillars pillar encoder (PFN 9-16-32), a SECOND backbone, a SECONDFPN neck and a single-task CenterPoint head, on a 480x480 head grid (base) or a 240x240 one with a stride-2 first block (tiny, a quarter of base's compute). One LiDAR point cloud in base_link goes in (one sweep, or Autoware's 2-sweep densified cloud). Out come 3D boxes of CAR, TRUCK, BUS, TRAILER, BICYCLE and PEDESTRIAN equivalent to Autoware's DetectedObjects, with the pre- and post-processing of the autoware_lidar_centerpoint node (voxelization, decode, circle NMS, IoU NMS, area-based class remap).
Runs on Tenstorrent p150 — see the serving profiles below.
Packaged and published with tt-model-manager 0.1.0 (manifest schema 5.1).
At a glance
| Hardware | p150 |
| License | apache-2.0 |
Intended use
LiDAR 3D object detection for Autoware-style sensor setups (concatenated clouds in base_link): research, prototyping and offline processing of recorded LiDAR data, with the outputs of Autoware's lidar_centerpoint node.
Prerequisites
- The Tenstorrent CLI,
tt:uv tool install tenstorrent(or use tt-model alone, see the Quickstart) - Docker
- Tenstorrent hardware: p150
Quickstart
tt serve changh95/centerpoint-p150
tt serve downloads the Docker image and the AutowareFoundation/lidar_centerpoint at 494c8171def40bd36cc2feb323e0a5acbfab132b weights (into your HF cache; they are not in the image), then starts the model's own HTTP server on port 20000 (or the next free port, if that one is busy). The first start compiles kernels for your device, which takes several minutes; the server is ready when it logs Application startup complete.
Without tt-cli: tt-model serve changh95/centerpoint-p150.
Send the sample point cloud shipped in this repo (Autoware's own test.pcd, as an npz) to /predict, on the port
tt serve reported:
curl -sLO https://huggingface.co/changh95/centerpoint-p150/resolve/main/code/tt_centerpoint/samples/test_pcd.npz
printf '{"points": {"format": "npz", "data": "%s"}}' "$(base64 -w0 test_pcd.npz)" > req.json
curl -s localhost:20000/predict -H 'Content-Type: application/json' -d @req.json
Serving profiles
Select a different serving profile using --profile.
| profile | hardware | mesh | description |
|---|---|---|---|
base (default) |
p150 | P150 | CenterPoint (Autoware default lidar_centerpoint model, 480x480 head grid) |
tiny |
p150 | P150 | CenterPoint-tiny (first block stride 2, 240x240 head grid) |
Capabilities
This package exposes the model's own HTTP server on port 20000, not an OpenAI-compatible chat API — its request and response shapes are the model's own. See the author's notes for the payload it expects.
POST /predict takes one point cloud as JSON and returns its 3D detections. GET /health and GET /info report
the server and device state (/info lists every parameter default); GET /v1/models is a stub, not a chat API.
| request field | meaning |
|---|---|
points |
{"format": "npz" | "npy" | "pcd" | "bin" | "list", "data": "<base64 file bytes>"}: one cloud in base_link, metres, fields x, y, z (intensity is ignored, as in Autoware); a time_lag column marks an already densified cloud |
sweeps (optional) |
past sweeps for client-side densification: [{"points": {...}, "time_lag_s": 0.1, "T_current_from_sweep": <transform>}] |
stream (optional) |
server-side 2-sweep densification as in Autoware: {"id", "timestamp_s", "T_world_from_ego"} |
params (optional) |
score_threshold (default 0.35 for every class and distance bin), score_thresholds (per class), distance_bin_upper_limits ([50, 90, 121, 200]), yaw_norm_thresholds (0.3, PEDESTRIAN 0), z_range ([-4, 6]), circle_nms_dist_threshold (0.5), iou_nms_threshold (0.1), iou_nms_search_distance_2d (10.0), remap_classes (true), max_detections (none) |
output_format (optional) |
json (default) or npz (adds lossless arrays) |
Response for the sample cloud (base profile; two of the ten detections shown, meta shortened):
{"model": "centerpoint-p150", "frame_id": "base_link", "num_detections": 10,
"detections": [
{"label": "TRUCK", "label_id": 2, "score": 0.7409, "center": [24.16, 11.304, 1.693], "size": [8.131, 2.85, 3.404], "yaw": -3.1406},
{"label": "TRUCK", "label_id": 2, "score": 0.7322, "center": [21.25, -0.423, 1.694], "size": [7.609, 2.619, 2.993], "yaw": 0.0407}],
"meta": {"variant": "base", "num_points": 48048, "num_pillars": 9416, "pillar_overflow": false, "counts": {"after_threshold": 38, "after_circle_nms": 12, "after_iou_nms": 10}},
"timing_ms": {"preprocess": 4.807, "device": 13.846, "postprocess": 4.768, "total": 43.301, "decode": 19.532, "model_call": 23.452}}
center,size([length, width, height]) andyaware inbase_linkmetres and radians, in Autoware's convention;label_idis theautoware_perception_msgsObjectClassificationvalue; detections are sorted by score, andscoreis Autoware'sexistence_probability.- No velocity is returned (both networks have no twist head, as in Autoware). TRAILER and remapped TRUCK labels
come from Autoware's area-based class remapper;
meta.label_before_remapkeeps the network's class. - A Python API with the same outputs (
tt_centerpoint.CenterPoint) is described incode/PYTHON.md; it needs a tt-metal build with the two patches in this repo'spatches/directory.
Example output
Boxes computed by this package (base profile) on 50 LiDAR scans of the Autoware sample rosbag (a VLS-128 roof
LiDAR and two VLP-16, each scan densified with the previous one, about 10 Hz), drawn from above, also as
MP4. The video shows LiDAR points and boxes only, no camera pixels. The rosbag is the one
Autoware's rosbag-replay demo plays; its publisher states no licence. Attributions for every file in media/:
media/ATTRIBUTION.md.
Expected performance
Agreement with the fp32 CPU reference of the same network (same weights, same pre- and post-processing, identical voxel input); detections match when they have the same label and BEV centres at most 0.5 m apart:
| eval | this package | fp32 CPU reference | frames |
|---|---|---|---|
Detections matched, sample cloud, base |
10 of 10, max score difference 0.0128 | 10 | 1 |
Detections matched, sample cloud, tiny |
3 of 3, max score difference 0.0018 | 3 | 1 |
Detections matched, public driving frames, base |
45,814 of 46,160 (99.25 %), precision 99.77 % | 46,160 | 652 |
Detections matched, public driving frames, tiny |
36,841 of 37,012 (99.54 %), precision 99.80 % | 37,012 | 652 |
Score at each reference detection's cell, held-out frames: max difference, base / tiny |
0.042 / 0.034 | – | 54 |
Pillar feature net output PCC, base / tiny |
0.999985 / 0.999973 | – | 1 |
5-class mAP, base, nuScenes v1.0-mini mini_val |
0.598 | 0.600 | 81 |
5-class AV2-style mAP within 50 m, tiny, 3 Argoverse 2 val logs |
0.460 | 0.461 | 471 |
Public driving frames: PandaSet 019 and 090 (100), nuScenes v1.0-mini mini_val (81) and three Argoverse 2 val logs (471). Held-out frames: 45 of them plus 9 frames of the Autoware sample rosbag. The mAP rows score the networks against the datasets' ground truth with re-implemented protocols (nuScenes devkit functions with Autoware's 5 classes; an AV2-style AP, not the official CDS) on small splits; the weights repo publishes no dataset-level accuracy to compare with.
| speed (batch 1, warm) | input | median | throughput |
|---|---|---|---|
Device time per frame, back-to-back trace replays, base / tiny |
sample cloud (48,048 points, 9,416 pillars) | 6.01 ms / 2.04 ms | 166 / 491 frames/s |
Device time per frame, back-to-back trace replays, base / tiny |
PandaSet frame (213,007 points, 2 sweeps, 26,730 pillars) | 6.09 ms / 2.12 ms | 164 / 471 frames/s |
Python model() call (pre-processing, device, post-processing), base |
sample cloud | 29.8 ms (p99 33.7) | 34 frames/s |
Python model() call, tiny |
sample cloud | 19.9 ms (p99 21.0) | 50 frames/s |
Python model() call, base / tiny |
PandaSet frame, uncompressed .npy |
44.5 ms / 34.8 ms | 22 / 29 frames/s |
Served POST /predict, server timing_ms.total, base / tiny |
sample cloud (npz) | 43.5 ms / 33.8 ms | – |
Served POST /predict, client round trip on loopback, base / tiny |
sample cloud (npz) | 51.5 ms / 41.3 ms | – |
Measured with this package's code on one p150 in an 8-vCPU AMD EPYC-Rome host: code/scripts/bench.py (100 warm
iterations per stage; device time over 5 rounds of 50 back-to-back replays) and 50 served requests of the sample
cloud per profile. The model() and served times are host-bound: on the sample cloud, host pre-processing
(reading the input file plus voxelization) takes about 10 ms of the model() call, and the server's base64 and
npz decode of the request another 19 ms.
Limitations
- Do not use it to drive or control a vehicle or as any safety function: it is not a certified Autoware component and has no functional-safety qualification.
- Do not use its outputs as a CenterPoint accuracy benchmark: the weights are TIER IV's, trained on nuScenes (base) or Argoverse 2 (tiny) plus TIER IV data, and accuracy on other LiDAR setups (mounting, beam count) is not characterized; the mAP rows above come from small splits.
- Not a ROS 2 node: it serves HTTP and Python only, and takes arrays or files, not
PointCloud2messages. It runs thebaseandtinymodels of the weights repo; thesigma(variance heads) andshort_rangemodels are not included. - Batch 1, one cloud per request; requests are served one at a time, one model per serve profile. Up to 40,000 pillars per frame on a fixed 480x480 canvas; above that the front-most 40,000 are kept.
- One p150 only. The image runs device dispatch on the chip's Ethernet cores, so multi-chip meshes are not supported.
- Deterministic voxelization: a fixed seeded point selection per pillar replaces Autoware's random one, points at exactly (0, 0, 0) and non-finite points are dropped, and the score sort before circle NMS is stable. Outputs were compared with the fp32 CPU reference, not with Autoware's TensorRT engine.
- fp32 weights and bf16 activations: scores and boxes differ slightly from the fp32 reference. An object near Autoware's decision thresholds (score 0.35, rotation-head norm 0.3, the circle-NMS neighbourhood, the 12.1 / 36 m² remap areas) can appear, disappear or come from a neighbouring cell: 346 (base) / 171 (tiny) reference detections in 652 public frames have no partner, 30 / 44 of them with a score of 0.40 or more.
- On public frames the weights themselves (on CPU and on p150 alike) give tiny less than half of base's mAP on nuScenes' 32-beam clouds, swap buses and box trucks in tiny on Argoverse 2, label many pickups TRUCK, and turn 12-14 m buses into TRAILER through Autoware's remapper.
Licensing
- Weights: AutowareFoundation/lidar_centerpoint at tag
v4.1(commit494c8171def40bd36cc2feb323e0a5acbfab132b), Apache-2.0 per its model card. Downloaded bytt serveat that commit, not redistributed here. The upstream card's Legal Notice: base was trained on nuScenes (CC BY-NC-SA 4.0) plus TIER IV data, tiny on Argoverse 2 (CC BY-NC-SA 4.0) plus TIER IV data; read it before commercial use. - Pre- and post-processing ported from autoware_universe
perception/autoware_lidar_centerpoint(Apache-2.0). - Port and serving code (
code/) and the tt-metal patches inpatches/: Apache-2.0. - Sample cloud
code/tt_centerpoint/samples/test_pcd.npz: Autoware's owntest.pcdfrom autoware_universeperception/autoware_ground_segmentation/test/data/(Apache-2.0). - Demo media in
media/are renders, not part of the package. The demo video is a LiDAR-only render of the Autoware sample rosbag, whose publisher states no licence; it contains no camera pixels and no rosbag data ships here. The nuScenes and Argoverse 2 renders (media/*_NC.jpg) are non-commercial use only, CC BY-NC-SA 4.0, © Motional AD Inc. and © 2021 Argo AI, LLC. The PandaSet renders: CC BY 4.0 and the PandaSet Dataset Terms (Scale AI and Hesai). No dataset owner endorses this work. Full attributions:media/ATTRIBUTION.md.
Related packages
- The Autoware collection: the other Autoware perception and planning models packaged for the p150.
- changh95/pointpainting-p150 and changh95/transfusion-p150: Autoware's other LiDAR 3D detectors (camera-painted CenterPoint, and TransFusion).
Feedback
Questions or problems with this package: open a discussion at https://huggingface.co/changh95/centerpoint-p150/discussions — that is what reaches its author. A problem with the tt tooling itself: tt report issue (collects your environment and opens a prefilled issue against tenstorrent/tt-cli). Product feedback: [email protected].
Provenance
The exact sources the image was built from — code/ in this repo is byte-identical to the model code inside the image:
| component | built from |
|---|---|
| tt-metal | 44d66500520fda9f2c7060c0f6b41ec48f7ab37e (dirty tree — the image includes uncommitted changes) |
code/ digest |
261fb3e166cd378d (sha256, first 16 hex digits) |
| built | 2026-10-16T18:15:56+00:00 by tt-model 0.1.0 |
Model tree for changh95/centerpoint-p150
Base model
AutowareFoundation/lidar_centerpoint