G-Force Simulating Centrifuge

A car produces changing longitudinal and lateral acceleration, while a centrifuge produces a load that depends on its radius and angular speed. This project investigates how those two descriptions can be connected. Rather than simply spinning a model faster whenever a racing car accelerates, it separates the magnitude of the required horizontal load from the orientation in which a seated rider would experience it.

The desktop application makes that mapping inspectable. A three-dimensional rig shows the rotating arm, carriage and yaw/pitch/roll gimbal, while recorded racing data supplies the changing target. Orbit and zoom controls let the same run be examined as an overview or from close to the seat. The result is a visual concept study, not a design certified for construction or human use.

Recorded telemetry is organised by race, session and driver, with lap-time information providing a way to choose a run. The browser can filter and rank laps using measures such as lap time, peak G and speed. Cached metadata avoids rediscovering the same information every time a folder is revisited.

After selection, the telemetry becomes a common timeline for the rig and the instruments. Longitudinal and lateral acceleration are read from the supplied acc_x and acc_y estimates and converted from metres per second squared to G. The data is treated as recorded evidence, including its omissions: unavailable steering information is shown as missing rather than inferred and presented as a measured signal.

For the rotating arm, horizontal acceleration follows a = omega squared times r, with angular speed obtained from RPM. The model uses standard gravity, 9.80665 metres per second squared, to express that acceleration in G. Radius changes the horizontal load at a given spin speed; doubling angular speed has a squared effect on acceleration.

Earth gravity remains part of the result. One horizontal G and one vertical G combine to approximately 1.414 G at 45 degrees, not two G. The target therefore includes a constant downward gravity component alongside the two racing acceleration components. The derived vertical acceleration field in the supplied lap data is excluded from this mapping.

Physical acceleration and the apparent loading felt by a supported rider are not interchangeable arrows. Establishing a consistent sign convention was essential: a visually plausible animation can still point the rider in the wrong direction if the physical and apparent vectors are mixed.

The peak horizontal load in the selected lap establishes a constant spin speed at the five-metre end of the arm. Lower loads are then reproduced by moving the carriage inward in proportion to the required horizontal acceleration. This makes the main relationship visible: one lap establishes the rotational operating point, and the changing telemetry determines the carriage position.

A minimum-angle orientation solution adjusts yaw, pitch and roll so the target vector and the simulated rider-relative vector agree. Separating that orientation calculation from load magnitude makes it possible to inspect whether a mismatch comes from the carriage radius, a coordinate transformation or the seat attitude.

This is an idealised mapping. It does not establish that a physical carriage could follow every requested movement, or account for the complete Coriolis, Euler, inertia and structural loads of that movement. Those omissions matter when interpreting the animation.

The seat animation is only useful if it can be compared with the event that caused it. Speed, throttle, brake, gear, engine RPM and lap time accompany the rig. A marker follows the recorded XY track, and a cursor moves through the full-lap G history.

Scrubbing moves all of these views to the same point. A braking zone can therefore be paused and examined against the target load, carriage location and seat orientation, then compared with a corner or straight. The complete lap history gives context that a single instantaneous gauge cannot: it shows whether a movement is a brief spike or part of a sustained section.

The most important debugging work involved coordinate frames and force direction. Left and right in the racing data, the world-space rig and the rider's local frame have to remain consistent. Fixing a visual reversal required checking those transformations rather than hiding the problem with a camera adjustment.

The application also needed usable selection and inspection controls. A dropdown contrast problem made choices difficult to read; correcting the control styling was a functional fix, not merely decoration. The cached lap browser and synchronised instruments similarly help expose errors that would be hard to notice in the rig alone.

A simulation should explain its assumptions through inspectable state. Showing the target and reconstructed vectors together makes a sign error visible, while a shared timeline keeps separate displays from telling conflicting stories.

The other lesson is to distinguish a useful geometric model from a complete physical machine. Matching an ideal load vector is a meaningful result, but does not prove mechanical feasibility, comfort or safety. The draft keeps those boundaries explicit while leaving room for deeper dynamics modelling later.