Dalaran puts robot data on one clock
Dalaran records and displays time-indexed data from robots, simulators, and offline jobs. Camera frames, point clouds, IMU readings, transforms, and ordinary series can share one timeline. The same Arrow-backed chunks can be viewed in 2D or 3D and queried as dataframes. Python, Rust, and C++ clients log into a viewer, a file, or a remote endpoint. The checked-out repository is substantial: 8,176 files, about 876,821 source lines, and 42.1 MB.
The project is a hard fork of Rerun, and that ancestry matters. Dalaran says its .dlr container retains the RRF2 framing used by upstream .rrd recordings. It accepts the older extensions and reads chunks whose metadata uses either namespace. Saved upstream layouts have only partial compatibility, however, and very old recordings may still need migration. A team moving existing files should test the layouts it depends on, not stop after confirming that sensor data opens.
The advertised robotics layer conflicts with its own roadmap
The README says several robotics features work today: a high-level robot API, ROS 2 bridging and bag replay, axis-convention helpers, occupancy grids, costmaps, a diagnostic command, and portable dataset bundles. ROADMAP.md tells a different story. It puts the robot API, axis helpers, costmaps, diagnostics, and direct .rrd opening in near-term work. ROS 2 bridging and .dlrpack bundles sit in the mid-term section.
That contradiction changes the decision more than the 823 GitHub stars do. A prospective user cannot tell which document describes commit da14440 without inspecting source and trying each required path. The roadmap also says dates are deliberately absent and its items are intentions rather than promises. Dalaran may already contain partial implementation, but the two documents do not provide a dependable boundary between shipped and unfinished behavior.
What happened when we ran it
Our sandbox installed 33 Python packages in 29 seconds and used 36 MB on disk. The build completed in another 9 seconds. Those two steps make the Python surface cheap to inspect. Pip-audit reported 0 known vulnerabilities among the installed dependencies. These measurements came from commit da14440 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets.
The test result was poor. Pytest stopped with exit code 1 after 15 seconds: 49 tests passed, 29 failed, and 96 produced collection or setup errors out of 174. The tail lists failures across validators, vector data, versions, video helpers, views, coordinates, the viewer client, viewport blueprints, and two log benchmark modules. That tail does not contain the underlying exceptions, so it cannot support a claim about missing packages or broken code. It does show that the full command did not pass in our fresh environment.
The repository includes a tests directory, yet our scan found 0 GitHub CI workflow files and no Dockerfile. A local suite can still be well maintained, and external automation may exist, but neither signal gives a new adopter a visible reference environment. Until the maintainers publish one, teams should preserve their exact toolchain and treat a clean run as an adoption requirement.
Source development needs Rust, Pixi, PyO3, and Git LFS
The one-minute Python example hides most contributor setup. BUILD.md pins Rust 1.95.0 and uses Pixi to prepare commands and environments. PyO3 needs a generated configuration file before direct Cargo work. Git LFS is described as generally required for the proper development environment because test snapshots live there. On Windows, C++ builds also require Visual Studio 2022. That is reasonable for a multilingual viewer, but it is far beyond installing 33 Python packages.
Graphics and platform differences add another branch. The native viewer uses wgpu; the diagnostic material refers to adapters and drivers. A web viewer build requires the wasm32-unknown-unknown target and a feature flag. Windows users must also make sure Git creates symlinks. The build guide documents these details better than the quick start, which is useful once a developer knows which layer they are actually trying to change.
Pre-1.0 support means following the latest release
Dalaran's status section says the API is evolving and breaking changes should be expected between releases. Its security policy supports only the latest released version, with fixes landing on the main branch before the next release. GitHub's latest-release endpoint returned no published release for this repository, even though the README links package registries and mentions prerelease wheels. That mismatch deserves clarification before a production rollout.
The last push recorded by GitHub was August 12, 2026. GitHub listed 8 open issues and pull requests, and every returned open item was an automated dependency pull request. This is recent maintenance activity, but it gives little evidence of user discussion around ROS compatibility, recording migration, or the failed test areas. The project has an Apache-2.0 license and a private security-reporting path, both sensible foundations for self-hosting.
Rerun remains the safer default today
Dalaran has a clear reason to exist: robotics teams often need typed costmaps, frame conventions, bag replay, and synchronized sensor review rather than a generic plotting tool. The problem is proof. At commit da14440, 125 of 174 tests either failed or errored in our run, and the public documents disagree about whether the main differentiators have shipped.
Try Dalaran in a disposable environment if one of those additions solves a specific pain, especially if existing .rrd data must remain readable. Keep Rerun beside it during evaluation and compare real recordings, saved layouts, ROS messages, and export behavior. A team choosing its standard viewer should wait for a clean suite and one authoritative feature list.