Estimation, control and GPS-denied navigation
Your robot works in the lab. Why not in the real world?
I fix estimation and control that pass in simulation and fail on real hardware. Position estimates that drift once GPS drops out, sensor fusion that falls apart on the vehicle, controllers that go unstable outside the regime they were tuned in.
/The problem
Some robots stall because the problem is genuinely hard. Others stall because the scope grew until nothing ran.
The genuinely hard version usually looks like this: estimation that has to work without GPS, control that has to hold on real hardware. From the outside, a hard problem and an over-scoped one are indistinguishable, and both eat the deadline.
I have spent my career in that gap. The first thing I tell you is which one you have.
/Who this is for
Your robot works until the conditions change.
You have a deadline, your team has been on this for weeks, and the behaviour on the bench does not match the behaviour on the vehicle. Every fix moves the problem somewhere else.
- EKF rejecting GPS, or the estimate diverging after a GPS or VIO dropout
- Heading or altitude jumps nobody can reproduce on the bench
- Vibration aliasing quietly corrupting an IMU-based estimate
- A controller that is fine in simulation and unstable on the airframe
- Estimation that degrades in exactly the regime you cannot afford to lose
- Drone and UAV companies
- AMR and mobile robot builders
- Robotics startups shipping a first deployment
- Medical and surgical robotics
- Research institutes
- Defense teams
- Integrators with a project to deliver
/What I do
Three things I get called in for.
GPS-denied and GNSS-degraded navigation, EKF and complementary filter design and tuning, IMU, GPS and vision fusion, drift and divergence diagnosis. My PhD was optimization-based estimation for autonomous robots, including flight with intermittent measurements.
Trajectory tracking, optimization-based and predictive control, stability margins that survive vibration and delay, controllers that hold outside the regime they were tuned in.
A system that works in the lab and not in the field, with a deadline. I find what is actually broken, get a version running, and hand it back.
/How I work
I find what's broken, get it working, and build from there.
Quick and dirty first if that's what it takes. A version that runs beats a clean one that doesn't.
A rough version that runs is worth more than a beautiful one that doesn't. Get it working, then make it good.
Most stalls are over-scoping, not hard problems. I strip it back to what actually has to work.
No slide decks, no list of recommendations to hand off. I get into the hardware and the code and fix it.
I get it moving, hand it back to your team, and go. No permanent overhead, no empire building.
Who I am
Alex Andriën
Robotics control and deployment specialist. Real-time control, estimation, sensor fusion, and the messy work of making robots actually run outside the lab.
// estimation · control · sensor fusion · sim-to-real · deployment
/The work
When a controller only works in the demo
Control and estimation for a robotics research institute, client confidential. A UAV that could only loiter over a stationary target, turned into a controller that tracks a moving target and changes altitude on demand.
A UAV that could loiter, but only in the easy case: a stationary target, fixed conditions, the flight path hardcoded with sines and cosines. Convincing in a demo and impossible to build on. The moment the target moved or the aircraft needed a different altitude, the approach had nowhere to go.
I replaced the hardcoded path with a Lyapunov-based tracking controller, grounded in published control theory rather than a scripted curve, and built the trajectory generation for altitude. That single change turned a one-off into a general capability: track a target moving in any direction, and move between heights on demand.
A controller that tracks a moving target in arbitrary directions and transitions between altitudes reliably. Not a demo that works once under perfect conditions, but a result the team could rely on and extend.
/How it works
Three steps. Start small.
Start with a call, keep the scope tight, and go bigger only if it's a fit.
A short call about your robot, what's blocking it, and your deadline. No pitch. We work out whether I'm the right guy for it.
I spend a day with your team and your robot. By the end you get a straight answer on what's actually wrong, and a plan to fix it with timeline and cost. That's it. No strings.
If it's a fit, we scope it: clear end date, weekly progress you can see. I get it shipped and hand it back.
Call → Diagnosis → Shipped
/What I need from you
To work fast I need a clear mandate: direct access to your engineers and the authority to make the technical calls. Whoever you are, we agree on that up front, in writing if that's how you work.
In return you get someone who tells you straight what's going on, even when it's not what you want to hear, and gets the thing finished.