R-D6 robot on Arduino Uno delivers cargo through a browser city with physics and pedestrians
PinPort is an online lab where you build a circuit in your browser, write an Arduino sketch, and see the result on an emulator. This time, its creators expanded it with a virtual city featuring cars, traffic lights, and pedestrians—and sent in a six-wheeled robot called R-D6 that hauls cargo from point A to point B. The robot isn't controlled by JavaScript but by a regular Arduino Uno sketch, compiled server-side via arduino-cli and run on an ATmega328P emulator. The emulator runs at 16 MHz, synchronized with the Rapier physics engine (2 ms step). The lidar and navigator connect over I2C, sensors are implemented as registers, and motor control runs through PWM and an L298N driver. • **City**: a 3×3 grid with 32 m spacing, 8-meter roads in each direction, 3-meter sidewalks, 5 traffic lights (50-second cycle: 20 s green, 3 s yellow, 2 s all-red) • **Dynamics**: 12 cars drive the lanes, 20 pedestrians walk the sidewalks and cross with a 0.4 probability, yielding to the robot once it comes within 1.7 m • **Reliability**: determinism via mulberry32, one sketch = one outcome, runs identically across different machines
AI-processed from Habr AI; edited by Hamidun News
PinPort is an online lab for teaching robotics, where you write Arduino sketches in your browser and see the result on an emulator. The developers built a 3D city with cars, traffic lights, and pedestrians, through which a six-wheeled robot named R-D6 drives. It's controlled by a real Arduino Uno sketch, compiled server-side via arduino-cli and run on an ATmega328P emulator. The robot must deliver an order from point A to point B while obeying traffic rules.
Architecture: three synchronized layers
The system consists of three parts moving in lockstep: the AVR emulator (16 MHz, PWM, I2C, UART), the Rapier physics engine (2 ms step), and the city with its traffic-light and pedestrian logic. The board and the physics alternate: two milliseconds of emulation, then a physics step.
Sensors are implemented as I2C registers. The lidar (address 0×52) outputs 36 sectors of 10° each at 10 Hz, with a range of 20 m. The navigator (0×53) updates 50 times per second and returns position, heading, bearing to the target, and distances. The lidar consists of three rays per sector (−3°, 0°, +3°), with the closest hit taken. Motor control runs via PWM on the ENA/ENB pins and L298N driver logic levels. The built-in RD6.h library reads the lidar scan (72 bytes) in three 24-byte chunks, since the Wire buffer is only 32 bytes.
The city and its inhabitants
The layout is a 3×3 grid with 32 m spacing, 8 m of roadway in each direction, and 3 m sidewalks. Five traffic lights sit at the intersections (50-second cycle: 20 s green, 3 s yellow, 2 s all-red). Twelve cars drive the lanes, keep their distance, and pick turns randomly at intersections. U-turn radii: 2 m for right turns, 6 m for left turns.
Twenty pedestrians walk loops along the sidewalks. At a crosswalk, they decide to cross with a 0.4 probability, start crossing on green, and don't start on a flashing signal. Pedestrians yield to the robot: if it comes within 1.7 m, a person stops and steps back after 0.6 s. Cars and pedestrians are physical bodies in Rapier, so the lidar sees them just as it sees buildings, and collisions are real contacts within the engine.
The route is built using Dijkstra's algorithm on a graph. The navigator doesn't point to the next waypoint but to a "carrot"—a position 2.5 m ahead (classic pure pursuit). Without this, the robot would cut corners toward distant points, drift toward the curb, and stop in front of trees (which grow every 8 m). With the carrot, the robot stays centered on the sidewalk and in the middle of the crosswalk. Building facade windows are drawn every 2.6 m horizontally and 3 m vertically. The finish is registered once the robot's center comes within 1.5 m of point B.
Determinism and reproducibility
The entire system is designed to produce one single result whether run on a weak laptop or a powerful computer. Three rules: randomness comes only from mulberry32 with a fixed seed, time is counted in physics steps (no Date.now()), and cars and pedestrians make decisions once every 20 ms on a fixed grid.
Verification: the firmware is run twice with different time slicing (2 ms and 7.3 ms per call), and the world-state hashes are compared—they match. On the competitive arena, the server runs a participant's firmware in Node.js using the same modules as the browser, and the hashes match down to the last digit.
A five-rule autopilot passed all 12 "route × scenario" combinations without violations. Delivery takes 65–135 seconds of simulated time. Extensions include: night mode (around 45% of windows lit, based on a hash of floor and bay), rush hour with 40 pedestrians, and sidewalk repairs. Rendering runs on a custom WebGL renderer without external engines: buildings are rendered as boxes, with windows drawn by a fragment shader. The camera follows the robot and rises if a building blocks the view. Tree canopies along the line of sight aren't drawn. A top-down Canvas 2D view is available for debugging, showing the route, every traffic light's signal, and the lidar rays.
Key Questions Answered
What are the key details on Architecture: three synchronized layers?
The system consists of three parts moving in lockstep: the AVR emulator (16 MHz, PWM, I2C, UART), the Rapier physics engine (2 ms step), and the city with its traffic-light and pedestrian logic. The board and the physics alternate: two milliseconds of emulation, then a physics step. Sensors are implemented as I2C registers. The lidar (address 0×52) outputs 36 sectors of 10° each at 10 Hz, with a range of 20 m. The navigator (0×53) updates 50 times per second and returns position, heading, bearing to the target, and distances. The lidar consists of three rays per sector (−3°
What are the key details on The city and its inhabitants?
The layout is a 3×3 grid with 32 m spacing, 8 m of roadway in each direction, and 3 m sidewalks. Five traffic lights sit at the intersections (50-second cycle: 20 s green, 3 s yellow, 2 s all-red). Twelve cars drive the lanes, keep their distance, and pick turns randomly at intersections. U-turn radii: 2 m for right turns, 6 m for left turns. Twenty pedestrians walk loops along the sidewalks. At a crosswalk, they decide to cross with a 0.4 probability, start crossing on green, and don't start on a flashing signal. Pedestrians yield to the robot: if it comes within 1.7 m, a
What are the key details on Determinism and reproducibility?
The entire system is designed to produce one single result whether run on a weak laptop or a powerful computer. Three rules: randomness comes only from mulberry32 with a fixed seed, time is counted in physics steps (no Date.now()), and cars and pedestrians make decisions once every 20 ms on a fixed grid. Verification: the firmware is run twice with different time slicing (2 ms and 7.3 ms per call), and the world-state hashes are compared—they match. On the competitive arena, the server runs a participant's firmware in Node.js using the same modules as the browser, and the h
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
The AI world, distilled — once a week
Seven stories that actually mattered, hand-picked. No noise, no reposts, no press releases.
Done! Check your inbox for a confirmation.