01 · SIH 2026 · SIH26037 · MathWorks · Robotics and Drones
SARATHI
サラティAdaptive path planning for unstructured Indian roads.
- Python
- NumPy
- SciPy
- WebSockets
- HTML5 Canvas
- pytest
- Playwright
- uv
- Mean route progress
- 43.3%
- Scenarios ahead
- 8 / 10
- Median p95 replan
- 46 ms
- Tests
- 155
against a lane-following baseline's 36.2%
same seeds, same sensor noise
inside the 50 ms that 20 Hz allows
including behavioural regressions
The idea
Every production autonomous-driving stack assumes a lane. Indian roads do not have lanes. They have a negotiated, continuously deforming free space shared by buses, auto-rickshaws, two-wheelers filtering through 60 cm gaps, pushcarts, pedestrians crossing wherever they like, and cattle.
So the two primitives that break down there were replaced rather than patched. Because it never needed lane markings in the first place, it degrades gracefully when they are faded, absent, or simply wrong — there is no branch anywhere in the code for “markings missing”.
The diagnosis
The planner would not pull away from a stopped obstruction. The reflex is to reach for the thresholds, and there are 31 of them to reach for.
Instead I counted what the lattice was throwing away. Of 131 candidate trajectories, 1 was usable. That is not a threshold problem — a threshold problem does not leave you with one survivor out of a hundred and thirty-one. It is a sampling problem: candidates were being generated outside the reachable set and then discarded, correctly, for being infeasible. The planner was doing the right thing with the wrong material.
Sampling inside the reachable set, and re-parameterising the lateral profile by distance travelled rather than by time, took the usable fan from 1 to somewhere between 35 and 50. No threshold moved.
The evidence
Every number here comes out of scripts/benchmark.py — ten scenarios, three
seeds, two controllers, identical seeds and identical sensor noise for both. The
baseline is a fair comparison rather than a straw man: it sees the same sensors
and the same noise, and it mostly fails by stopping rather than by crashing, which
is exactly why the contact counts are close while the progress numbers are not.
Both presentation decks read that same JSON and refuse to build without it, so a figure on a slide cannot drift away from what the code actually does.
Ours and Base are mean route progress, in percent. Clean counts how many of three runs finished without contact. p95 is the 95th-percentile replan latency in milliseconds; 50 ms is the budget 20 Hz allows.
What it does not do
- It is not yet safer than the baseline by raw contact count — 25 of 30 runs finish clean against the baseline's 27. Three of those five contacts happened with the vehicle stationary and another road user driving into it, which is a different failure from one we drove into, so every contact is recorded with our own speed and the bearing of the other body.
- The dense market peaks at 72 ms and is the one place the 50 ms replan budget is exceeded.
- The vehicle is over-cautious in dense traffic, and two scenarios account for four of the five contacts.
- Prediction priors are hand-built rather than fitted to data.
02 · The board
What I reach for
I came to this from physics, which is a useful place to start: you are trained to distrust a result you cannot reproduce, and to write down the conditions under which it was measured. Most of what follows is in service of that.
- Python
- TypeScript
- JavaScript
- SQL
- Node.js
- WebSockets
- REST API design
- PostgreSQL
- Supabase
- Next.js
- React
- HTML5 Canvas
- Claude API
- Groq · Llama 70B
- LLM application design
- AWS
- Docker
- Git
- uv
- pytest
- Playwright
03 · Writing
Not yet
There is a queue: how counting rejected candidates beats tuning thresholds, why a serverless runtime cannot host a 20 Hz simulation, and what a substring match costs when the string is a diagnosis. When the first one is written it appears here.