AOS

The Autonomous Orbital Sentinel you didn't know you needed.

Comment

What Inspired Me

AOS (Autonomous Orbital Sentinel) started with a simple question: what if orbital operations, space weather, and mission analysis could all exist in one interactive environment?

Most tools in the field are highly specialised or rely on static dashboards. I wanted to build something different: a living console where users could track satellites,investigate hazards, interact with an AI operator, and even extend the underlying simulation themselves.

I was also interested in bridging the gap between publicly available space data and accessible visualisation. AOS grew into an attempt to bring real-world data, forecasting, simulation, and AIdriven interaction together in one browser-based platform.

What I Learned

Building AOS taught me that a complex system isn't defined by its individual features, but by how well they work together.

  1. Real-time systems' needs for legitimate boundaries: I learned to distinguish between observed, forecast, and simulated data. Whether it was a hazard displayed in the console or a value reported by Sybil, communicating where information comes from is essential to building trust.

  2. Forecasting means working with uncertainty: Developing the (K_p) forecasting model introduced me to evaluation metrics such as RMSE, MAE, and the Brier score. More importantly, it taught me that even well-evaluated models have limitations, particularly when important geomagnetic storm drivers only become apparent shortly before impact.

  3. Extensibility requires careful design: Developing the Rust scripting interface taught me that allowing users to introduce behaviours or override algorithms also requires validation, constraints, and meaningful diagnostics.

  4. Small details matter (: : Working on camera controls, gesture smoothing, object picking, and custom typography showed me how much interaction quality depends on seemingly minor details.

How I Built My Project

AOS combines a browser-based frontend with a custom simulation engine.

| Frontend and Visualisation

  • Built with HTML, CSS, and JavaScript, using three.js for the 3D orbital environment.
  • Includes a cinematic landing experience, live console, account interface, and scripting environment.
  • Supports object inspection, camera controls, hazard injection, and interactive visualisation.

| Orbital Data and Forecasting

  • Uses TLE elements and SGP4-based propagation to visualise satellite trajectories.
  • Integrates NOAA/GFZ-derived space weather data and historical context.
  • Includes a trained model for next-day geomagnetic activity and storm likelihood.

| AI Operator (Sybil)

  • Uses structured tools to inspect simulation state, modify hazards, retrieve forecasts, and manage scripts.
  • Routes requests through a backend relay to keep API credentials off the client.
  • Includes a local command parser as a fallback when no LLM provider is configured.

| Simulation and Infrastructure

  • Built a Rust workspace (aos-sim, aos-core, and aos-instance) compiled to WebAssembly.
  • Exposes simulation hooks and a defined contract for user-authored Rust scripts.
  • Uses MediaPipe for camera-based gesture controls and a custom typography workflow for operational displays.
  • Runs on a Node.js backend with SQLite persistence, with additional experimentation around Cloudflare Workers and D1.

Challenges I Faced

  1. Maintaining simulation accuracy: Making orbital visuals and hazard effects technically grounded, rather than simply convincing-looking, required careful handling of data sources and modelling assumptions.

  2. Handling unreliable external data: Feeds and catalogues can be incomplete or unavailable. I had to build fallbacks without making simulated or cached information appear live.

  3. Browser performance: Running propagation, rendering, and interaction together required balancing responsiveness with simulation fidelity. Rust and WebAssembly helped, but introduced additional build and integration complexity.

  4. Safe extensibility: Supporting user-authored Rust scripts meant dealing with sandboxing, dependency management, resource limits, and execution safety.

  5. Making complexity approachable: Features such as forecasting, conjunction screening, and gesture controls needed intuitive workflows so users could explore them without being overwhelmed.

Closing Thoughts

AOS became much more than an orbital visualisation project. It brought together areas I wanted to explore, from orbital mechanics and forecasting to Rust, WebAssembly, and agentic AI.

The biggest thing I took away from building it was that engineering a capable system is only half the challenge. Making it reliable, understandable, and enjoyable to interact with is just as important.

Note: Despite the extensive research that went behind the project in the RELATIVELY short span given, I wanted to be as transparent as I could wrt the use of AI regardless of the extent to which it is permitted. I used AI for debugging, help with some of the physics and inspiration and inspiration ONLY for the site UI (as i did think that it's hyper tendency to resort to hyper modern layouts and themes would fit rather elegantly here. Modern solutions for modern problems (= ). The code was however written 100% by hand, by myself. I hope you enjoy (:

Built With

Share this project:

Updates

Submission history