Building a Force Plate: Software Problems
The hardware measures force. The software has to decide what the force means. That turned out to be the hard part: noise, body-mass estimation, drift, integration error, and false flight detection.
Architecture Shift
I originally tried to make the platform self-contained: one ESP32 measured data, another displayed results. Debugging, memory limits, missing charts, and no database made that approach feel wrong. The final architecture is simpler: the ESP32 streams raw data, while the Python desktop app owns the physics, state machine, and UI.
Problems and Fixes
| Problem | Cause | Fix |
|---|---|---|
| Unknown mass | Noisy load-cell signal while the user stands on the plate. | Block-based stability detection before accepting body mass. |
| Sensor drift | Temperature, humidity, and material behavior move the zero point. | Smart auto-tare while the platform is unloaded and stable. |
| Velocity drift | Small force errors accumulate during integration. | Reset velocity during stable windows before jump onset. |
| Late movement start | Trigger thresholds miss the beginning of the impulse. | Retroactive integration from a short pre-trigger buffer. |
| Unweighting vs. flight | A fast dip before a jump can reduce measured force almost to zero. | Use velocity direction and duration to separate downward unweighting from actual flight. |
Jump Phases
- Unweighting: force drops below body weight as the jumper moves downward.
- Braking: velocity stops decreasing and starts moving back toward zero.
- Propulsion: velocity becomes positive and force is integrated for takeoff.
- Flight: measured force stays low after upward takeoff.
- Landing: force spike and post-landing data collection.
The full project summary is here: Force Plate.