Improving the USOFS software | Project planning and misc | Forum

Since appearing on spacehack.org, we've had a nice influx of new members, a few of whom are software people and have expressed an interest in helping to improve the currently quite basic USOFS software.  This thread is supposed to be a place where (i) I can present these new people with the information they need to start working on USOFS and (ii) the entire community can throw around ideas on what sort of improvements/features USOFS could really stand to have.

First things first:  What is USOFS?  USOFS, or Uncontrolled SubOrbital Flight Simulator, is a program for simulating the trajectories of uncontrolled rockets on suborbital trajectories (i.e. trajectories with maximum altitudes exceeding 100km, hence "in space", but with maximum velocities too low to achieve orbit).  It is primarily intended to help plan the construction of the OHKLA rocket.  It's fairly simple, conceptually: the underlying physics model includes simply gravity (which is modelled as constant across altitudes), a constant acceleration from the rocket engine, and drag computed according to the standard drag equation.   The equations of motion are solved numerically using a 4th order Runge Kutta algorithm.

So: Where is USOFS?  It's in the Mercurial repository of the CSTART Google Code Project.  You can view the trunk source code in your web browser.  It's written in Python (2.x).

How can you work on USOFS?  The standard procedure is for you to create a clone of the Mercurial repository.  This is a complete duplicated of the official repository which you can work on however you like without any kind of fear of breaking anything, like your own personal sandbox.  You can do so from this page by using the link under the "Create your own clone" header – note that you must be signed into a Google account to do so.  Once you've got something that you think is good committed to your clone (if you're new to Mercurial and need help using it, check out this tutorial or just Google around), you can contact anyone who has committer access to the official repository (currently myself, brmj and rpulkrabek) and ask us to have a look at your work (in the case of USOFS I am probably the best person to contact).  If it's good, one of us will merge your work into the main repository.  If you make a few good contributions to the repository in this manner and you seem generally trustworthy, you'll eventually be offered committer access yourself.

What sort of stuff would it be useful for you to do on USOFS?  Some preliminary ideas:

1. GUIfication.  Currently USOFS is command line only.  While I think it would be good to maintain the ability to run it from the command line, a GUI option as well would be handy.  This shouldn't be too hard, it is mainly just a case of giving the user a way to enter some numerical values and then having some "go" buttons and a nice way to present the data.  This last part leads into…
2. Graph generation.  Currently USOFS spits out big text files full of figures in a CSV format.  I have been using the gnuplot program to create graphs so far.  It would be very nice if USOFS could generate its own graphs (displaying them onscreen when running in GUI mode and saving them to a .png file when running in command line mode).  The matplotlib library for Python seems like the obvious solution to this.
3. Different thrust profiles.  Currently USOFS makes the fairly inaccurate assumption that the rocket engine produces constant thrust for the entire duration of its burn.  While we should keep this option as a fall back, it would be good if we could have people specify different profiles, e.g. a linearly decreasing thrust from some initial maximum to some final minimum, exponentially decaying thrust, etc.  This is the one proposed modification so far which would require an actual understanding of how the physics code works, not just the interface it presents.  I'm happy to advise anybody who wants to tackle this problem on how to go about making these changes.
4. Better supersonic drag simulation: this would require somebody with more knowledge than the current CSTART team seems to have collectively about aerodynamics.  If you are such a person or know such a person, please speak up.

I realise this has been written fairly briefly and there is probably a lot to absorb in a short time.  If anybody has any specific further questions, please ask and I will do my best to clear them up to the point that you can do some work

We're very keen to see some progress made on this front, so if anything is troubling you please speak up and we will try our best to accommodate you.  If you can't or don't want to figure out how to work Mercurial, we can work something out where you just email .py files to someone and they'll put them in the repository for you or something like that.

Wow, that was quick work!  I have a tonne of work to take care of today so I can't check this out just now, but I will certainly have a play with this later tonight – I'll use that as motivation to get my work done quicker. :)  Thanks very much for such a quick contribution.

brmj said:

I home some of that was at least a little helpful.

You've answered it better than I was likely to!  I had only some very simple curves in mind (e.g. linearly decreasing), but if there are standardised file formats for exchanging thrustcurve data then it absolutely makes sense to include the ability to load those.

As for actually including arbitrary thrust profiles in the code, for the purposes of simulating a flight where all specifications are given (i.e. the "simualte_flight" function), I think it should simply be sufficient to replace the reference to "specs.T" on line 163 with a call to a thrust function accepting the variable "t" as its only argument.  However, the "search" fuction (which calls "simulate_flight" with a range of spect.t_B and spec.T values to determine the requried burn time for any given constant thrust to obtain an apogee > 100 km) would take some more effort to update.  It doesn't make much sense as a function unless the thrust is either constant or a very simply parameterised function.

kksm19820117 said:

@brmj:

Thanks! I'll start working on it this weekend.

How did it go?  Were you able to make some progress?  If you want any help getting started please don't hesitate to ask.

This is great work!  Thank you very much.

A few quick thoughts:

• Looking at the graphs has given me quite some concern about the simulation accuracy.  i notice that before the huge sudden drop in acceleration at engine burn-out (which is to be expected), there is a small sudden drop in acceleration, which seems a little weird.  I also notice that the altitude appears to go negative after launch and only eventually turns positive, which is obviously wrong.  I remember having a problem with negative altitudes while writing OHKLA, but I was certain I had fixed it.  Anyway, when I get back home in a few days I will look into these issues.  They certainly aren't your fault, so don't let this detract from the praise you rightly deserve for your work.
• It would be fantastic if, in addition to the graphs, the GUI could give some basic, important summary statistics.  Maximum altitude,  maximum velocity, maximum acceleration (in m/s and in g) and maximum dynamic pressure come to mind as obvious candidates, along with the times at which these things occur.  Knowing these maxima will be important in making sure things are built properly.

Sorry I don't have time right now to provide more comment, but once again, great work and thank you.

This is certainly possible.  It's also possible I did something stupid like fixed the problem and committed to my local repository without pushing it to Google's servers.  i am sure I will be able to fix this quite quickly once I get home.