ANNOUNCEMENT: OpenRocket 23.09 is now available for download

[the random rocketer]

Happy dance time!! Downloading the .jar file does it. It opens and runs and on a pi 5 It's even snappy. I haven't had time to explore yet as I've got something else to do but will try it out fully later and report back. Install the Java runtime environment as per the instructions on the raspberry tips site. Then download the jar file from open rockets site. Run it with java -jar OpenRocket-23.09.jar

And I'm half through an upscale Estes Bandit to 2.5 inch PS 2 size.

 

[DaveRKP]

A small break

After that, something we've been talking about for a looong time is improving design warnings to users. We're also gonna improve/modernize the project structure and documentation, hoping that can attract new developers.

Sibo, Grand kudos to your and the other individuals delivering v23.09. I'm still new to my way around the upgraded app, but do have a question on design warnings. Where would one find documentation on warning messages and guidance on how to resolve them? In a current design, I have numerous "Thick fins may not simulate accurately' and warnings on the phantom body tubes for pods: "Forward end of airframe is open (radius is > 0)".

I've wandered through the wiki, tried searches both on the web and on TRF, but still struggling to find a reference. Would welcome references from anyone on this thread.

Thanks!

 

[neil_w]

It doesn’t exist right now. It’s been in my todo list to write a tutorial about this. I suppose I should get to it.

It would also be good if the program had some explanations built-in, but in the short term an external reference is more likely.

 

[neil_w]

Oh, I suppose I could, you know, answer your *real* question.

In general, design warnings indicate aspects of the design that break the assumptions OR is making when it calculates drag and CP etc. So there will be some inaccuracy. Sometimes the inaccuracy if very small and you can ignore it. Knowing which warnings to ignore and which to heed is a bit of an art.

The "thick fins" warning comes from fins that are very thick compared to... um, I don't actually know the criteria. Usually you know them when you see them.

The "Open forward end" warning is from a body tube with non-zero diameter that doesn't have a closed front (usually a nose cone). The open front end of a body tube is not something that OR knows how to simulate. If it's a phantom tube that is zero-length but non-zero diameter, you can usually ensure it'll be OK by simply overriding the Cd to zero. Actually you can usually avoid this situation with judicious use of pods.

If you post the design I can give more specific explanations.

 

[OzHybrid]

Oh, I suppose I could, you know, answer your *real* question.

In general, design warnings indicate aspects of the design that break the assumptions OR is making when it calculates drag and CP etc. So there will be some inaccuracy. Sometimes the inaccuracy if very small and you can ignore it. Knowing which warnings to ignore and which to heed is a bit of an art.

The "thick fins" warning comes from fins that are very thick compared to... um, I don't actually know the criteria. Usually you know them when you see them.

The "Open forward end" warning is from a body tube with non-zero diameter that doesn't have a closed front (usually a nose cone). The open front end of a body tube is not something that OR knows how to simulate. If it's a phantom tube that is zero-length but non-zero diameter, you can usually ensure it'll be OK by simply overriding the Cd to zero. Actually you can usually avoid this situation with judicious use of pods.

If you post the design I can give more specific explanations.

Found that out when I tried to create a camera shroud as a thick short fin. Didn't like it.
Is a camera shroud doable? Would it simulate drag in one place and any weight offset/ drag causing an arc in the flight?
eg https://www.additiveaerospace.com/products/mobius-shroud

 

[neil_w]

I would just use the thick fin. It'll still simulate, probably, not too far off accurate.

I don't believe the OR currently models off-center drag.

 

[JoePfeiffer]

I don't believe the OR currently models off-center drag.

And the off-center drag from a camera shroud makes surprisingly little difference in actual flight (at least I was surprised the first time I did it!).

 

[DaveRKP]

Oh, I suppose I could, you know, answer your *real* question.

In general, design warnings indicate aspects of the design that break the assumptions OR is making when it calculates drag and CP etc. So there will be some inaccuracy. Sometimes the inaccuracy if very small and you can ignore it. Knowing which warnings to ignore and which to heed is a bit of an art.

The "thick fins" warning comes from fins that are very thick compared to... um, I don't actually know the criteria. Usually you know them when you see them.

The "Open forward end" warning is from a body tube with non-zero diameter that doesn't have a closed front (usually a nose cone). The open front end of a body tube is not something that OR knows how to simulate. If it's a phantom tube that is zero-length but non-zero diameter, you can usually ensure it'll be OK by simply overriding the Cd to zero. Actually you can usually avoid this situation with judicious use of pods.

If you post the design I can give more specific explanations.

Thanks for the response. Attached is the design - a 3x Orbital Transport upscale, based on some previous work by Stephen Heilman.

Lot's of 1/8" 'thick' fins, enclosures, etc. and lots and lots of pods. As I'm still a noob to OR, I expect that I may not be setting up the pods correctly / consistently, hence the errors in that regard. I'm still in the process of adding all the components and was planning that, once I entered everything in the design, I was going to 'circle' back through to address warnings, check materials, finish, etc.

So in addition to the two warnings previously noted ( that are the bulk of the list ), I did note that there is also 'Discontinuity in rocket body diameter' - which I assume will be easy to resolve as well as a 'Too many parallel fins' - which I may need to live with...

Appreciate any guidance that can be provided!

 

[Sandy H.]

It doesn’t exist right now. It’s been in my todo list to write a tutorial about this. I suppose I should get to it.

It would also be good if the program had some explanations built-in, but in the short term an external reference is more likely.

Just a comment/thought.

My previous employer had a phenomenal control system, but terrible error codes - honestly sometimes they were just wrong (i.e. someone hits an e-stop and the error would say oil temp is high. . . ). Our sister company had a sub-optimal performing control system, but insanely great documentation on error codes built into the software (i.e. Oil temperature is high. Ensure water inlet temperature is less than 90 deg and outlet temperature is not greater than 120 deg. Verify recirc flow. Verify oil level. etc.).

Customers loved their system from a user standpoint, not from a performance standpoint. They won, we didn't.

If you're going to do the work to create a guide/tutorial, it might be worth doing it in such a way that its easier to implement directly in the software at some point. By that, I am thinking create a database of the options and use HTML/CSS to produce the written document vs. just writing it in MSWord and then someday trying to implement it into the software by recreating the work you already did.

Again, just a comment/opinion. I'm not a real software guy at all, but when I see something implemented well, I try to think about the what's and why's. Anytime you can prevent double work, especially on a passion project vs. a paid gig, that seems helpful.

Thanks for all the work you do on OR.

Sandy.