The role

You stand at the boundary between airframe and software. When a pilot says the position fix was bad, you are the person who can say whether it was sky obstruction, multipath, or our code. From November there are no black-box failures on your watch.

Key responsibilities

- Own the telemetry lab — bench, replay, visualisation and ground-truth data, live and reproducible
- Own protocol work with the first drone manufacturer and the evaluation of second and third-source adapters
- Run recent-technology spikes: correction services, edge inference, alternative power
- Deliver field diagnostics into the war room a week before stations go live — a diagnostic first used under pressure is one that does not work
- From November, give every flight anomaly data and a written hypothesis within four hours
- Pin the decoder to a declared protocol version and fail loudly on an unknown message rather than dropping it silently

Eligibility




- Three to five years at the hardware–software boundary: serial protocols, radio links or flight controllers
- Comfortable with a standard telemetry protocol
- You understand what a flight controller is doing — inertial measurement, barometer, compass, how they fuse and how they fail
- Three or more solo proofs of concept taken from nothing to a written finding
- Lab discipline: documented, reproducible setups and honest negative results
- Willing to travel to Erode for field validation in October and November

What you get
- A real lab, and spikes with a defined question and a stopping rule
- Findings written up honestly, including the ones that did not work

How the process runs
- Fill in the short form on this page.
- We read it ourselves. Every application is read.
- If we want to meet you, we call you.

📌 R&D Engineer — Drone Systems (Chennai)
🏢 https://drone-port.in/
📍 Chennai