centerpoint-p150

CenterPoint (Autoware lidar_centerpoint): the LiDAR 3D object detector that Autoware deploys by default (autoware_lidar_centerpoint), and its CenterPoint-tiny variant, ported to one Tenstorrent Blackhole p150 with tt-nn. One LiDAR point cloud in base_link in (one sweep, or Autoware's 2-sweep densified cloud); Autoware DetectedObjects-equivalent 3D boxes of CAR, TRUCK, BUS, TRAILER, BICYCLE and PEDESTRIAN out, with the node's exact pre- and post-processing. One image, two serve profiles: base (the default) and tiny. Weights: AutowareFoundation/lidar_centerpoint v4.1 · Paper: arXiv:2006.11275 · Autoware package: autoware_lidar_centerpoint · Training code: autowarefoundation/mmdetection3d (Autoware fork, projects/AutowareCenterPoint) · Port: code/

Runs on p150 (mesh P150). Configuration: dispatch on the ETH cores, 1 command queue, 12×10 compute grid. Precision: fp32 weights, bf16 activations, HiFi4 math with fp32 accumulation; no bfp8. Both serve profiles run in this configuration, and all numbers on this card were measured in it.

Packaged and published with tt-model-manager 0.1.0 (manifest schema 5.1).

Quickstart (Python)

Prerequisite: a tt-metal / ttnn environment at tt-metal 44d66500520 with patches/tt-metal-eth-dispatch.patch applied. ttnn is not on PyPI.

hf download changh95/centerpoint-p150 --exclude "image/*" --local-dir centerpoint-p150 && cd centerpoint-p150
pip install -e .                        # adds numpy<2, pillow, pyyaml, onnx, huggingface_hub; ttnn and torch come from tt-metal
pip install -e ".[server,test]"         # optional: the HTTP server and the tests

Run the snippet from the model repo root: code/tt_centerpoint/samples/test_pcd.npz (Autoware's test.pcd) is a path relative to it.

from tt_centerpoint import CenterPoint

with CenterPoint.from_pretrained(device_id=0) as model:           # variant="tiny" for CenterPoint-tiny
    out = model("code/tt_centerpoint/samples/test_pcd.npz")       # path, (N, C) array, .npy/.npz/.pcd, or a PointCloud

for d in out.to_dicts()[:5]:
    print(d["label"], d["score"], d["center"], d["size"], d["yaw"])

• from_pretrained downloads base/ and tiny/ of AutowareFoundation/lidar_centerpoint at the pinned commit 494c8171def (tag v4.1, 41 MB) to your HF cache, opens the chip, builds the graph of the variant and captures the metal trace. The first load compiles the kernels (about 74 s for base and 56 s for tiny with an empty JIT cache); later loads take about 7.2 s.
• The trace is captured during the load, so the first call is as fast as the later ones.
• The with block releases the trace and closes the chip. Without with, call model.close().

Input	A point cloud in base_link: path (.npy / .npz / .pcd / .bin), raw bytes with fmt=, an (N, C) float array or tensor, or a PointCloud; fields x, y, z (intensity is ignored, as in Autoware). A column named time_lag (s) marks an already densified cloud. Optional sweeps= (client-side densification) or stream= (server-side, Autoware's own densification with poses).
Options	score_threshold=None (the ml_package thresholds: 0.35 for every class and distance bin), score_thresholds={"CAR": 0.4, ...} (per class, one value or one per distance bin), distance_bin_upper_limits=[50, 90, 121, 200], yaw_norm_thresholds={"CAR": 0.3, ...}, z_range=[-4, 6] (narrows the z filter), circle_nms_dist_threshold=0.5, iou_nms_threshold=0.1, iou_nms_search_distance_2d=10.0, remap_classes=True, max_detections=None. from_pretrained(device_id=0, variant="base" | "tiny", dispatch="eth", weights_dir=None, device=None).
Output	Detections3D: boxes float32 [N, 7] (x, y, z, length, width, height, yaw), scores [N] (Autoware's existence_probability), label_ids [N] (ObjectClassification values), labels, meta (pillar counts, overflow flag, per-stage counts, orientation availability, labels before the remapper), timing_ms. Sorted by score.
Methods	out.to_dict() gives the /predict JSON. out.to_dicts() gives the detection list. tt_centerpoint.viz.render_bev(points, out.to_dicts()) draws a bird's-eye view.

• The API gives the same output as the HTTP server /predict: both share the decoders, the device trace and the host post-processing (checked on the device by test_api_equals_server, with and without every knob).
• variant selects the network at load time: base is the model Autoware runs by default; tiny has a stride-2 first block and a 240×240 head grid (a quarter of base's compute).
• Every option is a host-side knob with Autoware's value as the default; none changes a device shape. A bad value is refused before the device runs.
• One model uses one chip; calls from several threads are serialised.
• Full reference: code/PYTHON.md. Runnable example: examples/quickstart.py (also writes quickstart_bev.png, the points and the boxes from above).

Serving (HTTP)

tt-model pull  changh95/centerpoint-p150 --with-weights
tt-model serve changh95/centerpoint-p150       # CenterPoint-tiny: tt-model serve --profile tiny changh95/centerpoint-p150 (options go before the repo id); tt-cli: tt serve changh95/centerpoint-p150
python3 code/tt_centerpoint/server/client.py --points code/tt_centerpoint/samples/test_pcd.npz --out req.json
curl -s localhost:20000/predict -H 'Content-Type: application/json' -d @req.json
tt model stop changh95/centerpoint-p150

• The image does not contain the weights. --with-weights puts them in your HF cache.
• The server uses port 20000 (or the next free port). It is ready when the log shows Application startup complete.
• Two serve profiles (tt-model profiles changh95/centerpoint-p150): base (the default) and tiny. Each serves one variant.
• client.py builds the request with the standard library only; add --url http://127.0.0.1:20000 to send it, --param 'score_thresholds={"CAR": 0.4}' to set a knob.
• POST /predict: points (base64 .npy / .npz / .pcd / raw bin, base_link, fields x, y, z (+ intensity, ignored) or a pre-densified cloud with a time_lag column); optional sweeps (past sweeps with time_lag_s and T_current_from_sweep) or stream (id, timestamp_s, T_world_from_ego: server-side 2-sweep densification as Autoware), params (every option above), output_format. Also GET /health, GET /info (with the effective default of every knob), GET /v1/models (stub). Contract: SERVING.md section 3.

{
  "model": "centerpoint-p150",
  "frame_id": "base_link",
  "num_detections": 10,
  "detections": [
    {"label": "TRUCK", "label_id": 2, "score": 0.7396, "center": [24.159, 11.304, 1.692], "size": [8.147, 2.852, 3.404], "yaw": -3.1401},
    {"label": "TRUCK", "label_id": 2, "score": 0.7335, "center": [21.248, -0.422, 1.693], "size": [7.609, 2.619, 2.99], "yaw": 0.0402},
    ...
  ],
  "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": 46.322, "device": 75.766, "postprocess": 17.612, "total": 160.927, "decode": 19.268, "model_call": 141.342}
}

• center / size ([length, width, height]) / yaw are in base_link metres / radians, Autoware convention (yaw_ros = -yaw_net - pi/2); label_id is the autoware_perception_msgs ObjectClassification value; detections are sorted by score.
• base and tiny have has_twist: false, so no velocity is returned (as in Autoware). TRAILER and remapped TRUCK labels come from Autoware's area-based class remapper (remap_classes=false turns it off; meta.label_before_remap keeps the network's class).

Demo

The p150 output on the shipped sample (Autoware's test.pcd, one sweep): the p150 boxes in colour over the fp32 CPU reference's boxes (light outlines); a box without a partner would be ringed and tagged.

CenterPoint (base) on p150 vs the CPU reference	CenterPoint-tiny on p150 vs the CPU reference

On public driving datasets (p150 outputs; the frames themselves are not in this repository). The caption of each image gives its agreement with the fp32 CPU reference on that frame.

PandaSet 019, frame 40, base: front camera and bird's-eye view	PandaSet 019, frame 40, tiny
PandaSet 019, frame 40, base: p150 over the CPU reference	PandaSet 019, frame 40, tiny: p150 over the CPU reference
PandaSet 019, frames 00-79 (8 s at 10 Hz), base	nuScenes v1.0-mini scene-0103, key-frame 20, base: non-commercial, CC BY-NC-SA 4.0
Argoverse 2 val log 280269f9, sweep 80, tiny: non-commercial, CC BY-NC-SA 4.0

PandaSet renders: contains data from PandaSet (Scale AI and Hesai), https://pandaset.org, licensed under CC BY 4.0 and the PandaSet Dataset Terms; converted to bird's-eye views and resized camera images with drawn boxes; Scale AI and Hesai do not endorse this work. The nuScenes render is non-commercial (CC BY-NC-SA 4.0): rendered from the nuScenes dataset, © Motional AD Inc., nuScenes Terms of Use; Motional does not endorse this work. The Argoverse 2 render is non-commercial (CC BY-NC-SA 4.0): © 2021 Argo AI, LLC, Argoverse 2 Sensor Dataset; no endorsement by Argo AI is implied. Sources, changes and the full attributions: media/ATTRIBUTION.md.

Demo & Performances

Warm, batch 1, 2026-10-08 (stage bench) and 2026-10-09 (served, load times, agreement, mAP; re-check of the stage bench to within 0.02 ms on the device rows). Latency: the stage bench of OPT_BASELINE.md (code/scripts/bench.py, 100 iterations per stage) on the shipped sample test.pcd (48,048 points, one sweep) and on a PandaSet frame (213,007 points, two sweeps; not shipped); the served rows from uvicorn on the host (the app the container runs) and a loopback client, 50 requests of the shipped sample. The host is shared with other jobs, so the host stages move with its load; the device rows repeat to 0.01 ms. Accuracy: the p150 output against the fp32 CPU reference of the same network (same weights, same pre- and post-processing, identical voxel input), matched by label and BEV centre distance (<= 0.5 m).

Metric	Performance
Agreement with the fp32 CPU reference, shipped sample test.pcd	base 10 / 10 reference detections matched (same label, centres <= 0.5 m; max |Δscore| 0.0092), tiny 3 / 3 (0.0009)
Agreement, all 652 public frames: PandaSet 019 / 090 (100), nuScenes v1.0-mini mini_val (81), Argoverse 2 val, 3 logs (471)	base 45,815 / 46,160 reference detections matched (99.25 %; precision 99.75 %) · tiny 36,833 / 37,012 (99.52 %; precision 99.79 %)
Frozen device gates, 10 development + 54 held-out frames (PandaSet, nuScenes, Argoverse 2, Autoware's sample rosbag)	33 / 33 pass; held-out recall / precision on the 45 public frames base 0.9927 / 0.9975, tiny 0.9939 / 0.9975 (all 54 incl. the 9 rosbag frames: 0.9926 / 0.9973, 0.9938 / 0.9976); score at every reference detection's cell within 0.047 / 0.037 (gate 0.05)
5-class mAP, base on nuScenes mini_val (81 key-frames; nuScenes devkit functions, Autoware's classes)	p150 0.598 · fp32 CPU reference 0.600
5-class AV2-style mAP, tiny on 3 Argoverse 2 val logs (471 sweeps, within 50 m)	p150 0.460 · fp32 CPU reference 0.461
Module PCC vs the fp32 reference (replay outputs; PandaSet 019 f40 voxels)	PFN 0.999985 / 0.999973 · fg-masked heatmap 0.999889 / 0.999899 · sigmoid heatmap 0.999782 / 0.999910 (base / tiny)
Python model() call, shipped sample test.pcd (host pre-processing, H2D, trace, D2H, host post-processing)	base 173.1 ms p50 (5.8 calls/s) · tiny 88.9 ms p50 (11.3 calls/s)
Python model() call, PandaSet frame (213,007 points, 2 sweeps; not shipped)	base 253.6 ms · tiny 238.1 ms p50
Served /predict timing_ms.total (uvicorn on the host, the shipped sample)	base 163.9 ms · tiny 102.9 ms median
Served client round trip, loopback	base 173.2 ms · tiny 111.3 ms median
Device trace, one blocking forward	base 28.09 ms · tiny 16.83 ms
Back-to-back trace replays	base 27.99 ms per forward (35.7 frames/s) · tiny 16.77 ms (59.6 frames/s)
Host pre-processing · input staging + H2D · D2H + unpack · post-processing (test.pcd)	base 66.3 · 11.6 + 9.9 · 13.6 + 29.8 · 22.8 ms; tiny 59.9 · 4.1 + 5.9 · 3.2 + 1.8 · 5.5 ms
from_pretrained load: empty JIT cache / warm cache	base 73.8 s / 7.2 s · tiny 56.5 s / 7.2 s

All numbers in this table were measured with dispatch on the ETH cores, 1 command queue and a 12×10 compute grid on one p150, with the published precision (fp32 weights, bf16 activations). The mAP rows are indicative only: 81 key-frames of 2 nuScenes scenes and 3 Argoverse 2 logs, re-implemented protocols (nuScenes devkit functions with Autoware's 5 classes; an AV2-style AP, not the official CDS), and no published number exists for these weights. Details: VERIFICATION_2026-10-08.md, OPT_BASELINE.md, OPT_REPORT.md.

No GPU comparison: no GPU was available on the host where this port was built and measured, so this card makes no GPU speed claim. The reference rows are the port's own fp32 CPU reference on the same host (a correctness baseline, not a speed target). Autoware runs this network as a TensorRT engine (fp16 by default, trt_precision of the ml_package), with a randomized point selection per pillar; this port is deterministic and was validated against the fp32 reference, not against a TensorRT engine. p150 power was not measured, so no efficiency comparison is made.

Caveats

• First release: baseline port, optimization pending. Each profile runs as one metal trace and is kernel-bound, but 63 % (base) / 69 % (tiny) of its 28.0 / 16.8 ms is layout changes and data movement, and the host stages dominate the end-to-end time (pre-processing 60-205 ms, head-map unpack 2-30 ms and post-processing 6-37 ms per frame on the measured host, OPT_BASELINE.md). OPT_REPORT.md ranks what comes next.
• Deployment status in Autoware: base is the model Autoware's full stack runs by default for LiDAR object detection (autoware.launch.xml leaves lidar_detection_model at centerpoint, which loads base/ of the weights repo); tiny is selectable with lidar_detection_model:=centerpoint/centerpoint_tiny. This bundle is not a ROS 2 node (Python API and HTTP) and not a certified Autoware component; do not use it for safety-critical driving decisions.
• Not ported: the sigma/ (variance heads) and short_range/ (ConvNeXt backbone, opt-in in Autoware and off by default) variants of AutowareFoundation/lidar_centerpoint v4.1; base and tiny are.
• Documented deviations from the node:
  • deterministic voxelization: a fixed seeded permutation (seed 0) and the first 32 points of each pillar replace Autoware's time-seeded GPU shuffle, so the output is reproducible (Autoware's own repeat runs differ slightly); pillar ids keep Autoware's flipped-x order, and above 40,000 pillars the front-most pillars are kept (Autoware drops a race-dependent subset; 1 of 9 two-sweep frames of Autoware's sample rosbag overflows, none of the public frames used here does);
  • points at exactly (0, 0, 0) (the missing returns of organized clouds) and non-finite points are dropped on every input path; Autoware's voxelizer would keep a (0, 0, 0) point;
  • a stable score sort before circle NMS (ties keep the cell order; Autoware's thrust sort is not stable);
  • the voxelization, the decoration, the decode, both NMS and the class remapper run on the host, bit-identical to the CPU reference; the network (pillar feature net, scatter, SECOND, SECONDFPN, CenterHead) on the device;
  • inputs are arrays or files, not PointCloud2 messages; Autoware's 2-sweep densification is a time_lag column, client-side sweeps or the server-side stream state machine (one past sweep per stream id).
• Precision policy of this release: fp32 weights (the device multiplies them at about TF32 precision), bf16 activations, HiFi4 math with fp32 accumulation and packer L1 accumulation everywhere; no bfp8. bf16 weights pass every frozen gate but lose accuracy in base's deep conv stack (block2 PCC 0.980 instead of 0.9955) and its rotation head; fp32 activations into the convs are less accurate on this tt-metal (held-out recall 0.983 / 0.978 instead of 0.993) and 26-35 % slower. So the outputs differ slightly from the fp32 reference (see the agreement rows).
• Decision thresholds turn small differences into different detections. Autoware's decoder keeps a BEV cell only if its score is >= 0.35 and, for cars, trucks, buses and bicycles, its rotation-head norm is >= 0.3; circle NMS keeps the best cell of a 0.5 m neighbourhood; the class remapper relabels by box area (12.1 / 36 m²). A cell within the device's error of one of these thresholds can go either way, in both profiles, so an object near a threshold can appear, disappear or come from the neighbouring cell. Every disagreement found so far is such a flip. The figures below are maxima measured on the stated frame sets, not bounds:
  • 54 held-out gate frames (45 PandaSet / nuScenes / Argoverse 2, 9 from Autoware's sample rosbag): the device matches 99.3 % (base) / 99.4 % (tiny) of the reference's detections and 99.7 % / 99.8 % of its own detections match one; at the cell of every reference detection the scores differ by at most 0.047 / 0.037 (99 % within 0.015 / 0.013); detections from the same cell agree in z within 0.074 / 0.035 m, in size within 1.8 % / 3.5 % and, for car-like objects (orientation SIGN_UNKNOWN in Autoware), in yaw within 0.17 / 0.04 rad, with no pi flips; the rotation-head norm flips the 0.3 gate at 22 of 13,954 (base) and 5 of 7,098 (tiny) reference decision cells, and the largest score difference between matched detections from neighbouring cells is 0.17 / 0.04.
  • 102 other public frames (the second verification round): matched pairs up to 0.19 (base) and 0.37 (tiny) apart in score where an NMS-order or yaw-norm flip makes a neighbouring cell win (tiny: a 0.746 CAR cell dropped at the yaw-norm gate, its 0.379 neighbour kept); same-cell z up to 0.14 m, car-like yaw up to 0.26 rad, size up to 2.4 % (base) / 3.6 % (tiny).
  • all 652 public frames of this release (PandaSet, nuScenes mini_val, Argoverse 2 val): the matched pairs (any pair of the same label within 0.5 m, so neighbouring-cell winners included) differ in score by at most 0.22 (base) / 0.42 (tiny), p99 0.014 / 0.010; in z by at most 0.23 / 0.18 m, in size by at most 24 % / 30 %, in car-like yaw (mod pi) by at most 0.87 / 0.90 rad (p99 0.025 / 0.010 rad); 345 / 179 reference detections have no partner (27 / 48 of them with a score >= 0.40, the highest 0.78 / 0.81), and 6 / 7 of the 652 frames match fewer than 95 % of the reference's detections.
  • Test: code/tt_centerpoint/tests/test_heldout_device.py; the verification reports: VERIFICATION_2026-10-08.md.
• Domain: the weights were trained on nuScenes and TIER IV data (base) and on Argoverse 2 and TIER IV data (tiny); on another LiDAR setup (mounting, beam count, concatenated clouds) accuracy can drop without fine-tuning, as the upstream card says. The public frames here show it in the fp32 reference itself, and the p150 agrees with it: tiny reaches less than half of base's mAP on nuScenes' sparse 32-beam clouds; on Argoverse 2 tiny swaps buses and box trucks (BUS AP 0.03) and base labels 544 regular vehicles TRUCK (likely pickups, which nuScenes counts as trucks); Autoware's remapper turns PandaSet's 12-14 m buses into TRAILER; bicycle AP is low where parked two-wheelers dominate (nuScenes mini_val, PandaSet). On PandaSet the base_link x origin is the pose origin under the roof rig, not the rear axle (offset unknown, not corrected).
• Validation scope: agreement with the fp32 CPU reference of the same network on public driving data (PandaSet, nuScenes v1.0-mini, Argoverse 2 val) and Autoware's sample rosbag, plus the paper-style mAP above (indicative only: small splits, re-implemented protocols, no published number for these weights). The knobs were validated at their Autoware defaults; other values change the outputs on purpose.
• Does not scale to multiple p150 in a mesh configuration. The build uses a 12×10 compute grid of Tensix cores: the dispatch functions move from one Tensix column to the ETH cores (patches/tt-metal-eth-dispatch.patch), so this build assumes that you do not need chip-to-chip ethernet communication.
• dispatch="worker" (server: CENTERPOINT_DISPATCH=worker) is an A/B opt-in. On a p150 it gives an 11×10 grid (28.63 ms per base replay instead of 28.00 ms; 16.46 ms instead of 16.76 ms for tiny); if ETH dispatch is not available (tt-metal without the patch), the model falls back to it with a warning. The numbers on this card do not apply to that mode.
• Batch 1, one frame per request; requests are serialised on the chip; one variant per process (the serve profile). The device input has a fixed size (40,000 pillar rows, a 480×480 canvas), whatever the cloud.
• Not an OpenAI-compatible API; GET /v1/models is a stub so the tt-model ready card does not 404.
• p150 power was not measured, so no efficiency comparison is made.

Licensing

• Weights: AutowareFoundation/lidar_centerpoint at tag v4.1 (commit 494c8171def40bd36cc2feb323e0a5acbfab132b), Apache-2.0 per its model card. Not redistributed here: the package only points to them. The upstream card's training data: base (centerpoint) on nuScenes (about 28k LiDAR frames) plus TIER IV internal data (about 11k), tiny (centerpoint_tiny) on Argoverse 2 (about 110k) plus TIER IV internal data. Its Legal Notice: the nuScenes dataset is released for non-commercial use under CC BY-NC-SA 4.0 and the nuScenes Terms of Use (commercial licenses: nuscenes@motional.com); Argoverse 2 is CC BY-NC-SA 4.0 as well. Read them before commercial use.
• Pre- and post-processing ported from autoware_universe perception/autoware_lidar_centerpoint (Apache-2.0); the thresholds, bins and remapper matrices are read from the weights repo's yaml files at load time.
• Port and serving code (code/): Apache-2.0. patches/tt-metal-eth-dispatch.patch modifies tt-metal (Apache-2.0).
• Sample data: code/tt_centerpoint/samples/test_pcd.npz is derived from autoware_universe's perception/autoware_ground_segmentation/test/data/test.pcd (Apache-2.0): the non-zero returns moved to base_link. Only this redistributable sample ships; the public-dataset frames of the accuracy rows are not in this repository.
• Demo media (media/, sources and changes in media/ATTRIBUTION.md):
  • PandaSet renders: Contains data from PandaSet (Scale AI and Hesai), https://pandaset.org, licensed under CC BY 4.0 and the PandaSet Dataset Terms. Changes: converted to bird's-eye-view renders and resized camera images with drawn boxes. Scale AI and Hesai do not endorse this work. Cite: P. Xiao et al., PandaSet: Advanced Sensor Suite Dataset for Autonomous Driving, ITSC 2021.
  • nuScenes render (media/nuscenes_0103_kf20_base_tt_NC.jpg), non-commercial, CC BY-NC-SA 4.0: Rendered from the nuScenes dataset, © Motional AD Inc., CC BY-NC-SA 4.0 and the nuScenes Terms of Use (https://www.nuscenes.org/terms-of-use). Non-commercial use only; adaptations under the same license. Motional does not endorse this work. Cite: H. Caesar et al., nuScenes: A Multimodal Dataset for Autonomous Driving, CVPR 2020.
  • Argoverse 2 render (media/av2_280269f9_s080_tiny_tt_NC.jpg), non-commercial, CC BY-NC-SA 4.0: Contains data from the Argoverse 2 Sensor Dataset, © 2021 Argo AI, LLC (https://www.argoverse.org), licensed under CC BY-NC-SA 4.0. Non-commercial use only; adaptations are shared under the same license. Changes: image cropped above the ego hood and resized, boxes and bird's-eye view drawn. No endorsement by Argo AI is implied. Cite: B. Wilson et al., Argoverse 2: Next Generation Datasets for Self-Driving Perception and Forecasting, NeurIPS Datasets and Benchmarks 2021.
  • test_pcd_* renders: Apache-2.0.
  • The mAP rows use nuScenes v1.0-mini (CC BY-NC-SA 4.0) and Argoverse 2 Sensor val (CC BY-NC-SA 4.0) annotations; only the resulting numbers are on this card.

Provenance

These are the exact sources the container image was built from:

component	built from
tt-metal	44d66500520fda9f2c7060c0f6b41ec48f7ab37e + patches/tt-metal-eth-dispatch.patch (sha256 08d0ddf6…; dirty tree: the image includes the patch)
weights	AutowareFoundation/lidar_centerpoint@494c8171def40bd36cc2feb323e0a5acbfab132b (tag v4.1), files base/*, tiny/* (ONNX sha256 base dc1a8765… / 3fe7e128…, tiny 2c534657… / 9bb0b634…)
Autoware reference	autoware_universe 9ceaccf026c31ffc5319bc9eeb4bd7bede0af3fd (perception/autoware_lidar_centerpoint, package 0.53.0)
shared package	ttaw 0.20.0, vendored as code/tt_centerpoint/ttaw from the Autoware ports' shared common repository at commit 89dec49 (code/tt_centerpoint/ttaw/VENDORED.json: version, commit and per-file sha256)
code/ digest (image)	f2fa1614b43d8a1c (sha256, first 16 hex digits; built.code_sha256 of tt_kernel_manifest.json)
image	tt-model/centerpoint-p150:d1a00862ad61 (sha256:d1a00862ad61dd7f2830d3f07b794e4dc502b7d41021d6ce737b519a879b5f32)
base images	build stage ghcr.io/tenstorrent/tt-metal/tt-metalium/ubuntu-22.04-dev-amd64:latest @ sha256:df9d279c7f85c17c6fad982d196802682d669cca1b7ced9cbaad8181339cd5fc; runtime stage docker.io/library/ubuntu:22.04 @ sha256:5ec03bb3441e8b0bf3b4f9cd4629a1ae763010dc3035bb8da3ae6cf026486401 (tt-model's FROM tags float; these are the digests this build resolved, see build_info.json)
built	2026-10-09T05:21:32+00:00 by tt-model 0.1.0