skein/todo.md

47 lines
3.9 KiB
Markdown
Raw Normal View History

2024-09-24 01:52:10 +02:00
Can we determine orbits entirely from an orbital state vector?
Can we use a state vector to generate initial orbital elements?
Can we use a state vector to modify an existing orbit?
The [perifocal reference frame](https://orbital-mechanics.space/classical-orbital-elements/perifocal-frame.html) has a right-handed coordinate system where p=x,q=y and w=z.
We want to be able to represent three orbit types individually as elliptical orbits are fundamentally cyclical in a way that para/hyperbolic orbits are not.
Hyperbolic orbits more useful than parabolic since they allow us to actually leave a planet.
They need to be positioned at a unique point in time, where elliptical orbits do not.
What additional orbital element information is required to position them in time?
Orbits take place in a (non-inertial?) reference frame. How should we model these?
We need a set of 3D axes and a clock for a reference frame.
What elements of our existing implementation would change?
It should be possible to get reference frames from a particle.
Should we be constructing orbits with a reference frame?
- [x] Make C properly pause time
- [x] Make W print out the normalized Cartesian velocity
- [x] Verify that the velocity is in opposite directions on opposite sides of the orbit
- [x] Make W convert the orbital elements to cartesian
- [x] add 10% to the velocity
- [x] then convert cartesian back to kepler elements and update the orbit
Now we can update the shape of the orbit but the position of the planet is not preserved. This is probably because we are calculated mean anomaly as a function of time, instead of taking into account the planet's existing elements.
Therefore when converting from cartesian to keplerian elements, we lose the information about the true anomaly. If we conserve this information when setting the planet's position in following frames we should maintain the planet's position within its orbit.
Currently we get a planet's position by querying the map with a time parameter. Instead, we should update the map with a time parameter and then query it. This means that we can update the entire map to the same time value, and then operate on its objects in the context of a single instant. We still avoid directly storing a time value in the map, but we will have complete elements with which to orbital operations.
I think to resolve this we will have to update the particle map (particle simulation?)
We assume that true anomaly is 0 at t=0 to avoid having to consider the previous position. We can't actually make this assumption when we change the shape of the orbit, because the period of the orbit changes as well. As such the calculated position doesn't take into account motion that happened when the orbit was a different shape.
Now we set the true anomaly when setting the particle velocity. However, the particle still jumps around due to us always calculating the particle position based on an absolute time, rather than taking into account the new period.
We need to calculate the particle's position as a function of the absolute time AND the specific particle's true anomaly at t=0. We need to update the latter when we modify the orbit.
We actually want to calculate the particle's mean anomaly at epoch when we update orbital parameters. This is because it is the mean anomaly which is computed as a function of time. When we update the orbital parameters, we can compute the mean anomly from the true anomaly on both occasions, which gives us the different in the mean anomaly at epoch before and after the update.
2024-09-28 17:15:02 +02:00
Argument of Periapsis
Hypothesis: The shifting in position is caused by a the change in the argument of periapsis which is not accounted for when updating the orbit
Test: Update the velocity such that the apo- and periapses of the orbit swap sides. This would cause the particle to jump to the other side of the planet
Test: Position the particle exactly at the apo- or periapsis before updating the velocity. The particle should remain stationary.