Design Concepts Overview

The Sugarcoat philosophy is centered around four key pillars: Modular Execution, Active Resilience, Event-Driven Behavior, and Centralized Orchestration.

A Component is the main execution unit in Sugarcoat, each component is configured with Inputs/Outputs and Fallback behaviors. Additionally, each component updates its own Health Status, to keep track of the well/mal-functioning of the component. Components can be handled and reconfigured dynamically at runtime using Events and Actions. Events, Actions and Components are configured in imperative scripts called “Recipes” and brought to life using the Launcher.

../_images/component_dark.png ../_images/component_light.png

1. The Component: Smart Execution

At the heart of the system is the Component. Unlike a standard ROS2 node, a Sugarcoat Component is Lifecycle-managed and Health-aware by default. It executes a specific logic (e.g., a path planner, a driver, or a controller), and validates its own configuration automatically.

2. Active Resilience: Status & Fallbacks

Robots fail. Sugarcoat Components are designed to handle failure gracefully rather than crashing.

  • Health Status: Every component continuously reports its internal state, distinguishing between Algorithm failures (e.g., “no path found”), Component failures (e.g., “driver crash”), or System failures (e.g., “missing input”).

  • Fallbacks: When a failure is detected, the component automatically triggers pre-configured recovery strategies—such as retrying an operation, re-initializing a driver, or safely shutting down—without requiring external intervention.

3. Dynamic Behavior: Events & Actions

To create reactive autonomy, Sugarcoat layers an Event-Driven system on top of standard data flows.

  • Events: These act as triggers that monitor ROS2 topics for specific conditions (e.g., “Battery < 20%”, “Target Lost”, or “New Terrain Detected”).

  • Actions: When an Event triggers (or a Fallback activates), an Action is executed. Actions can reconfigure components, switch controllers, start/stop processes, or send goals to other nodes.

4. Orchestration & Recipes Launcher

Finally, the system is brought to life and supervised by the Launcher, a Pythonic interface to define and deploy your system. It supports running components in Multi-threaded or Multi-process modes, managing their lifecycles automatically and handling event/action coordination.