Signal Filtering
Filtering in Line Tracking
Filtering helps clean up noisy sensor signals, especially from optosensors that can flicker due to lighting, dirt, or contrast issues.
🔸 Low-pass Filter (LPF)
-
Use: Smooth out high-frequency noise from sensor readings.
-
Example (Simple IIR filter):
python
CopyEdit
filtered_value = alpha * new_reading + (1 - alpha) * previous_valuealpha~ 0.1 to 0.5 depending on how responsive you want it.
-
Effect: Makes your error signal smoother and avoids jittery corrections.
🔸 Median Filter
-
Use: Rejects spikes caused by momentary bad readings.
-
How it works: Keeps a short history of sensor values and outputs the median.
-
Good when: You get occasional garbage values from one sensor.
🧠 2. Adaptive Filtering
Adaptive filters adjust themselves based on signal conditions. They're useful when sensor noise or system behavior changes over time.
Example: LMS (Least Mean Squares) Adaptive Filter
-
Tries to predict the signal and reduce the error between the predicted and actual signal.
-
Use case: Tracking slowly drifting sensor baselines, e.g., optosensors that vary as lighting changes.
Realistic Use:
Most student-level line followers don’t need this, unless:
-
You have unpredictable lighting, or
-
You’re doing sensor fusion (e.g., line sensor + IMU),
-
You’re building a high-speed competition robot where precision matters.
🔁 3. What About Non-LTI Systems?
LTI = Linear Time-Invariant. Most classical control (like PID) assumes the system is LTI.
But your robot is not LTI:
-
Non-linear: Motor response isn’t linear. Friction, battery level, PWM ≠ speed linearly.
-
Time-varying: Battery voltage drops over time, sensors degrade, terrain changes.
Why it matters:
-
PID tuning might not work well everywhere.
-
You get instability if you don't account for these effects.
Solutions:
🔧 1. Gain Scheduling
- Switch PID parameters based on known modes (e.g., high speed vs low speed).
🧠 2. Adaptive Control
-
System learns or adapts parameters on the fly (e.g., adjusts Kp, Ki, Kd based on error trends).
-
Can use model-based approaches (like MIT rule, Lyapunov methods), or even machine learning in advanced cases.
💡 3. Non-linear Control
- Like sliding mode control or feedback linearization, but probably overkill unless you're building advanced robotics.
🎯 TL;DR for your use case
| Concept | When to Use | Benefit |
|---|---|---|
| Low-pass filter | Always | Smooths sensor noise |
| Median filter | Noisy signals | Removes spikes |
| Adaptive filter | Varying noise | Adjusts to changing conditions |
| Gain scheduling | Multi-mode robot | Optimized control |
| Adaptive control | Changing dynamics | Self-tuning |
| Non-linear control | High precision robots | Advanced compensation |
.
🧠 What Is a Kalman Filter (KF)?
A Kalman Filter is a recursive estimator — it fuses noisy sensor measurements with a model of the system to produce a best estimate of the system’s current state.
It assumes:
-
The system is linear (or extended to non-linear in EKF),
-
There’s process noise (your system model isn’t perfect),
-
And measurement noise (your sensors aren’t perfect).
🔍 When Should You Use a Kalman Filter?
| Use Case | Kalman Filter? | Why |
|---|---|---|
| Just smoothing a noisy line sensor | ❌ | Overkill — use low-pass or median filter. |
| Fusing multiple noisy sensors (e.g., IMU + encoders) | ✅ | KF shines at sensor fusion. |
| Estimating position, velocity, heading from multiple inputs | ✅ | Helps track state with higher confidence. |
| Your system is very dynamic or changes fast | ✅ | KF adapts to measurement vs model trust. |
| Only a single sensor with low noise | ❌ | Simpler filters (moving average, IIR) work fine. |
🦾 Line-Following Robot — Do You Need Kalman?
Probably not for basic line tracking, unless you're doing one of these:
✅ Use Kalman if:
-
You combine line sensors with IMU (for estimating heading/position),
-
You’re implementing dead reckoning (using wheel encoders to estimate position),
-
You have very noisy sensors and want smooth, predictive control,
-
You want to predict future line position at high speed (advanced!).
🔧 Example Use Case (Advanced Line-Follower):
You have:
-
4 optosensors for line position,
-
An IMU giving yaw rate,
-
Wheel encoders giving velocity.
You want to estimate:
-
Actual position on track (even if line is lost),
-
Heading angle drift (to correct motor speeds),
-
Predict future trajectory.
➡️ Kalman filter can fuse the sensor data to estimate the robot's true position even when sensors glitch or the line temporarily disappears.
✨ Extended Kalman Filter (EKF)
If your robot model is non-linear (e.g., turning on curves), use an EKF:
-
Linearizes the model at each step
-
More complex but widely used in mobile robotics and SLAM
🚦 TL;DR
Use a Kalman Filter when:
-
You're fusing multiple sensor sources,
-
You want to track hidden or noisy system states (like position, angle, velocity),
-
You're working in non-ideal, fast-changing environments,
-
You need prediction + correction in control (not just filtering).
Professional Context: Industrial & Automotive Signal Processing
Your simple low-pass filter works for smoothing sensor noise. Professional systems use sophisticated signal processing chains for reliability, safety, and performance. Here's how they compare:
Signal Processing Comparison
| Feature | Your Robot | Industrial | Automotive | Aerospace/Defense |
|---|---|---|---|---|
| Filtering | Software IIR | Hardware + software | Multi-stage, redundant | Certified algorithms |
| Sample rate | 50-100 Hz | 1-100 kHz | 1-10 kHz | 100+ Hz, deterministic |
| Anti-aliasing | None | Required by design | Mandatory | Proven, tested |
| Sensor fusion | Optional | Common | Essential (ADAS) | INS/GPS, multi-sensor |
| Redundancy | None | Optional | ASIL-dependent | Triple-redundant |
| Certification | None | Optional | ISO 26262 | DO-178C, MIL-STD |
Signal Conditioning Chain
Professional systems don't just filter in software—they condition signals at every stage:
Your robot:
Sensor ──► ADC ──► Software filter ──► Control
(raw) (maybe)
Industrial signal chain:
┌─────────────────────────────────────────────────────────────────┐
│ │
│ Sensor ──► Amplifier ──► Anti-alias ──► ADC ──► Digital ──► │
│ (signal filter (high filter Use │
│ conditioning) (hardware) res) (FIR/IIR) │
│ │
│ Each stage has a purpose: │
│ • Amplifier: Scale signal to ADC range, impedance matching │
│ • Anti-alias: REMOVE frequencies above Nyquist BEFORE ADC │
│ • High-res ADC: 16-24 bit, differential, low noise │
│ • Digital filter: Programmable, precise characteristics │
│ │
└─────────────────────────────────────────────────────────────────┘
Why anti-aliasing matters:
Your ADC samples at 100 Hz
Noise at 150 Hz exists in signal
Without anti-alias filter: 150 Hz appears as 50 Hz (aliased!)
→ You filter a "ghost" signal that isn't real
→ Control system responds to phantom noise
Kalman Filter Variants
Beyond basic Kalman, professionals use specialized variants:
┌─────────────────────────────────────────────────────────────────────┐
│ Kalman Filter Family │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Linear Kalman Filter (KF) │
│ ├── Your robot could use this │
│ ├── Assumes linear system: x[k+1] = A*x[k] + B*u[k] + w │
│ ├── Optimal for linear systems with Gaussian noise │
│ └── Computationally cheap │
│ │
│ Extended Kalman Filter (EKF) │
│ ├── Most common in practice │
│ ├── Linearizes nonlinear systems at each step │
│ ├── Used in: GPS receivers, robot localization, automotive │
│ └── Can diverge if system is highly nonlinear │
│ │
│ Unscented Kalman Filter (UKF) │
│ ├── Better for highly nonlinear systems │
│ ├── Uses "sigma points" instead of linearization │
│ ├── More accurate than EKF, slightly more expensive │
│ └── Used in: spacecraft attitude, advanced ADAS │
│ │
│ Particle Filter (Sequential Monte Carlo) │
│ ├── Non-parametric: doesn't assume Gaussian │
│ ├── Can handle multi-modal distributions │
│ ├── Computationally expensive (many particles needed) │
│ └── Used in: SLAM, tracking, computer vision │
│ │
│ Information Filter │
│ ├── Inverse of Kalman (works with precision, not covariance) │
│ ├── Better for multi-sensor fusion │
│ └── Used in: distributed sensor networks │
│ │
└─────────────────────────────────────────────────────────────────────┘
Automotive Sensor Fusion
Modern vehicles fuse many sensors for safety features:
┌─────────────────────────────────────────────────────────────────────┐
│ ADAS Sensor Fusion Architecture │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Raw Sensors: │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Camera │ │ Radar │ │ Lidar │ │ USS │ │ IMU │ │
│ │ (vision)│ │ (range) │ │ (3D) │ │(parking)│ │ (motion)│ │
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │ │ │
│ └───────────┴───────────┴───────────┴───────────┘ │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ Sensor Fusion │ │
│ │ (EKF / UKF) │ │
│ │ │ │
│ │ • Object tracking │ │
│ │ • Position/velocity│ │
│ │ • Classification │ │
│ └──────────┬──────────┘ │
│ │ │
│ ┌───────────────────┼───────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ AEB │ │ ACC │ │ LKA │ │
│ │(Braking) │ │ (Cruise) │ │(Lane Keep│ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ Why fuse? │
│ • Camera: Good classification, poor range │
│ • Radar: Good range/velocity, poor resolution │
│ • Lidar: Good 3D, expensive, weather-sensitive │
│ • Fusion: Combines strengths, covers weaknesses │
│ │
└─────────────────────────────────────────────────────────────────────┘
Aerospace INS/GPS Fusion
The gold standard for navigation uses tightly-coupled sensor fusion:
Your robot (dead reckoning):
Encoders → Integrate → Position estimate
Problem: Drift accumulates forever
INS/GPS Fusion (aircraft, missiles, spacecraft):
┌─────────────────────────────────────────────────────────────┐
│ │
│ IMU (Inertial Measurement Unit) │
│ ├── 3-axis accelerometer │
│ ├── 3-axis gyroscope │
│ ├── Very high rate (100-1000 Hz) │
│ ├── Short-term accurate │
│ └── Drifts over time (gyro bias, accelerometer bias) │
│ │
│ GPS (Global Positioning System) │
│ ├── Absolute position (no drift!) │
│ ├── Low rate (1-10 Hz) │
│ ├── Can be jammed, multipath errors │
│ └── No velocity/attitude directly │
│ │
│ Kalman Filter Fusion: │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ State: [position, velocity, attitude, IMU biases] │ │
│ │ │ │
│ │ Predict: Use IMU to propagate state (fast, drifts) │ │
│ │ Update: Use GPS to correct drift (slow, accurate) │ │
│ │ │ │
│ │ Result: Best of both worlds │ │
│ │ • High-rate, smooth position (from IMU) │ │
│ │ • Long-term accuracy (from GPS) │ │
│ │ • Continues working if GPS lost briefly │ │
│ │ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Tight coupling: GPS pseudoranges used directly in KF
Loose coupling: GPS position used to correct INS
ESC Sensor Fusion Example
Electronic Stability Control fuses multiple sensors in real-time:
Your line follower:
4 optocouplers → Calculate position → PID → Motors
(No fusion, just direct measurement)
ESC (Electronic Stability Control):
┌─────────────────────────────────────────────────────────────┐
│ │
│ Sensors (all sampled at 100+ Hz): │
│ ├── Yaw rate gyroscope (rotation) │
│ ├── Lateral acceleration (sideways G-force) │
│ ├── Steering wheel angle │
│ ├── Wheel speed × 4 (ABS sensors) │
│ └── Brake pressure │
│ │
│ State Estimation (Kalman Filter): │
│ ├── Vehicle yaw rate (how fast spinning) │
│ ├── Side-slip angle (are we sliding?) │
│ ├── Tire slip ratios × 4 │
│ └── Road friction estimate (!!) │
│ │
│ Control Decision: │
│ ├── Compare desired yaw (from steering) vs actual yaw │
│ ├── If difference too large → intervene │
│ └── Brake individual wheels to correct │
│ │
│ Note: Side-slip angle can't be measured directly! │
│ Must be ESTIMATED from other sensors via KF │
│ │
└─────────────────────────────────────────────────────────────┘
Digital Filter Design
Professional systems carefully design filters for specific requirements:
Your robot:
alpha = 0.2 # "seems to work"
filtered = alpha * new + (1-alpha) * old
Professional filter design:
Requirements:
├── Passband: 0-20 Hz (signal of interest)
├── Stopband: >50 Hz (noise to remove)
├── Ripple: <0.1 dB (flatness in passband)
├── Attenuation: >60 dB (noise rejection)
└── Phase: Linear (no distortion)
Design process:
1. Specify requirements mathematically
2. Choose filter type (Butterworth, Chebyshev, Elliptic, FIR)
3. Calculate coefficients (MATLAB, Python scipy)
4. Verify frequency response
5. Implement and test
Filter types:
┌─────────────────────────────────────────────────────────┐
│ FIR (Finite Impulse Response) │
│ ├── Always stable │
│ ├── Linear phase possible (no distortion) │
│ ├── More coefficients needed │
│ └── Used when phase matters (audio, communications) │
│ │
│ IIR (Infinite Impulse Response) │
│ ├── Can be unstable if poorly designed │
│ ├── Fewer coefficients for same performance │
│ ├── Nonlinear phase │
│ └── Used when efficiency matters (control systems) │
└─────────────────────────────────────────────────────────┘
# Professional filter design with scipy (free!)
from scipy import signal
import numpy as np
# Design a 4th-order Butterworth low-pass filter
# Cutoff: 20 Hz, Sample rate: 200 Hz
fs = 200 # Sample rate
fc = 20 # Cutoff frequency
order = 4
# Normalized cutoff (0 to 1, where 1 = Nyquist)
Wn = fc / (fs / 2)
# Design filter
b, a = signal.butter(order, Wn, btype='low')
# Check frequency response
w, h = signal.freqz(b, a, fs=fs)
# For embedded: convert to second-order sections (more stable)
sos = signal.butter(order, Wn, btype='low', output='sos')
# Apply filter to data
filtered_data = signal.sosfilt(sos, raw_data)
Redundancy and Voting
Safety-critical systems don't trust single sensors:
Your robot:
One sensor → One reading → Trust it
Flight control (triple redundancy):
┌─────────────────────────────────────────────────────────────┐
│ │
│ Sensor A ────┐ │
│ │ │
│ Sensor B ────┼───► Voting Logic ───► Use this value │
│ │ (median, or │
│ Sensor C ────┘ fault detection) │
│ │
│ Scenarios: │
│ A=100, B=100, C=100 → Output 100 (all agree) │
│ A=100, B=100, C=999 → Output 100 (C is faulty, ignore) │
│ A=100, B=200, C=150 → Output 150 (median) │
│ │
│ Plus: Each sensor has its own signal conditioning chain │
│ Different sensor types when possible (diverse) │
│ Continuous monitoring for sensor health │
│ │
└─────────────────────────────────────────────────────────────┘
What the Industry Uses
| Tool/Library | Use | Cost |
|---|---|---|
| MATLAB Signal Processing Toolbox | Filter design, analysis | $$$$ |
| scipy.signal | Filter design, analysis | Free |
| FilterPy | Kalman filters in Python | Free |
| Robot Operating System (ROS) | Sensor fusion packages | Free |
| dSPACE | HIL testing of filters | $$$$ |
| NI LabVIEW | Signal processing | $$$ |
| Analog Devices (hardware) | Signal conditioning ICs | $ per chip |
| Texas Instruments (hardware) | ADCs, signal chain | $ per chip |
Hardware Limits Principle
What Software Can and Cannot Fix
Software CAN improve: - Noise reduction → digital filtering - Sensor fusion → Kalman filter, complementary filter - Drift compensation → bias estimation - Outlier rejection → median filter, fault detection - Adaptability → adaptive filters, tunable parameters
Software CANNOT fix: - Aliasing → needs hardware anti-alias filter BEFORE ADC - ADC resolution → 10-bit noise can't become 16-bit clean - Sensor bandwidth → physical sensor can't respond faster - Quantization noise → inherent to digital conversion - Sensor physics → magnetometer near motor will always be noisy - Correlation → if two sensors see same noise source, fusion won't help
The lesson: A Kalman filter can optimally fuse noisy sensors, but it can't create information that isn't there. If your gyroscope drifts 1°/s and you have no absolute reference, Kalman can slow the drift but not eliminate it. Hardware choices (sensor quality, anti-aliasing, shielding) determine the floor; software determines how close you get to that floor.
Real Example: IMU Filtering
| Challenge | Your Robot | Professional Solution |
|---|---|---|
| Gyro drift | Ignore it | Fuse with magnetometer/GPS |
| Accelerometer noise | Low-pass filter | Kalman with motion model |
| Vibration from motors | Hope it averages | Hardware isolation + notch filter |
| Temperature effects | Ignore | Calibration tables + compensation |
| Magnetic interference | Ignore | Hard/soft iron calibration |
Your robot's IMU pipeline:
Professional IMU pipeline:
Raw IMU data
│
├── Hardware: Anti-alias filter on ADC inputs
│
├── Calibration: Apply factory + runtime calibration
│ ├── Gyro bias (measured at rest)
│ ├── Accelerometer offset and scale
│ └── Temperature compensation tables
│
├── Filtering: Remove vibration (notch at motor frequency)
│
├── Sensor Fusion (EKF/UKF):
│ ├── Predict: Use gyro to propagate attitude
│ ├── Update: Correct with accelerometer (gravity direction)
│ └── Update: Correct with magnetometer (heading)
│
└── Output: Calibrated, filtered, fused attitude estimate
Further Reading
- Kalman Filter Tutorial - Visual explanation
- FilterPy Documentation - Python Kalman filters
- Sensor Fusion on Mobile Devices - Google I/O talk
- Introduction to Random Signals and Applied Kalman Filtering - Brown & Hwang textbook