The Mission Gap

Agricultural stewardship at community scale requires a physical mobile agent capable of autonomous rounds, crop monitoring, and task execution — operating reliably off-grid where connectivity is intermittent and on-site technical support is hours away.

• General-purpose humanoid robots are over-engineered for agricultural stewardship and under-designed for outdoor terrain variability, power constraints, and unsupported remote operation.
• A fleet of 5–8 units across 3–5 acre plots requires a cost-disciplined, maintainable architecture with shared parts pool and a CI/CD pipeline that allows safe iteration without on-site expertise.
• Security and identity cannot be retrofitted onto edge devices in a community IoT fleet — they must be established before logic, not bolted on after.

Purpose-Built from First Principles

Every hardware and software decision in Kevin's design is constrained by one mission and one deployment context. Not by what is conventional for humanoid robotics — by what works for off-grid agricultural stewardship on the Stewardship Node.

• Container + workspace established first (Phase A) so the build graph is correct before any node is written — colcon, systemd watchdog, and L4T base locked before any application code.
• Interface definitions locked before node development (Phase B) — ROS 2 .msg/.srv/.action files define the contract. Changing them later forces rebuilds everywhere; define once, correctly.
• Security baseline applied to the container and DDS layer before nodes are written (Phase C) — seccomp profiles, SROS2 keystore, per-topic access control. Retrofitting is painful; starting secure is not.
• All core nodes developed against synthetic sensor data (Phase D) — the full stack is CI-testable and hardware-independent. Risk is deferred to Phase 2 hardware bring-up, not front-loaded.
• health_monitor as safety backbone: e-stop logic enforced by architecture. If the safety node fails, Kevin stops — not because policy says so, but because no other node can proceed without it.

Security Design

• SROS2 keystore with per-topic DDS-Security access control — node identities generated before node code is written; FastDDS authentication enabled from day one. Every node is born with an identity, not assigned one after the fact.
• Docker security hardening: seccomp profile, capability dropping, non-root user, read-only rootfs where possible — applied to compose.yaml before any application code. Retrofitting container security is painful; building it in is not.
• AWS IoT Thing with X.509 certificate — cloud identity provisioned by kevin-infra Terraform monorepo, not manually configured. Same model as Watershed: no shared credentials, no secrets on edge hardware.
• E-stop logic in health_monitor (task 8) — safety backbone. If health_monitor fails, Kevin stops. The safety invariant is enforced by node dependency, not by convention or policy.
• Interface definitions locked in Phase B (task 5) before any node development — .msg/.srv/.action files are the interface contract. Changing them forces rebuilds everywhere; treat them like a public API.

Observability & Operations

rosbag2 logs all ROS 2 topics to disk on the edge device — the full sensor stream, node outputs, and health events are available for post-run analysis with zero network dependency. The MQTT bridge (task 12) streams selected topics to AWS IoT Core, connecting Kevin to the Project A Meal fleet telemetry layer. At fleet scale (5–8 units), every Kevin is observable from Marlene's dashboard without SSH access to individual nodes.

Phase 1 — In Progress

Phase 1 software foundation is underway. The architecture is designed to be fully validated in simulation and CI before any physical hardware integration — reducing risk at the most expensive phase of the build.

• Phase A — Container + workspace: Docker L4T base, colcon workspace skeleton (kevin_bringup, kevin_sensors, kevin_base, kevin_health), systemd lifecycle and watchdog units.
• Phase B — Identity + interfaces: URDF TF frame tree (base_link, odom, map, sensor frames), ROS 2 custom message/service/action definitions for all nodes.
• Phase C — Security baseline: SROS2 keystore + per-topic DDS policy, Docker seccomp + capability dropping, non-root user — security built in before any node logic.
• Phase D — Core nodes: health_monitor (safety backbone), robot_state_publisher, sensor mock + rosbag2 harness, base_controller, MQTT data logger, EKF config, GitHub Actions CI/CD.
• Fleet vision: 5–8 Kevin units at community scale, one per 3–5 acres, shared parts pool, each reporting to Marlene and Project A Meal via AWS IoT Core.