Overview

Solarian is an open-source Python framework for building, controlling, teleoperating, and training robots. It gives you a clean three-node architecture, real-time multi-process modules, plug-and-play hardware and skills, and a dual-process AI controller — all configured with Hydra and connected over ZeroMQ.

Intro

Solarian sits between your hardware and your application code. It handles the parts of robotics that every project has to solve — networking, configuration, calibration, real-time loops, observation/action schemas, recording, training — and lets you focus on the parts that make your robot unique: which hardware you have and what you want them to do.

A typical Solarian project looks like this:

  • myrobot/
    • myrobot/Your Python package
      • settings.pyWhich Robot, Controller and Server classes to run
      • robot.pyYour Robot: one attribute per module
      • controller.pyYour Controller: keys, events, skills as tools
      • server.pyYour RelayServer
      • observation.pyObservation/ModuleObs schemas
      • action.pyAction/ModuleAction schemas, and any custom action types
      • modules/Your Module implementations
        • arm.py
        • gripper.py
      • skills/Your Skill implementations
        • pick_object_skill.py
      • datasets/Your dataset ops, one per file
        • drop_short_episodes.py
    • conf/Hydra YAML, organized by who reads it
      • robot.yaml · controller.yaml · server.yamlOne per process
      • modules/One per module, named by the robot attribute
      • skills/One per skill config
      • services/Services and processors
      • commands/record.yaml, replay.yaml
      • training/One complete training run per file
      • calibrations/Calibration results, cameras/ included
      • deployment/Addresses and device paths, one file per host layout
    • recordings/Sessions written by solarian record, robot/ and controller/. Kept out of git.
    • models/Policies trained by solarian train, and the weights services download. Kept out of git.
    • assets/Sim scenes and meshes, for a robot with a simulator.
    • pyproject.toml

Dashed folders are not scaffolded: a command or plugin creates them the first time it needs them.

You write a few small classes, declare your hardware modules, and Solarian wires the rest together.

Vision

Robotics is hard because the infrastructure is hard. Hardware vendors ship their own SDKs, every research lab invents its own networking layer, and every team rewrites the same calibration, recording, and replay tools.

Solarian's vision is to standardize the boring parts so that hardware modules, controllers, and AI policies become reusable across projects. A Feetech-based arm should plug into the same Module interface as a UR5 arm. A keyboard teleop session should produce the same Observation/Action stream that a learned policy will later consume. A Skill written for one robot should run on another that exposes the same ModuleAction.

Architecture

Solarian is structured as a Robot ↔ Server ↔ Controller system. Each role is a separate process and can run on a separate machine.

Actions flow from the Controller (laptop, PUSH/SUB) to the RelayServer (anywhere, PULL/PUB) and on to the Robot (on the robot, PULL/PUB). Observations flow back from the Robot through the RelayServer to the Controller.

  • Robot runs on the robot. It owns the hardware: every Module subclass becomes its own OS process, polls actuators and sensors, and streams typed observations back out. Implementation: solarian/core/robot.py.
  • RelayServer runs anywhere reachable from both ends. It forwards actions from controllers to robots and observations from robots to controllers, and can run server-side observation processors. Implementation: solarian/core/server.py.
  • Controller decides what the robot should do next. Subclass Controller for keyboard teleop, leader-arm teleop, a learned policy, or add an agent: block to let a planner model drive it from a chat. Implementation: solarian/core/controller.py.

All three nodes speak the same protocol: a Pydantic-validated Action goes one way, a Pydantic-validated Observation comes the other. Both are msgpack-serialized over ZeroMQ.

Key features

  • Real-time multi-process modules. Each hardware Module runs in its own process at its own configurable rate (frequency Hz), talking to the robot loop through shared-memory ring buffers, so a 500 Hz arm and a 30 Hz camera coexist without blocking each other. Scheduling is a property, not a base class, so cheap input devices like a keyboard run inline instead of paying for a process.
  • Typed observations and actions. Observation and Action are Pydantic-typed schemas that bind directly to your modules. The same data flows from hardware through the wire to your controller, your dataset, and your policy.
  • Plug-and-play hardware. Hardware drivers ship as standalone solarian-<name> plugins. solarian install ur5 installs the package and copies the default config straight into conf/modules/ur5.yaml.
  • Hydra-driven configuration. Every command takes its config from a YAML file (robot.yaml, controller.yaml, server.yaml, record.yaml, …) composed via Hydra defaults. Each module's config lives in conf/modules/<module_name>.yaml matching the attribute name on your Robot. A skill config lives in conf/skills/<config_name>.yaml, a service config in conf/services/<name>.yaml, and a training run in conf/training/<name>.yaml.
  • AI Controller. Any controller can take tasks in plain language: a planner model calls its Skills as tools while a fast monitor model watches each one through the cameras.
  • Recording, replay, and training. First-class CLI commands (record, replay, train) let you go from teleoperated demonstrations to a trained policy without leaving the framework.
  • Settings and lifecycle. A simple settings.py pattern (à la Django) registers your Robot, Controller, and Server classes, so the CLI can discover and run any of them with the right configuration.

How a typical project flows

1. create-solarian myrobot               (scaffold the project)
2. solarian install ur5                  (install a plugin and copy its config)
3. edit conf/modules/ur5.yaml            (set port, ID, frequency, …)
4. solarian run-server                   (relay machine)
5. solarian run-robot                    (on the robot)
6. solarian run-controller               (your laptop — keyboard teleop)
7. solarian record                       (capture an episode)
8. solarian train ...                    (train a policy)
9. solarian run-service <skill conf>     (serve the policy a skill drives)

Each step uses the same Robot, Controller, Observation, and Action classes you defined once in your project package.

Where to next?

Was this page helpful?