DimOS

Runtime de robótica em Python com agentes, SLAM e teleoperação, sem ROS

Licença

Apache-2.0

Visão geral

DimOS é um runtime em Python para construir aplicações robóticas sem ROS. Os subsistemas são Módulos com fluxos tipados In[] e Out[]; os blueprints os conectam com autoconnect(), que casa fluxos por nome e tipo de mensagem e pode ser composto, remapeado ou trocado de transporte. Acima disso ficam as capacidades que a maioria das pilhas monta à mão: navegação com SLAM e mapas de custo com planejamento A* e exploração de fronteiras, percepção com detectores e VLMs, uma memória espaço-temporal que localiza objetos ao longo do tempo e agentes que rodam como módulos nativos assinando qualquer fluxo. A CLI dimos executa blueprints, acompanha logs, envia um comando a um agente e chama habilidades via MCP. Os modos de replay e de simulação em MuJoCo fazem os guias de início rápido funcionarem sem nenhum robô na mesa.

As entradas de robótica agêntica deste catálogo quase todas se apoiam em ROS 2 — RAI, AgenticROS, ROS-MCP e as demais tratam o ROS como substrato e acrescentam uma camada de linguagem por cima. O DimOS aposta no contrário: substitui também o middleware. Módulos, fluxos tipados, blueprints e transportes próprios (LCM, WebRTC, um broker hospedado) formam uma alternativa completa a nós, tópicos e arquivos de lançamento do ROS, escrita em Python com Rust e C++ onde a velocidade importa. Se essa aposta se sustenta é exatamente a questão a ponderar, e o repositório dá material suficiente para julgar: 4.500 estrelas, commits diários, uma dúzia de contribuidores identificados e uma matriz de hardware franca sobre o que é estável.

Essa matriz é a página mais útil do README. O Go2 da Unitree é a única plataforma marcada como estável; o humanoide G1, o xArm e o AgileX Piper estão em beta; MAVLink e DJI em alfa; o B1 e a sensoriamento de força-torque são experimentais. A instalação é graduada do mesmo jeito: Ubuntu 22.04 e 24.04 são o caminho suportado, NixOS e Linux genérico não passam por CI, macOS é alfa. Um projeto que rotula com honestidade os próprios níveis de suporte é mais fácil de avaliar do que um que lista todas as plataformas como iguais, e o repositório inteiro carrega um aviso de beta pré-lançamento.

O dimTELE, a metade de teleoperação, merece nota à parte. O robô disca para fora, até um broker hospedado, de modo que nenhuma porta de entrada precisa ser aberta, e quem opera dirige pelo navegador ou por um headset Quest via WebRTC. Funciona bem e é a demonstração mais nítida da pilha, mas exige conta e chave de API do console da própria Dimensional. O cliente e o código de transporte estão no repositório Apache-2.0; o broker do outro lado não.

Por que importa

Todo outro framework de robótica agêntica que vale listar pressupõe ROS 2 e constrói uma camada de linguagem por cima. O DimOS é o único que pergunta se o próprio middleware não deveria ser substituído, e está avançado o bastante para ser julgado em vez de especulado: fluxos Python tipados no lugar de tópicos, uma pilha de navegação e memória que funciona, agentes como módulos de primeira classe e dados de replay para conferir as afirmações sem hardware. Adotando-o ou não, é hoje o argumento mais forte de que o padrão em formato de ROS é uma escolha, não uma lei.

Problema que resolve

Construir uma aplicação robótica normalmente significa adotar o ROS 2 e tudo que vem junto — o sistema de build, as definições de mensagem, os arquivos de lançamento — antes de escrever uma linha de comportamento. O DimOS oferece essa mesma camada como Python comum: fluxos tipados entre módulos, uma CLI para executá-los e inspecioná-los, e navegação, percepção, memória e integração de agentes já construídas em cima.

Pontos principais

• Um runtime de robótica em Python que deliberadamente não usa ROS — Módulos com fluxos tipados In[]/Out[], conectados por autoconnect() em blueprints componíveis
• Traz navegação (SLAM, mapas de custo, planejamento A*, exploração de fronteiras), percepção e uma memória espaço-temporal que registra onde cada objeto esteve e quando
• Agentes são módulos nativos com ferramentas MCP, então dimos agent-send "explore the room" e dimos mcp call move_to são verbos de CLI de primeira classe
• Os modos de replay e simulação em MuJoCo executam os guias de início rápido em destaque sem nenhum robô conectado
• A matriz de hardware classifica o próprio suporte com honestidade: Unitree Go2 estável, G1 e xArm em beta, MAVLink e DJI em alfa, B1 experimental
• O dimTELE dá teleoperação por navegador e Quest sobre WebRTC discando para um broker, sem portas de entrada na rede do robô
• Apache-2.0 da Dimensional Inc., com cerca de uma dúzia de contribuidores regulares e commits entrando diariamente

Para quem é

• Desenvolvedores Python que querem escrever comportamento robótico sem antes aprender ROS 2
• Equipes que trabalham com quadrúpedes ou humanoides Unitree procurando uma pilha acima do SDK do fabricante
• Quem constrói agentes de LLM ou MCP que precisam assinar fluxos reais de sensores em vez de chamar um endpoint REST
• Operadores que precisam de teleoperação remota atravessando NAT sem abrir portas de entrada
• Pesquisadores comparando projetos de middleware que querem uma referência séria fora do ROS para contrapor

Limitações

• O repositório se declara beta pré-lançamento e o PyPI ainda está em 0.0.x, então convém esperar que as interfaces mudem
• Cerca de 700 issues estão abertas — projeto ativo, mas também um acúmulo grande para ler antes de se comprometer
• Não usar ROS corta o acesso ao ecossistema ROS: sem drivers existentes, sem Nav2, sem MoveIt, sem rosbag, e o que o projeto não construiu você constrói
• O suporte de hardware é estreito e majoritariamente instável — o Go2 da Unitree é a única plataforma marcada como estável, e todo o resto é beta, alfa ou experimental
• O broker do dimTELE é um serviço hospedado da Dimensional que exige conta e chave de API; o repositório Apache-2.0 entrega o cliente, não a outra ponta
• Ubuntu 22.04/24.04 é o caminho testado; macOS é alfa e Linux genérico está explicitamente fora do CI
• Isto é tanto o roteiro de produto de uma empresa quanto um projeto comunitário — repositório aberto e console hospedado são desenvolvidos juntos