Difference between revisions of "Feature wishlist"

From OpenRocket wiki
Jump to navigation Jump to search
(content)
Line 1: Line 1:
 +
{{Access}}
 +
 
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 [https://lists.sourceforge.net/lists/listinfo/openrocket-devel OpenRocket-devel mailing list] and we can help you get started.
 
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 [https://lists.sourceforge.net/lists/listinfo/openrocket-devel OpenRocket-devel mailing list] and we can help you get started.
  
This page complements the [http://openrocket.svn.sourceforge.net/viewvc/openrocket/trunk/TODO distribution TODO file], which contains more ideas in a shorter form.
+
This page complements the [http://openrocket.svn.sourceforge.net/viewvc/openrocket/trunk/TODO distribution TODO file], which contains more ideas in a shorter form.  Please feel free to comment on the issues.
  
  

Revision as of 20:42, 26 March 2010


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.


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)
  • Re-arranging components, simulations, motor configurations using drag-and-drop


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!)

  • should probably use Java3D (seems to be the de-facto standard)
  • 3D view as an alternative to the side and back rocket view
    • rotation using the mouse drag-and-drop
    • possibility to make the outer components translucent
  • An animation of a simulated flight
    • general overview of flight (with possibility to magnify the rocket)?
    • a near-by view of the rocket during flight, with x-, y-, z-axis visible
      • 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?)


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!