Feature wishlist

The feature wishlist details some desired features for OpenRocket, concentrating on ones that can reasonably well be implemented without deep knowledge of the OpenRocket internals. If you find something you'd like to contribute (or make something up yourself), please inform us about that on the OpenRocket-devel mailing list and we can help you get started.

This page complements the distribution TODO file, which contains more ideas in a shorter form. Please feel free to comment on the issues.

From SourceForge project Page:

• tube fins
• fins on boattails (V-2 anyone?)
• support (and print patterns for) cluster mount centering rings
• strap-on boosters / parallel staging
• compound fins
• support for other cases: i.e. (Shrox, I'm looking at you)
• rail buttons
• launch lug/rail button standoffs

- rsholmes, Sourceforge.net, comments from project page

UI improvements

There are various places in need of attention in the UI. The UI code is also in some places a bit messy, and should be cleaned up.

• Intuitive zooming of the plots
  • normal magnifying glass buttons for zoom in/out
  • currently click-drag towards the lower-right zooms in, towards the upper-left resets the zoom to original - very unintuitive (JFreeChar default)
  • should be implemented as a generic component that could be used in various places
• Ctrl+scroll wheel should zoom in/out the rocket design (and maybe also plots)
• Component databases
• Rework base frame to have better use of realestate. Replace the component selection box with something smaller and reuse that space for editing components. Perhaps use a library like InfoNode Docking Windows

3D view of the rocket

A 3D view of the rocket is greatly desired, but I have no experience in 3D programming. Below are a few ideas or a "wish list" (not all need to be implemented!)

• 3D view as an alternative to the side and back rocket view
  • rotation using the mouse drag-and-drop
  • either "normal" view or a translucent view, where the opacity of each component is something like 0.3-0.5
  • decals - allow a user to define 1-n images that are positioned at some point of the rocket body or fins
  • allow configuring a spiral wound for body tubes
  • selecting components by clicking on them (like you can in the 2D view). Not sure whether it's a good idea to show the selected component in any special way though.
  • allow defining "shininess" of the component (there's really something like 3 parameters controlling this, but for UX I think we should try to make a single parameter which works reasonably for all)

• An animation of a simulated flight
  • general overview of flight (with possibility to magnify the rocket)?
  • different camera angles to choose from, some ideas:
    • launcher view
    • profile view
    • a camera attached to the rocket pointing to the side / tail
    • a camera moving along with the rocket either from the top or side
  • selectable launch scenery
  • allow selecting whether xyz-axis are displayed on the rocket during flight
    • provides a visualization of what the rocket is doing during the flight
    • rocket movement often very hard to visualize looking at just graphs
    • may require additional flight parameters to be stored during simulation

Printing support

Printing is one of the most asked-for features for OpenRocket. At the same time it would be natural to allow exporting the same as PNG, SVG or PDF.

Support can be implemented in various levels. At least the following are candidates for places where print/export may be desireable:

• fin templates, conical transition/nose cone templates, nose cone profiles
• the rocket design view
• the simulation plots (JFreeChart has some support built-in)
• printing a design report (see below)

Creating/printing a rocket design report

The ability to create a report containing the most important design information to present to a RSO at a launch event. The structure of the report could be something like the following:

• Title
• Section describing the rocket in general without motors
  • design name
  • empty mass & CG
  • CP position
  • CP position at 5 degree AOA (or similar)
  • number of stages
  • parachute/streamer sizes
  • max. diameter (caliber)
• Section for each motor configuration
  • a summary of the motors, e.g. 3xC6-0; B4-6
  • a list of the motors including the manufacturer, designation (maybe also info like burn time, grams of propellant, total impulse)
  • total grams of propellant
  • total impulse
  • takeoff weight
  • CG and CP position, stability margin
  • predicted flight altitude, max. velocity and max. acceleration
  • predicted velocity at chute deployment
  • predicted descent rate
• Diagram of the rocket (positioned vertically on the right side of the first page)
  • CP position
  • CG position without motors and in each configuration (the labels should alternate on right and left sides to avoid being on top of each other)

The user flow could be something like the following:

• Select from menu Rocket -> Design report
• A dialog opens to ask which motor configurations to include in the report
  • maybe ask paper size as well
• Simulations are run for each to get most up-to-date info
• Report is shown to user, allowing them to save or print it

Technical considerations:

• Predicted data readily available from OR (ask for details)
• The rocket plot can and should use the same rendering as the design window
• How to define launch conditions? Should the user select simulations to include in the report instead of motor configurations?

One issue is also in what format and how to create the report. Below are a few alternatives that have been considered, others are possible as well.

• Generate the report in HTML
  • Pros:
    • easy to generate
    • can be displayed using a JTextPane
    • allows saving as HTML
    • easy to print from Java using JTextComponent.print()
  • Cons:
    • including the plot might be problematic and requires a separate file when saving
    • rocket diagram needs to be in raster format
    • no support for smart pagination
• Use iText or some other PDF generator
  • Pros:
    • exported directly as PDF, only one file in output
    • more control, can produce more professional-looking output
    • rocket diagram can be in vector format
    • can be better paginated
  • Cons:
    • may be more difficult to generate(?)
    • smart pagination may be challenging / require additional work
    • displaying and printing the report may need separate support (maybe using PDFBox?)
• Generate LaTeX document and figures for later compilation
  • Pros:
    • Extremely high quality output
    • Equations, pagination, sections, hyperlinks and anything else you could want
    • Fully vectorised graphics
    • User can easily manually customise output file
    • Easy to program on the Java side as just generating plain text
  • Cons:
    • Requires an external LaTeX distribution
    • Not everyone knows LaTeX.

Rocket Model and Simulation enhancements

• Add deployment events, ignition events, and other rocket components to be modified per configuration. Examples of configurable properties:
  • mass objects to support models with changable nose weight or different electronic configurations
  • different recovery devices used for different motor selection
  • use different deployment events (different altitude settings for example) with different motors
  • better model high power staging and air-starts
• Support fins on transitions

Memory profiling

OpenRocket seems to consume quite a lot of memory, and likely has numerous memory leaks. (During initial development the effort was on getting it to work, not managing memory.) Below are a few suggestions what could be done to improve the memory handling.

• Profile OpenRocket's memory usage to find potential leaks
• Implement a scheduled task that checks the memory usage every ten seconds or so
  • Warn the user if 90% of available memory has been used
  • Offer to send memory profiling data automatically to developers (?)

Aerodynamic computation enhancements

While OpenRocket produces reasonably accurate results for typical model rockets, there are many cases which are in need of expert attention.

In most cases the implementation can be done by the core developers if only clear methods are available!

• Drag and CG estimation at higher supersonic speeds (>1.5M) are currently poor

• Support for additional components, such as external pods and tube fins
  • Estimation of CG, CNa and drag coefficient are required

• Roll rate estimation is off by about a factor of two for unknown reasons (see sections 3.3 and 6.3 of the technical documentation)

• Aerodynamic force computation using CFD (computational fluid dynamics)
  • Should preferably use some standard package such as Elmer or OpenFOAM
  • Communication either using JNI or stdin/stdout to a standalone executable
  • Implementation requires at least:
    • creation of the simulation mesh
    • calling the computational method
    • deducing the forces and moments (preferably being able to separate the contribution of different components)
    • cacheing and interpolating data for efficient simulation
  • Visualization would be a great plus!
• Should implement warning when the descent velocity is too high
• Support parachutes with holes, x-form parachutes
• Custom shaped nose cones - perhaps the aerodynamics could be estimated by approximating the shape with a series of transitions.

• Aerodynamic forces and moments coefficients and derivatives should be computed using Missile DATCOM instead of CFD. CFD is not very accurate, and requires very advanced inputs to be accurate.
  • Not sure what the availability of Missile DATCOM is, but it may make this an ITAR controlled software.
• Combined with a batchmode analysis for trajectory dispersion analysis, as well as further support for wind profiles to be entered as a function of altitude and direction, and optimization of launcher azimuth and elevation, this software will be a powerful tool for the design, optimization, and performance, stability, and trajectory analysis of suborbital sounding rockets.

Dispersion Analysis

Dispersion analysis answers the question, where will the rocket land.

• Summary:

Dispersion analysis permits several input parameters to the standard OpenRocket flight model to be treated as random variables instead of scalars. A Monte Carlo wrapper is put around the OpenRocket simulation, numerous simulations are executed randomly changing the input parameters, and the results are tabulated. At the end of the Monte Carlo simulation, the landing point is estimated along with 1 sigma, 2 sigma, and 3 sigma confidence bands around this answer. Flight trajectories including maximum altitude are determined as well.

• Design of the model:

Since December 2008, in the US, dispersion analysis is required for all rocket flights whose total impulse exceeds 40,960 N-sec. The documentation requirements are greater than non-Class 3 rockets, and the FAA will verify the results of a dispersion analysis using their own models. The initial release of an OpenRocket dispersion analysis tool should use inputs as close as possible to the inputs used by the FAA internal tools.

Even in places outside US FAA jurisdiction, analyzing where a large rocket will land is good practice. Following FAA established procedures is sensible first approach.

• Inputs to the model:

The only commercially available program (I know about) which provides dispersion analysis accepted by the FAA identifies 19 variable parameters. These parameters could be specified as an expected value plus a variance or standard deviation around this value.

• • Mass Of The Rocket
  • Moment Of Inertia
  • Product of Inertia
  • Center Of Gravity Location
  • Axial Force Coefficient
  • Normal Force Coefficient
  • Center of Pressure Location
  • Fin Cant Angle
  • Total Impulse Of The Motor
  • Propellant Mass
  • Thrust Axis
  • Wind Direction
  • Wind Velocity
  • Launch Rail Azimuth Angle
  • Launch Rail Elevation Angle
  • Ignition Failure Likelihood
  • CATO Of The Rocket Motor Likelihood
  • Deployment Failure Likelihood
  • Chute Failure Likelihood

Many of these numbers are difficult to quantify without access to significant research facilities, but reasonable defaults are known and accepted. OpenRocket should permit any/all/none of these values to default.

Future enhancements could include adding additional variables, and enhancing the input to resemble the Rocket Optimization screen.

• Output of the model:

OpenRocket should output a predicted landing zone, with circles at the 1 sigma, 2 sigma, and 3 sigma confidence bands. A flight trajectory should output as well. Initially the landing zone could be a set of GPS coordinates, or coordinates relative to the launch site in feet or meters.

Future enhancements could include enhanced graphics and possibly overlay the simulation results with Google Maps or similar.