Tuning SLAM against a flapping period

At TiHAN — IIT Hyderabad, India's autonomous navigation hub, I worked on bio-inspired flight: autonomous ornithopters. Flapping-wing UAVs oscillate along every axis by design. The airframe is not a disturbance you filter out. It is the propulsion.

Visual-inertial SLAM on a quadrotor assumes the body is relatively well-behaved between frames. On an ornithopter the camera itself is on a periodic shake. ORB-SLAM3 with a RealSense D435i still sees features. It just sees them moving for a reason the filter did not budget for.

GPS-denied indoor flight removes the usual fallback. If the map drifts, you hit a wall. Outdoor flight is not automatically easier: the same flapping period is still in the IMU.

We used UWB ranging for absolute position — a second opinion the vision stack could not talk itself out of. ROS held the control loop. The work was less 'run SLAM' than tune against the airframe's own flapping period: what you can trust in the residual, what you have to treat as the wingbeat, and when to believe the UWB over the map.

That is a systems problem wearing a research badge. Sensors are poor. The platform is unhelpful. The control has to survive both. It is still the problem I find hardest to put down, which is why it sits on the About page.

The stack, in the order it actually mattered: the airframe, the period, UWB, ORB-SLAM3, ROS, then Python for the glue and the logs from flight tests. Papers reverse that order. Flight does not.

The result is chapter 20 in Artificial Intelligence Applications in Aeronautical and Aerospace Engineering (Wiley, 2025): 'Navigation of Unconventional Drones — Autonomous Ornithopter', with S. Syam Narayanan, P. Rajalakshmi, Y. Gangurde, S. Movidi, and me.

A chapter is a clean story. The weeks were not. Indoor tests fail for reasons that look like software until you watch the wing. Outdoor tests fail for reasons that look like wind until you look at the residual at the flapping frequency. The write-up is the part where we admitted which of those we had actually understood.

If you are coming from product software, the temptation is to treat SLAM as a library. On this vehicle it is a contract with a periodic plant. Break the contract and the map is fiction.

I later spent a year as an associate AI engineer at OSCOWL, then started shipping production platforms at Klinn AI. The ornithopter is the other end of that line: autonomy under constraint, not a demo in a gym.

The master's at OVGU is me going down a layer on purpose. Navigation software sits on devices. Devices sit on physics. I wrote a companion piece on what a software engineer misinterprets about device physics because that gap is the reason I left Hyderabad for Magdeburg.

The paper is the artefact. The lesson is smaller: if the platform oscillates, your estimator has to know the period. Otherwise you are localising a bird as if it were a brick.