Component Topology

How the internal components of OctoMY™ nodes connect and communicate.

Did You Know?

The courier system is inspired by medieval postal services - each courier has a mandate specifying urgency and priority. CommsChannel acts as the postmaster, deciding which couriers get to send based on their mandates and available bandwidth.

Data flow overview

The main components of the distributed OctoMY™ system work together as follows:

Inputs: Sensors, audio, and video inputs record values in real-time into a local event inventory - a performant and scalable time series database.

Processing: Some data is pre-processed using filters such as speech recognition, object detectors, or SLAM to generate higher-level events. A logic inference process runs asynchronously, constantly augmenting events using common sense databases.

Control: The master consciousness driver is the main process. When running normally, it processes recent events from the local event inventory and makes immediate decisions for behavior. It generates high-level instructions for:

• Route Planner - Controls robot hardware navigation
• Agenda Planner - Manages and refines agendas for future actions

Outputs: Actuator control sends signals based on currently executing behaviors. Video and audio outputs show status and user interface.

Hub Integration: When an Agent is in contact with a Hub, the local event inventory may be shared, queried, or augmented by the global event inventory. The Hub may run its own consciousness drivers with access to additional compute and online services.

Communication stack

The OctoMY™ communication system is layered:

CommsCarrier

The carrier mechanism handles data transfer between endpoints.

Responsibilities:

• Handle a single protocol (UDP, Bluetooth, etc.)
• Connect to/disconnect from endpoints
• Transfer data bidirectionally
• Provide connection statistics
• Handle errors gracefully

Supported Carriers:

CommsChannel

The main node-to-node communication API.

Design Philosophy:

• Embraces ~512 byte packet size limit
• Two layers: intrinsic (internal) and courier (application)
• Intrinsic handles session management, encryption, reliability
• Courier handles application data

Intrinsic Features:

• Session initiation and handshake
• Bandwidth detection and throttling
• Encryption key exchange
• Reliability for critical messages
• Duplicate/corrupt packet detection

Couriers

Couriers are typed message handlers registered with CommsChannel.

Key Couriers:

CourierMandate

Each courier exposes a mandate describing its needs:

• Urgency - Milliseconds until next send desired
• Priority - 0-255, lower = lower priority
• Accept reads - Whether incoming data is wanted
• Want to send - Whether outgoing data is ready
• Payload size - Expected bytes to send

CommsChannel uses mandates to schedule sending opportunities fairly.

Sessions

Communication sessions progress through states:

Handshake Protocol:

1. A → B (SYN): Session ID + Nonce, encrypted with B's pubkey
2. B → A (SYN-ACK): Full ID + Session ID + Return nonce + New nonce
3. A → B (ACK): Full ID + Return nonce

Session directory

The CommsSessionDirectory tracks all sessions:

Agent internal topology

Remote internal topology