Composite robot terminal design

An Android tablet, robot controller, and MCU can form one customer-visible robot without sharing one device identity. The recommended design registers the tablet and controller as separate DDI devices, keeps the MCU behind the controller, and groups all three components under one logical robot asset.

Topology

┌────────────────────────────────────────────────────────────────────┐
│ Customer-visible robot asset: one robot_asset_id                   │
└───────────────┬───────────────────────────────────┬────────────────┘
                │ contains                          │ contains
      ┌─────────▼──────────────┐          ┌─────────▼──────────────┐
      │ Android tablet         │◄── AOA ─►│ Robot controller       │
      │ DDI thing_id: tablet   │          │ DDI thing_id: robot    │
      │ ClearJanitor applet    │          │ runnerchecker process  │
      └─────────┬──────────────┘          └─────────┬──────────────┘
                │                                   │ local bus
                │                         ┌─────────▼──────────────┐
                │                         │ MCU / IMU component    │
                │                         │ no direct DDI identity │
                │                         └────────────────────────┘
                │ mTLS MQTT + HTTPS                 │
                └─────────────────┬─────────────────┘
                                  ▼
                    ┌──────────────────────────────┐
                    │ things.flexgalaxy.ai         │
                    │ one broker + one HTTPS edge  │
                    └──────────────────────────────┘

Android Open Accessory (AOA) is the USB application transport between the two computers. It does not merge their cloud identities and does not authorize one component to impersonate the other.

Identity and ownership

The tablet and controller each generate and retain their own private key. Each certificate SAN contains its own thing_id, and each MQTT client publishes only below device/<its_thing_id>/. Never copy the tablet certificate into the controller or use the controller certificate from the tablet.

The platform registrar establishes these relationships:

Entity

Parent

Role

tablet DDI device

logical robot asset

tablet

controller DDI device

logical robot asset

controller

MCU component

controller DDI device

imu_mcu

The relationship is management-plane data. The DDI SDK provisions identities and carries device traffic; it does not create the customer-visible asset or make an AOA pairing authoritative. A factory or replacement workflow must bind the registered serials to the same robot_asset_id before the product is handed to the customer.

This separation makes tablet replacement safe. A replacement tablet receives a new DDI identity and is attached to the existing robot asset; the robot’s customer history and controller identity do not change.

Telemetry ownership

Each process publishes through the DDI client of the hardware that executes or proxies it. Do not create custom MQTT topics per process because the broker ACL binds a certificate to the frozen device topic tree.

Producer

Publishing DDI device

Example numeric metrics

Example string tags

ClearJanitor

Android tablet

job_duration_seconds, cleaned_area_m2, water_used_ml

producer=clearjanitor, applet_id=clearjanitor, robot_asset_id, job_id

runnerchecker

robot controller

motor_current_a, motor_temperature_c, motor_health_score

producer=runnerchecker, component=drive_motor_left, robot_asset_id

MCU IMU

robot controller

accel_rms_mps2, gyro_peak_dps, imu_temperature_c

producer=mcu, component_id=imu-01, robot_asset_id

These names are an application convention for this example, not new DDI wire fields. The shipped telemetry message supports numeric metrics and string tags. It does not carry arbitrary cleaning-job JSON, arrays of raw IMU samples, or an independent source timestamp through the convenience APIs.

The controller should filter or aggregate high-rate IMU samples locally. If the cloud truly requires raw vectors or the exact MCU sample time, DDI needs a versioned batch/event schema rather than overloading tags or publishing every sample at QoS 0.

Treat robot_asset_id in a tag as query context only. Authorization and durable ownership must join the certificate-derived thing_id to the registrar-owned asset relationship; a device-supplied tag is never proof of ownership.

OTA ownership

The same two certificate identities become two OTA controller targets:

Target

Assignment contents

Installer responsibility

tablet

ClearJanitor APK, tablet agent, or Android system image

a privileged Android device-owner/system installer

robot controller

robot runtime or controller OS

the controller’s A/B or recovery updater

MCU, through controller target

an MCU-firmware artifact in a controller assignment

the controller validates compatibility, invokes the MCU bootloader, verifies the running version, and reports feedback

The DDI OTA clients poll, follow confined HawkBit HAL links, download, verify SHA-256, and send feedback. They do not install an APK, switch a Linux boot slot, or flash an MCU. Product-specific installers perform those actions after the SDK returns a verified artifact.

An MCU-only rollout does not require a third DDI identity. Bazaar can assign an MCU firmware artifact to the robot-controller target; the controller dispatches that artifact to the MCU installer and reports the result using its own identity.

When the count changes

Register the MCU as a third DDI device only when it can independently protect a private key, establish IP networking and mTLS, poll its own OTA assignment, and report its own lifecycle. That produces three registrations and three client connections, but still one shared broker endpoint and one customer-visible robot asset.

If the robot controller has no IP path and the tablet cannot provide ordinary network tethering, the current SDK does not tunnel a second certificate-bound DDI client over AOA. Choose one of these explicit models:

  1. give the controller an IP path through tablet tethering so it still opens its own mTLS sessions;

  2. register only the tablet as the DDI device and model the controller and MCU as tablet-managed components; or

  3. add a delegated gateway protocol with separate identity and authorization semantics before claiming two DDI devices are connected.

The recommended two-device design assumes both the tablet and controller can open their own DDI connections, even when they share the tablet’s physical network access.

Trade-offs

Two identities add provisioning, replacement, and certificate-rotation work. They also isolate compromise, preserve accurate lifecycle state, allow tablet and controller rollouts to progress independently, and prevent a tablet failure from rewriting the controller’s history.

One identity is simpler but makes the connected computer an opaque component. Three identities give the MCU independent lifecycle and rollout state but add a credential and network stack where the controller can already act as a safer installer proxy.

See How to integrate a composite robot for SDK calls and verification steps.