# M2DGR is a ground robot SLAM dataset with a paper, a benchmark and a community attached

> M2DGR is a multi-modal and multi-scenario dataset for ground robots, published with an RA-L and ICRA 2022 paper, and its real strength is the ecosystem that grew around it: a larger M2DGR-plus, the M3DGR dataset, a dedicated benchmark repository and a long list of open source SLAM systems evaluated on it. The dataset itself is not in the repository, which holds the paper, calibration results and some ROS configuration.

**SJTU-ViSYS/M2DGR** — M2DGR： a Multi-modal and Multi-scenario Dataset for Ground Robots(RA-L2021 & ICRA2022)

- Repository: https://github.com/SJTU-ViSYS/M2DGR
- Stars: 1,222 · Forks: 131
- Language: Unknown
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/sjtu-visys-m2dgr

## A dataset published with a paper and a review culture

M2DGR is titled a Multi-modal and Multi-scenario Dataset for Ground Robots, and the badge in the repository title says RA-L and ICRA 2022. The first author is Jie Yin, with the paper on arXiv at 2112.13659 and the journal version as an IEEE RA-L document.

What makes the project unusual is the recommendation in the Notice section. The authors strongly recommend that a newly proposed SLAM algorithm be tested on M2DGR, M2DGR-plus, M3DGR or the Ground-Challenge benchmark, and the argument given is about the data itself. The claim is that if your algorithm outperforms the state of the art systems on this benchmark, your paper will be much more convincing and valuable. That is a benchmark recruiting its own baselines, and it explains the shape of the repository, which is as much about process as about data.

Two things follow from that framing. The first is that the dataset is meant to be compared against specific systems, with LIO-SAM and ORB-SLAM3 named in the notice as the systems the data is intended to challenge. The second is that the list of projects built or evaluated on M2DGR is long, and it includes Ground-Fusion, LVI-SAM-Easyused, SI-LIO, MM-LINS, Log-LIO and Log-LIO2, LIGO, Swarm-SLAM, VoxelMap++, GRIL-Cali, LINK3d, i-Octree, LIO-EKF, Fast-LIO ROS2, HC-LIO, LIO-RF, PIN-SLAM, Section-LIO, I2EKF-LO, LiLoc, BMBL, Light-LOAM, faster_lio_localization, Fast-LIVO2 and D-Li-Init.

For a reader, the practical value of that list is that it tells you which sensors and scenarios each of those systems expects, and therefore which parts of M2DGR have already been used successfully.

## The sensor set is the reason to use it

The first of the three features the notice lists is rich sensory information including vision, lidar, IMU, GNSS, event and thermal-infrared images, and the second is various scenarios in real-world environments including lifts, streets, rooms and halls.

The sensor list is the substantive part, because it determines which algorithms can be evaluated at all. A lidar and camera pair covers the visual and lidar SLAM systems, and a GNSS receiver and IMU add the ability to evaluate systems that fuse satellite positioning with dead reckoning, which matters for a ground robot that spends part of its life outdoors and part of it indoors where GNSS is unreliable. The event camera is what makes the dataset interesting for a different set of systems, since event data is a fundamentally different signal from a frame and a large part of the recent work in the field is about fusing it.

The multi-scenario claim is the other half. A lift is a degenerate corridor, a narrow space where the lidar sees almost nothing beyond the walls and where a pose estimate that is slightly wrong cannot be recovered from geometry. Streets are the opposite, with dynamic objects and open space. Rooms and halls are enclosed, cluttered and often featureless in their floor texture. A system that works on all four has solved a harder problem than one that works on one, which is exactly the reasoning behind the recommendation.

The third feature in the notice is the difficulty claim, that the data brings great challenge to the SLAM systems that exist today.

## The extension lineage keeps moving the goalposts

The News and Updates section is a timeline of the dataset's descendants, and it is the best evidence that the project is still active rather than an archive.

In October 2024 the authors introduced M2DGR-benchmark, a repository for benchmarking the newest state of the art LiDAR-visual SLAM algorithms on both M2DGR and M2DGR-plus. In June 2025 they announced an IROS 2025 paper, Towards Robust Sensor-Fusion Ground SLAM: A Comprehensive Benchmark and A Resilient Framework, with the code in Ground-Fusion++ and the dataset M3DGR. In March 2026 they added a time-sorted list of papers citing M2DGR, compiled from Google Scholar. And in June 2026 they released a preview of Ultra-Fusion, a system that unifies WIO, VIO, LIO and LVIO in one configurable optimisation framework, with optional wheel and GNSS fusion and online calibration.

The direction of travel is consistent. M2DGR-plus extends the original dataset, M2DGR-benchmark and Ground-Fusion++ turn it into an evaluation suite, M3DGR extends it again with a new paper, and Ultra-Fusion is a single framework that can run in the four modes the dataset exercises. Each step makes the benchmark harder, which is what keeps the citing papers list growing.

The award is in the same timeline: in January 2025 the paper was recognised as an ESI Highly Cited Paper in the top one percent. That is a measure of citation rather than of quality, but for a dataset it is the closest thing to a signal that the community treats it as a reference point.

## What is in the repository, and what is not

The top level of the repository is short, and it tells you where the data actually lives.

There is LICENSE, README.md, cover.png, main.pdf, and then a set of files that look like working material: calibration_results.txt, hall_03.txt, module_sam.launch, my_params_camera.yaml and my_params_lidar.yaml. So the repository holds the paper, some calibration output, and ROS launch and parameter files for the sensors, and it is a documentation and configuration repository rather than a data repository. The dataset itself is distributed elsewhere, and the README links the paper, the dataset extension M2DGR-plus, the video, the news post and the related datasets, and a Google Scholar citation list.

The table of contents in the README shows the full shape of the documentation: Introduction with the abstract, main contributions and a video, License, Sensor Setup with the acquisition platform and sensor parameters, Dataset Sequences with Outdoors, Indoors and Alternative Indoors and Outdoors, Configuration Files, and then Development Toolkits covering extracting images, evaluation, calibration, getting RINEX files and ROS drivers for UVC cameras.

That last group is what a new user actually needs. Extracting images matters because the recordings are multi-sensor and the images live inside the raw bags rather than as files, and getting RINEX files matters because the GNSS data has to be brought into a form that a SLAM system or a trajectory evaluation tool will accept. The ROS driver note for UVC cameras suggests the project expects people to work with the raw camera data directly as well.

## The toolkits are where the real work for a new user starts

The evaluation and calibration sections are the parts a reader planning an experiment should read first, because they describe the work between downloading a sequence and getting a result.

Calibration is the first hurdle in any multi-sensor SLAM dataset, and the repository ships calibration results, which means someone has already done the per-sequence work and published the answer. That is a substantial saving, because the extrinsic and intrinsic calibration of a lidar, several cameras, an IMU and a GNSS receiver is the part that eats a graduate student's first month, and getting it slightly wrong produces a system that runs and produces a trajectory that is subtly wrong.

Evaluation is the second. A benchmark is only useful if the metric is defined and the splits are fixed, and the existence of a dedicated M2DGR-benchmark repository for evaluating the newest LiDAR-visual systems is the sign that this part was taken seriously enough to be worth separating out.

The alternative approach to a dataset like this is to record your own robot, and for a quick experiment that is often simpler. The difference in approach is that a self-recorded sequence is guaranteed to match your sensors, your mount and your calibration, while a benchmark sequence is a different robot, a different mounting and a different set of extrinsics, and part of the work of using it is absorbing that difference. In exchange, the benchmark gives you a comparable number, which is the entire point if the result is going in a paper.

So the trade is between comparability and convenience, and the notice in the README is explicit that the authors would rather have the comparability.

## Maintenance, licence and what a new user should check

The licence is MIT, which is the permissive end of the scale and about right for a research dataset that people want to build on. The repository is not archived and the last push was on 2026-09-05, with no published releases, which is normal for a repository whose deliverables are a paper and a pointer to a dataset rather than a package.

The first thing to check is which dataset you actually want. There are four in the family: the original M2DGR, the M2DGR-plus extension, M3DGR, and the Ground-Challenge set, and the notice asks that new algorithms be evaluated on them, which implies the reviewer of your paper will look for those results.

The second is the sequence you need. The Dataset Sequences section splits the recordings into Outdoors, Indoors, and Alternative Indoors and Outdoors, and the alternative category exists because the same location recorded differently is often the more informative comparison, since a different route through a familiar space separates the effect of the route from the effect of the place.

The third is the sensor configuration files, since my_params_lidar.yaml and my_params_camera.yaml are the concrete description of how the sensors were run, and a SLAM system configured differently from those will not produce a comparable result.

The fourth is the documentation's own recommendation about the toolkit sections. A dataset that ships raw multi-sensor recordings is not a plug and play input, and the extraction, calibration and evaluation sections are the instructions for turning it into one.

## Conclusion

M2DGR suits a SLAM researcher who needs a multi-sensor ground robot sequence with a published baseline and a community already evaluated on it, and whose work will be reviewed against those baselines. It does not suit a team that wants a small, quick dataset to debug a parser, since the sequences are large and multi-sensor by design, and it is the wrong place to look for the data files themselves, because the repository is documentation and configuration. Verify first which dataset revision you need, M2DGR, M2DGR-plus, M3DGR or the Ground-Challenge set, since the notice asks that new algorithms be tested on them, and read the extraction and calibration sections before planning an evaluation, because the raw recordings need preprocessing before a SLAM system can read them.

## FAQ

### What is the M2DGR dataset?

It is a multi-modal and multi-scenario dataset for ground robots, published with an RA-L and ICRA 2022 paper by Jie Yin and colleagues at SJTU-ViSYS. It includes vision, lidar, IMU, GNSS, event and thermal-infrared data collected in real world environments such as lifts, streets, rooms and halls.

### What related datasets and benchmarks exist alongside M2DGR?

There is the M2DGR-plus extension, the M3DGR dataset introduced with an IROS 2025 paper, and the M2DGR-benchmark repository for evaluating LiDAR-visual SLAM systems on M2DGR and M2DGR-plus, alongside a Ground-Challenge set.

### Does the M2DGR repository contain the sensor data?

No. The repository holds the paper, the README with the documentation, calibration results, ROS launch and parameter files, and configuration. The dataset itself is distributed separately.

### What development tools does the M2DGR documentation cover?

Sections on extracting images, evaluation, calibration, getting RINEX files and ROS drivers for UVC cameras, along with the sensor setup, the acquisition platform, the sensor parameters and the dataset sequence listings.

### What licence applies to M2DGR?

The repository is under the MIT licence, and the project credits the first author Jie Yin and points to the arXiv preprint and the IEEE RA-L version of the paper.

## Sources

- [Issues](https://github.com/SJTU-ViSYS/M2DGR/issues)
- [License: MIT](https://github.com/SJTU-ViSYS/M2DGR/blob/main/LICENSE)
- [README](https://github.com/SJTU-ViSYS/M2DGR/blob/main/README.md)
- [SJTU-ViSYS/M2DGR on GitHub](https://github.com/SJTU-ViSYS/M2DGR)

---

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