bibbster
Well-Known Member
Wrong thread.
ANNOUNCEMENT: The OpenRocket 22.02 Beta Period is now finished
- Thread starter neil_w
- Start date
Help Support The Rocketry Forum:
I was playing at lunch, and have a question. The question is on the SIMs for a comparison of a 3 motor cluster where all 3 motors light, and the same with the ignition of one outboard motor set to never. This gives a flight with 2of3 motors working. It does give the correct lift-off weight, landing weight, etc. and seems to give answers that could be correct. Just wondering if anyone has looked into this as believable or not. The 2 images below are the configuration 2nd row has 1 motor ignition set to never, and the main simulation page. Note ~2/3 of altitude, acceleration, etc. and higher landing velocity... is the OFF-AXIS thrust taken into account at all by OpenRocket?
This is the graphs for a "normal" flight.
This is the graphs for a "non-normal" flight with only 2 motors.
It's "odd" that at 2/3 of altitude the horizontal travel at apogee is approximately the same (200ft into 5mph wind). It makes sense to me that there will be more horizontal travel per unit of vertical travel with the off-axes thrust, but I would think it would be even more than this.
I did switch which of the POD motos didn't light, and the horizontal distance was a little more with the windward side not lit, than when the leeward side was not lit.
Thanks to helping me think thru this...
Mike
This is the graphs for a "normal" flight.
This is the graphs for a "non-normal" flight with only 2 motors.
It's "odd" that at 2/3 of altitude the horizontal travel at apogee is approximately the same (200ft into 5mph wind). It makes sense to me that there will be more horizontal travel per unit of vertical travel with the off-axes thrust, but I would think it would be even more than this.
I did switch which of the POD motos didn't light, and the horizontal distance was a little more with the windward side not lit, than when the leeward side was not lit.
Thanks to helping me think thru this...
Mike
No, OR doesn't take off-axis thrust into account. I'm a little surprised that which motor you shut off made a difference in your results.
Last edited:
Joe, Thanks for the confirmation: I figured the speed off rail and descent velocity were good, time to apogee may be "kind of" close.
I expected the flight side profile, and stability, to be off, but when it was changing based on which engines I set to never ignite, it made me start wondering.
I expected the flight side profile, and stability, to be off, but when it was changing based on which engines I set to never ignite, it made me start wondering.
Not sure if this is the correct thread to report this...
Seems to be what I *think* is a data error. (could be computational, but I doubt it)
Had a rocket come down this weekend on a very late ejection delay. Looking at the sim using an AT 24/40 F39W, it shows a time to apogee as 7.92s and optimum delay of 7.86s. So all I had was a 9 second delay, flew with that. Hey, only a second too long. But it came in scary fast before chute ejected. Altimeter showed time to apogee was 7.3s, as it didn't quite reach projected altitude. To make matters worse, it appears I got a bit of "bonus delay" of nearly 2 seconds. But of course there is nothing the sim could do to forecast that.
Looking at other motor sims for the same rocket, the optimum delay that is calculated for nearly all the rest is very close to (Time to apogee) - (Burn time). Which seems reasonable. But for the F39W, that would give a delay of 6.67s, not the 7.86s shown on the printout.
If it is a data error, you might also look at the AT 29/40-120 F22J. Shows time to apogee 8.94s, burn time 3.14s, optimum delay 7.31s. If you subtract the burn from the time to apogee, you get 5.8s.
Hans.
Seems to be what I *think* is a data error. (could be computational, but I doubt it)
Had a rocket come down this weekend on a very late ejection delay. Looking at the sim using an AT 24/40 F39W, it shows a time to apogee as 7.92s and optimum delay of 7.86s. So all I had was a 9 second delay, flew with that. Hey, only a second too long. But it came in scary fast before chute ejected. Altimeter showed time to apogee was 7.3s, as it didn't quite reach projected altitude. To make matters worse, it appears I got a bit of "bonus delay" of nearly 2 seconds. But of course there is nothing the sim could do to forecast that.
Looking at other motor sims for the same rocket, the optimum delay that is calculated for nearly all the rest is very close to (Time to apogee) - (Burn time). Which seems reasonable. But for the F39W, that would give a delay of 6.67s, not the 7.86s shown on the printout.
If it is a data error, you might also look at the AT 29/40-120 F22J. Shows time to apogee 8.94s, burn time 3.14s, optimum delay 7.31s. If you subtract the burn from the time to apogee, you get 5.8s.
Hans.
The optimum delay is the time to apogee minus the burn time, so this doesn't sound right. Please post your .ork file so we can take a look at it (I may not be able to look until next week, but the other team members should be around in the mean time).
- Joined
- Aug 6, 2022
- Messages
- 3,194
- Reaction score
- 2,881
I would love it if there was a way to export the simulation results summary table as a .csv. I tend to try out a lot of motors, and it would be nice to be able to save that table and play with it in Excel. For example, indicating the short list of particularly good matches, highlighting bad ones, adding comments, etc.
I could just delete the bad ones, but then my little terrier brain will want to go back and try them again, which wastes time. I leave them in the file to keep a log of what I've tried that didn't look good, but I'd also like to be able to produce a compact list of just the good ones.
I could just delete the bad ones, but then my little terrier brain will want to go back and try them again, which wastes time. I leave them in the file to keep a log of what I've tried that didn't look good, but I'd also like to be able to produce a compact list of just the good ones.
Charles_McG
Ciderwright
It would also be a way to compare design changes- at least externally.
I’ve already submitted this, as well as the option to pick more column, as a feature request.
I’ve already submitted this, as well as the option to pick more column, as a feature request.
- Joined
- Jun 4, 2018
- Messages
- 1,287
- Reaction score
- 924
Submit a pull request!
Charles_McG
Ciderwright
So over this thread, I was working out to tune the sim for drogueless descent : https://www.rocketryforum.com/threads/simming-descent-rate-in-openrocket.174961/#post-2324917
Got some pointers, and now have it worked out.
I'm wondering how hard it would be to implement an option to 'release' (disable/not count) one chute when a later one is deployed. I'm thinking a checkbox in the design window. Maybe fancier recovery configuration options.
Got some pointers, and now have it worked out.
I'm wondering how hard it would be to implement an option to 'release' (disable/not count) one chute when a later one is deployed. I'm thinking a checkbox in the design window. Maybe fancier recovery configuration options.
It shouldn't be too hard... I'd generally like he some fancier options -- being able to separate the payload section will be another.
I can't replicate the issue....
My computer crashed sometime after printing out the sims for the Aerotech Cheetah. Upon reopening OR, it seems I didn't save the Cheetah file after loading a few motors to sim. So I added them back in. It now looks like the delays are more reasonable. The 24/40 F39W still looks slightly off, but it's much closer now.
What might have happened is that I could have done the sims with 22.02. Beta 2. I have the printouts, nothing that I now do to the Cheetah file agrees with those printouts. The file itself was ported from AT's published RocSim file and not modified except for a 0.7 oz adjustment to the mass. Weird.
Hans.
Where should I go with a feature request? The ability to optimize for delay time would be useful for a few things I’m thinking about.
- Joined
- Jun 4, 2018
- Messages
- 1,287
- Reaction score
- 924
Figure it out and submit a pull request
OpenRocket already provides the optimal delay for a specific flight configuration on the Flight simulations tab.
What are you thinking of where you would optimize specifically for delay time?
What are you thinking of where you would optimize specifically for delay time?
I've known several people to build a rocket just to get rid of a surplus of a particular motor of a particular delay.
Basically.
Thank you.
ANNOUNCEMENT: OpenRocket version 22.02 Public Beta 5 is now available
Download: https://openrocket.info/downloads.html?vers=22.02.beta.05Financial contributions: https://opencollective.com/openrocket
Full release notes: https://openrocket.info/release_notes.html
Ongoing discussion and support: https://www.rocketryforum.com/threa...-is-now-available.171295/page-21#post-2327284
Reporting new issues: https://github.com/openrocket/openrocket/issues
Wiki User's Guide: http://wiki.openrocket.info/Main_Page
Please review the release notes and outstanding issues before opening a new issue that you discovered or experienced prior to the release of OpenRocket 22.02 beta 5.
Last edited:
The first few posts in this thread are now up-to-date with the latest and greatest info regarding Beta 5.
I wanted to repeat, in case gets lost in the shuffle, that the OpenRocket project is now accepting donations to fund our ongoing operations. For more details see https://openrocket.info/donate.html. Of course, donations are entirely voluntary, and OpenRocket remains free to use for everyone.
I wanted to repeat, in case gets lost in the shuffle, that the OpenRocket project is now accepting donations to fund our ongoing operations. For more details see https://openrocket.info/donate.html. Of course, donations are entirely voluntary, and OpenRocket remains free to use for everyone.
- Joined
- Jun 4, 2018
- Messages
- 1,287
- Reaction score
- 924
"Starting with the 2022 release, we will be distributing OR primarily as a packaged application for Windows, Mac, and Linux."
Gah...
Otherwise good idea.
Gah...
Otherwise good idea.
For use with Beta 5 and higher.
To assist those who wish to use the Estes motor hooks in their designs, a 13mm (mini) and 18mm (standard) motor mount file is attached. Although there is a pending issue for the creation of a freeform mass component to replace this freeform fin hack, until that is done users need to be aware that this hack negatively affects flight performance. In other words, OpenRocket will not correctly simulate the flight of a rocket using this outer component hack to simulate an inner component that is aerodynamically ignored, without adjusting the engine hook Cd.
As an adjustment to partially correct for the increase in Cd caused by the use of this hack, beginning with Beta 5, OpenRocket allows a negative value Cd override so that the user can match pre and post engine hook use performance by overriding the engine hook Cd with a negative value. However, because the Cd changes throughout a flight, this engine hook Cd override value is motor specific.
This is how to use one of the motor mount files. . . cut and paste the circled parts to the last outer airframe component (tube or transition) in your design; the fore diameter of the transition in the motor mount file should always be set to auto.
The proper use of these files will not trigger a discontinuity warning, but will trigger zero length and jagged edge warnings.
To assist those who wish to use the Estes motor hooks in their designs, a 13mm (mini) and 18mm (standard) motor mount file is attached. Although there is a pending issue for the creation of a freeform mass component to replace this freeform fin hack, until that is done users need to be aware that this hack negatively affects flight performance. In other words, OpenRocket will not correctly simulate the flight of a rocket using this outer component hack to simulate an inner component that is aerodynamically ignored, without adjusting the engine hook Cd.
As an adjustment to partially correct for the increase in Cd caused by the use of this hack, beginning with Beta 5, OpenRocket allows a negative value Cd override so that the user can match pre and post engine hook use performance by overriding the engine hook Cd with a negative value. However, because the Cd changes throughout a flight, this engine hook Cd override value is motor specific.
This is how to use one of the motor mount files. . . cut and paste the circled parts to the last outer airframe component (tube or transition) in your design; the fore diameter of the transition in the motor mount file should always be set to auto.
The proper use of these files will not trigger a discontinuity warning, but will trigger zero length and jagged edge warnings.
Last edited:
The .jar is still available. We don't foresee changing that.
I'll take a jar any time over an installer... THANK YOU!
What is required for it to run on ARM, my Raspberry Pi?
If you have Java 11 installed on your Raspberry Pi, then I think you can run the JAR file. 3D stuff will be non-functional, though (right now it’s x86-specific).
Thanks. Tried it, things like the file open dialogue cause it to crash, etc. I didn't understand that OR needs native libs installed.
Same question for a new Mac using an M1 or M2 ("Apple silicon") processor. I don't have one of these, but after seeing how screamingly fast my wife's new M2 MacBook Air is, I may move replacing this 15 inch MacBook Pro up a bit in priority....
I will admit, however, that I haven't even started playing with OR 22.02 at all yet, so this question certainly doesn't need an answer in the near term. However, I did just download the Mac .dmg file for beta 5 and will play with it some in the next couple of days.
Thanks to all for huge amounts of work on this!!!
Last edited:
- Joined
- Mar 27, 2013
- Messages
- 22,535
- Reaction score
- 14,935
Little confused about the contribution vs backer thing... I would have selected backer but for the "fine print"
I was going to select a yearly contribution but the "same day each month" part confused me, and as much as I love OR, I can't afford to be contributing $600 per year ($50/month) towards it.
Similar threads
- Sticky
