OpenRocket 14.03 released

[K'Tesh]

I run my simulation and then look at the "time to apogee" then adjust my delay accordingly. Does anyone know a way of attaching external boosters? Or how about pods on the fin tips?

Pods on the fin tips? Sure my workaround is to create a body tube that is the Diameter of the tip of the fins. That body tube is .000001" thick, and .000001" long. To that, I attach launch lugs in the right places, with the correct diameter of the pod. Now If I could only figure out how to put a nose/tail cone on it. I might make the Launch lugs solid, but adjust the weight to reflect the actual values.

 

[Rex R]

well kev, if you should happen to get to Bong this summer...say for ECOF or LDRSXXXIII... played with the photo bit and more or less figured out how to get a skidmark motor effect...looks a little strange when you know its' a 13mm motor.
Rex

 

[bill2654]

Pods on the fin tips? Sure my workaround is to create a body tube that is the Diameter of the tip of the fins. That body tube is .000001" thick, and .000001" long. To that, I attach launch lugs in the right places, with the correct diameter of the pod. Now If I could only figure out how to put a nose/tail cone on it. I might make the Launch lugs solid, but adjust the weight to reflect the actual values.

Here is what I meant about fin pods and external boosters.

 

[DAllen]

Just when I think an open source program can't get any better this version of OR comes out...


Sent from my iPhone using TopRamens Rocketry Forum App

 

[Winston]

Just wondering, can't you do a line in the code that says something along the lines of "if -20<v_deployment<20mph, display green flag, if v_deployment<-20mph, display down arrow, if v_deployment>20mph, display up arrow".

I'd rather be the one determining what maximum is acceptable. A "deployment velocity" figure with an up or down arrow next to it would be preferable to me. I know it's already easy to see the direction at deployment by generating a graph, but an arrow would eliminate the need to do that.

 

[K'Tesh]

Here is what I meant about fin pods and external boosters.
View attachment 166379
View attachment 166381

And this is what I meant about work around...

 

[Derek]

K'Tesh,

That rocket looks to be a lot more stable than or leads you to believe. Is it stable?

Cool looking rocket. Nice work!

 

[K'Tesh]

K'Tesh,

That rocket looks to be a lot more stable than or leads you to believe. Is it stable?

Cool looking rocket. Nice work!

Thanks Derek!

Glad you like it... I have no idea if it is as stable (or not)... It's an Estes Sizzler (1906) simulation that I threw a phantom body tube (0.00001" length, 0.00001" thickness, 4.85" diameter), some extra fins, and launch lugs on (then adjusted for effect) just to show how my workaround "works".

 

[Zebedee]

K'Tesh,

That rocket looks to be a lot more stable than or leads you to believe. Is it stable?

Cool looking rocket. Nice work!

Looks like it's using the width all the way out to the pods to calc the calibers of stability judging by the distance between the CP and CG.

 

[Rex R]

just playing with smoke etc., big daddy.
Rex

 

[accooper]

OK, I know I'm the dullest knife in the drawer, but one of you needs to explain to me how you do those tubes. Explain it like I was a child. hey, I'm from Texas, we are a little slow. Except John Lee and Jeff.

Andrew

 

[K'Tesh]

OK, I know I'm the dullest knife in the drawer, but one of you needs to explain to me how you do those tubes. Explain it like I was a child. hey, I'm from Texas, we are a little slow. Except John Lee and Jeff.

Andrew

They're oversized launch lugs... The ones on the tips of the fins are actually launch lugs attached to the phantom body tube. I just alter the dimensions of them to match a body tube

 

[Leo]

Man, do I love the software!!

Here my workhorse. The Estes Mongoose used as dual deploy recovery:

 

[JMZawodny]

I'm not particularly worried about the computation time - I'm more worried about my time I totally understand the requirements and the need. As far as features go, I think the "automagic motor finder" would be much more useful to a lot of people.

Kevin

I doubt I would ever use an "automagic motor finder". I typically run sims for all of the motors from a particular set of vendors (e.g., all CTI 38mm motors). When I want to fly I look at the list, compare it to those motors I own and pick one. If it is a single deploy flight, I'll look at the optimal delay and trim the delay as needed. Having said that, I am grateful for any and all effort you put into OpenRocket. If I had the time (sound familiar?) I'd be willing to look over the code and work up a solution.

 

[JMZawodny]

You're welcome. I'm also a rocket builder & flier and have a lot of projects going on including a *BIG* project which I haven't talked about yet. Unfortunately for the greater rocket world the big project had consumed a lot of my hobby time.

One thing to keep in mind, the squeaky wheel does get the feature. Just ask CarVac!

As it is, this "time for optimal delay" need is fully understood. It would be ideal if it could be used for HPR delay-drilling too. I'm thinking about it more and Sampo's approach seems pretty clean. My preference would be to have a column which tells you how short/long your delay is from optimal - Say "-5s" means 5 seconds too short, and "3" means 3 seconds too long. This is a pretty easy concept to wrap my head around and I don't think there are a lot of edge cases - so it's certainly doable. If I get motivated during the march madness, I might take a stab at this before the motor finder.

Kevin

I think most fliers understand what the optimal delay is and probably do not need the simple subtraction math done for them. As for an implementation, sim the flight until apo or the requested delay is achieved, which ever is later. Note the optimal delay time. Then jump back to the point in the flight for requested delay, if applicable, and continue on with the sim.

 

[Sampo]

Hi,

Pods on the fin tips? Sure my workaround is to create a body tube that is the Diameter of the tip of the fins. That body tube is .000001" thick, and .000001" long. To that, I attach launch lugs in the right places, with the correct diameter of the pod. Now If I could only figure out how to put a nose/tail cone on it. I might make the Launch lugs solid, but adjust the weight to reflect the actual values.

Unfortunately that will simulate as if you had a thin plate the diameter of the phantom body tube attached at the bottom of your rocket. Air does not flow through body tubes, even though you can see through them in the 3D view. The simulation methods assume that all body tubes are capped.

I think most fliers understand what the optimal delay is and probably do not need the simple subtraction math done for them.

I agree. I think it's natural that optimum delay indicates which delay you should choose. You can also set the deployment to be at apogee or some time after it, which would make such a substitution meaningless, while the optimum delay is still relevant.

Cheers,
Sampo N.

 

[Winston]

I doubt I would ever use an "automagic motor finder".

Same here.

If it is a single deploy flight, I'll look at the optimal delay and trim the delay as needed.

All that I want would be, I think, simple to include - an up or down arrow as appropriate in the "Velocity at Deployment" column to indicate pre or post-apogee deployment and a column that shows the result of the subtraction of the chosen motor's burn time from the "Time to Apogee" result using that motor, the resulting figure being the optimal delay time. The "Time to Apogee" would be the time to the end of coasting assuming no pre-apogee deployment.

Having said that, I am grateful for any and all effort you put into OpenRocket.

I definitely second that.

 

[bdureau]

That photo studio thing is just great

 

[FastCargo]

Yep, definitely digging the new OR version!



FC

 

[Right Wing Wacko]

My desire is to have a place to add extra weight ahead of the motor on various simulations.

Many of us don't own every possible motor casing, and in the case if CTI you can get by owning just the 3 Grain and 6 Grain casing and fly just about every motor they make (except the 6XL's). However this results in the extra weight from the larger casing as well as the spacer(s).

Yes, I know I can add my own extra weight, but I need it to be able to vary based on the motor configuration.

 

[matthew]

That is actually a nice segue into my wish item - de/selectable items. We put a lot of time and effort into building our simulated rockets. It becomes a pain to try different parts. Say, what if I tried a different nosecone, or a different fin shape? Or as RWW suggests, different motor case length, or even motor adaptors. Maybe something like creating a "parts group" that allows a radio button style part selection: Fin set A, Fin set B, Fin set C, None. And so on.

And on the subject of selectable, how about on the printout if you could select only a couple of the motors you have simulated instead of it default printing them all? That way I don't have to print reams of paper to get the data I want to take to the range with me. Also, it would be nice if the page break was set between motors. As it stands, using A4, I get the motor name at the bottom of a page, and the rest of the data on the next page (and so on for as many pages as it takes).

Like everyone else, I am hugely appeciative of the work you guys do to deliver such a fantastic application.

 

[Leo]

That is actually a nice segue into my wish item - de/selectable items. We put a lot of time and effort into building our simulated rockets. It becomes a pain to try different parts. Say, what if I tried a different nosecone, or a different fin shape? Or as RWW suggests, different motor case length, or even motor adaptors. Maybe something like creating a "parts group" that allows a radio button style part selection: Fin set A, Fin set B, Fin set C, None. And so on.
...

I have several versions of the same rocket but different add-ons and every time I make a change to the rocket I have to change all the files. At times it's quit a hassle.

I've asked for this feature last year but it seems more difficult to implement than we realise.

Anyhow, I just love this software

 

[ChrisAttebery]

Leo,

How did you make the graphics for the Mongoose? I haven't tried making a skin for any of my rockets yet.

Man, do I love the software!!

Here my workhorse...

 

[Swissyhawk]

There was a post in the OpenRocket 13.04 release thread regarding the fins not following the tail cone.

https://www.rocketryforum.com/showthread.php?53254-OpenRocket-13-04-public-beta&p=524114#post524114

I was wondering if this limitation will be addressed? I'm modeling a LOC R2 (slightly extended V2). I used the fin tabs to generate "fins" outside of the tailcone. I think it looks great, but I don't think the external tabs get accounted for in the CP calculations. This might be hard to get an RSO to sign off on.

 

[CarVac]

There was a post in the OpenRocket 13.04 release thread regarding the fins not following the tail cone.

https://www.rocketryforum.com/showthread.php?53254-OpenRocket-13-04-public-beta&p=524114#post524114

I was wondering if this limitation will be addressed? I'm modeling a LOC R2 (slightly extended V2). I used the fin tabs to generate "fins" outside of the tailcone. I think it looks great, but I don't think the external tabs get accounted for in the CP calculations. This might be hard to get an RSO to sign off on.


View attachment 167329

It looks fine but it's actually more conservative than including the extra fin area. The rocket is more stable than indicated.

 

[bkuker]

Carlo,

I tried to do this initially, unfortunately all velocities are referenced to the rocket's direction so they are always positive. I suppose one could project the rocket velocity vector on unit-z, but what if the rocket is travelling horizontally? It could still be deploying at a very large velocity but the z component of that velocity is 0.

Kevin

How about saying something like "Deployment at 20m/s at apogee +5s" or "Deployment at 50m/s at apogee -5s"

 

[1tree]

Ok, so I haven't used the software a whole lot, but as a developer my first thought on finding the optimum delay would be to use the data already there to give an approximation.

I am making the assumption that you have a series of speed and acceleration data. From this one should be able to approximate what the optimum delay would be. Or if the rocket is accelerating, cheat and use apogee time.

This would of course only be approximate information based on a smooth acceleration/speed curve.


Sent from my iPhone using Rocketry Forum

 

[rocketgeek101]

Quick Question: is there a way to add your own "environment" to the Photo studio?

 

[Rex R]

I've asked, short answer is not yet. I got curious and peeked into the jar file...in theory one could do manually, be a bit of a pain though. I'll wait till it gets automated .
Rex

 

[bdureau]

Quick Question: is there a way to add your own "environment" to the Photo studio?

yes open the OpenRocket.jar with something like winrar and replace the pictures
It is dead easy, no need to be a developper