Tsukada Lab, The University of Tokyo — Evaluation Platform Sub-Team Prof. Manabu Tsukada, Prof. Ehsan Javanmardi, March 2026
A five-year bet that cars and roads should talk to each other
When the CooL4 project began in 2021, Level-4 autonomy on open Japanese streets was still a distant promise. By the time it closed at the end of March 2026, a driverless bus was turning right through a busy intersection in Kashiwa-no-ha — guided, in part, by sensors bolted to the traffic signals overhead.
CooL4 — the Cooperative Level 4 activity of Japan’s national RoAD to the L4 programme (Theme 4) — set out to answer a specific, stubborn question: in a truly mixed-use environment, where autonomous buses share narrow streets with pedestrians, cyclists, and human-driven cars, can roadside infrastructure do what onboard sensors alone cannot?
The answer took five years, a consortium of six institutions (The University of Tokyo, Nagoya University, AIST, Mitsubishi Research Institute, Japan Automobile Research Institute, and Advanced Mobility Co., Ltd.), and a real bus running a real route. On 13 January 2026, the Kashiwa-no-ha service began formal Level-4 Special Autonomous Operation — one of the first in Japan on an open, mixed-use public road.
This article is about what happened underneath that headline: how our team, the Evaluation Platform sub-team at Tsukada Lab, built the open simulators, analysers, and methods that made it possible to measure whether the cooperation was actually working.
Our role: if cooperation can’t be measured, it can’t be trusted
Within CooL4, our remit was narrow and specific — build the evaluation platform. Other teams designed the roadside units (RSUs), the autonomous driving stack, the data-linkage platform. Our job was to make all of it visible: to quantify V2X communication quality, to model where sensors should go before concrete was poured, and to simulate the effect of cooperation on real traffic before sending a real bus into real traffic.
Over the final year, this work crystallised into three concrete deliverables — two of which are now open source and available to anyone who wants to evaluate cooperative driving on their own streets.
Achievement 1 — AVVV: making packet loss visible
Before you can improve a V2X network, you have to see it. AVVV (Autonomous Vehicle V2X Visualiser) is a toolchain — analyser, reporter, visualiser — that turns raw ROS-encapsulated V2X traffic into latency, jitter, RSSI, and packet-loss metrics a human can actually read.
AVVV consumes the ROS messages autonomous vehicles already produce, ships them as UDP packets between vehicle OBUs and roadside RSUs, and measures what arrives, when, and intact. The tooling follows the ETSI CPM (Collective Perception Message) standard, so results are comparable across sites and projects that use the same spec.
This year we completed what matters most for a research tool: we opened it. AVVV is now a fully documented open-source release — install guides, configuration, API reference, protocol notes, dataset access, and troubleshooting — enough for a third-party team in a different city to deploy it independently.
AVVV links:
- Documentation: https://tlab-wide.github.io/avvv_etsi/
- GitHub: https://github.com/tlab-wide/avvv_etsi
AVVV ETSI documentation homepage.
Why open-sourcing matters
V2X evaluation is one of those quiet bottlenecks where every project tends to re-invent the same wheel, poorly. By releasing a reference implementation pinned to a real standard, we remove several engineer-months of duplicated work from whoever comes next — and we nudge the field toward comparable numbers instead of artisanal ones.
Achievement 2 — Quantitative sensor placement at Gan-ken intersection
A roadside LiDAR that can’t see a cyclist behind a tree is just expensive scenery. This year we extended our 3D sensor-placement evaluation method — originally built for the Kagaku-keisatsu-ken (科警研) West intersection — to a second site: the Gan-ken (がん研) intersection, another key point on the Kashiwa-no-ha bus route.
The method is pragmatic. We build a high-fidelity 3D scene from real point-cloud data of the intersection (buildings, trees, kerbs, signals — everything), place virtual LiDAR sensors in candidate positions, and sweep ray-traced detections against pedestrians, cyclists, and vehicles moving through the scene. The output is a heatmap: for every square metre of the intersection, the probability that something standing there would be seen.
3D simulation model vs. real-world point cloud data at Gan-ken intersection. Left column: simulation model. Right column: same viewpoints superimposed on the real point cloud.
Four candidate placement patterns were evaluated at Gan-ken, covering the existing south-west corner sensor and three alternative positions across the pedestrian island and east sidewalk. All four used the Cepton P60 as a reference model (200 m sensing range, 60° horizontal × 22° vertical field of view, 88 channels, ~3 cm range error at 10 Hz).
Viewpoints from each of the four candidate LiDAR positions.
The heatmap tells the story
No single sensor does everything. Pattern 1 — the existing installation — is strong along the east-west direction the bus actually travels, but foliage at the south edge shadows part of its view. Pattern 4, mounted on the east footpath, neatly complements it. When we integrate all four sensors, the red “blind” regions on the pedestrian heatmap essentially vanish: 80–100% detection coverage across the entire walking envelope.
Pedestrian, cyclist, and vehicle detection heatmaps with all four sensors integrated.
Simulated LiDAR point-cloud output from each pattern (colour-coded) and all four combined.
The concrete recommendation to the project: for Gan-ken, keep Pattern 1 and add a sensor at the east position (Pattern 4). This work now feeds directly into real RSU deployment planning — height, angle, and mount position all traceable to measurable coverage, not eyeballing.
Achievement 3 — V2XSim × Simple_AV: does cooperation actually make traffic smoother?
This is the question that mattered most — and the hardest one to answer honestly. We built, extended, and this year open-sourced the tools to answer it: V2XSim, a Unity-based cooperative simulation environment, and Simple_AV, a ROS 2 autonomous-driving stack tuned to the CooL4 speed profile.
V2XSim (left) driving the virtual world, and Simple_AV (right) running the autonomous driving stack with the same ROS 2 messages a real bus would see.
The scenario
We focused on one action: the bus making a right turn at Kagaku-keisatsu-ken West intersection, with vulnerable road users (VRUs) potentially crossing the target area. Without infrastructure assistance, the bus conservatively crawls through at 3 km/h. With RSU-provided object information, if the danger zone is clear, it passes at 12 km/h. That is the cooperation. The question is what it costs and what it buys.
Scenario anatomy: the ego autonomous bus, surrounding vehicles, VRUs, detection boxes, signal phase, and the ADS’s two-speed decision.
Three things we built this year into the simulator
A simulator is only useful if its assumptions match reality. Last year’s V2XSim could already render cars and crosswalks; what it lacked was statistical realism. We added three capabilities that, together, turn it from an animation tool into an evaluation instrument.
1. Real-data-driven NPC spawning. Previously, pedestrians and cyclists appeared via uniform random sampling — fine for visuals, misleading for evaluation. We now drive spawns from real 12-hour observations at Kagaku-keisatsu-ken West, mapped to 14 waypoint paths. Spawn intervals follow a Poisson process, preserving the clustering and lulls of real traffic.
2. Pedestrian/cyclist deadlock avoidance. Waypoint-based crowd simulation has a classic failure mode: two agents trying to pass through the same narrow gap at the same time, vibrating forever. We added a repulsion-based local avoidance layer and a frozen-body fallback for pathological cases.
3. Teleport with signal-cycle-synchronised repeat experiments. Restarting the whole simulator between trials is slow and loses the traffic-signal state. We implemented a physics-stable teleport that resets the bus to a calculated spawn position — back-solved so that each arrival at the intersection samples the 90-second signal cycle uniformly. Hundreds of trials in one run, with clean statistics.
Grounded in real Kashiwa-no-ha observations
To make sure the simulator’s conclusions transferred to reality, we spent three days observing actual VRU and vehicle counts around the target intersection.
Four scenarios, 1,133 simulation rounds
With realistic NPC traffic in place, we ran 1,133 simulation rounds across four VRU conditions — none · always present · Kashiwa normal · Kashiwa low-density — each with and without RSU cooperation. Then we added a fifth scenario at 2× vehicle traffic to stress-test the following-traffic effect.
A visual intuition: same moment, two buses
The clearest demonstration isn’t a number, it’s a frame. Two simulations, identical seed, identical traffic — one with RSU cooperation, one without. By the time the uncooperative bus is still halfway through the crosswalk at 3 km/h, the cooperative one has already cleared the intersection and is back up to 29 km/h.
Side-by-side comparison at the same timestamp. Left: infra-less bus, forced to 3 km/h while a VRU is detected. Right: cooperative bus, already past the intersection.
The danger-zone logic, in one picture
The danger-zone polygons (SW1, SW2, SW3, CW1, CW2) that the v2xHandler node evaluates against incoming RSU object streams. A non-empty SW zone during approach flips the speed target from 12 km/h down to 3 km/h.
The quantitative verdict
Across all four VRU conditions, without cooperation the intersection passage time collapses to a flat ~26 seconds — the 3 km/h is the bottleneck, regardless of whether anyone is actually crossing. With cooperation, passage time falls to:
- 12 seconds in the empty case (no VRUs present)
- 18 seconds in Kashiwa low-density conditions
- 21.5 seconds in normal Kashiwa conditions
- ~26 seconds only when VRUs permanently occupy the danger zone (the worst case — and an honest one)
Bar chart comparing intersection passage time (navy) and travel time (light blue) across all four scenarios, infrastructure off vs on.
Travel time results across the four scenarios, infrastructure off vs on.
Video — Results of cooperative right-turn at Kagaku-keisatsu-ken West intersection.
Time-space diagrams: the honest microscope
Averages tell one story; individual rounds tell another. The time-space diagram plots the bus and each following vehicle against time and distance through the intersection. Green lines are following vehicles that made it through the same green-light cycle as the bus. Red lines are vehicles that didn’t — trapped behind the slow bus, waiting for the next cycle.
40 rounds of bus right-turns shown as time-space diagrams, split across four panels. Blue = bus, green = following vehicles that passed, red = blocked.
Simulator view of the following traffic. Top: infra off — the bus crawls at ~4 km/h, the first following car makes it through, the second does not. Bottom: infra on — 12 km/h passage lets 3–4 following cars complete the turn in the same signal phase.
The headline numbers on following traffic
Infrastructure cooperation reduced the number of following vehicles blocked behind the bus by:
- 85% in the ideal (no VRUs) case
- 51% in Kashiwa low-density conditions
- 38% in normal Kashiwa conditions
- 23% in the high-traffic (3.88 vehicles/minute) scenario — with, notably, the largest absolute reduction
Cooperation earns its keep exactly as much as the danger zone is actually clear. That is both the strength of the approach and its honest limit: if pedestrians are genuinely always present, no amount of V2X will let the bus move faster. The value of the infrastructure scales directly with how often it can tell the bus the road is safe.
Open-source releases: leaving the work behind
A research project that ends in closed binaries is a research project that ends. We released both of our platforms as open source this year, on the theory that the most useful thing we can contribute to whoever is building the next cooperative-driving system somewhere else is to hand them our tools.
AVVV — Autonomous Vehicle V2X Visualiser
- ETSI CPM-compliant V2X communication analyser, reporter, and visualiser
- Measures latency, packet loss, jitter, and RSSI between RSUs and vehicle OBUs
- Ships with docs, tutorials, API spec, and a sample dataset from Kashiwa-no-ha
- Documentation: https://tlab-wide.github.io/avvv_etsi/
- GitHub: https://github.com/tlab-wide/avvv_etsi
V2X E2E Simulator (V2XSim) — Cooperative driving simulation environment
- Unity + ROS 2 cooperative-driving simulator with the Kashiwa-no-ha scene bundled in
- Autoware/AWSIM compatible; pseudo-sensors, cyclist and pedestrian models
- Real-data-driven NPC spawning and repeat-experiment infrastructure
- Documentation: https://tlab-wide.github.io/V2X_E2E_Simulator/
- GitHub: https://github.com/tlab-wide/V2X_E2E_Simulator
Closing
Five years ago we asked whether infrastructure could help a bus turn right. Today a bus turns right, and we have the tools to tell you exactly how much help it got.
Thank you to everyone who rode, built, and reviewed.
References and links
- Project page: Theme 4 — RoAD to the L4
- Team: Tsukada Lab, The University of Tokyo — Prof. Manabu Tsukada, Prof. Ehsan Javanmardi
- Consortium: The University of Tokyo, Tokai National Higher Education and Research System (Nagoya University), AIST, Mitsubishi Research Institute, Japan Automobile Research Institute, Advanced Mobility Co., Ltd.
- Funding: METI & MLIT
- Published specifications:
