dimos - Moses Yebei

The Problem

Building applications for robotics can be a nightmare. You've got a myriad of frameworks, each with its own quirks. You either end up spending weeks on setup or drowning in dependencies like ROS. Dimensional aims to simplify this chaos, letting you develop applications in Python without the overhead of traditional robotics frameworks.

What This Does

Dimensional provides a framework for creating robotics applications that run on various hardware like humanoids, quadrupeds, and drones. The dimos/agents directory contains the core code for agent communication and interaction, while data/ holds your assets and various resource files. The bin/ folder is packed with handy scripts, including bin/dev for local development and bin/dockerbuild for building Docker images.

You can easily extend functionality or create custom agents with the provided examples in dimos/agents/skills/. For instance, if you want to implement a GPS navigation skill, just check out dimos/agents/skills/gpsnavskill.py and start tweaking it to fit your needs.

Real-World Use

Imagine you want your robot to navigate through your office and avoid obstacles. You can drop in a SLAM algorithm using the pre-built functionality in dimos/agents/skills/navigation.py. Your main application could look like this:

Just like that, your robot is off to find the coffee machine, avoiding all those pesky chairs in the way.

The Bottom Line

Dimensional is an ambitious framework that cuts through the complexity of robotics development. It’s a decent fit for those looking to create robust applications without getting buried under a mountain of dependencies. But if your project is small-scale, this might be overkill. If you’re serious about robotics, though, Dimensional could save you a ton of headaches.

What the analyser found

Deployment readiness

3/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

200 files

Python43
JSON25
YAML9
Markdown6
Shell1

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["dimos<br/>853 modules"] g1["examples<br/>6 modules"] g2["docker<br/>3 modules"] g3["bin<br/>2 modules"] g1 -->|16| g0

Module dependencies

The 10 most depended-upon modules of 865, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_os_msgs_sensor_msgs___init__["__init__"] n1_dimos_utils_logging_config["logging_config"] n2__msgs_geometry_msgs___init__["__init__"] n3_dimos_core_module["module"] n4_dimos_core_stream["stream"] n5_dimos_core_core["core"] n6_dimos_utils_data["data"] n7_dimos_core_blueprints["blueprints"] n8_dimos_core_transport["transport"] n9_dimos_types_timestamped["timestamped"] n7_dimos_core_blueprints --> n3_dimos_core_module n7_dimos_core_blueprints --> n4_dimos_core_stream n7_dimos_core_blueprints --> n8_dimos_core_transport n7_dimos_core_blueprints --> n1_dimos_utils_logging_config n3_dimos_core_module --> n5_dimos_core_core n3_dimos_core_module --> n4_dimos_core_stream n3_dimos_core_module --> n7_dimos_core_blueprints n3_dimos_core_module --> n8_dimos_core_transport n4_dimos_core_stream --> n1_dimos_utils_logging_config n8_dimos_core_transport --> n4_dimos_core_stream n9_dimos_types_timestamped --> n1_dimos_utils_logging_config n6_dimos_utils_data --> n1_dimos_utils_logging_config classDef cyc stroke:#ef4444,stroke-width:2px; class n0_os_msgs_sensor_msgs___init__,n2__msgs_geometry_msgs___init__,n3_dimos_core_module,n7_dimos_core_blueprints,n8_dimos_core_transport,n9_dimos_types_timestamped cyc;