How to add Motors to Open Rocket Free Software

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
TA,

OpenRocket only supports RockSim (RSE) and RASP format files. Try downloading a different format file, or you'll have to hand massage it to the correct format.

Kevin
 
Ya I did that, it did not work. I put it in the thrust curve file too and I still get nothing.

TA
 
Hey CarVac,

These are great ideas. I think you'll be surprised that a couple of them will be in the next release. We have extended the "motor configuration" concept to "flight configuration". You can configure for each flight: motors, motor ignition, stage separation, and recovery deployment. All of these (except) motors can have a default defined on the rocket component itself (in the edit window), but you can override the default per configuration. We have added a copy operation which allows you to copy one configuration to a new one - with the expectation that you will modify some parameters in the new one.

There had been some discussion of making the environmental and launch condition defaults stored in preferences and used to populate the dialog; though that hasn't been implemented and doesn't really sound like what you would want. However, it would make automatically adding a simulation for each configuration much easier.

For 4, what are you considering part of the "rocket configuration"?

Kevin



UI's are extremely difficult.
My idea of a good UI for this:

1. Shared launch conditions between all simulations. Temperature, altitude, launch rod length, etc., would be selected at the top of the window. Overrides (via a dialogue box as is currently done) would be possible for individual simulations.
2. Motor configurations would automatically create simulations: as you add the motor configuration the simulation appears on the list. I don't see any reason to have a motor configuration that is not simulated, and it's irritating to have to add it in two places.
3. If you want to do override parameters, you would be able to duplicate the simulation/motor configuration and then override the parameters.

4. I want multiple rocket configurations. You should be able to initialize a second configuration, which would start out identical to the previously-selected configuration. You could change which one is active via drop-down box (possibly where the current motor configurations are located) (and this would be selectable in the simulation tab on a simulation-by-simulation basis). When editing a feature of the rocket, there would be two 'apply' boxes: one to apply to all (or some) configurations, and one to only the current configuration.

This would be implemented by adding a two tags to each part in the file structure: an ID and a configuration tag. If the configuration tag is 0, it applies to all configurations. If it's non-zero, then it applies to that configuration only. When parsing the file tree, it would pick out only parts labeled either 0 or the current configuration, and ignore anything else. Obviously if there is something shared by all but one configuration, the part with the non-zero configuration tag gets priority.

For saving: If you make a part vary between configurations, then it would have two identical ID tags and differing configuration tags. To apply a change to all configurations (or selected ones), it just deletes any other items with the same ID tag (except those with un-selected configuration tags) and sets the new one's configuration tag to 0 so it'll be accessed by all configurations.

5. When you add a motor configuration, the simulation that would be created should be set to the current rocket configuration.
 
Hey CarVac,

These are great ideas. I think you'll be surprised that a couple of them will be in the next release. We have extended the "motor configuration" concept to "flight configuration". You can configure for each flight: motors, motor ignition, stage separation, and recovery deployment. All of these (except) motors can have a default defined on the rocket component itself (in the edit window), but you can override the default per configuration. We have added a copy operation which allows you to copy one configuration to a new one - with the expectation that you will modify some parameters in the new one.

There had been some discussion of making the environmental and launch condition defaults stored in preferences and used to populate the dialog; though that hasn't been implemented and doesn't really sound like what you would want. However, it would make automatically adding a simulation for each configuration much easier.

For 4, what are you considering part of the "rocket configuration"?

Kevin

Regarding "rocket configuration" I am imagining that anything in the design tree could have multiple versions that differ between 'configurations'.

In my school club we sometimes share components, so av-bays and nosecones get swapped, for example. One person needed a heavier nosecone on his Madcow DX3 in order to be stable on an I, so he swapped it for another member's fiberglass one for that flight. Had it been simmed in OpenRocket (we just had a RASAero file for that one), we would have had to make another file just for that one flight.

Disappearing Act, before its unfortunate demise, could have easily flown on a longer J motor rather than the I's it was built for by adding a spacer tube between the main body tube and the fincan. I have 8 different different .ork files: the original, 5 different ones with spacers, another one with a different fin can, and one more with a tailcone. When I made modifications to one, I had to modify them all and that was a pain. If all configurations share the same part, changing nosecone shape in one configuration, for example, would change all of them. If I polished the final fincan, I could change its surface finish in all of the configurations that shared it.



EDIT: Regarding the launch conditions, I don't think those should be put in menus. Weather conditions change on a day-by-day basis. If it's 15 mph out, I want to run all of my sims at 15 mph. If it's 95 F, I want all of my sims at 95 F. If It's 20 F, I want them all at 20 F. I don't necessarily want new simulations to share default values, but rather I want all simulations to share certain values. Sometimes. (not when comparing the same flight with multiple conditions)

Part of this comes from the fact that I actually bring my laptop out to launches and run sims on the day of, unlike (it seems) most rocketeers. But it would still be helpful to those who do not; you look at the weather and say "oh it's going to be cold tomorrow" and set all of the sims, in one click, to the predicted temperature.
 
Last edited:
Forgot about the .eng file not being supported, so yes that could be a problem.
 
Hi,

There's a fine line between being flexible and being complicated as hell. OpenRocket tries to tread this line as being flexible enough for advanced users while still being relatively simple to use for beginners as well. (Whether it succeeds here is a matter of debate.)

I fear that allowing any parameter to be configurable would make the UI very complex and/or confusing, and also would complicate the internal computations significantly. That said, the new flight configurations contains the framework to allow almost any parameter to be made overrideable. One prime candidate would be the mass object mass. This way you could simulate different payload masses with a single design. Another might be, as you said, a motor spacer length (though I think this would warrant a separate Motor spacer component type). Even these changes may have implications on the internals though, and might not be very easy to implement.

One idea for allowing variable configurations I've been toying around with is to have a "selector" meta-component, which selects which of a set of sub-structures is present in the rocket at a given time. For example, you might have configuration A with a drogue+main parachute, and configuration B with a single mid-sized parachute, or you could switch between different payloads. This needs to be thought through first and the impact on the internals assessed. For example traversing the rocket design becomes more complex, because you need to know the current configuration in every code location.


You have a fair point on the simulations. The whole point of having many simulations is to be able to vary the conditions (windy/calm, hot/cold, etc), but there is also the use case for having all simulations contain the same settings but different motor configurations. Do you think it would be sufficient to have a button which copies the current simulation settings to all simulations? Would it need to be separate for Wind/Atmosphere/Launch site/Launch rod, or a single button for all options?


Regarding adding the motor definition: .eng is the typical extension for a RASP thrust curve, and thus should be supported. Try opening the .eng file with Notepad to check if it looks sane. If you're interested in debugging the issue, you can check the debug log (Help -> Debug log), there should be a line indicating loading the files (look for "Loading motors from ...") and a possible error message.


Cheers,
Sampo N.
 
Last edited:
Back
Top