State estimation is the process of inferring the current internal state of a system, such as a robot’s position, orientation, velocity, joint angles or battery charge, from noisy and incomplete sensor measurements combined with a mathematical model of how the system moves. In robotics control systems, it supplies the feedback signal that controllers act on, because sensors rarely measure the full state directly and never measure it perfectly.
An estimator answers two questions at every time step: what is the most likely state, and how uncertain is that estimate. The uncertainty matters as much as the value, since controllers, planners and safety monitors need to know when an estimate can be trusted and when it has degraded.
How state estimation works
Most estimators follow a predict and update cycle. In the prediction step, a process model propagates the previous estimate forward using known inputs, such as motor commands or measured accelerations, and the uncertainty grows to reflect model errors. In the update step, a measurement model compares predicted sensor readings with actual readings and corrects the estimate, shrinking the uncertainty in proportion to how much the sensor can be trusted.
The balance between trusting the model and trusting the sensors is set by noise parameters: the process noise describes how imperfect the motion model is, and the measurement noise describes how noisy each sensor is. Tuning these values is one of the most important practical tasks, because wrong noise settings make an estimator either sluggish or jittery.
| Element | Role | Robotics example |
|---|---|---|
| State vector | Quantities being estimated | Position, velocity, heading |
| Process model | Predicts how the state evolves | Wheel kinematics or IMU integration |
| Measurement model | Relates state to sensor output | GNSS position, lidar ranges |
| Process noise | Uncertainty of the model | Wheel slip, unmodeled forces |
| Measurement noise | Uncertainty of sensors | GNSS error, encoder quantization |
| Covariance | Confidence in the estimate | Error ellipse around the pose |
Main state estimation algorithms
The choice of algorithm depends on how nonlinear the system is, whether the noise is approximately Gaussian and how much computation is available. The Kalman filter is optimal for linear systems with Gaussian noise; its extensions and alternatives handle the nonlinear reality of most robots.
| Algorithm | Assumptions | Strength | Typical use |
|---|---|---|---|
| Kalman filter | Linear model, Gaussian noise | Optimal and very fast | Simple tracking, sensor smoothing |
| Extended Kalman filter | Mild nonlinearity, linearized | Widely used, efficient | IMU and GNSS fusion |
| Unscented Kalman filter | Stronger nonlinearity | Better accuracy without Jacobians | Attitude estimation |
| Particle filter | Arbitrary distributions | Handles multiple hypotheses | Map-based localization |
| Complementary filter | Sensors with split frequency bands | Extremely light | Drone attitude on microcontrollers |
| Factor graph smoothing | Batch or sliding window | High accuracy, uses past data | Visual-inertial odometry, SLAM |
Filters estimate only the current state from past data, while smoothers optimize over a window of past states, which improves accuracy at the cost of computation and some latency. Modern mobile robots often run a fast filter for control and a slower smoother for mapping.
State estimation compared with neighboring control concepts
State estimation is distinct from control but tightly coupled to it. Feedback control, including PID, compares the estimated state with a setpoint and computes a correction. Model predictive control and LQR require a full state vector, so they depend directly on an estimator. In linear systems, the separation principle allows the estimator and controller to be designed independently; in nonlinear systems this holds only approximately.
| Concept | Question it answers | Dependency on estimation |
|---|---|---|
| Feedback control | What correction to apply | Uses the estimate as input |
| Open-loop control | What command to send | Uses no estimate |
| Localization | Where the robot is on a map | A specific estimation task |
| Sensor fusion | How to combine sensors | Usually implemented by an estimator |
| Observer | How to reconstruct hidden states | Control-theory term for an estimator |
Designing a state estimator in practice
Practical design starts with choosing which states to estimate and at what rate. Attitude estimators on drones typically run at hundreds of hertz to over a kilohertz, while pose estimators for ground robots often run at tens of hertz. Sensor timestamps must be accurate and synchronized, since a delay of a few milliseconds produces measurable errors at high speeds.
- Calibrate sensors for bias, scale and mounting position before tuning noise values.
- Check observability: some states, such as heading from a stationary IMU, cannot be estimated.
- Reject outliers with gating tests before measurements enter the update.
- Monitor innovation, the gap between predicted and actual readings, as a health signal.
- Use proven libraries, such as the ROS 2 robot localization tools, before writing custom filters.
Limitations and common failure modes
Estimators fail in recognizable ways. Divergence occurs when the estimate drifts away from reality while the reported uncertainty stays small, usually because process noise is set too low or a linearization is poor. Overconfidence after fusing correlated measurements as if they were independent leads controllers to trust a wrong state. Unmodeled effects, such as wheel slip or magnetic disturbances, appear as biased estimates that no amount of filtering removes.
Because a wrong state can drive a robot into collisions, safety-critical systems compare several independent estimates and fall back to a safe behavior when they disagree beyond a threshold.
In simple terms
A robot never knows exactly where it is or how fast it is moving. Its sensors are noisy and sometimes wrong. State estimation is the robot’s best educated guess about its own situation.
It works like walking through a dark room. You know roughly how many steps you took, and now and then you touch a wall to correct yourself. The robot combines its own motion with sensor clues in the same way. It also keeps track of how sure it is about its guess.
A practical example
A warehouse delivery robot uses wheel encoders, an IMU and a 2D lidar. Wheel odometry alone drifts by several centimeters per meter on polished floors, which is too much for docking at charging stations with a tolerance of about one centimeter.
The engineering team implemented an extended Kalman filter that predicts motion from the encoders and gyroscope and corrects it with lidar-based localization against the warehouse map. They tuned noise values from logged runs, added gating to reject lidar matches distorted by passing forklifts and monitored the innovation to detect slipping wheels. With the fused estimate, the robot docked reliably within the required tolerance, and the controller received smooth velocity estimates that removed visible jerks during turns.