OpenDM: Dexmal's DM0.5 Vision-Language-Action Model for Robot Control
An Open-World Foundation Model for General-Purpose Embodied Intelligence.
At a glance
- What is it?
- OpenDM packages the DM0.5 vision-language-action model with training, inference and evaluation scripts for open-world robot control. It is a research and fine-tuning kit, not a plug-in library, and the README leaves deployment details thin.
- Who is it for?
- OpenDM suits robotics research groups that can already run a CUDA 12.8 machine and want a pretrained VLA checkpoint to fine-tune against simulators such as LIBERO, RoboTwin2.0 or VLA-Arena. It is the wrong choice if you need a turnkey production controller or have no GPU cluster, since the repository is a training and evaluation toolkit rather than a runtime service.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 21, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap DM0.5 is built to fill in robot learning
Most vision-language-action models are trained and demonstrated on a fixed set of tasks. Add a new instruction phrasing, a longer task horizon, or a second robot arm, and the policy degrades. OpenDM is Dexmal's release of DM0.5, described in the README as a next-generation VLA model for open-world robot control that builds on the native embodied modeling approach of DM0, with upgrades aimed at open-ended instructions, long-horizon tasks, dynamic disturbances and multi-embodiment control.
The audience is narrow and specific. The README says OpenDM provides DM0.5 model weights, training and inference scripts, dataset registration examples and evaluation workflows for researchers and developers to train, fine-tune, evaluate and deploy the model. If you want a robot that works out of the box, this is not that. If you want a checkpoint and a training harness to adapt to your own arm, it is aimed at you.
What the repository actually contains
The top-level layout is a Python research project: an opendm package, a playground directory, script, tests, docs and third_party, alongside a Dockerfile, pyproject.toml and a pre-commit configuration. There are no service manifests, no helm charts and no packaging beyond the setuptools build declared in pyproject.toml.
The dependency list tells you what kind of code this is. torch 2.11.0 and torchvision 0.26.0 anchor the stack, with transformers 5.3.0, accelerate 1.14.0, peft 0.19.1 and bitsandbytes 0.49.2 for training and parameter-efficient adaptation. liger-kernel is present for fused kernels. Data handling leans on datasets 5.0.0, decord and av for video decoding, albumentations for augmentation, and megfile with boto3 for remote object storage. FastAPI, uvicorn and flask appear for serving, and gradio for interfaces. Python 3.10 or newer is required.
That mix of training, storage and web serving dependencies in one project is worth noting. It suggests one environment is expected to cover data preparation, fine-tuning and inference, which simplifies setup but makes dependency conflicts more likely than in a project that splits those concerns.
Installing OpenDM and pulling the base checkpoint
The README does not give a step-by-step install sequence. The repository does provide a Dockerfile, so the container is the most documented path. It starts from nvcr.io/nvidia/cuda:12.8.1-cudnn-devel-ubuntu22.04, sets DEBIAN_FRONTEND to noninteractive and TZ to Asia/Shanghai, installs build-essential, openssh-server, vim, git, curl, tmux and git-lfs, then installs Miniconda3 and configures conda channels. Because the base image is CUDA 12.8.1, the torch 2.11.0 pin in pyproject.toml lines up with a cu128 build.
If you build outside the container, match the Python floor and the CUDA generation yourself. The project declares Python 3.10 or newer:
pip install -e .That installs the dependencies listed in pyproject.toml, including the pinned torch and transformers versions. Expect a large download and a long resolve.
The README's one concrete download example fetches the base DM05 checkpoint, the model the README recommends for fine-tuning:
huggingface-cli download Dexmal/DM05 --local-dir ./checkpoints/DM05After it finishes you should have a local checkpoint directory at ./checkpoints/DM05. Every other model in the table (DM05-libero, DM05-robotwin2, DM05-SO101-Pick-Cube, DM05-VLA-Arena, DM05-Table30v2, DM05-MEM-Robodojo-Sim) follows the same pattern with a different repository name, and each is mirrored on ModelScope for users who prefer that host.
For a first real use, the README points to per-benchmark guides rather than a single quickstart. The SO101 pick-cube LoRA workflow is documented in docs/en/dm05_so101_lora_training.md, and the RoboTwin2.0 supervised fine-tuning and evaluation flow in docs/en/dm05_robotwin2.md. Those documents, not the README, are where the actual training commands live.
Where the reported numbers come from, and what they do not cover
The README's benchmark table is the strongest signal in the repository, and it is also the easiest to misread. Reported success rates are 99.0% on LIBERO, 93.6% clean and 93.3% randomized on RoboTwin2.0, 89.0%/53.6%/44.1% across VLA-Arena levels L0/L1/L2, a score of 24.90 with 19.34% success on RoboDojo-Sim, and 54.42 score with 43.0% success on the real-world RoboChallenge Table30V2. The table places Pi0, Pi0.5 and GROOT-N1.7 alongside for comparison.
Read the shape of the curve, not just the headline. VLA-Arena drops from 89.0% at L0 to 44.1% at L2, and RoboDojo-Sim success sits at 19.34%. Those are the open-world and long-horizon settings the model was explicitly built for, and they remain hard. A 19% success rate on a bimanual manipulation benchmark is a research result, not a deployment readiness signal. The README does not report variance across seeds, hardware used, or inference latency, so the table cannot tell you how the model behaves under repeated runs or on your own arm.
The real constraint: no deployment story in the README
The README documents training, fine-tuning and evaluation. It does not document rollback, versioning of checkpoints, safe shutdown, or how to run the model against live hardware in production. The physical robot material that does exist is a modification guide, docs/en/robot_platforms.md, covering camera changes and the robot-name mapping used by the algorithm for AgileX COBOT Magic and DOS-W1. That is setup documentation for a lab bench, not an operations manual.
There is also a versioning risk that comes with the pinned stack. transformers 5.3.0, torch 2.11.0 and numpy 1.26.4 are exact pins. If you need to coexist with another project in the same environment, or you depend on a library that has not caught up to transformers 5.x, the resolve will fight you. The Dockerfile exists precisely because reproducing this environment by hand is fiddly.
Finally, the license is Apache-2.0, which is permissive for the code in this repository. The model weights are hosted separately on Hugging Face and ModelScope, and the README does not restate their terms, so check the model card for the checkpoint you intend to use before you build on it.
OpenDM compared with a general VLA training framework
The natural alternative is LeRobot, Hugging Face's framework for robot learning, which takes the opposite approach. LeRobot is organized around a dataset format and a set of policy implementations you assemble yourself, with the emphasis on the tooling and the ecosystem around it. OpenDM ships one model family with its own training and evaluation scripts and its own benchmark guides, so the integration work is scoped to Dexmal's stack rather than to a general abstraction.
The practical difference shows up in what you get on day one. With OpenDM you get a DM05 checkpoint that already reports numbers on LIBERO, RoboTwin2.0, VLA-Arena, RoboDojo-Sim and RoboChallenge Table30V2, and fine-tuned variants for each. With a general framework you get the plumbing and pick your own policy. If your goal is to compare against DM0.5 or to fine-tune it on a specific arm, OpenDM saves you the assembly. If your goal is to swap policies freely or to standardize on a shared dataset format across teams, the general framework is the better fit. The README does not claim interoperability with other VLA stacks, and nothing in the repository layout suggests a plugin interface.
Maintenance, licensing and upgrade cost
The last push to the default branch was on 2026-09-16, and the repository is not archived. The README's news entries run from 2026-07-09, when DM0.5 was released, through 2026-08-26, covering the SO101 LoRA workflow, the RoboTwin2.0 checkpoint and SFT code, the physical robot modification guide, and the DM05-MEM-Robodojo-Sim fine-tune. That is a steady cadence of additions rather than a frozen release.
No releases are published, so there is no tagged version to pin against. Upgrades mean tracking main, and the exact pins in pyproject.toml mean an upgrade is not a drop-in: moving to a newer transformers or torch requires re-validating the training and inference scripts. Budget for that.
On licensing, the repository carries Apache-2.0 and the pyproject.toml classifier confirms it. Apache-2.0 permits commercial use and modification with attribution and a patent grant, but it applies to this code. The checkpoints are separate artifacts on Hugging Face and ModelScope, and the README does not state their terms. Treat the code license and the weight license as two questions, and read the model card for whichever checkpoint you deploy.
Editorial conclusion
OpenDM suits robotics research groups that can already run a CUDA 12.8 machine and want a pretrained VLA checkpoint to fine-tune against simulators such as LIBERO, RoboTwin2.0 or VLA-Arena. It is the wrong choice if you need a turnkey production controller or have no GPU cluster, since the repository is a training and evaluation toolkit rather than a runtime service. Before adopting it, verify that the pinned stack in pyproject.toml (torch 2.11.0, transformers 5.3.0, Python 3.10 or newer) resolves in your environment, and read docs/en/robot_platforms.md to confirm your arm appears in the supported camera and robot-name mapping.
Frequently asked questions
What is OpenDM?
OpenDM is Dexmal's open-source release of the DM0.5 vision-language-action model for open-world robot control, packaged with model weights, training and inference scripts, dataset registration examples and evaluation workflows.
What does it mean to have an open DMS?
In this repository the term refers to an open-world embodied model rather than a document management system: DM0.5 is described as a VLA model for open-world robot control, and OpenDM provides the weights and scripts around it.
Which Python version and CUDA generation does OpenDM need?
pyproject.toml requires Python 3.10 or newer and pins torch 2.11.0 with torchvision 0.26.0, while the Dockerfile builds on nvcr.io/nvidia/cuda:12.8.1-cudnn-devel-ubuntu22.04.
How do I download a DM0.5 checkpoint?
The README gives the example huggingface-cli download Dexmal/DM05 --local-dir ./checkpoints/DM05, and every other model in the table follows the same pattern with a different repository name, with ModelScope mirrors listed as well.
Does OpenDM document how to deploy the model on a real robot?
The README documents training, fine-tuning and evaluation. The only physical robot material it points to is docs/en/robot_platforms.md, which covers camera changes and the robot-name mapping for AgileX COBOT Magic and DOS-W1.
Community notes