Description

What if SUSE Fleet didn’t just deploy software to robots — but deployed skills? Fleet² (“Fleet Squared”) explores a simple but powerful idea: one robot learns in the field, and SUSE Fleet safely delivers that learning to the rest of the fleet. A robot figures out a better way to pick up an apple, and minutes later every compatible robot has that improved skill — with canaries, rollbacks, and full version history.

This Hack Week project prototypes a collective-learning delivery pipeline powered by SUSE Fleet + K3s. Fleet isn’t a learning system by itself, so the core pattern is to treat robot “learnings” as versioned artifacts — model weights (ONNX/TensorRT), RL policies, behavior trees, calibration packs, or maps — and use GitOps + Fleet bundles to distribute them at scale.

Each robot runs a lightweight K3s cluster with a Fleet agent. A central Fleet Manager reconciles desired state from Git, enabling staged rollouts, capability-aware targeting, and instant rollbacks for both robot software and learned skills. The demo will simulate an end-to-end loop:

a “trainer” robot produces a new skill version,

a validation/approval step gates it,

SUSE Fleet rolls it out to canary robots,

then to all robots.

Optionally, the architecture pairs with NVIDIA Jetson/JetPack + Isaac ROS/GR00T for accelerated perception/manipulation and foundation-model priors — with Fleet² acting as the safe distribution bus for skills across the fleet.

State at start of Hack Week: architecture defined; repo + bundles to be implemented during Hack Week; first end-to-end skill rollout demo targeted.

Goals

By the end of Hack Week, I want to have:

Fleet² repo + bundles working

K3s + Fleet agent running on 2–3 “robot nodes” (real Jetsons or simulated edge nodes)

A Fleet bundle that deploys a minimal robot runtime stack (containerized ROS2 / worker app)

Skill artifact packaging

Define a minimal “skill” format (e.g., model.onnx + metadata.json)

Store versioned skills in object storage / registry

GitOps reference to skill versions via Fleet Helm values

Collective learning rollout demo

Scripted demo where “Robot A learns skill v1.0.1”

Simple validation gate approves it (manual OK for demo)

Fleet delivers v1.0.1 to canary robots → then all robots

Rollback by reverting Git

Capability-aware targeting

Label robots by capability (GPU/no-GPU, sensor pack, arm type)

Show selective rollout to compatible robots only

Short write-up

1–2 page summary of architecture, results, and next steps

Stretch goals (if time):

Lightweight federated-learning “aggregator” service stub

Isaac ROS / Jetson GPU scheduling proof-point

Simulation gate using Isaac Sim or a simple sim KPI

Resources

Docs / sources / references

SUSE Fleet / GitOps for edge clusters

K3s lightweight Kubernetes for edge/IoT/robots

ROS 2 containerization / Kubernetes deployment patterns

NVIDIA Jetson JetPack + Isaac ROS / GR00T (optional integration path)

Planned repo structure (draft)

bundles/robot-runtime/ — ROS2 or robot workload Fleet bundle

bundles/skill-distributor/ — pulls skill artifacts, mounts into runtime

skills/grasping/vX.Y.Z/ — versioned skill artifacts

targets/ — trainers, canary, all-robots

A README with exact links + commands will be added once the repo is live.

Collaboration

Looking for collaboration from folks with:

SUSE Fleet / K3s / Rancher GitOps experience (bundle + target setup, edge-cluster best practices)

Robotics / ROS2 knowledge (packaging nodes, structuring skills, runtime constraints)

NVIDIA Jetson / GPU edge familiarity (nice-to-have) (Isaac ROS containers, GPU device plugin on K3s)

MLOps / federated learning intuition (nice-to-have) (validation gates, multi-robot learning artifact patterns)

Even a short pairing session on rollout/targeting patterns or skill packaging would be super helpful.