C++20 engine for telemetry and simulation apps
I built Cosmic to run my own engineering software. It is a C++20 engine and editor for 2D apps on Windows, and it runs SF_Telem, the telemetry app for my combat robot.
Two apps run on Cosmic today. SF_Telem is the one I use on real hardware. PendulumLab is the sample app I check against a known answer. More are planned, starting with to-9km-and-beyond.
Live ESC telemetry and drivetrain analysis for my 30 lb combat robot, Shear Force.
A damped pendulum simulation, integrated with RK4 at 240 Hz and checked against the analytic solution.
Trajectory animation and plots for my C++ subsonic airplane MDA tool. A test app with synthetic trajectory data already builds and packages against Cosmic; the real integration waits for real to-9km-and-beyond data.
I wanted an engine and renderer that helps my engineering projects and is not behind a paywall. I also think the best engine for a task is one built for that task. Unity and Unreal are far better for most work; they are not necessarily better for mine, which is live telemetry, test benches and simulations whose physics I write myself.
That split is deliberate. The engine is a tool: Cosmic takes care of the rendering and the boilerplate around it. The apps I build on it are mine, including their physics and engineering logic: SF_Telem's drivetrain model is a port of my command-line drivetrain calculator, and its weapon model is a port of my weapon speed spreadsheet. PendulumLab, below, is the engine's sample app rather than one of my projects; the apps I build next will follow the SF_Telem pattern.
Cosmic was mostly written with AI tools. I started it myself, writing the OpenGL graphics code and the application loop, and then AI tools took over most of the implementation and optimization while I set the direction and approved the high-level design decisions. It was also how I learned to work with AI tools and how an engine works at a high level: an application's run loop is close to a flight computer's main loop, and I wanted to understand how a computer turns data into pixels.
SF_Telem is the app I built on Cosmic for Shear Force, my 30 lb combat robot. It has two halves: live telemetry from the robot's three ESCs, and the drivetrain analysis I use to choose wheels and pulleys.
I started SF_Telem to check my drivetrain calculations against real data. Copying numbers from the Arduino serial monitor by hand, and then a third-party serial plotter, was not reliable enough, so I wrote my own app on Cosmic.
The ESP32 reads each ESC's telemetry UART, checks every frame's CRC, decodes the fields and re-aligns the stream when bytes are lost. It sends each reading as a tagged text line with an XOR checksum over Bluetooth. SF_Telem checks the checksum and converts the fields to volts, amps, rpm and speed with motor and gearing constants I can edit while it runs, so a change needs no reflash.
SF_Telem recorded the weapon ESC data behind the ESC root cause analysis on the Shear Force page.
The Analysis screen starts from my drivetrain spin-up model, a port of the drivetrain tool on the Shear Force page (Simulation V1). The motor's torque-speed line goes through the 19:1 gearbox and the belt pulleys to each wheel, is capped by traction, and is stepped forward in time into speed, acceleration, force and distance for the front (2.5 in) and rear (3.5 in) wheels. It flags a traction-limited launch. I compared its predictions with live telemetry during testing.
Around it are the Simulation V2 tools for changing the gearing when the axle heights are fixed: a lift planner that lists the whole-tooth pulley swaps that keep both wheels in sync for the same chassis lift, a same-pulley range, a feasibility check, a wheel-diameter sweep and a pulley-ratio table.
PendulumLab is the sample app for the Cosmic app workflow: a C++ service does the physics, the screens are made in the editor, and the data bus is the only link between them. A pendulum's small-angle motion has an analytic solution, so the integrator can be tested against it.
The service integrates the full nonlinear pendulum equation with fourth-order Runge-Kutta (RK4) at a fixed 1/240 s step. It publishes angle, angular velocity, energy and a period estimate; the Lab screen plots them, and a flow-graph rule opens a Stopped screen when the energy falls below 0.01. It packages to a standalone PendulumLab.exe.
| Check | Bar |
|---|---|
| Small-angle mode against the analytic solution, 10 s | within 1e-4 rad |
| Damping 0.05: energy over 10 s | never increases; ends at 0.55 to 0.65 of the start (analytic 0.61) |
| Period estimate against 2π√(L/g) | within 1 % |
| Two runs of the same case | bit-identical |
Cosmic is a C++20 engine for 2D real-time apps on Windows, with an editor, Starforge, built on the same runtime. An app is a set of screens whose widgets (plots, gauges, readouts, sliders, buttons) are bound to a live data bus, a flow graph that decides which screen is shown, and C++ services that publish the numbers.
The engine and each app are built separately, so changing an app never rebuilds the engine. Simulations run on a fixed timestep: 60 Hz by default, adjustable from 1 to 1,000 Hz.
In Starforge I lay out screens, bind widgets to data bus channels, draw the flow graph, and jump from any widget to the C++ that feeds it. When I save a C++ file during a run, the editor rebuilds the app's DLL, swaps it in and resumes on the same screen with the data kept; a compile error stops the run and shows the error. File > Package makes a standalone folder with the app's own exe.