I have been writing recently about C Kernel Engine as a CPU-native AI runtime and training system. But that is only one side of the bigger Antshiv Robotics direction.

The other side is the physical machine.

If C Kernel Engine is the runtime for local AI computation, then the flight controller stack is the runtime for physical motion.

The two systems are different, but the architecture mindset is similar.

Two runtimes

C Kernel Engine weights, tensors, kernels, memory plans, generated C, inference, training

Flight Controller Stack sensors, state estimation, dynamics, control laws, motor mixing, stable flight

In both cases, I am trying to make the hidden runtime explicit.

For AI, that means exposing tensors, kernels, memory, backprop, generated C, and hardware execution.

For drones, it means exposing attitude math, sensor fusion, dynamics, control systems, motor commands, telemetry, and physical validation.

1. The Flight Controller Is Not One Thing

When people say "flight controller," it sounds like one board or one firmware image.

That is true at the product level, but not at the systems level.

A flight controller is a stack of layers working together:

1. attitude math
2. sensor fusion
3. state estimation
4. vehicle dynamics
5. control systems
6. motor mixing
7. hardware abstraction
8. telemetry
9. simulation
10. physical validation

If any layer lies, the system becomes unstable. If attitude math is wrong, the estimator is wrong. If the estimator is wrong, the controller fights the wrong state. If the mixer is wrong, the right correction goes to the wrong motor. If the motor model is wrong, the simulation gives false confidence.

That is why I am building this slowly from the bottom up.

2. Attitude Math Library: Orientation Is The Foundation

The first layer is attitudeMathLibrary.

This is the math foundation for representing orientation in 3D space. A drone has to know roll, pitch, and yaw, but internally it also needs safer representations like quaternions and direction cosine matrices.

The library includes:

• quaternion normalization, multiplication, inversion, and rotation
• Euler angle conversions
• direction cosine matrix conversions and orthonormality checks
• axis-angle conversion
• SLERP interpolation
• vector math: dot product, cross product, magnitude, normalization
• explicit quaternion rotation demos for teaching the q * v * q* sequence

This is not abstract math for its own sake. This is the layer that lets every other part of the flight stack agree on orientation.

If a drone cannot represent orientation correctly, it cannot estimate, control, visualize, or stabilize itself correctly.

3. State Estimation: Sensors Do Not Tell The Truth Directly

The next layer is stateEstimation.

Raw sensors are noisy. Gyros drift. Accelerometers see gravity and motion at the same time. Magnetometers can be disturbed. Barometers are noisy. Time-of-flight sensors only work in certain conditions. GPS is useful but not fast enough for the inner control loop.

The state estimator tries to answer a practical question:

Given imperfect sensor measurements, what is the drone most likely doing right now?

The library already documents attitude and altitude estimation paths:

• complementary filter
• Kalman-style estimation
• quaternion-based attitude representation
• gyro bias estimation
• optional magnetometer fusion for yaw correction
• altitude fusion from IMU, barometer, and time-of-flight sensors
• sensor dropout handling

This layer is where the flight controller stops reacting to raw noise and starts reacting to an estimated state.

If the estimator is wrong, the controller is not controlling the drone. It is controlling an illusion.

4. Dynamic Models: The Drone Has To Obey Physics

The next layer is dynamic_models.

This repository is the physics backbone. It already contains a rigid-body quadrotor plant, numerical solvers, linear model examples, and documentation that connects free-body diagrams back to code.

Some concrete pieces:

• rigid-body quadrotor plant with thrust, torque, gravity, and quaternion kinematics
• Euler, RK4, and adaptive RK-style numerical integration utilities
• hover examples for checking whether rotor thrust balances weight
• linear systems like point mass, mass-spring, pendulum, inverted pendulum, and double pendulum
• motor dynamics scaffolding
• battery model and battery management scaffolding
• neural state-space and system identification direction

This matters because controllers need a plant. A controller computes commands, but the physics model tells us how the vehicle should respond.

The simplest hover condition already says a lot:

sum(rotor_thrust) ≈ mass × gravity

But a real drone needs more than hover. It needs roll, pitch, yaw, inertia, motor lag, payload effects, battery behavior, wind, and disturbances. The dynamic model is where that complexity starts becoming inspectable.

5. Control Systems: Error Becomes Correction

The next layer is controlSystems.

A controller compares desired state against estimated state and computes a correction.

The repository already includes control strategies and tests for:

• PID control
• LQR
• MPC
• robust control
• mixer logic
• attitude-hold examples

PID is the practical starting point because it is understandable and widely used. LQR, MPC, and robust control become more useful as the model becomes richer and the test loop becomes stronger.

The goal is not to pretend one controller solves everything. The goal is to build a control library where different strategies can be tested, compared, tuned, and eventually connected into one flight stack.

6. Mixer: Control Intent Becomes Motor Command

The mixer is one of the easiest layers to underestimate.

A controller usually thinks in terms of:

• throttle
• roll correction
• pitch correction
• yaw correction

The physical vehicle needs individual motor commands.

That translation is the mixer.

If the mixer is wrong, the vehicle can respond backward. A roll correction can become pitch. A yaw correction can fight the wrong motors. A mathematically reasonable control output can become a physically wrong motor command.

That is why the controlSystems repo includes mixer-specific tests and docs. The mixer is not glue. It is where intent becomes actuator command.

7. INS: The Flight Loop Comes Together

The integration layer is inertial_navigation_system.

This repository is meant to wrap the major pieces:

• attitude math
• state estimation
• control systems
• dynamic models
• hardware abstraction
• examples for flight control and test rig integration

The loop looks like this:

Flight loop

Sensors IMU, gyro, accel, barometer, magnetometer, GPS, ToF

State Estimator combine noisy measurements into attitude, altitude, velocity, position

Controller compare desired state against estimated state and compute correction

Mixer translate throttle, roll, pitch, yaw into motor commands

Vehicle motors, propellers, frame, battery, payload, environment

That loop has to run continuously and predictably. In embedded robotics, timing matters. Memory matters. sensor update rates matter. Control loop frequency matters. Latency matters.

This is why I keep coming back to C. The point is not nostalgia. The point is to keep the system close to the machine.

8. AeroDynControlRig: Seeing The Math Run

Numbers are not enough.

That is where AeroDynControlRig fits.

AeroDynControlRig is the desktop visualization and testbed layer. It uses C++17, OpenGL, GLFW, Dear ImGui, and telemetry panels to visualize the flight-control stack.

The repo already documents and shows:

• quaternion visualization
• real-time telemetry plots
• rotor analysis panel
• state estimator panel
• sensor suite display
• power monitor
• OpenGL rendering pipeline docs
• ImGui cockpit-style UI
• roadmap for dynamics, estimation, control, and data export

The point is to see the system fail before the hardware fails.

If the quaternion math is wrong, the model rotates wrong. If the estimator drifts, the plot should show it. If the controller oscillates, the telemetry should expose it. If rotor commands saturate, the UI should make that obvious.

This is the same reason I care about visualizers in C Kernel Engine. When the runtime is hard to see, bugs hide.

9. Rotor Dynamics: The Propeller Is Not Just A Spinner

The rotorDynamics repo is currently the planned propulsion analysis layer.

Its goal is to model and eventually validate:

• momentum theory
• blade element theory
• thrust coefficients
• torque coefficients
• RPM sweeps
• pitch and air-density effects
• lookup tables for dynamic_models and AeroDynControlRig
• validation against thrust stand data

This is the bridge between simple motor commands and real propulsion behavior.

A conservation drone cares about endurance. Endurance depends on how battery power becomes useful thrust, airflow, noise, and flight time. That means rotor dynamics eventually connects directly to ecological monitoring.

The mission metric is not maximum speed. The mission metric is maximum useful ecological data per watt-hour.

10. ThrustStand: Measuring Propulsion Instead Of Guessing

Between rotor theory and a full drone test rig, there is another important layer: the ThrustStand.

This is where the flight controller starts to become grounded in real propulsion data. Rotor Dynamics can estimate thrust, torque, power, and efficiency. OpenFOAM or actuator disk models can visualize airflow. But the motor, propeller, ESC, battery, mount, vibration, and wiring do not care about the theory unless the measured system agrees.

The thrust stand is the place where propulsion becomes data. It should eventually measure:

• thrust vs RPM
• torque vs RPM
• power draw vs throttle
• voltage sag and current draw
• propeller efficiency
• motor/ESC response
• vibration and mechanical noise
• repeatability across propeller and motor combinations

This is not a side project. It is part of hardening the flight-control loop. The controller asks for a correction. The mixer turns that correction into motor commands. The motors and propellers convert those commands into forces and torques. If that conversion is wrong, the controller is correcting against a fantasy.

Propulsion validation

Rotor model predict thrust, torque, and power from theory or lookup tables

Thrust stand measure real motor, propeller, ESC, battery, mount, and load-cell behavior

Coefficient update fit or correct k_t, k_q, power curves, response lag, and saturation

Mixer and controller feed corrected propulsion data into dynamic_models, AeroDynControlRig, and the control loop

That is the connection: thrust stand data hardens the propulsion model; the propulsion model hardens the mixer; the mixer hardens the control loop; and the control loop is what keeps the drone stable enough to collect useful ecological data.

For ecological monitoring drones, this matters because endurance is not theoretical. A propeller that looks efficient on paper has to prove it in measured watt-hours, thrust, noise, vibration, and useful flight time.

11. DroneTestRig: The Physical Validation Layer

Simulation is not enough.

The DroneTestRig repo contains the mechanical direction: CAD files, 3D-printable parts, connectors, square-rod mounts, bearing supports, lever/cam pieces, tolerance tests, and a physical rig concept.

The test rig is not just a frame. It is the physical harness for hardening the closed-loop flight controller before trusting it in the air. The attitude math, state estimator, controller, mixer, propulsion model, and sensor stack all need a place where they can fail safely while still producing real measurements.

This is where the separate work starts to connect: thrust stand data calibrates motor and propeller behavior; attitude rigs validate orientation math; the test rig constrains the drone so controller behavior can be observed; and those measurements feed back into the software stack.

This is where the stack eventually touches reality.

The long-term validation loop should look like this:

Validation loop

Model derive or simulate the expected behavior

Visualize inspect it in AeroDynControlRig

Build 3D print fixtures, assemble rig, mount hardware

Measure collect thrust, torque, vibration, attitude, sensor data

Correct update coefficients, models, controllers, and assumptions

This is why I do not want the drone work to stay only theoretical. The rig is part of the same system.

12. Where AI Fits

AI does not replace the inner flight-control loop.

A neural network should not be the thing keeping the drone stable at the lowest level. The inner control loop needs deterministic, real-time behavior.

But AI fits around the flight stack.

AI can help with:

• image classification
• vegetation analysis
• anomaly detection
• mission planning
• sensor data interpretation
• simulation automation
• case generation and report writing
• local inference on edge hardware

This is where C Kernel Engine and Antshiv Robotics start to converge.

The flight controller stack keeps the machine stable. The local AI runtime helps the machine understand what it is seeing.

A useful autonomous ecological machine needs both.

13. Why This Matters For Ecological Monitoring

The final goal is not just flight.

The larger goal is ecological monitoring and biodiversity conservation.

I want Antshiv Robotics to eventually help monitor:

• forest fragmentation
• vegetation stress
• wildlife corridors
• roads and construction
• shipping and coastal activity
• industrial activity
• human impact over time

For that mission, stability matters. Repeatability matters. Sensor placement matters. Flight paths matter. Battery efficiency matters. Data quality matters.

The drone is not the final product by itself. The larger product is:

flight → imagery → environmental context → AI analysis → ecological insight → repeatable monitoring

The flight stack is what makes the data trustworthy enough to use.

14. Current State

The honest current state is that the pieces exist, but they are not yet one polished product.

The stack is spread across several repos:

Some layers are more mature than others. Attitude math, numerical solvers, rigid-body dynamics, early controls, and visualization already have meaningful work. Rotor dynamics, thrust stand measurement, and physical validation need more hardening. INS integration needs to become more than a wrapper. AeroDynControlRig needs to become the place where the whole loop can be exercised.

That is the point of writing this post. It forces the architecture to become explicit.

15. The 2-3 Year Bet

I am giving myself a 2-3 year horizon to make these systems converge.

The goal is not just to have separate repos. The goal is to make them work together as one embedded robotics stack:

• flight math
• state estimation
• control systems
• dynamics
• motor models
• simulation
• physical rigs
• local AI
• ecological monitoring

I am not claiming all of this works cohesively today. I am saying this is the direction I am intentionally hardening.

The same way C Kernel Engine is becoming the AI-runtime side of the work, this flight controller stack is becoming the motion-runtime side.

Conclusion

A drone is a physical machine, but useful flight starts as math.

Orientation has to be represented. Sensor noise has to be filtered. Physics has to be modeled. Controllers have to compute corrections. Mixers have to translate those corrections into motor commands. The loop has to run fast enough to keep the vehicle stable.

That is what I mean by building a flight controller stack from scratch.

It is not one library. It is a system of layers.

And over the next few years, I want those layers to become the foundation for Antshiv Robotics: an open-source Linux/C robotics platform for autonomous ecological monitoring.