AVAILABLE FOR PROJECTS — WE REPLY WITHIN ONE WORKING DAY

WE BUILD COMPLEX THINGS.

SOFTWARE · AI · ROBOTICS · SYSTEMS

Software for machines that have to work outside the lab.

See the work Bring us a problem

Dashboards, ground stations and mobile apps, written by the same people who write the real-time code underneath.

SOFTWARE React · React Native · TypeScript · FastAPI · SQLite · WebSocket · Vite

Three things you can check.

The estimated trajectory drawing itself against OXTS ground truth on KITTI raw 2011_09_30_drive_0027_sync, and snapping shut when the loop closes. 1,106 stereo frames, 348 keyframes, 21 loop closures, ATE RMSE 3.33 m to 1.29 m. Rendered from the run’s own pose output.

Stereo visual SLAM, written from scratch

ROBOTICS · ESTIMATION — KITTI 2011_09_30/0027, 1,106 frames, 694.7 m — 1.256% TRANS · 0.01092 DEG/M · ATE 1.276 M · 21/21 LOOPS

VIEW CASE

YOLOv8n detections on real COCO val2017 photographs, decoded and drawn by the benchmark. The boxes are the ones the 36.63 mAP figure is computed over.

A COCO metric that matches the reference exactly

AI · PERCEPTION — COCO val2017, 4,872 images, 367,010 detections — mAP 36.63 · 0.0e+00 vs PYCOCOTOOLS · INT8 −0.93 FOR 2.36×

READ THE CODE

The sphere2500 pose graph converging, rendered from the solver’s own per-iteration state: 2,500 poses and 4,949 constraints, absolute trajectory error 27.93 m to 0.180 m in ten iterations.

A pose-graph back end on NumPy

ROBOTICS · OPTIMISATION — 12 g2o DATASETS, sphere2500 2,500 POSES / 4,949 EDGES — ATE 27.93 M → 0.180 M IN 10 ITERATIONS, 2.8 S

READ THE CODE

A robot with a camera and no externalpositioning has to work out its own motionfrom what it sees. Errors compound, andwrong data is silent.

01 — THE PROBLEM

02 — THE IDEA

Seven stages, and one of them lies.

KITTI stereo pair
feature detect + bucket
stereo match, epipolar + LR check
RANSAC PnP
Gauss-Newton SE(3)
windowed bundle adjustment40 px reprojection error → keyframes moved 2–4 m
BoW loop closure

03 — BUILD

13.3 % → 2.0 % → 1.26 %, AND WHY THE MIDDLE STEP WAS NOT A TUNING PROBLEM

CAPTURED — benchmarks/run.py

$ python3 benchmarks/run.py --sequence data/kitti/2011_09_30/2011_09_30_drive_0027_sync
sequence      : data/kitti/2011_09_30/2011_09_30_drive_0027_sync
frames        : 0..1106 of 1106
baseline      : 0.5372 m
focal length  : 707.09 px
machine       : 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz, 8 logical cores
vocabulary    : training on 60 held-out frames (200..800 step 10)
                trained in 73.8 s
running pipeline ...
  frame   400  keyframes  129  landmarks  10168  tracked  195
  frame   800  keyframes  251  landmarks  15666  tracked   49
====================================================================
frames processed        : 1106
keyframes               : 348
landmarks               : 21393
mean tracked features   : 163.6
loop closures accepted  : 21
loop gate counters      : {'queries': 347, 'appearance_candidates': 1555, 'rejected_consistency': 1062, 'rejected_few_matches': 467, 'rejected_geometry': 5, 'accepted': 21}
translation error       : 1.256 %
rotation error          : 0.01092 deg/m
ATE RMSE                : 1.276 m
ground-truth path       : 694.7 m
estimated path          : 696.6 m

FULL LOG

Tracked features and flow vectors on the real rectified KITTI frames of drive 2011_09_30_drive_0027_sync, inliers and rejections distinguished. Mean 163.6 tracked features per frame.

RULED OUT

The odometry itself. Raw frame-to-frame steps matched ground truth to a few centimetres the whole time, which is why the error was invisible in every per-frame diagnostic.
Feature quality. A ratio test plus a mutual-best cross-check was already in place; the matcher was not the problem, trusting it was.
A tuning problem in bundle adjustment. Instrumenting the windows showed them starting at 34–72 px reprojection RMSE and finishing at 32–60. The optimiser was not failing to converge, it was converging on a contradiction.
The motion plausibility gate, which was added second and masked part of the symptom. With the association bug fixed it fires zero times on this drive, and the ablation table in the repository says so rather than quietly keeping the credit.

04 — THE MOMENT

Ground truth in grey, the estimate in amber. KITTI raw 2011_09_30_drive_0027_sync, 1,106 poses decimated to 180 on identical indices, projected to the XZ plane. Read from benchmarks/output/trajectory.txt and ground_truth.txt.

ATE RMSE: 3.331 m1.276 m
TRANSLATION: 2.020 %1.256 %

The same run, animated from its own pose output: the estimate drawing itself against OXTS ground truth and snapping shut when the loop closes. 348 keyframes, 21 loop closures.

05 — RESULT

1.256 %: KITTI 09_30/0027translation error over 694.7 m
21 / 21: accepted loop closures correct1,555 candidates, 1,534 rejected
0.0e+00: largest abs. difference vs pycocotoolsacross all twelve COCO metrics

REPRODUCE: git clone https://github.com/Pratyush150/stereo-visual-slam && python3 benchmarks/run.py --sequence data/kitti/2011_09_30/2011_09_30_drive_0027_sync

Numbers you can run yourself.

Every number on this page was produced by code in a public repository, on a public dataset, and the command that produces it is printed beside it.

REPRODUCE

git clone https://github.com/Pratyush150/stereo-visual-slam && cd stereo-visual-slam
python3 tools/fetch_kitti.py --output data/kitti
python3 benchmarks/run.py --sequence data/kitti/2011_09_30/2011_09_30_drive_0027_sync

Before and after loop closure, same run, same sequence.
	translation (%)	rotation (deg/m)	ATE RMSE (m)
before loop closure	2.020	0.01125	3.331
after loop closure	1.256	0.01092	1.276

The first full-sequence run scored 13.3%. Every descriptor match between consecutive keyframes was being turned into a landmark observation and roughly half of them were wrong; the per-frame poses were fine throughout. Gating the association on a reprojection check took odometry from 13.3% to 2.0%. That is in the repository, with the instrumented bundle-adjustment residuals that found it.

READ THE REPOSITORY

REPRODUCE

git clone https://github.com/Pratyush150/object-detection-benchmark && cd object-detection-benchmark
python3 tools/fetch_assets.py --dest assets
python3 benchmarks/verify_metric.py --annotations assets/annotations/instances_val2017.json --detections assets/cache/fp32_<hash>.json

All twelve COCO metrics, both implementations, same 367,010 detections over the same 4,872 images.
metric	detbench	pycocotools	abs diff
AP @ 0.50:0.95, all	0.366292468048	0.366292468048	0.0e+00
AP @ 0.50, all	0.514783906518	0.514783906518	0.0e+00
AP @ 0.75, all	0.398023047115	0.398023047115	0.0e+00
AP @ 0.50:0.95, small	0.173954129172	0.173954129172	0.0e+00
AP @ 0.50:0.95, medium	0.404532620277	0.404532620277	0.0e+00
AP @ 0.50:0.95, large	0.520095107021	0.520095107021	0.0e+00
AR @ 0.50:0.95, maxDets=1	0.303619498914	0.303619498914	0.0e+00
AR @ 0.50:0.95, maxDets=10	0.493089837060	0.493089837060	0.0e+00
AR @ 0.50:0.95, maxDets=100	0.531297782877	0.531297782877	0.0e+00
AR @ 0.50:0.95, small	0.289230886977	0.289230886977	0.0e+00
AR @ 0.50:0.95, medium	0.592759654029	0.592759654029	0.0e+00
AR @ 0.50:0.95, large	0.706709325495	0.706709325495	0.0e+00

pycocotools is not a dependency of the package. It appears only in the test suite and in benchmarks/verify_metric.py, to hold the from-scratch implementation honest.

READ THE REPOSITORY

REPRODUCE

python3 benchmarks/run_sweep.py --assets assets --annotations assets/annotations/instances_val2017.json --images assets/val2017
python3 benchmarks/run_latency.py --assets assets --sweep benchmarks/results/sweep.json

YOLOv8n, ONNX Runtime on CPU, 4,872 val2017 images. The last row is the failure this benchmark exists to catch.
variant	size	mAP	Δ mAP	inference p50	speed-up
fp32	12.82 MB	36.63	—	82.4 ms	1.00×
int8-static-c16	3.66 MB	35.70	−0.93	34.9 ms	2.36×
int8-static	3.66 MB	35.22	−1.41	35.8 ms	2.30×
int8-static-pertensor	3.58 MB	34.24	−2.39	34.2 ms	2.41×
int8-static-notail	3.60 MB	0.00	−36.63	28.3 ms	2.91×

The unflattering number: Ultralytics publishes 37.3 mAP for YOLOv8n on val2017. This measures 36.63 on 4,872 images and 36.57 on all 5,000 with the same settings — about 0.7 points short. It is not a disagreement about the metric, which is verified above to twelve decimal places on these exact detections. The five causes are (1) single-label decode rather than multi-label NMS, (2) NMS at IoU 0.7 with 300 boxes, tuned per release upstream, (3) letterbox padding colour, upscaling and offset rounding, which move boxes by about a pixel where AP75 lives, (4) export settings — opset 13, static 640×640, no graph simplification, NMS outside the graph, and (5) 4,872 images rather than 5,000, because 128 are reserved for quantisation calibration; that split is worth 0.06 points. Every one of them is a command-line flag in the repository.

READ THE REPOSITORY

REPRODUCE

git clone https://github.com/Pratyush150/pose-graph-slam && cd pose-graph-slam
python3 tools/fetch_datasets.py intel manhattan manhattan_gt sphere2500 sphere2500_gt
python3 benchmarks/run_benchmarks.py
python3 tools/gtsam_crosscheck.py   # the outside column

Final chi-squared, ours against GTSAM 4.2 on the identical files. Both run untuned: default LevenbergMarquardtParams, a tight prior on the first pose.
dataset	our final chi2	GTSAM final chi2	agreement
CSAIL	40.55	40.56	same to 3+ figures
intel	45	45.01	same to 3+ figures
parking-garage	1.268	1.268	same to 3+ figures
manhattan	3549	3549	same to 3+ figures
sphere2500	1351	1351	same to 3+ figures
cubicle	2746	2749	within 0.1%
torus3D	5.99e+04	5.996e+04	within 0.1%
tinyGrid3D	18.63	18.66	within 0.2%
smallGrid3D	1036	1039	within 0.3%
sphere_bignoise	7.370e+06	7.814e+06	ours lower by 6%
city10000	512	1.836e+07	ours lower by 4 orders
MIT	770.2	4.414e+09	GTSAM took no step

Reading the last three rows honestly: on sphere_bignoise, city10000 and MIT the two solvers did not land in the same place, and ours landed lower. That is not a claim to have beaten GTSAM — it is an untuned comparison in both directions, and torus3D and sphere_bignoise are local minima on our side too. The repository says so in the same table.

READ THE REPOSITORY

3,449 TESTS COLLECTED · 16 REPOSITORIES · A CI WORKFLOW ON EVERY ONE READ ANY OF IT

Collected with pytest on the fourteen Python repositories and counted as it()/test() blocks in the two TypeScript ones. Sixteen repositories, sixteen workflow files.

Five layers, and the way each one fails.

BOARD BOUNDARY

Someone else's board, and what our code has to survive on it

Pixhawk-class autopilots, Jetson and Raspberry Pi companions, serial and USB links, encoders, Modbus devices — your hardware, not ours. We write the firmware and the drivers that run on it and the software that talks to it. Everything below this line has a physical failure mode that has to be handled in code.

Pixhawk · Jetson Orin/Nano · Raspberry Pi · RS-485 · USB CDC-ACM · quadrature encoders

BOARD BOUNDARY — the USB port renumbers between boots, so /dev/ttyACM0 is a different device than it was yesterday and the bringup script is confidently wrong.

FIRMWARE & TRANSPORT

The link, and everything that lies about it

MAVLink over serial, UDP and TCP; rate control, offboard setpoints and link diagnostics. A heartbeat tells you the link is up. It does not tell you the stream is alive.

MAVLink 2 · pymavlink · MAVROS · PX4 · ArduPilot · pyserial · 8N1 bandwidth modelling

TRANSPORT — ATTITUDE keeps arriving at a perfect 10 Hz with a timestamp that stopped advancing when the autopilot browned out, and every downstream node keeps publishing the last good value.

MIDDLEWARE

ROS 2, and the acquisition layer for machines that are not robots

Bringup, lifecycle, geodesy, missions, geofence and state machines on the robot side; Modbus and OPC-UA acquisition with alarms and a historian on the plant side.

ROS 2 Humble · rclpy · DDS · rosbag2 · Modbus TCP/RTU · OPC-UA · MQTT Sparkplug B

MIDDLEWARE — a Modbus device reverses its word order on a firmware update and the historian records a plausible number that is off by a factor of 65,536.

PERCEPTION & ESTIMATION

Where wrong data is silent

Stereo and LiDAR SLAM, pose-graph back ends, PnP and Gauss-Newton on SE(3), Kalman and extended Kalman filters, detection and tracking on the edge.

OpenCV · NumPy · SciPy sparse · ONNX Runtime · g2o file format · KITTI · COCO

ESTIMATION — nothing throws. The bundle adjustment starts from a 40-pixel reprojection error, arbitrates between contradictory observations, and resolves it by moving keyframes two to four metres.

INTERFACE

The part the operator actually touches

Fleet dashboards, ground stations, mobile telemetry apps. Built against the same message definitions as the robot, so a schema change breaks the build rather than the shift.

React · React Native · TypeScript · WebSocket · Vite · Vitest

INTERFACE — the dashboard renders a stale value indistinguishably from a fresh one, and the operator trusts it for four hours.

LIMITS

What runs offline: every benchmark and every test on this page. Heavy dependencies are guarded, so the suites pass with pymavlink, ONNX Runtime and the datasets absent.
What needs a network: dataset fetches, the LLM-backed assistants, and the ONNX export step. Nothing else.
The SLAM and detection work is evaluated on public benchmarks — KITTI and COCO — not on your sensor rig. Numbers on your data will differ, and the first thing we would do is measure them.
Several repositories are reference implementations rather than production systems: they exist to be read and to be correct, not to be deployed unmodified.
We write software, not hardware. Firmware, drivers, embedded C++ and board bring-up in software terms for boards you already have: yes. Building, wiring, assembling or repairing a machine, PCB and mechanical design, or anything that would have to be shipped to us: no.
We decline work we would do badly. That currently includes web3, ad tech, growth automation, and anything where the brief is a design comp and a deadline.

Things we wanted to know.

Can a robot work out where it is from two cameras and nothing else?

Stereo visual SLAM from scratch. 1.256% translation error over 694.7 m of KITTI, 21 of 21 loop closures correct.

STATUS: SHIPPED

Can a pose graph disagree with itself?

A back end on NumPy, cross-checked against GTSAM 4.2 on twelve g2o datasets. It agrees on nine and lands lower on three.

sphere2500 converging, drawn from the solver’s own per-iteration state: 2,500 poses, 4,949 constraints, ten iterations.

STATUS: SHIPPED

What does INT8 actually cost?

One point of mAP for 2.36× — and one recipe that is 2.91× faster and detects nothing at all.

STATUS: SHIPPED

Can a swarm avoid itself when one agent is late?

CBS, ECBS and prioritised planning over the standard MAPF benchmark maps, plus a dependency-graph execution layer. Across 1,119 measured runs, zero invalid plans. At 40 agents on random-32-32-20, plain CBS solves none and ECBS at w=1.1 solves all of them; a three-tick delay on one agent costs a fixed timetable its separation and the dependency graph none.

STATUS: SHIPPED

Can a bag-of-words vocabulary be small and still find a revisit?

Dropping the vocabulary from 1000 words to 400 collapsed top-3 loop recall from 0.71 to 0.35. Abandoned: the memory it saved was not worth the recall it cost, and the tuning note in the repository records the dead end rather than deleting it.

STATUS: ABANDONED

Can detections be scored without trusting the scorer?

The COCO protocol implemented twice — once here, once by pycocotools — and asserted equal on 367,010 detections.

YOLOv8n detections on real COCO val2017 photographs, including a genuine failure case.

STATUS: SHIPPED

How an engagement runs.

01IDEA
02DISCOVERYTell us what is going wrongDescribe the machine or the process, the versions, and send whatever evidence you have — a log, a bag file, a register map, a screenshot of the failure, a document corpus. We will tell you within a working day whether this is something we can fix and roughly what it takes.
03PROTOTYPEPaid diagnosis or scoping firstWe analyse the evidence and send a written report: what is actually failing, the reasoning behind that conclusion, what we ruled out, and the specific changes we would make. It is a fixed low price and it stands on its own. If you take the report and do the work in-house, that is a fine outcome.
04ENGINEERINGImplementation with visible progressIf you want it built, we scope it against the report and work in visible increments. You get running code, not a status update. Scope changes get flagged when we find them, not at delivery.
05TESTING
06DEPLOYMENT
07MAINTENANCEHandover you can maintainCode with comments and tests, a README that explains how to run it, and a recorded walkthrough of the architecture and the parameters worth touching. On Premium engagements we stay available while you run it on your own hardware or put it in front of real users.

One team. One conversation. End-to-end execution.

We say no to work we would do badly.

Pratyush Vatsa — PRATYUSH VATSAINDIA — WORKING WORLDWIDE

You will be talking to the person writing the code.

There is no account manager between you and the work. The person who reads your logs is the person who writes the fix, which is why the first thing you get back is a diagnosis rather than a quote.

The work runs across four layers — flight stacks and control, simulation and testing, industrial acquisition and AI, and the interfaces people actually operate. They are the same job at different altitudes, and the seams between them are where projects usually break.

A wrong yes costs you more than an honest no.

01 — DIAGNOSIS BEFORE IMPLEMENTATION: Every engagement opens with a written root-cause report. It stands on its own — you can act on it whether or not the implementation is bought here.
02 — EVERY NUMBER IS REPRODUCIBLE: Results on this page were produced by public code on public data, and the command that produces each one is printed beside it. Including the one that is worse than the published figure.
03 — SOFTWARE ONLY, FIRMWARE INCLUDED: We write the software, including the software that runs on your hardware — firmware for your flight controller, drivers, embedded C++, ROS 2 nodes, MAVLink integration, perception. We do not build, wire, assemble or repair the machine, and nothing has to be shipped to us: logs, parameter dumps and a photo of the setup are what we work from.
04 — SCOPE IS NAMED, NOT DISCOVERED: Remote robotics debugging has unbounded scope, so it is sold as diagnosis first and quoted afterwards. Work that would be done badly is declined rather than accepted.

Bring us a problem.

Describe the machine or the process, the versions, and send the evidence. We reply within one working day with an honest answer about whether we can help and what it would cost. If it is not something we can do well, we will say so.

Every engagement starts with a written root-cause report, at a fixed low price. You get an explanation you can act on even if you never hire us for the fix.

Best first message: what the system is, what it does wrong, when it started, and a link to a log, a bag file, a register map or a document sample. That gets you a useful answer instead of a scheduling email.

READ THE CODE BEFORE YOU TALK TO US

BASED IN INDIA · WORKING GLOBALLY · ISTGMTESTPST

WE BUILD COMPLEX THINGS.

What we work on

Three things you can check.

Stereo visual SLAM, written from scratch

A COCO metric that matches the reference exactly

A pose-graph back end on NumPy

Case study: stereo visual SLAM on KITTI

Seven stages, and one of them lies.

13.3 % → 2.0 % → 1.26 %, AND WHY THE MIDDLE STEP WAS NOT A TUNING PROBLEM

RULED OUT

Numbers you can run yourself.

REPRODUCE

REPRODUCE

REPRODUCE

REPRODUCE

Five layers, and the way each one fails.

Someone else's board, and what our code has to survive on it

The link, and everything that lies about it

ROS 2, and the acquisition layer for machines that are not robots

Where wrong data is silent

The part the operator actually touches

LIMITS

Things we wanted to know.

Can a robot work out where it is from two cameras and nothing else?

Can a pose graph disagree with itself?

What does INT8 actually cost?

Can a swarm avoid itself when one agent is late?

Can a bag-of-words vocabulary be small and still find a revisit?

Can detections be scored without trusting the scorer?

How an engagement runs.

You will be talking to the person writing the code.

Bring us a problem.