Distributed Robotics Group
The Distributed Robotics Group studies and develops protocols for onchain robotics — examining how decentralized coordination, blockchain infrastructure, and robots and physical AI intersect to create new classes of protocol design challenges. Building one robot is an engineering challenge; getting two or more to coordinate is a protocol problem.
Meeting Archive — 7 sessions
-
September 3, 2026Stigmergy as a coordination mechanism in distributed roboticsRobots as protocol citizensWorkshop on robot autonomy and decentralized systems
Participants: anurajenp, rafa_0x
The group did a round-robin of reactions to a swarm-robotics paper, praising it as "really cool" while probing its limitations (an engineered/constrained environment, and a claim about automated control software that may only hold for simple finite-state machines). Discussion evolved into a generative brainstorm about how to apply the paper's ideas to an upcoming symposium/workshop, coalescing around Will's coined term "ferrabyte" (a digital pheromone). The session closed with logistics about the hands-on robot-kit workshop and a possible physical maze experiment in Berlin.
- **Maier — critique of the experiment:** Two shortcomings. (1) The paper ignores robots *changing* the environment (e.g., moving LEGO bricks), which he finds more interesting; this omission is what forces the engineered, constrained UV/photo-floor setup. (2) The "computers write control software better than humans" conclusion is overstated — what they optimized was a small-state **finite state machine**, which computers optimize easily; this approach likely wouldn't scale to more open control (e.g., using LLMs), and suits many-simple-robot swarms more than fewer sophisticated robots.
- **Maier — layers of protocol:** Robots must first agree on *what counts as a marking* (recognition), then agree on *what each marking means* (semantics), and only then tackle a third layer: distributed algorithms for coordinated action. Non-engineered, heterogeneous environments make defining and accurately interpreting environmental changes much harder.
- **rafa — biological/analog framing:** Recommended the book *Vehicles* by Valentino Braitenberg (short, ~140 pages, read five times), about simple sensor-driven vehicles that appear "alive" in aggregate. Proposed the need for a **global robot-interaction protocol** analogous to TCP/IP packet handling, and asked what an appropriate "stigmergic" (stigmatizing, per transcript) protocol looks like in the real world. Suggested pheromones might live on a **digital map overlay** rather than physically.
- **rafa — deeper questions:** Do pheromones live on the map itself or on a *mapping of the map* (e.g., a blockchain-hosted coordinate system, akin to but more specific than what3words)? Digital maps also degrade/diverge locally over time like physical ones. Also floated that **one robot might itself be a swarm of agents** (some agents acting like the robot's "organs"), so a robot may not evolve to be a monolithic agent.
- **shreeram:** Skeptical of the sweeping claim that "Habanero" beats humans in all cases — a determined human might still win. Noted the method is constrained to a fixed set of software modules; unclear from the paper exactly what those modules are and how they're grouped per task. Found it striking that such a constrained setup still yields good outcomes. Later raised teleoperation over wireless (e.g., a mining robot on an asteroid) where data/power is limited.
- **Spencer:** Interested in applying the ideas to the symposium. Suggested a rectangular built environment; robots could come **pre-wired with a shared protocol (like instinct in ants)** rather than negotiating one. Proposed a sliding weight too heavy for one robot but movable by two+ (a way to let robots change their environment, addressing Maier's point). For distributed/remote robots, aim for near-identical environments where agents navigate to the same pose and measure how closely different algorithms converge. Later proposed **battery life as an analog of an ant's lifetime**: send consecutive bots into a maze with limited time to leave "ferrabyte breadcrumbs," so later bots navigate faster; test 1 vs 2 vs 3 bots and randomized time limits.
View discussion in Discord →Links discussed -
August 20, 2026Claude model application to robotics tasksTeleoperation mechanisms and controlVisual perception tools for egocentric robot visionComparative evaluation of perception assistance methodsCompass-based orientation guidance for models
Participants: anurajenp, sn37, rafa_0x
The group went around sharing reactions to Anthropic's robotics/LLM experiments, then broadened into discussion of the practical stack for LLM-controlled robots — teleoperation, latency, and where compute should live. Jenna introduced an organizational note about a planned PI (Protocol Institute) quarterly journal and possible written/interactive outputs from the group. The session ended with Anuraj demonstrating a live browser-based teleoperation setup controlling his robot in Finland.
- **rafa:** Robotic control by LLMs feels increasingly like a "solved problem" in principle — the open questions are *when* and *which narrow use cases* get solved first. Noted a recent general AI model for robotics that learns by watching examples. Raised the "stack of problems" that remain even if driving/control is solved: latency, real-time reconstruction, and deciding what compute lives on the robot vs. off it. Anchored this in his own struggle to get reliable home Wi-Fi/mesh networking.
- **shreeram:** Wants to see the actual implementation code, not just the writeup (his robotics background is minimal). Found it notable that in the "policy task," supervision made older models *worse*. Confused by unexplained ~20-second gaps in the pendulum/classic-control tasks. His main critique: the paper never establishes what the *best non-LLM method* can achieve as a baseline, so it's unclear whether LLMs are actually the right tool or just a hammer being applied everywhere.
- **Spencer:** Most interested in the experiment-level details — how small setup changes yield outsized improvements. Highlighted two examples: adding a "compass" giving the locomotive robot orientation in degrees, and adding a crosshairs/reticle to the camera view. Argued we should look for ways to help models "in the way they want to be helped," rather than forcing them into human-style control paradigms.
- **Anuraj:** Had a "meh" reaction. Argued the path of using a language model alone won't yield much for real-world navigation — you need a *world model* for embodied action (humans don't verbally reason about walking or holding a cup; it's a different mode of thinking). Thinks LLMs are better suited to higher-level planning, while low-level control needs models trained from scratch with embodiment. Agreed with shreeram's "hammer" framing — Anthropic seems to try many reward setups to see what sticks. Suspects robotics isn't a major Anthropic priority, hence the simple experiments.
- **Maier:** Read the goal as a mix of *safety* (will people use our AI to build killer robots?) and *capability assessment* (how good are LLMs today?). Noted they tested LLMs at ~four levels of abstraction but tried to solve all layers with one model — whereas he'd use a *different LLM per layer*, both because that mirrors biology and because these problems are too hard to solve simultaneously in one decision. Called Anuraj's "let LLMs do what they're good at, glue from elsewhere" view exactly the kind of prescription the paper lacked. Found "points of light": LLMs writing their own control code, and the question of what *protocol* a robot should use to get help from an LLM (given LLMs are energy/CPU heavy — maybe a robot runs a small/pretrained model locally).
View discussion in Discord →Links discussed -
August 6, 2026HTTP/MCP Server implementation for PiCar Freenove robot kitTwo-tier API architecture (high-level autonomous agent vs. low-level tethered control)Low-level telemetry and verbose monitoring capabilitiesWorkshop logistics and participant recruitment for symposiumRegistration and onboarding infrastructure setup
Participants: anurajenp, _vgr, shreeram8484, drevius., rafa_0x
Anuraj R gave a live demonstration of a small (~$80) four-wheeled robot kit he assembled and programmed, showing how he ported its stock software to a custom FastAPI HTTP server and connected it to the group's robot gateway/MCP server so that a browser-based Claude agent could teleoperate it. The discussion covered the technical architecture (adapters, plugins, gateway, tunneling), how the build was done with AI coding agents, ideas for future features, and a recurring open problem of how to *verify* that a robot actually performed a task. The group also began planning a hands-on workshop where participants would assemble and register robots on the marketplace.
- _vgr advocated for a dual-mode API design supporting both autonomous agent behavior and direct controller tethering, with comprehensive low-level telemetry access.
- drevius. expressed interest in purchasing the kit and volunteered to participate in workshop dry-runs while on vacation through August 30.
- The group decided to use a Google Form for participant registration rather than email-based systems to avoid spam filter complications.
- Hardware assembly requires separate procurement of Raspberry Pi and batteries beyond the robot kit itself.
- The project is being integrated into the Protocol Symposium 2026 workshop program under 'Robots as Protocol Citizens' theme.
View discussion in Discord →Links discussed -
July 23, 2026A2A (Agent-to-Agent) Protocol applicability for roboticsIntegration of A2A protocol with yakrobot-gateway (currently MCP-based)Comparison of deterministic vs. probabilistic coordination protocolsCore objects and structure of A2A for robot task managementAgent-to-robot coordination at swarm scaleSymposium capstone incentivization strategies
Participants: anurajenp, rafa_0x, maier.fenster, sn37
The session compared the A2A protocol and a "marketplace protocol" as candidate negotiation layers for a robot marketplace, questioning how well web-agent standards map onto physical robots. Participants debated task verification, timing mismatches, centralized vs. distributed coordination, and how payments/authentication would work. The second half turned to logistics for an upcoming symposium workshop involving assembling and registering Raspberry Pi–based robots.
- **Reusing web standards for robot agents (christopher boette):** Suggested leaning on existing web-based tech and letting broadcasting agents declare which schemes they accept. Noted the trustless agents spec called out something composable with A2A, making interoperability worth exploring. Robot capabilities change over time (sensor degradation, tool loss); the spec points to broadcasting via a `.well-known` mechanism, and keeping that index up to date seems "easily solvable."
- **Timescale mismatch (christopher boette):** A recurring concern he'd raised before — verification and task completion for a physical robot operate on very different time scales than a database operation for a web agent. Liked seeing that a task has a start and an ID, plus a streaming mechanism, and presumed you can also query task status by ID.
- **Two-layer marketplace (rafa):** Envisions robots having an "agent mediation layer." A2A-style communication fits the *initial* phase — task definition, negotiation, bidding — but there's a **handover** to a different tempo for *execution management*. He doubts the agent-to-agent framework fits the physical execution phase; the two layers may need different standards.
- **Verification problem (shreeram):** Unclear how you verify a task was done optimally or as intended — even the A2A trip-planning example doesn't make this obvious. Raised whether robotic comms even need to piggyback on web-agent flows plus a separate physical endpoint, and weighed the A2A approach as a hedge against lock-in by big companies (e.g., Google).
- **Protocol as a negotiation layer (Anuraj R):** In the current stack, a robot is just an MCP tool with little agency, requiring continuous monitoring by the calling agent (e.g., a persistent cloud-session connection to an MCP gateway/orchestrator). This protocol would let a sufficiently autonomous robot negotiate more independently and separate the task state from the calling agent. Direct coordination/control already has standards (**OpenRMF**, originally from hospitals, used as a factory orchestrator); the novel piece is *probabilistic negotiation between autonomous agents*. Gave an example: broadcast "get me the map of this field, I'll pay $10," and three robots + a drone bid different prices; the protocol lets you pick (e.g., choose the drone).
- **Meta-concern: robots are different (Maier):** Worried the process copies concepts from autonomous agents to shrink the work, but the underlying problems of robots are genuinely different — changing abilities, physical/spatial limits, power, much slower operation. Fears locking into a mindset via inherited standards that won't fit robot needs.
View discussion in Discord →Links discussed -
July 9, 2026EIP-8126 specification and requirementsRobot verification methods and approachesVerification criteria and validation standardsDistributed robotics authentication mechanisms
Participants: anurajenp
The Distributed Robotics Group held their third meeting to review EIP-8126 and discuss robot verification mechanisms. The meeting prompt called for general commentary on the EIP alongside exploration of various robot verification approaches, implementation methods, and what specific aspects of robot systems require validation. The discussion centered on understanding the verification landscape for distributed robotic systems and how to establish trust and authenticity within the network.
- The meeting focused on evaluating EIP-8126 as a framework for robot verification within distributed systems, examining both the technical specification and practical implementation approaches.
- Multiple verification methodologies were under consideration to establish identity and authenticity of robots in the DRG ecosystem.
- Key verification concerns include determining what robot attributes and capabilities require validation and establishing appropriate verification protocols.
View discussion in Discord →Links discussed -
June 25, 2026ERC-8004 standard and trustless agent identity frameworkThree on-chain registries: Identity, Reputation, and ValidationApplication of trustless agent identity to physical robots vs software agentsProtocol design for distributed robotics coordination
Participants: anurajenp, _vgr, jdbb
The DRG group held a study session focused on ERC-8004, an Ethereum standard for trustless agent identity. The meeting began with preparation materials including the ERC specification, GitHub repository, and explanatory blog post. Participants were scheduled to meet on June 25, 2026 at 16:30 UTC in the Whitehead room for a structured learning session. The agenda called for 25 minutes of silent reading and study of the ERC-8004 standard, with particular emphasis on its three core on-chain registry components: Identity, Reputation, and Validation layers. A central theme for discussion was exploring what trustless agent identity means in the context of physical robots operating in the distributed robotics space, as opposed to traditional software agents, and understanding the implications for robot coordination and trust establishment.
- ERC-8004 introduces a trustless identity layer specifically designed for agents, requiring examination of how this applies to physical robotic systems rather than just software agents.
- The standard implements three distinct on-chain registry components (Identity, Reputation, Validation) that work together to establish trust without central intermediaries.
- A core discussion point is how the concept of trustless identity fundamentally differs when applied to physical robots that exist in the real world versus purely digital agents.
View discussion in Discord →Links discussed -
June 11, 2026Group formation and member onboarding for Distributed Robotics GroupSurvey deployment to understand participant backgrounds and experience levelsArchitecture evaluation criteria and module selection philosophyStack technology choices and open-source alignment preferencesFull-stack opinions vs. constraints in system design
Participants: anurajenp, _vgr, rafa_0x
The Distributed Robotics Group held its inaugural kickoff meeting on June 11, 2026. The session focused on onboarding new members and establishing foundational processes for the group's work. Organizers distributed a brief survey to gather information about participants' backgrounds, experience levels, interests in robotics, and preferred working styles, with results intended to inform the group's agenda and office hour scheduling over the coming months.
Key discussion centered on establishing evaluation criteria for architectural decisions and module selection. While acknowledging that the protocol itself may remain agnostic to many technology stack choices, participants argued for developing rubrics that reflect the group's philosophical alignment with open-source and community-driven solutions. The group recommended maintaining strong full-stack opinions on architecture even when not imposing hard constraints, preferring solutions like open-source VPN alternatives to proprietary options when capabilities are equivalent.
- The group developed a background survey to understand member interests, hardware/software experience, and robotics work preferences to shape the agenda and organize office hours.
- A rubric for evaluating modules was proposed as a valuable artifact, even when the protocol itself remains agnostic to stack choices, to ensure philosophical alignment with group values.
- Open-source alternatives are preferred over proprietary solutions when other factors are equal (e.g., open VPN alternatives over Tailscale).
- The group should maintain full-stack opinions on architectural choices even when not enforcing full-stack constraints or commitments.
View discussion in Discord →Links discussed
Interested in joining? Join the Discord community →