Architecture#
EMOS, the Embodied Operating System, is the software layer that turns a robot into a physical AI agent. It gives quadrupeds, humanoids and mobile robots one runtime in which they see, think, move and adapt, and it does so without caring which robot it is on. The application, a recipe, is written once against standard interfaces, and a plugin adapts it to the hardware.
The body and the mind#
EMOS separates the robot’s body from its mind. The body is the hardware: motors, sensors, actuators and the drivers that speak to them. The mind is the software that perceives, reasons and decides. Between the two sits a standard interface, and everything EMOS adds to a robot lives on the mind’s side of it. That is what lets the same recipe run on a wheeled base, a quadruped or a humanoid.
The stack#
Three open-source packages make up the stack, each building on the one below it.
Sugarcoat, the architecture layer#
Sugarcoat is the framework the other two are built on. It provides the primitives every recipe is made of:
Components, lifecycle-managed nodes that report their health and heal themselves.
Events and actions and routines, the reactive layer that switches behaviour on live data.
The launcher and its Monitor, which bring a recipe up in threads or processes and orchestrate it while it runs.
The plugin framework, through which a robot and its sensors are adapted to the standard interfaces.
The web interface a recipe can serve for itself.
EmbodiedAgents, the intelligence layer#
EmbodiedAgents is the framework for agentic graphs of models: vision-language models, speech in and out, object detection in two and three dimensions, a spatio-temporal memory, semantic routing of commands, motion policies, and Cortex, the agent that plans with the recipe’s actions and routines as its tools. Its components run models locally or through cloud APIs and can switch between them at run time. See Intelligence.
Around the stack#
Three more things ship with EMOS and sit around the stack rather than inside it.
Plugins adapt one robot or one sensor to the interfaces above. A robot plugin carries the robot’s odometry, sensors and commands, its own actions and events, its localization and how it is mapped. A sensor plugin adds one device that is not part of the robot. They are installed from a catalog, and the plugins page covers using them.
The CLI, emos, installs the stack in one of three modes, keeps it updated, manages plugins, builds and manages maps, and runs recipes with their logs kept. It is the operator’s tool on the robot itself. See the CLI reference.
The dashboard is the robot’s web page: recipes to pull, run and follow, plugins to install, maps, and the system’s state, served securely to a paired browser on the same network. It is separate from the web interface a recipe serves for itself. See the dashboard.
Recipes#
A recipe is a Python script that declares a whole application: which components run, how they are wired, which plugin adapts the robot, which events matter and what happens when they fire. There are no launch files and no scattered configuration.
from ros_sugar import Launcher
from myrobot_plugin import MyRobotPlugin
# Components from any layer: perception from EmbodiedAgents,
# planning and control from Kompass, or your own on Sugarcoat
robot = MyRobotPlugin()
launcher = Launcher()
launcher.add_plugin(robot)
launcher.add_pkg(components=[planner, controller], package_name="kompass", multiprocessing=True)
launcher.add_pkg(components=[vision, agent], package_name="agents", multiprocessing=True)
launcher.on(robot.events.low_battery(20.0), robot.actions.dock())
launcher.bringup()
The same script runs from a terminal while it is being written and through emos run or the dashboard once it is done. Running Recipes covers both.