System Architecture

Keero Bot is organized as a small set of clear functional blocks rather than a single monolithic board story. This makes the platform easier to understand, easier to extend, and easier to position for prototyping partners.

Block-Level View

This is the simplest public way to understand the system: one mainboard core, one firmware layer coordinating it, one interaction stack, one power story, and one modular expansion path.

1. Mainboard Core

The mainboard is the central hardware layer of the platform. It brings together compute, power management, sensing, wired interfaces, and module connectivity in one reusable core.

From a system perspective, the mainboard is responsible for:

• hosting the ESP32-S3 compute core
• coordinating local peripherals
• managing power across the device
• exposing interfaces to external modules

This is important for Keero Bot because the project needs one stable hardware center that can survive across multiple enclosure, dock, and mobility concepts.

2. Interaction Layer

Keero Bot is designed around real-world interaction rather than pure compute.

The public hardware story includes support for:

• camera-based perception
• microphone and speaker paths
• haptic feedback
• user input and motion sensing
• display output for local feedback

Together, these pieces position the platform as an embodied AI device rather than a conventional development board.

From a product-story perspective, this interaction layer is what makes the project immediately understandable to both developers and sponsors.

3. Power and Mobility Layer

The system is intended for portable and dockable use cases. Publicly, that means the architecture includes:

• battery-powered operation
• managed charging behavior
• dock-oriented connectivity
• support for mobility-oriented modules such as tracks

The detailed rail implementation stays private, but the public system design clearly communicates that power was treated as a first-class part of the platform.

That matters because serious portable hardware has to be designed around real operational modes, not only a lab-bench power story.

4. Modular Expansion Layer

Modularity is one of the defining parts of Keero Bot.

The platform is designed so that:

• the mainboard remains the reusable brain
• external modules add form factor or capability changes
• pogo contacts and board-level expansion interfaces support iteration without redesigning the full system

This is especially important for future docking, mobility, and accessory experiments.

Modularity is also a strong sponsor-facing signal because it suggests repeated prototype value instead of a one-off fabrication run.

5. Firmware Layer

Firmware is the orchestration layer that turns the board into a coherent product platform.

Its long-term role is to:

• initialize and coordinate hardware subsystems
• manage interaction behavior
• support module-specific functionality
• provide the bridge to AI logic and connected services

Public docs keep firmware more open than hardware production data, which supports community understanding without exposing the full manufacturing recipe.

This asymmetric openness is intentional. Firmware benefits from openness, while production-ready hardware assets benefit from more control.

Architecture At A Glance

If Keero Bot is read as a layered system, the stack is:

1. mainboard hardware core
2. interaction peripherals
3. portable and docked power behavior
4. modular accessories and attachments
5. firmware orchestration

That structure is simple enough to communicate clearly and rich enough to support future demos, iterations, and partner discussions.

Public Disclosure Boundary

This architecture page is intentionally high level.

It explains:

• what the system does
• how the major blocks relate
• why the design is credible

It intentionally avoids:

• exact PCB implementation details
• low-level signal maps for replication
• full manufacturing or sourcing instructions