Forum

I am pleased to see this subject getting more detailed consideration.  Your basic outline here seems entirely sound.

A few quick thoughts:

• I like the use of a Cartesian x-y-z coordinate scheme.  I wondered about this for a while myself, since spherical coordinates feel a little more natural for orbit simulations.  However, what really pushed me in this direction was the realisation that inertial measurement units invariable use Cartesian coordinates.  The spaceship's navigation computer is going to think in Cartesian terms, so it makes sense that our planning software should too.
• I think the coordinate scheme should be centred on the sun rather than on Earth.  For CLLARE it would feel a little more natural to centre things on Earth, but by using a heliocentric system we make it easier to extend things to solar system wide missions later.  Also, this approach will make it easier to include solar radiation pressure (which varies with inverse square distance from the sun) – this would require adding surface area and reflectivity variables to bodies.
• While the cordinate system used for the internal calculations of the software should be a heliocentric Cartesian solution, the user should be able to define their own coordinate systems almost arbitrarily and have the results displayed in that system.  Setting up a spherical coordinate system centred on the Earth and aligned with the Earth-Moon orbital plane should be particularly easy to do.
• I would love to see some sensible automated scaling of timeslice length and perhaps even included factors.  Obviously we would always want a "full accuracy" option which uses a fixed, small timeslice and includes gravity from every body in the solar system, solar radiation pressure, etc., but for exploratory analysis we don't need quite that much accuracy – our system should take larger timesteps during the "boring" parts of the trajectory and only include gravity from say the sun and the 2 nearest non-sun bodies.

I will probably have more to say on this either later tonight or tomorrow.

Hi Kelly,

Thanks for your comment and the link to OTIS4.  It does look like a useful program.

My main concern with using OTIS4 is the export restriction.  If only US citizens may get a copy, then that means only US citizens may participate in planning our trajectories, which is contrary to the open and collaborative spirit of CSTART.

It also seems like OTIS4 is not available under an open source license.   While our Social Contract does not obligate us to only use open source software, we are supposed to do so wherever we can.  I like to think that a secondary goal of CSTART is to increase the amount of open source software out there which can be used to plan space missions.

If the problem were a lot more difficult I would be more inclined to put aside these problems and just use OTIS4, but as it stands, the problems we actually have to solve (it looks like OTIS4 contains a lot of stuff above and beyond this) are not really all that difficult and I think it is well within our means to produce a simple program for our trajectory planning.  There is not really an urgent need to get this ready quickly in order to facilitate more detailed design, since the delta-v requirements can easily be found without this sort of software and they are the only figures needed to determine the extremely basic stuff that needs to be known before any work can begin.  More detailed trajectories are not really needed until we start thinking about guidance software, and that ideally shouldn't be until more work has been done on the RCS stuff.

The other big advantage to rolling our own is that we can absolutely make sure it is applicable to whatever design we may come up with, even if it is a little unconventional and not something NASA has ever done before.

All that said, it's very useful for us to know that OTIS4 is out there and I thank you for bringing it up.  If it turns out that we do have a harder time than expected on this project, or we find that we do need detailed trajectories sooner than expected, we can always jump to OTIS4 as a fallback.  We shouldn't let our ideology get in the way of success if it ever comes down to that.

Changing topic slightly, speaking particularly to brmj, are you interested in starting work on this fairly soon?  After SpaceUp, say?

Not only unrealistic, but if the very data itself could not be exported it would basically mean that our trajectories would be "semi-secret", which is not very open.

It really is unfortunate that arms trafficking laws apply to so many exciting, positive dual use technologies.  It isn't only space launch vehicles which suffer from this problem, it has historically been quite a bad problem for cryptography as well.