Component Runtime

[brainwavecoder9]

A dynamic component runtime that gives 3rd parties the option to bring their own hardware (or software tbh). Think: broad extensibility with external modules, without modifying daemon or SDK code. This is first-class integration for third-party devices.

The framework is laid out BUT I'm broadly flexible and happy to make further refinements/decisions and any necessary changes to align with the team's expectations.

I've established some baseline requirements:

• The robot always wins - Component issues will never impact daemon startup
• There is a single source of truth - Loading decisions are explicitly declared
• Components cannot break each other - Isolated loading, no cross-dependencies, no direct interactions
• Provenance must be known - Must be able to trace the origin of every component
• The daemon owns the lifecycle - Components are always passive

From there, we can layer on some conceptual expectations:

• Components are libraries - They only expose APIs
• One isolated namespace - Explicit optionality, no collisions, clear delineation between 3rd party and official
• Applications orchestrate - All the things happen through apps, components simply expose the device

That keeps the implementation simple, with the entire process looking something like this:

1. Devs publish components to HuggingFace Spaces
2. Users declare in a manifest
3. Daemon loads into an isolated namespace
4. Apps access components VIA a dedicated robot interface (e.g., robot.component["third-party-thing"])

For Example:

### Minimal component definition (published Hugging Face space)
my-component/
├── __init__.py
└── (component owner's implementation files)

### Daemon's manifest (e.g., components.txt, refs HF Space repo tag): 
my-component=username/my-component:v1.0.0

### Dynamic auto-loader provides via component namespace 
robot.component["my-component"]

Design rationale:

While we could support other sources or local folders, this type of inclusion can introduce additional challenges (management overhead, troubleshooting and debugging, security). A single, simple, manifest-driven source of truth, means we can turn things off/on very easily without having to know or understand any of the details. A text file as a control point means less-technical people have a simple installation process (also easy to add to dashboard as toggles).

The dedicated namespace means we don't have to be concerned about collisions or confusion, and the overhead is never a burden for the team. Dynamic loading is automatic and super straightforward (I've added placeholder comments to the daemon). If there's a problem it's always a component problem... the entire robot.component namespace is the responsibility of the corresponding 3rd party. For issues Pollen can always simply defer with something like "We are not involved with 3rd party components, you will need to speak with the developer of that component"

Component owners having to maintain this independently is a small price to pay. Devs get fully integrated access to their devices, the robot is never impacted, and Pollen doesn't have to know or care about those external integrations.

PyPi / GitHub / etc. are also possible, but given the low level access I think Hugging Face exclusivity makes sense, because it's the only place that provides a direct lever for HF (of all options it's the only one where you can pull the plug directly). That said, happy to enable whatever you want.

As for developers, requiring a component factory to be returned means they can implement as they please. This gives broad flexibility and control for 3rd party inclusions, without compromising the robot, and still maintaining a control point for HF. This unlock allows the community to freely extend Reachy without requiring Pollen's involvement.

Example: A researcher publishes alice/reachy-imu:v1.0.0 to add IMU support. Users add one line to their manifest. No review, no merge, no waiting, and no additional setup; apps then have direct access to the device through the robot interface. The contract is simple device exposure without any coupling.

Next steps:

Seeking additional thoughts and confirmation on approach. The code is pretty simple (see included changes) but I'll complete the draft when we've confirmed how we want to go about this.

Let me know if you have any questions, would like further clarification or changes, or whatever else I can do to make this easier to explore.

[brainwavecoder9]

TL;DR: The component defines its own API, an the daemon exposes it through the existing robot interface.

The contract:

• Factory supplied with context = {"simulation": bool}.
• A Component must be returned, but it's composition is arbitrary.
• Version must be available as a string.
• cleanup() is the only expected method, and is optional.

[brainwavecoder9]

FYI since it came up, this approach would support any source, including non-Python apps, additional languages, etc. Component maintainers are able to bind whatever they want in init, including other languages or sources.

A less obvious unlock is that this also means components are infinitely composable. There is no requirement to supply a complete library. A component can be a granular module, and an app can be a collection of calls to robot/integrated component/multiple standalone components.

[FabienDanieau]

Thanks, that's an interesting discussion to have. What do you think of the plugin system proposed here #743 ?

[brainwavecoder9]

Thanks, that's an interesting discussion to have. What do you think of the plugin system proposed here #743 ?

I can see how it could be useful for motion-based events. It’s not a problem I'm focused on, and I wasn’t involved in the related discussion or development. #743 addresses a narrower need in a different problem space. I would consider it separately if there is a desire for tighter component/robot integration.

I'm envisioning something far more ambitious and less restrictive. Creating an extensible surface would allow external developers to explore freely without asking Pollen to take on any additional burdens.