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 — 9 sessions
-
October 1, 2026Making the robotics workshop repeatable and accessible through instructional materials and kitsLeveraging the IKEA Effect to increase user engagement through assembly-required kitsDifferentiating DRG research from traditional robotics by focusing on protocol space applicationsDrone kit application for home inspection and automated visual assessmentUser experience insights from initial kit testing and emerging patterns in user behavior
Participants: jdbb, anurajenp, sn37, rafa_0x, drevius.
The group used this session to debrief their first fully-remote robotics workshop, in which participants bought and assembled a camera/sensor robot kit, connected it via crypto payments, and controlled it with LLM agents (Claude Code / Codex). Participants shared their build experiences, discussed how to improve kit selection, the software/crypto UX, and facilitation, then brainstormed turning the setup into a repeatable, possibly revenue-generating product — including streamed "arena" games and a Halloween-themed maze event. The conversation closed on near-term goals: choosing a better kit, building a simulator, and drafting a pitch to seek grants/partnerships.
- Anuraj: ~14 registrations, ~10 on the mailing list, with several dropping to attend other symposium workshops (e.g. a SIG/FPT-related one). Actual participants included Andre, Jenna, Spencer, Rafa, and Giovanni. He emphasized that running the workshop fully remotely was much harder than his prior in-person (robotics) workshops, where you can see participants' screens and help directly.
- Goal: make the workshop fully repeatable — a Yakrobot website section with region-specific kits (US / EU, possibly a Bangalore, India lab contributing to the protocol), documentation an agent can read, so others could run workshops in their own maker spaces. Build experience
- Andre: found parts generally intuitive to fit (he works in construction), though some required backing off/loosening screws to seat others — a potential roadblock for less hands-on people. Building the robot was easier for him than setting up the Raspberry Pi and loading the program.
- Spencer: committed early, procrastinated, nearly backed out, but assembled it just in time and was very glad he did. Stressed that solo pre-building was valuable.
- Jenna: assembled the tumbler easily and enjoyed it; her first Frino kit arrived pre-assembled and broken, the replacement arrived after her window had closed, and she got stuck on a white camera cable (possibly broken). She noted "kits are an art form" and has since switched to a software/virtual rover to still participate. Kit quality & selection
- Rafa: the kit was "okay" but a better kit and a proper bundled "protocol-institute kit" (one-click bundled purchase) would be an improvement; suggested an agent-driven "kit buying portal" (drop-shipping style, possibly including custom PVC parts). Framed a one-year objective: "can we find a better kit?"
View discussion in Discord →Links discussed -
September 17, 2026
Participants: Anuraj, Spencer Norwick, shreeram, Andre Comeau
This was a working session ahead of an upcoming robotics workshop/symposium in which participants will assemble a small "PiCar"-style robot and put it behind a crypto-payment gateway. Anuraj gave an extended screen-share walkthrough of his current build: an MCP server plus a browser teleoperation UI, a Cloudflare Worker payment service using testnet USDC, on-chain robot registration/attestation, and hashed time-based access tokens. The rest of the group (Spencer, Andre, shreeram) asked questions about hardware readiness, security/hackability, extending the gateway to other IoT devices, and adding a Stripe-based payment option.
- Hardware readiness (mixed): Spencer: Waiting on a Raspberry Pi to arrive; had assumed the kit required a larger Pi and didn't realize it was compatible with the Pi Zero. Anuraj: Confirmed the Pi Zero works for teleoperation but is too limited to run small ML models; larger Pis (e.g. with 2GB) allow more. Cost difference is small. Andre: Robot is partly assembled and moves, but he ordered the wrong batteries. He has a 5A battery (enough to power on and move) but was missing the 10A+ battery needed to run the full feature tests (e.g. lights); testing cuts off, likely due to insufficient power. A higher-powered Pi may also draw more; he's waiting on replacement batteries and is unsure they'll arrive in time. He's in Canada, and Anuraj's kit link didn't work for him.
- The gateway demo (Anuraj): Running the gateway opens two interfaces on the same server: an MCP server (so an agent can be talked to/control the robot) and a browser-based teleoperation UI, which can be publicly exposed via ngrok. A single setting toggles payments on/off (payment enabled = 1 shows a paywall; = 0 lets you just drive it). Payment flow: built on a Cloudflare Worker; operator sets price and lease duration via environment variables. Users connect a browser wallet (MetaMask or similar), sign a transaction to connect, and pay in testnet USDC on Base Sepolia. WalletConnect for mobile is possible but not yet implemented. On-chain trust model: Robots are registered on-chain with the operator's wallet; Anuraj maintains an approved-wallet allowlist and an admin page to attest robots. Payments are only accepted for attested robots and only routed to the attested operator's wallet, all verified on-chain (and via IPFS for capabilities). Time-based access: Current setting is ~1 USDC for 5 minutes, with the ability to release early. On payment, the Cloudflare Worker timestamps and signs a token; the gateway starts a clock from that timestamp. The token is a hash ("capability" token, similar in spirit to a JWT) so tampering with the time changes the hash — preventing users from faking the clock in-browser.
- Extending to other devices (shreeram's interest): shreeram asked whether household devices (he has a rootable, dead Roomba) could be placed behind the gateway. Anuraj said yes — the robot is essentially an ESP32-class device, and IoT devices can be put behind the gateway by writing a plugin (a protocol adapter + the MCP tools). Adapter type depends on the device's interface (HTTP endpoint → HTTP adapter; UDP → UDP adapter). He'd previously tried Home Assistant devices behind the gateway but hit issues and didn't pursue it.
- Assembly/config detail (Anuraj): There's a setup script that runs a series of tests and, because everyone mounts motors differently, walks you through identifying each wheel's rotation direction (e.g. "front right wheel, which direction?") and stores the result in a config file. This is installed as a system service on the Pi so it persists across reboots; the HTTP endpoints read the config to drive wheels in the correct direction. Anuraj runs the Pi headless via SSH.
- Vibe-coding the plugin: Anuraj mentioned building the PiCar plugin quickly (~15–18 minutes) by pointing his coding assistant at the SDK, the gateway, and templates/"little parts."
-
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). Practical stack & experiments (Anuraj)
- Built a teleoperation effort for his robot last weekend; fed camera screenshots into the controlling agent, which (with Claude memory/context enabled) could locate a "Tumblr" robot it had prior context on — demonstrating higher-level visual reasoning.
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.
- ~$80 kit, assembled over roughly two weekends (~6 hours total; could be done in ~3 hours straight). Assembly videos exist but are "not very clear."
- Hardware: four DC motors, two servos for camera/ultrasonic pan-tilt, ultrasonic sensor, ADC for battery voltage, LEDs, and mecanum-style wheels allowing sideways/angled ("drift") motion.
- Runs on a Raspberry Pi Zero (512 MB RAM, ~$50). A Pi 4/5 with more RAM would cost far more (~$300–350) but could run ROS onboard.
- No wheel encoders — rotation is done open-loop by timing motor commands rather than closed-loop feedback.
- An "ultrasonic scan" pans the sensor to take ~4 distance measurements as a crude LIDAR-like snapshot; display is rough. A small 2D LIDAR is seen as the easiest path to real mapping. Software architecture (Anuraj R)
- Ported the vendor software (TCP/WebSocket based) to a custom FastAPI HTTP server, making it fully independent of the vendor's code.
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. Maier's map example: With software agents you'd run three cheaply, each failing differently, and compare. With three robots building a map, there's a nonzero chance they physically interfere (hide the map, alter the space), and outputs differ physically (one slips here, one there, a mirror). Coordination issues for robots differ fundamentally from agents.
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 →