transfusion-p150

TransFusion-L (Autoware lidar_transfusion): the LiDAR-only TransFusion network that Autoware's autoware_lidar_transfusion node runs (release t4xx1_90m v2.1, the only model Autoware ships for this node), ported to one Tenstorrent Blackhole p150 with tt-nn. One LiDAR point cloud in base_link in (x, y, z, intensity 0-255; one sweep, or Autoware's 2-sweep densified cloud with a time_lag column); Autoware DetectedObjects-equivalent 3D boxes of CAR, TRUCK, BUS, TRAILER, BICYCLE and PEDESTRIAN out, with the node's pre- and post-processing. In Autoware it is an opt-in alternative: CenterPoint is the default LiDAR detector. Weights: AutowareFoundation/lidar_transfusion v2.1 · Paper: arXiv:2203.11496 · Autoware package: autoware_lidar_transfusion · Training code: tier4/AWML (projects/TransFusion; TransFusion-L base/0.3) · Port: code/

Runs on p150 (mesh P150). Configuration: dispatch on the ETH cores, 1 command queue, 12×10 compute grid. Precision: two-term (hi + lo bf16) weights and activations in the pillar feature net and the SECOND backbone with fp32 sums, fp32 weights and bf16 activations in the neck, head and decoder, HiFi4 math with fp32 accumulation; no bfp8. All numbers on this card were measured in this configuration. This is the second release: the optimized port (8.1× less device time per frame than the first release, see below).

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 and patches/tt-metal-reshape-rm-sys1419.patch applied and tt-metal rebuilt (the container image has both). The second patch avoids a Blackhole DRAM-arbiter deadlock (SYS-1419) in ROW_MAJOR reshapes into small DRAM pages; every number on this card was measured with it. ttnn is not on PyPI.

hf download changh95/transfusion-p150 --exclude "image/*" --local-dir transfusion-p150 && cd transfusion-p150
pip install -e .                        # adds numpy<2, pillow, pyyaml, onnx, huggingface_hub, numba; 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_transfusion/samples/test_pcd.npz (Autoware's test.pcd) is a path relative to it.

from tt_transfusion import TransFusion

with TransFusion.from_pretrained(device_id=0) as model:          # weights -> your HF cache, traces captured
    out = model("code/tt_transfusion/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 AutowareFoundation/lidar_transfusion at the pinned commit 8f07eb93038 (tag v2.1, 172 MB) to your HF cache, opens the chip, builds the graph and captures the metal traces (one per pillar-capacity bucket, 9 in all). The first load compiles the kernels (157 s with an empty JIT cache); later loads take about 18 s.
• The traces are captured during the load, so the first call is about as fast as the later ones (41.3 / 38.5 ms, first / second call on the shipped sample).
• The with block releases the traces 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 (0-255, Autoware's uint8 value; TransFusion uses it). 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=0.1, circle_nms_dist_threshold=0.5, iou_nms_threshold=0.1, iou_nms_search_distance_2d=10.0, remap_classes=True, max_detections=None; sampling="clean" | "autoware_compat" (an input keyword). from_pretrained(device_id=0, 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 / skip flags, sampling, per-stage counts, 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_transfusion.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).
• sampling picks how the points of a pillar are chosen: clean (default, deterministic: the first 20 points of each pillar in input order) or autoware_compat (an emulation of the deployed node's capacity-wide shuffle, including its skip of frames with fewer than 5,000 or more than 60,000 pillars).
• 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/transfusion-p150 --with-weights
tt-model serve changh95/transfusion-p150       # or with tt-cli: tt serve changh95/transfusion-p150
python3 code/tt_transfusion/server/client.py --points code/tt_transfusion/samples/test_pcd.npz --out req.json
curl -s localhost:20000/predict -H 'Content-Type: application/json' -d @req.json
tt model stop changh95/transfusion-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.
• client.py builds the request with the standard library only; add --url http://127.0.0.1:20000 to send it.
• POST /predict: points (base64 .npy / .npz / .pcd / raw bin, base_link, fields x, y, z, intensity (0-255) 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), sampling, params (every option above), output_format. Also GET /health, GET /info, GET /v1/models (stub). Contract: SERVING.md section 3.

{
  "model": "transfusion-p150",
  "frame_id": "base_link",
  "num_detections": 5,
  "detections": [
    {"label": "TRUCK", "label_id": 2, "score": 0.3686, "center": [-19.688, 33.146, 1.187], "size": [6.132, 1.572, 1.868], "yaw": -2.8107},
    {"label": "TRUCK", "label_id": 2, "score": 0.1476, "center": [-34.117, 31.017, 1.918], "size": [7.078, 1.633, 2.0], "yaw": -0.7621},
    ...
  ],
  "meta": {"variant": "default", "num_points": 48048, "num_pillars": 13058, "pillar_overflow": false, "sampling": {"mode": "clean", "offset": 0}, "counts": {"proposals": 500, "after_threshold": 6, "after_circle_nms": 6, "after_iou_nms": 5}},
  "timing_ms": {"preprocess": 5.539, "device": 23.802, "postprocess": 0.7, "total": 49.308, "decode": 19.009, "model_call": 30.066}
}

• center / size ([length, width, height]) / yaw are in base_link metres / radians, Autoware's convention for this node (z is the box centre, yaw counter-clockwise from +x); label_id is the autoware_perception_msgs ObjectClassification value; detections are sorted by score.
• No velocity is returned (Autoware ignores the network's velocity rows). 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, Apache-2.0): the p150 boxes in colour over the fp32 CPU reference's boxes (light outlines); a box without a partner would be ringed and tagged.

TransFusion-L on p150 vs the CPU reference, test.pcd

On public driving datasets (p150 outputs; the frames themselves are not in this repository; dataset boxes in thin grey):

PandaSet 019, frame 40: front camera	PandaSet 019, frame 40: p150 over the CPU reference
PandaSet 090 (El Camino Real), frame 40: front camera	PandaSet 090, frame 40: bird's-eye view, ±92 m
PandaSet 019, frames 20-59 (4 s at 10 Hz)	PandaSet 019, frame 40: bird's-eye view, ±60 m
nuScenes v1.0-mini scene-0103, key-frame 20: non-commercial, CC BY-NC-SA 4.0	the same frame from above: non-commercial, CC BY-NC-SA 4.0

These renders show the first release's outputs. Agreement with the fp32 CPU reference on these frames (same label, centres <= 0.5 m), first release: PandaSet 019 f40 79 of 80 reference detections (the miss is a class-remapper flip of one 12.8 m vehicle: 36.2 m² on the CPU, TRAILER; 35.9 m² on the p150, TRUCK); PandaSet 090 f40 111 of 113 (two cars dropped at the yaw-norm gate); nuScenes 0103 key-frame 20 22 of 22; the 40 frames of the animation 3,504 of 3,520. This release (frozen-gate run): PandaSet 019 f40 79 of 80, PandaSet 090 f40 112 of 113, nuScenes 0103 key-frame 20 22 of 22.

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 (licence plates and faces of nearby road users blurred) with drawn boxes; Scale AI and Hesai do not endorse this work. The nuScenes renders are 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. Sources, changes and the full attributions: media/ATTRIBUTION.md.

Demo & Performances

Warm, batch 1, measured 2026-10-11 on the code of this release. Latency: the stage bench of OPT_BASELINE.md (code/scripts/bench.py, 100 iterations per stage, back-to-back replays 5 × 50) on the shipped sample test.pcd (48,048 points, one sweep, 13,058 pillars: the 16,384-pillar bucket) and on a PandaSet frame (213,007 points, two sweeps, 38,158 pillars: the 40,960 bucket; not shipped), from the independent re-measurement VERIFICATION_OPT_2026-10-11.md; 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 (load average 4-5), 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
Back-to-back trace replays (device time per frame)	17.16 ms (58.3 frames/s) on test.pcd; PandaSet frame 18.04 ms (55.4 frames/s)
Device trace, one blocking forward	17.23 ms (test.pcd); PandaSet 18.11 ms
Python model() call, shipped sample test.pcd (host pre-processing, H2D, trace, D2H, host post-processing)	36.0 ms p50 (27.8 calls/s; p99 38.7 ms)
Python model() call, PandaSet frame (213,007 points, 2 sweeps; not shipped)	71.0 ms p50 (14.1 calls/s)
Served /predict timing_ms.total (uvicorn on the host, the shipped sample; includes 19.1 ms of request decoding)	49.6 ms median
Served client round trip, loopback (709 kB request)	57.1 ms median
This container image, served (tt-model serve, ETH, 12×10)	smoke test PASS (5 / 5 reference detections matched on test.pcd, max |Δscore| 0.0027); ETH stress of 2,400 /predict requests (8 clouds derived from test.pcd, 6,253 to 67,493 pillars: 8 of the 9 pillar buckets plus the overflow path): 0 errors, every repeated output bit-identical to the first, test.pcd output identical to the smoke run's; test.pcd timing_ms.total median 69.0 ms (round trip inside the container 77.3 ms), measured while the host ran other jobs (load average 8 on 8 cores), so the host stages are slower than in the served rows above
Host pre-processing · input staging + H2D · D2H + unpack · post-processing (test.pcd)	10.7 · 2.7 + 3.5 · 0.63 + 0.28 · 0.73 ms
First release (2026-10-09), for comparison	device per frame 139.39 ms (7.17 frames/s); model() on test.pcd 211.8 ms, PandaSet 356.7 ms; served 227.7 ms
Agreement with the fp32 CPU reference, shipped sample test.pcd	5 / 5 reference detections matched (same label, centres <= 0.5 m; max |Δscore| 0.0027)
Agreement, 21 development frames (test.pcd, PandaSet ×8, nuScenes mini_val ×5, Argoverse 2 val ×3, Autoware's sample rosbag ×4)	1,002 / 1,009 reference detections matched (recall 0.9931, precision 0.9931); score of the same proposal within 0.0163 (gate 0.05); yaw-norm gate flips 2 of 1,068 decision proposals
Agreement, 34 held-out frames never used for any precision choice	recall / precision PandaSet (16 frames) 0.9965 / 0.9957, nuScenes (9) 0.9906 / 0.9953, Argoverse 2 (9) 0.9981 / 0.9981; same-proposal score within 0.0124
Strong heatmap proposals (heat ≥ 0.1) selected by the device top-k, PandaSet 019 f40 / nuScenes 0103 k20 / rosbag frame 150	174 / 174 · 58 / 58 · 35 / 35 (frozen gate: 100 %)
Module PCC vs the fp32 reference (replay outputs, teacher-forced; worst of the three frames above)	pillar feature net 0.999996 · SECOND block2 ≥ 0.999939 · heatmap ≥ 0.999936 · worst module (rotation head) 0.999597
First release only (not re-run on this release): agreement on 40 public frames new to the port (independent verifier, two rounds); PandaSet 019 frames 20-59 (the demo animation)	recall / precision 0.994 / 0.998 and 0.995 / 0.996; 3,504 / 3,520 (99.55 %; precision 99.38 %)
from_pretrained load: empty JIT cache / warm cache	156.7 s / 17.7 s (9 traces; first / second call after the warm load 41.3 / 38.5 ms)

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, on tt-metal 44d66500520 with both patches of patches/. The first-release row was measured on 2026-10-09 on the same tt-metal without the reshape patch; on today's build the first release's code takes 141.66 ms per frame (141.71 ms on the PandaSet frame), so the device speed-up of this release is 8.1× against the published figure and 8.3× (7.9× on the PandaSet frame) on the same build; a model() call is 5.9× (test.pcd) and 5.0× (PandaSet) faster. All optimization steps but one give bit-identical outputs; the two-stage top-k (round 3) picks a different query of 500 on a heatmap tie, which moves every proposal's bits slightly through the decoder's self-attention and passes every frozen gate (the accuracy rows above are this release's). The demo renders above are from the first release; this release matches them detection for detection on test.pcd (5 / 5) and PandaSet 019 f40 (80 / 80, largest differences 0.004 in score, 2.1 cm in centre, 0.11 rad in yaw). No paper-style metric (mAP / NDS) is claimed: these weights were trained on TIER IV's internal data only, so a score on nuScenes, PandaSet or Argoverse 2 would measure the domain gap, not the port; the accuracy rows are agreement with the CPU reference. Details: OPT_REPORT.md (every optimization step with its A/B), OPT_BASELINE.md (before / after), VERIFICATION_OPT_2026-10-11.md (independent re-measurement and audit of this release), VERIFICATION_2026-10-09.md (first release).

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 with a shuffled point selection per pillar; this port was validated against the fp32 reference, not against a TensorRT engine. p150 power per inference was not measured (the stage bench only logged the board's telemetry, median 69 W over the whole run including the host stages), so no efficiency comparison is made.

Caveats

• Second release: the optimized port (rounds 1-4 of OPT_REPORT.md, each step one commit with an environment knob and a same-session A/B). A frame replays one metal trace per pillar-capacity bucket (8,192 to 65,536 pillars; the smallest bucket that holds the frame). Custom ttnn.generic_op kernels: M1, a module megakernel for the two-term pillar feature net and the scatter (one program per bucket on all 120 cores, an in-kernel grid barrier; 1.05 ms at the 16,384 bucket, where the first release spent about 110 ms in stock ops), and the two-term epilogues of the SECOND convs and of the head's shared conv. The pre- and post-processing run as compiled (numba) host code. No whole-model megakernel: the activations do not fit L1 (the 768×768×64 canvas alone is 75 MB in bf16) and the trace is kernel-bound, not dispatch-bound. The rest of the device time is the two-term SECOND backbone (about 12 ms) and the head and query decoder (about 3.5 ms); the last device profile is from round 3 (22.2 ms of kernel time); round 4 was measured with traced timings, not re-profiled.
• Deployment status in Autoware: opt-in, not the default. Autoware's launch defaults lidar_detection_model to centerpoint; TransFusion runs with lidar_detection_model:=transfusion, and v2.1 (t4xx1_90m) is the only model the node ships. 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 other TransFusion-L releases of AWML (base/0.4-0.6, the 120 m offline and 50 m nearby models), which Autoware's artifacts do not pin.
• Documented deviations from the node:
  • deterministic point sampling by default (sampling="clean": the first 20 points of each pillar in input order), where the deployed node shuffles the whole cloud with a fixed seed and keeps whatever its GPU atomics leave; sampling="autoware_compat" emulates that shuffle (not bit-exact to the GPU order);
  • at most 65,536 pillars, a fixed device capacity above Autoware's 60,000: no clean-sampled frame seen so far is cut (the densest, a 2-sweep frame of Autoware's sample rosbag, has 62,527), where Autoware would skip a frame above 60,000 (autoware_compat does too). Above 65,536 the first pillars in raster order are kept and meta.pillar_overflow is set; frames below Autoware's 5,000-pillar minimum run and are flagged in meta.autoware_would_skip;
  • 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;
  • the voxelization, the 11-feature decoration (fp32), the decode, both NMS and the class remapper run on the host, bit-identical to the CPU reference; so does the last step of the head, cls_score = query_heat · σ(heatmap) and center + query_pos in fp32. The network (pillar feature net, scatter, SECOND, SECONDFPN, dense heatmap, local max, top-500, the transformer decoder layer, the box heads) runs 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.
• Precision policy of this release: HiFi4 math with fp32 accumulation everywhere; the pillar feature net computes two-term (hi + lo bf16) products with fp32 hidden tensors and fp32 bias adds; the 16 SECOND convs use two bf16 weight terms and two-term activations; the neck, head and decoder use fp32 weights and bf16 activations; no bfp8. Every simpler variant measured in the port (one-term pillar net, bf16 SECOND weights or activations, fused biases) loses strong heatmap peaks on PandaSet, which the frozen 100 % gate forbids. In the first release this policy cost 112 ms of the 139 ms trace (OPT_BASELINE.md); this release keeps it unchanged and runs the pillar-net part and the conv epilogues in custom kernels.
• Heatmap peak near-ties: a heatmap cell becomes a proposal only if it is the maximum of its 3×3 neighbourhood, and the device compares the heat in bf16 (a resolution of about 0.4 %). When the fp32 reference decides that by less than about 0.5 % of the heat, the device's small heatmap error can pick the neighbour instead (a missed proposal) or in addition (an extra proposal next to a reference peak). On the three gate frames all 267 strong proposals (heat ≥ 0.1) are selected, including the eight that lead their neighbours by less than 1 % (0.07-0.78 %; on PandaSet 019 f40 two of 174 by less than 0.5 %), and every strong proposal decided by more than 1 % is selected (100 %, a frozen gate). Over the 55 evaluation frames, 3 of 3,118 reference decision proposals (raw score above 0.1) are not selected, and the device adds 22 decision proposals that the reference's top-500 does not hold (highest score 0.84). Most fall to NMS, but on held-out PandaSet 019 frame 75 one becomes a duplicate 0.84 PEDESTRIAN, 0.70 m from the matched one.
• Decision thresholds turn small differences into different detections: the score threshold 0.1, the yaw-norm gate (a car, truck, bus or bicycle proposal is dropped when its rotation-head norm is below 0.3), circle NMS (0.5 m), IoU-BEV NMS and the class remapper (by box area: CAR to TRUCK at 12.1 m², to TRAILER at 36 m²). A proposal within the device's error of one of them can go either way. Measured on this release: yaw-norm flips at 2 of 1,068 (development) and 4 of 2,049 (held-out) decision proposals; the rotation-head norm differs from the reference by at most 0.46 at one proposal of the development frames (99th percentile per frame at most 0.39) and by at most 0.24 on the held-out frames (at most 0.14); on the first release, the independent verifier saw a 0.81 CAR on an Argoverse 2 frame new to the port dropped at the gate (reference norm 0.303, device 0.212). On the demo frame PandaSet 019 f40 one vehicle is TRUCK on the p150 and TRAILER on the CPU (35.9 vs 36.2 m²). The agreement rows above include all of these.
• Domain: the weights were trained on TIER IV's internal JPNTAXI data (Japanese taxis); on another LiDAR setup accuracy can drop without fine-tuning, as the upstream card says. The fp32 reference itself shows it on the 16 public development frames (PandaSet, nuScenes, Argoverse 2), and the p150 agrees with the reference there (rows above): vehicles within 50 m are found well (recall 0.85-0.93 against the dataset annotations); pedestrians in groups and standing or sitting people are often missed (recall 0.33-0.48; one proposal per tight group after the 3×3 local max); parked bicycles are not detected; Autoware's remapper turns 12-14 m buses into TRAILER. These are indicative counts of the CPU reference on 16 frames, not a benchmark. 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), Autoware's sample rosbag and test.pcd; the knobs were validated at their Autoware defaults.
• 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: TRANSFUSION_DISPATCH=worker) is an A/B opt-in. On a p150 it gives an 11×10 grid, for which this release is not tuned: 19.79 ms per replay instead of 17.16 ms on test.pcd (20.78 instead of 18.04 ms on the PandaSet frame; 110 instead of 120 cores, and block1's L1-path convs do not fit 110 cores and fall back to DRAM slicing), with outputs bit-identical to ETH's (checked in round 4); 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. The device input has fixed sizes: nine pillar-capacity buckets (8,192 to 65,536 pillar rows of 32 points, two pillars per input tile) and a 768×768 canvas index; every bucket gives the same outputs as the full 65,536 trace (checked bit for bit on the device).
• Not an OpenAI-compatible API; GET /v1/models is a stub so the tt-model ready card does not 404.
• p150 power per inference was not measured (only board telemetry during the stage bench), so no efficiency comparison is made.

Licensing

• Weights: AutowareFoundation/lidar_transfusion at tag v2.1 (commit 8f07eb93038bfd62e35d1f78e56a6b3fb76b12aa), Apache-2.0 per its model card. Not redistributed here: the package only points to them. The upstream card's training data: TIER IV's internal database (DB JPNTAXI, about 11k LiDAR frames, not public); no public-dataset license applies to the weights.
• Pre- and post-processing ported from autoware_universe perception/autoware_lidar_transfusion (Apache-2.0); the thresholds, the class names and the 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 and patches/tt-metal-reshape-rm-sys1419.patch modify tt-metal (Apache-2.0).
• Sample data: code/tt_transfusion/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 (licence plates and faces of nearby road users blurred) 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 renders (media/transfusion_nuscenes_0103_kf20_tt_*_NC.*), 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.
  • transfusion_test_pcd_tt_vs_cpu.png: Apache-2.0.
  • The agreement rows use nuScenes v1.0-mini (CC BY-NC-SA 4.0), Argoverse 2 Sensor val (© 2021 Argo AI, LLC, CC BY-NC-SA 4.0), PandaSet (CC BY 4.0 + Dataset Terms) and Autoware's sample rosbag (license unstated) as inputs; 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…) + patches/tt-metal-reshape-rm-sys1419.patch (sha256 6be07ce5…) (dirty tree: the image includes both patches)
weights	AutowareFoundation/lidar_transfusion@8f07eb93038bfd62e35d1f78e56a6b3fb76b12aa (tag v2.1), files transfusion.onnx, transfusion_ml_package.param.yaml, detection_class_remapper.param.yaml, deploy_metadata.yaml (ONNX sha256 1d8f0ee6…)
Autoware reference	autoware_universe 9ceaccf026c31ffc5319bc9eeb4bd7bede0af3fd (perception/autoware_lidar_transfusion, package 0.53.0)
shared package	ttaw 0.23.2, vendored as code/tt_transfusion/ttaw from the Autoware ports' shared common repository at commit 60b6dd7 (code/tt_transfusion/ttaw/VENDORED.json: version, commit and per-file sha256)
code/ digest (image)	827057fc70e0aca0 (sha256, first 16 hex digits; built.code_sha256 of tt_kernel_manifest.json)
image	tt-model/transfusion-p150:129a77b8c0b7 (sha256:129a77b8c0b7a3845f6ea8cbdcb4ecec59a1c95c26fd4932d7b691301c4895d4)
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-11T12:35:26+00:00 by tt-model 0.1.0