# SuperMap fuses geometric SLAM with open-vocabulary perception into a 4D scene graph

> SuperMap is a training-free spatio-temporal SLAM system from Carnegie Mellon University's AirLab that builds a persistent semantic world model where every object carries spatial and temporal information, and it emits one JSON schema whether it runs offline on a dataset or live over ROS2. The repository currently holds a README and a paper directory, with the code announced for release after the conference.

**superxslam/SuperMap** — SuperMap is a living spatial memory for embodied AI — it perceives the world, remembers its evolution, and supports reasoning and action.

- Repository: https://github.com/superxslam/SuperMap
- Stars: 406 · Forks: 13
- Language: Unknown
- License: not declared
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/superxslam-supermap

## The repository is a README and a paper link

What is on offer today is a design document, not an implementation. The top level holds a README and a paper directory, and an announcement near the top states that the code will be released after the conference. Two news items are dated 2026-07-15: the project website and teaser video going live, and the initial README and overview being published. The last push to the default branch is dated 2026-07-16.

That shapes what a reader can do with it. The install commands are written out in full, the topics and outputs are named, the configuration files are identified, and the paper is available, but none of it can be executed against this repository yet.

There is a naming hazard worth naming too. Searches for this project name are dominated by an unrelated commercial geographic information system product family, which is why the README links a project website rather than expecting the repository name to be findable. If you arrive from a search engine, check the authorship before you conclude you have found the wrong thing.

The affiliation is stated plainly on the page, a robotics laboratory at Carnegie Mellon University, and the paper is a robotics conference paper for 2026 with ten authors listed.

## Two titles, one system

The page heading and the citation block disagree about what the system is called, and both cannot be the title of the paper.

The heading calls it a living spatial memory for embodied AI. The citation entry calls it a spatio-temporal SLAM system for visual-language navigation. Same authors, same venue, same year, two different titles, which usually means the framing shifted between the poster and the submission.

For anyone writing about the work or citing it, the citation block is the one to use, since it is the form the authors intend to be cited in. The heading is a slogan.

A second small artefact survives in the highlights: one bullet describes a queryable 4D scene graph supporting spatial and temporal reasoning, and the word temporal is missing its final letter in the text. That is the kind of detail that tells you the highlights were written quickly and reviewed once, which is fine for a teaser and worth remembering when a bullet is the only description of a subsystem you are meant to trust.

## Geometry runs fast, perception runs asynchronously

The core claim is architectural. SuperMap is described as a training-free spatio-temporal SLAM system that builds a persistent semantic world model, and it works by fusing high-frequency geometric SLAM with asynchronous open-vocabulary perception.

The split is what makes it interesting. Geometric SLAM is cheap and fast and produces a consistent camera and depth frame at high rate, while open-vocabulary perception, meaning recognising named things rather than a fixed set of classes, is slow and expensive. Running perception asynchronously means the object layer updates at its own pace and the geometric layer keeps running between updates.

The output is a 4D scene graph, described as a queryable map carrying both spatial and temporal information for every object. That is the load-bearing phrase: a map with time attached is what makes long-horizon reasoning possible, since an agent can ask what was where, not only what is where.

Identity across time is handled by 3D-aware instance association, which the highlights describe as giving stable identities across occlusions and scene changes, and persistent object identities are what let the system record how a scene evolves rather than only what it contains at one instant.

## The detector is a choice, not a dependency

The perception side is pluggable. The system is described as model-agnostic, working with an open-vocabulary grounding detector, a real-time detector, and pre-baked detections, meaning detections produced elsewhere can be fed in rather than computed on the fly.

That last option is the one that matters for evaluation. Running on a stored dataset with detections you already trust removes the detector from the error budget entirely, which is how you find out whether the mapping is the weak link or the recogniser is.

The offline example exposes the choice on the command line, along with a data directory, a config file, and a flag for the window to rerun over. The detection vocabulary itself is not in code: it is defined in a prompts configuration file, which means adding a new category of object is a text change.

The components named at the bottom of the page are the pieces the system builds on, including a segmentation model, the grounding detector, the real-time detector, and a multi-object tracking method. Those are credits for upstream work, not an exhaustive dependency list, and nothing in the README says which of them the released code will require at run time.

## One schema, whether the robot is there or not

The interface decision is the one that will age best. Both the offline mode and the live mode emit the same per-frame JSON structure, from the same serialization module, and the fields are listed: a 3D bounding box, a label, an identity, a centre, spatial relations, a status, and the timestamp of the latest observation.

That means a downstream consumer, whether it is a navigation policy, a language model, or a logging tool, can be written once. Without it, every consumer needs two code paths, and the offline path is the one that gets tested while the live path quietly rots.

Live mode publishes concrete topics: per-object point clouds under one name, labelled boxes under another, and annotated images. It subscribes to four inputs, namely RGB images, camera info, a point cloud topic, and odometry. Those five subscriptions are the entire contract with the robot, which is a short contract and means integrating with a different robot is mostly a matter of remapping topics and extrinsics.

Topic, extrinsic, and detector settings live in one YAML file. Configuration is therefore split in exactly two places, one file for how the system is wired and one for what it looks for.

## Live mode is a ROS2 package, not a script

Running against a live robot is a different kind of task than running on a dataset, and the README treats it as one.

The repository is cloned into the source directory of a workspace under a specific package name, built with a package selection flag, the workspace environment sourced, and a launch file started. The package name matters because it is what the build selection and the launch call both refer to, so renaming the checkout without renaming the package breaks the launch.

The stated requirements are Ubuntu 22.04 or 24.04, an NVIDIA GPU with at least 16 GB of video memory, Python 3.10 or newer, and a ROS2 Jazzy workspace for live mode. A Jazzy workspace is only required for live mode, so the offline path can be run without installing a robotics distribution at all, which is the cheap way to find out whether the system works on your data.

The 16 GB figure is the constraint that will decide your hardware. The highlights claim real-time performance on robot hardware, and both perception models and a tracking method have to fit at once, so this is a machine with a discrete GPU rather than a laptop.

## Setup pins the CUDA stack by hand

The install sequence is unusually explicit for a research system, and it pins a specific CUDA release.

```bash
conda create -n supermap python=3.11 && conda activate supermap

pip install torch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 --index-url https://download.pytorch.org/whl/cu124
conda install cuda -c nvidia/label/cuda-12.4.0
export CUDA_HOME=$(dirname $(dirname $(which nvcc)))

pip install -r requirements.txt
python -m spacy download en_core_web_sm
```

Three things are worth pulling out. The tensor stack is pinned to exact versions from a specific CUDA index, and the CUDA toolkit itself is installed as a pinned labelled channel rather than whatever the driver shipped with. The build variable is then derived from wherever the compiler lives on the machine, so extensions compile against the toolkit you just installed instead of a stale one.

The final line installs a small English language model, which tells you that text processing is part of the pipeline rather than an afterthought, consistent with a system whose map is meant to be queried in language.

One small inconsistency: the environment is created with Python 3.11 while the stated requirement is 3.10 or newer, so the documented path is narrower than the requirement line.

## Two hours across a campus, and what that does not show

The field validation claim is a single deployment: continuous two-hour operation across the university campus, with an interactive demo linked from the project website. That is a real test of long-term stability, since most systems degrade over tens of minutes rather than fail immediately.

It is also one deployment on one machine, and the README publishes no accuracy table, no drift figures, and no ablation. So the evidence available today is a stability claim plus a demo you can watch, and that is a different kind of evidence from a benchmark. Anyone planning to build on this should treat the demo as a claim to be reproduced rather than a result to be cited.

Two sibling projects from the same group are listed and are worth knowing about, since they cover the odometry layer and the evaluation side: a LiDAR-only and LiDAR-inertial odometry system, and a robustness metric for odometry and SLAM. A robustness metric published by the same authors is a useful companion to a system that claims field proven.

The acknowledgements thank two professors by name for suggestions and for extensive testing on visual-language navigation projects, and contact is offered through a chat server, an issue tracker, and two named email addresses.

## Conclusion

SuperMap suits someone planning visual-language navigation work who needs a persistent map where object identity survives across time, and who can read a design document before the code exists. It does not yet suit anyone who needs to run it today, and the repository publishes no accuracy table, so the campus deployment and the demo page are the entire evidence offered. Before planning around it, check whether the promised release has landed, confirm you have the GPU memory and ROS2 workspace the requirements demand, and read the two config files to see whether your detector fits the vocabulary format.

## FAQ

### Is the SuperMap code available yet?

Not in this repository. The top level holds a README and a paper directory, and an announcement states the code will be released after the conference. The news list records the project website, teaser video, and initial overview as published on 2026-07-15.

### What does SuperMap produce?

A persistent semantic world model built as a 4D scene graph, described as a queryable map carrying both spatial and temporal information for every object, produced by fusing high-frequency geometric SLAM with asynchronous open-vocabulary perception.

### What are the hardware requirements for SuperMap?

Ubuntu 22.04 or 24.04, an NVIDIA GPU with at least 16 GB of video memory, and Python 3.10 or newer. Live mode additionally requires a ROS2 Jazzy workspace, while the offline path does not.

### Which detectors can SuperMap use?

It is described as model-agnostic, working with a grounding detector, a real-time detector, and pre-baked detections produced elsewhere. The offline example exposes a detector option on the command line, and the detection vocabulary is defined in a prompts configuration file.

### How do I run SuperMap on a recorded dataset?

Prepare the example dataset once with the provided script, then run the example pipeline script. The options cover the detector choice, a data directory, a config file, and the window to rerun over, and both offline and live modes emit the same per-frame JSON structure.

## Sources

- [Issues](https://github.com/superxslam/SuperMap/issues)
- [README](https://github.com/superxslam/SuperMap/blob/master/README.md)
- [superxslam/SuperMap on GitHub](https://github.com/superxslam/SuperMap)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/superxslam-supermap