> VAUGHN_CAMPOS_
All Projects
Complete2024

Spacecraft Dynamics Simulation

Real-time spacecraft physics simulator built with C++ and OpenGL.

C++OpenGLPhysics SimulationQuaternion MathematicsControl Systems

Overview

A spacecraft simulator modeling orbital dynamics, attitude propagation, and spacecraft control, rendered in real time with a custom OpenGL viewer. The goal was to build a from-scratch environment for experimenting with attitude control concepts — rather than treating the physics engine as a black box, every piece from quaternion propagation to torque application is implemented and inspectable.

3D spacecraft renderingmedia pending — image
Real-time OpenGL render of the spacecraft with body-frame axes overlaid.

Problem

Attitude dynamics are easy to get subtly wrong: naive Euler-angle integration introduces gimbal lock, and small numerical errors in quaternion propagation compound over long simulation runs. At the same time, a physics simulation that isn't visualized in real time is hard to build intuition from — numbers on a plot don't reveal whether a controller is over-damped, oscillating, or correctly rejecting disturbance torques.

The project needed:

  • Numerically stable, singularity-free attitude representation and propagation
  • A real-time 3D viewer to visually verify simulated behavior as it runs
  • A control layer that could be swapped and tuned without touching the physics core

Technical Architecture

Physics architecturemedia pending — diagram
Simulation loop: state propagation, control law, torque application, and rendering.

The simulator is organized around a fixed-timestep physics loop:

  • Rigid-body state — Position/velocity in the orbital frame, attitude as a unit quaternion, and angular velocity in the body frame.
  • Dynamics core (C++) — Numerical integration (RK4) of translational and rotational equations of motion, with quaternion normalization each step to prevent drift.
  • Control layer — A pluggable controller interface so different attitude control strategies can be swapped in without modifying the propagation code.
  • Renderer (OpenGL) — A real-time 3D view of the spacecraft body, reference frames, and torque vectors, decoupled from the physics timestep so the simulation remains numerically stable independent of frame rate.

Implementation Details

Attitude is represented entirely with quaternions to avoid gimbal lock, with kinematics integrated via the standard quaternion derivative equation (q_dot = 0.5 * q ⊗ ω) and renormalized after each integration step to counteract floating-point drift. Angular velocity dynamics use Euler's rigid-body equation, accounting for the spacecraft's inertia tensor and any applied control or disturbance torques.

The renderer runs independently of the physics timestep: physics is integrated at a fixed rate for numerical stability, while rendering interpolates the most recent state for smooth visual output regardless of display refresh rate.

Challenges

Keeping the physics timestep decoupled from render timing, without introducing visible stutter or drift between the two, required care around how state was interpolated for display. On the control side, tuning a controller by staring at plots alone was slow — being able to watch the spacecraft body physically respond to a step disturbance in the OpenGL view made controller tuning far more intuitive and fast.

Results

Controller step responsemedia pending — graph
Attitude error convergence following a step disturbance, before and after tuning.

The simulator correctly propagates rigid-body attitude dynamics over long runs without quaternion drift, and the real-time viewer made it straightforward to visually confirm controller behavior — settling time, overshoot, and steady-state error — that would otherwise require careful plot inspection.

Lessons Learned

Visualizing physics in real time surfaces bugs that plots hide. Several early issues (a sign error in torque application, an incorrectly transposed rotation) were obvious within seconds of watching the spacecraft body behave unrealistically, but would have taken much longer to catch from time-series plots alone.

Future Work

  • Add flexible-body dynamics (solar array/appendage flexibility)
  • Model reaction wheel and thruster actuator dynamics explicitly, rather than applying idealized torques
  • Extend the control layer to support a full GNC pipeline (guidance + navigation + control)