Overview
How much does a higher-order integration rule help when acceleration is noisy? This study compares Euler, trapezoidal, and Simpson integration using a C quadrotor simulator and a separate Python Monte Carlo analysis.
Problem definition
Double integration turns accelerometer noise and bias into growing position error. Improving discretization order does not necessarily address that sensor-driven error.
Research motivation
The aim is to distinguish mathematical truncation error from practical sensor-noise limits before spending MCU computation on a higher-order integrator.
System architecture
The C simulation separates RK4 vehicle dynamics, cascaded PID control, IMU measurement generation, three integration methods, and CSV logging. Python scripts visualize flight and sweep sampling intervals.
imu_sim.c includes white noise scaled by inverse square-root sample interval, Gauss–Markov bias, vibration, quantization, and cross-axis coupling. These are modeled sensor effects, not recordings from an actual MPU6050 flight.
Methodology
integrator.c implements left-sample Euler, trapezoidal averaging, and alternating Simpson updates with a trapezoidal intermediate step. The analysis separately examines noise-free convergence and noisy double integration.
The Python study sweeps time steps from 1 to 100 ms across 80 Monte Carlo trials. The full drone mission and the analytic-input time-step sweep use different trajectories and durations; their RMSE values are separate evaluations.
Experimental setup
Report Table 5 describes a 35 s simulated mission at a 5 ms time step. Its noise model is based on MPU6050-inspired parameters. Table 6 reports the separate time-step sweep.
Results
In the report’s 35 s mission, RMSE is 3.283 m for Euler, 3.283 m for trapezoidal, and 3.199 m for Simpson. In the separate noisy time-step sweep at 5 ms, the values are 0.1080, 0.1078, and 0.1082 m respectively.
The study’s main observation is that sensor noise can dominate the gain from integration order. The smaller sweep errors must not be described as the full mission’s localization accuracy.
| Method | Mean error (m) | Final error (m) | RMSE (m) |
|---|---|---|---|
| Euler | 2.258 | 8.140 | 3.283 |
| Trapezoidal | 2.258 | 8.141 | 3.283 |
| Simpson | 2.189 | 7.942 | 3.199 |
| Δt (s) | Euler RMSE (m) | Trapezoidal RMSE (m) | Simpson RMSE (m) |
|---|---|---|---|
| 0.001 | 0.0827 | 0.0826 | 0.0838 |
| 0.002 | 0.1108 | 0.1110 | 0.1107 |
| 0.005 | 0.1080 | 0.1078 | 0.1082 |
| 0.010 | 0.1030 | 0.1033 | 0.1049 |
| 0.020 | 0.1056 | 0.1022 | 0.1032 |
| 0.050 | 0.1079 | 0.0961 | 0.0984 |
| 0.100 | 0.1449 | 0.1126 | 0.1132 |
Discussion
The white-noise analysis predicts position variance proportional to noise-density squared times duration cubed, without a leading dependence on sampling interval at fixed noise density. This explains why merely reducing the integration step can encounter a noise floor.
The report favors trapezoidal integration as a computational compromise. That recommendation concerns this model and task, rather than every inertial-navigation system.
Limitations
The model does not establish real-drone navigation performance, and inertial drift still requires appropriate estimation or external observations. Nominal mathematical convergence orders apply to the noise-free setting.
The repository README and report describe different mission durations and headline error magnitudes. The values here are explicitly attributed to the report’s tables; they are not presented as a fresh rerun of the current code.
References and resources
Sources: IMU-Simulator README, src/imu_sim.c, src/integrator.c, scripts/analysis.py, and docs/Report_EN.pdf, especially Tables 5–6. The exact reviewed revision is linked below.
Project resources
Implementation & data
Source files at the reviewed repository revision.
IMU noise modelIntegration methodsMonte Carlo analysisContent checked against the original report and linked implementation where available. Reported simulation or dataset results are distinct from physical validation.