Forum | First steps toward a flight plan!

The image below is zoomed out a lot to show interactions of the CSM's trajectory with the moon.  It's not very clear, sorry, I put these together in a hurry.  The Earth is located at the bottom right of the plot (at (0,0) on the axes).  The red arc is a segment of the moon's orbit around the Earth.  All the other lines are CSM trajectories.  All the trajectories have exactly the same delta-V, which is why they are blurred together into a yucky yellow-green line for most of the trip.  But the trajectories happen at slightly different times, so that they pass nearer or further to the moon.  You can see the deflection of the trajectories when they get near the red line, which is the moon's path.  The trajectories are being deflected rather sharply by the moon's gravity – I was hoping to find a free return trajectory which would swing the CSM back around headed toward Earth, but couldn't get it to work.  I think the CSM is travelling too fast to achieve free return in these simulations, I will have to experiment more later.  A quick note on the length of the various trajectories.  They all terminate an equal amount of time after launch, so the fact that the light blue line extends so very far after its deflection means that the CSM in this case has picked up an awful lot of speed during its gravitational sling shot!

The image below shows the same data as the last image, but it is zoomed in on the interesting part, where the CSM's trajectory interacts with the moon's gravity.  Note the really interesting loopy structure of the light blue trajectory!

That's all for now, these really are the absolute earliest experiments with a very rough play toy.  Nevertheless, it seems to be acting sensibly enough and I am optimistic about being able to extend it to be more useful.

Here's a list of things that will need to be tweaked for future versions, which will increase accuracy a lot:

• Currently the equations of motion are solved using Euler's method, which is the most blindingly simple algorithm for numerical solution of DEs there is, and which doesn't have great accuracy.  A later version should use something like the 4th order Runge Kutta method for improved accuracy.  This really won't be all that hard to implement.
• Real life injection burns will not be instantaneous.  They extend over a few minutes, and the acceleration increases slightly over that time as fuel mass is lost.  This should not be hard to model more accurately.
• The moon's orbit is modelled as a perfectly circular orbit around the Earth, with a radius that is the mean of the apogee and perigee of the moon's true elliptical orbit.  A later version should use the moon's actual orbit.  This shouldn't be too hard, either, orbital parameters for the moon will be easy to find.
• Gravity from the sun is currently completely ignored – only the Earth and the moon have any effect on the CSM's trajectory.  This may be a little bit of work to add.
• Solar radiation pressure is ignored completely.  My intuition is that this will not make a noticeable difference, but if it is easy enough to add, it will not hurt.
• There is no collision detection, the Earth and moon are both modelled as point masses.  I'm not unconvinced the super high speed light blue orbit doesn't actually involve getting closer to the moon than its physical radius would allow.   This would be easy to check, though.
• Modelling the Earth and moon as point masses ignores the fact that they are not perfect spheres, which has a subtle influence on their gravitational fields.  I don't know enough of the relevant theory to estimate either how big of a difference this is likely to make or how hard it will be to improve.
• This doesn't really affect the physical accuracy of the current simulations, but is more about accurately simulating something closer to what will actually happen: we should not assume that the CSM begins in a perfectly circular parking orbit.  Rather, we should be able to specify orbital parameters which we can determine from ground observations.

The other big short coming is that exploring the space of possible orbits now is literally a matter of manually guessing good values for all the parameters, looking at the plots, changing them, etc. until you get something close to what you want.  A better solution would be to determine some rough heuristics that can automatically ballpark, e.g. the relative position of the CSM and the moon at TLI burn time on the basis of the specified delta-V or vice versa, and then use quickly test a range of parameters within the neighbourhood of that ballpark to find some values that fit the desired criteria.

I will continue work on this software over the next few days and keep you all posted.  Once I have some code that is a little bit neater than what I am using now I will start putting copies of it in our DropBox so other people can have a look and contribute.  I think developing this program to the point that it enables really smooth and accurate flight planning will be a lot of fun and a great achievement for us!  We should endeavour to make sure it is adaptable from CLLARE to later missions.  Basically we should end up with something like a completely open source version of the Orbiter software that it was suggested we use for basic planning.

Feedback on anything and everything in this post is welcome!

I wanted to put the code in our CSTART Dropbox account but realised I don't know the [email protected] account password.  If someone could email it to me, that would be great.  For now, I'm hosting the code myself here.  I've put this version in the public domain since we haven't had a discussion yet about what the official CSTART license will be.

I've really enjoyed working on this.  I feel like there is a fairly natural evolutionary path for this program, from a simple lunar TLI simulator to a generic mission planning program that can compute trajectories to anywhere in the solar system.  Of course our first use for it will be purely lunar in nature but it should not be too hard to avoid artificially limiting it to the moon as we develop.  We can simply have it load orbital elements for a series of bodies in a list, and just set the list to only contain the moon for now.  In addition to plotting trajectories it could take care of things like predicting periods of radio blackout (which is just simple geometry – does a straight line from the craft to the Earth intersect any of the bodies), etc.

I would be excited to play a fairly key role in developing this software but don't want to get too carried away before there is some discussion to figure out, e.g.

• What the program should be called!
• What the most useful things to put in the program's scope would be,
• What language it should be written in,
• Which GUI library it should use  (which will depend on the above),
• What license it should be under, etc.

Questions, comments?