Have you ever wondered what happens when a satellite is first placed into orbit? It turns out that often, they tumble out of control, end over end, in a miraculous fight against stability. Check out our demo here of a control system attempting to rectify this: https://app.elodin.systems/sandbox/hn/cube-sat

The spacecraft does not appreciate tumbling: deploying solar panels and antennas might not work, and doing anything worthwhile is out of the picture. So what are you to do about this? You'll equip your satellite with reaction wheels (or magnetorquers), but now you have a second problem. What commands do you send to the reaction wheels?

We created Elodin to help solve problems like this. These problems are firmly in the realm of GNC (guidance, navigation, and control) engineers; they are traditionally solved with MatLab / Simulink, a bunch of Python scripts, and/or a tool like Gazebo or Basilisk. While building the flight software for a deep-space mission, I tried all of these tools and didn’t like them. In particular, I found that running Monte Carlo simulations in the cloud was painful.

So we set out to build a better framework for physics simulation. You might call it "Tensorflow for Physics." The name fits for two reasons: we use XLA to accelerate your math, and we've built an extensible framework for creating new physics engines. Most physics engines are fixed-function. For example, something like MuJoCo (https://mujoco.readthedocs.io/en/stable/overview.html) is great for traditional robotics, but GMAT (https://gmat.atlassian.net/wiki/spaces/GW/overview) is far better for orbital analysis. No single physics engine can solve all problems, and it’s hard to integrate multiple engines. Our framework allows you to easily compose different physics algorithms.

Space is hard enough—let’s not have software make it harder than it needs to be! We are still early in building our stack, so we’d be grateful to hear any feedback that you have.