I am a researcher studying orbital dynamics of asteroids/comets/dust. I made a very precise visualization tool for the solar system, it shows the motion of all of the known asteroids. When you click on a specific asteroid it will then show the hyper precise orbit for it which matches JPL's orbit calculations (full physics, n-body, relativity, non-spherical planets).
Research grade orbital mechanics, specifically of asteroids/comets.
I've been working on it for 4 years now, finally tried using some AI tooling the last few months and ended up vibe coding a fun little visualization.
Working on orbital dynamics code for my PhD in astronomy, written in rust, it can accurately calculate the positions of all asteroids/comets to within a few meters. Today I am adding a new numerical integration method which should enable me to predict orbits from observations.
Its an implementation of a pretty standard integrator used by astronomers informally called "RADAU", but it is not exactly the same RADAU you would find elsewhere. Basically it is about as good as you can typically get for multi-step integrators, tuned for speed not precision though.
Note that how the code is laid out you cant really simulate non-solar system masses. Its really aimed at massless objects in the solar system, your 3-body simulations are actually quite difficult to do given the design.
I suggest the appendix of the arxiv paper if you want to see some of the math required for solar system objects beyond simple Newtonian gravity (like Relativity corrections). I wrote that section specifically because I found it a pain in the ass to source those equations in literature.
This includes about 1.3 million known asteroids (most of the known ones), so the page is like 45mb. Consider yourself warned.
This is a plot of semi major axis, orbital eccentricity, and inclination of the orbit. The blobs are collisional groups, where a bigger rock(s) got smashed into 'families' of asteroids. Color is by the absolute magnitude H, which is a normalized, log scaled, brightness measurement. Typically smaller H means larger object.
You can see the Kirkwood gaps clearly along one axis, but as you move around you can see more complex orbital resonances. These resonances pump energy into or out of the orbit of the asteroid, causing them to leave the resonance after some time, depleting the region of phase space.
Source: I do solar system simulations for my PhD work.
One good reason to keep the raw data and orientation separate is hardware calibrations. I see some discussion here along the lines of "why not just flip the data before saving it", and one counter-argument is that you should store the flip metadata anyways, as it important to trace which hardware pixel corresponds to which stored pixel. I realize this information is not vital for everyone, but it is super useful in fields where you need to characterize the hardware performance at the pixel level (for example astronomy).
There are quite a few open source projects in astronomy, but in my experience there is a tremendous amount of code that is squirrelled away as it is difficult to reproduce and entrenches peoples positions. I have mixed feelings about this in general, as I understand the incentive structures, but I do wish in general some of the sub fields were a bit more open. I do think things are getting better in general.
Also I fully agree with the "codes" rant.
Source: working professionally in the field for 4 years.
This is really impressive! I considered buying a big harmonic drive mount for my scope, but the cost is really prohibitive.
I have experienced the pain of getting ekos/kstars/indi tools to work well on my personal scope. If you want to try driving indi devices via python I have some python code (it's not super polished, but it does enough for my needs): https://github.com/dahlend/contindi
Cool project. What prompted you to write this? Asking because EKOS already has pretty good scheduling features (I've seen, not used). Along the way I did vibe-code a TUI for controlling the INDI server running on the MeLE 4C minicomputer attached to the telescope: https://www.svendewaerhert.com/content/blog/telescope-mount/... - I switched to a headless setup using a remote indi server after having a bad experience with reliability using remote desktop in Gnome. I'll probably put this TUI on Github once I clean it up a bit.
I am a professional astronomer, and I am running a survey for asteroids. This needs to be controlled from python, as it decides every night which objects to observe.
I also heavily use Jupyter for analysis, and with this code I can take over the telescope and command it in a jupyter session, allowing me to do live data analysis.
It is neat to see some of the old work done in the field, this looks like a pretty classic treatment of the topic. It looks like they were using a fourth-order Runge-Kutta integrator, which would likely limit long term integrations accuracy (though looks sufficient for their use case). Many algorithms I have seen typically use much higher order integration methods to beat down the accumulation of numerical error.
Source: Working on my PhD in orbital mechanics of asteroids/comets, here are my open source (python/rust) orbital integration tools:
https://github.com/dahlend/kete
https://www.federalregister.gov/documents/2026/05/29/2026-10...
reply