Seeing the Long-Range Gap: Exploring Torc’s TruckDrive in FiftyOne

TruckDrive is a long-range highway driving dataset built to expose a problem most autonomous-driving data hides. City datasets top out around 100 meters of useful perception range, which is fine for a car creeping through an intersection. It is not fine for a fully loaded semi-truck at highway speed, which needs 150 to 200 meters just to stop. When you load TruckDrive into FiftyOne, you can see that today's best perception models are not ready for that distance.

This post walks through what TruckDrive is, why it's worth loading into FiftyOne, and the things you can see for yourself with the companion notebook.

TruckDrive: Long-Range Autonomous Highway Driving Dataset (Torc Robotics and Princeton, CVPR 2026) is a highway-scale, multimodal driving dataset captured from a sensor suite purpose-built for long range. It pairs seven long-range FMCW LiDARs (AEVA Aeries II, measuring range and per-point radial velocity out to ~400 m), three short-range LiDARs, eleven 8MP cameras at varying focal lengths, and ten 4D FMCW radars. The result is roughly 475,000 synchronized samples, 165,000 of them densely annotated, with 2D labels out to 1,000 meters and 3D labels out to 400 meters across 15–25 second clips at highway speed.

The headline finding is the part worth dwelling on.

The models don't gradually degrade — they hit a wall. The paper frames this as a systematic "long-range gap" that current architectures and training signals simply don't close, largely because they were shaped by short-range urban benchmarks where the problem never showed up.

That gap is a safety problem, not an academic curiosity. At highway speed, the distance where models break is precisely the distance a truck needs to see to brake in time.

A 99% performance drop is a striking number in a table. It is far more convincing when you can scroll to a truck sitting 200 meters down the road, see that the ground truth has it labeled, and watch the model miss it entirely.

That's the case for putting TruckDrive into FiftyOne. The dataset's whole point is distance, and FiftyOne lets you make distance a first-class, interactive dimension: tag every object with its range from the ego vehicle, filter and slice by it in the sidebar, color the grid by whether each detection was a hit or a miss, and jump straight to saved views of the failures. Instead of reading that recall collapses past 150 meters, you drag a slider and watch it happen.

FiftyOne also handles the multimodal side that makes TruckDrive distinctive. The same frame can hold a camera image, a 3D point cloud, and the relationship between them — all browsable together, all queryable. For a dataset built around an unusual long-range sensor stack, being able to see the sensors side by side matters.

This companion notebook loads a single real scene (no synthetic stand-in) and builds a set of FiftyOne datasets you can explore in the App. Everything below runs on data you download with the official devkit script, cached so it never re-downloads.

The long-range failure story is the centerpiece. The notebook tags every annotated object with its distance_from_ego, attaches model predictions, runs detection evaluation, and reports recall as a function of distance band. It saves two views — one that jumps straight to the long-range misses, and one that shows the model doing fine up close — so the contrast is a single click. In the App you can drag the distance filter yourself and color the grid by the evaluation result to explore the failure modes interactively.

The FMCW LiDAR point clouds are the visually striking part. Each frame becomes a 3D scene you can orbit and fly through, with points colored by their distance from the truck — near returns warm, far returns cool. Coloring by range isn't arbitrary: it makes the sensor's long reach immediately legible, which is the entire reason this dataset exists. There are bird's-eye orthographic previews too, so you can scan the spatial layout of each frame from the grid.

The grouped camera + LiDAR view ties a frame's image and its point cloud into one sample, joined by a shared sync ID. A slice selector lets you flip between the camera view (with its detections) and the 3D cloud of the same moment.

The projection overlay paints the LiDAR points directly onto the camera image, colored by distance band. Getting this right meant reading the real calibration: the camera intrinsics from the dataset's ROS CameraInfo files, and the LiDAR-to-camera transform composed by chaining the transform tree (velodyne → cab → camera). When it renders, you see the sensor's depth structure laid over the photo — points blanketing the road, the truck ahead, and the tree line, graded by range.

The Aeva sensors also report a per-point FMCW radial velocity, and the obvious dream demo is coloring points red/blue by whether they're approaching or receding.The catch is that the raw velocity is measured in the sensor's own frame, so the entire static world appears to rush toward the moving truck, and separating genuine movers from that ego-motion background requires compensation tied to the dataset's exact velocity convention — which lives in the devkit, not in anything we could reliably reverse-engineer from the numbers. Rather than ship a plausible-looking but wrong visualization, the notebook colors by range, which it can stand behind completely. It's a good reminder that a demo you can trust beats a demo that merely looks impressive.

If you want to take this further, a few directions stand out. Pulling the official devkit's point-cloud loader would let you add the FMCW velocity coloring correctly — using the poses modality for ego-motion compensation — which is the one genuinely unique visualization the sensor enables. Swapping the notebook's placeholder detector for a real model turns the recall-vs-distance curve into an actual benchmark of your model's long-range gap. And scaling from one scene to several would populate the far distance bands more densely and show the failure mode is systematic rather than a quirk of a single clip.

The broader invitation is the one the paper makes: the long-range gap is an open problem. Being able to see it — to scroll to the object a model missed at 200 meters and ask why — is where the work starts.