Anybody given this a test run?
 

Open Source (meaning free) CAD software called OpenRocket written in Java so it is multi-platform. It was written for a fellow's Master's thesis. I probably won't be home long enough until the weekend to try it out, but it looks promising. Since it is open source, anyone with the ability to do so can tweak, revise, etc.

Read about it here. Download it and give a quick comparison to RocSim, Space Cad, WinRASP, etc. if you have the desire to do so. It's still in Beta, so there will be quirks and bugs, but judging from the comments, it's pretty nice...except for the one Mac user. :) I've always been a "TLAR" person, but it might be fun to play around with.

I started playing with it a couple of days ago. It didn't take me too long to come up with a design, yet unflown. I need to put rockets that have had altimeter flights to see how close it matches reality. It seems to be user friendly so far.

Greg

I just downloaded it and started playing with it. Thanks for the link!

First impressions...

• I'm not a Java fan...
• The design side of the program has some nice features, such as the fin editor.
• The side view is nice and clean. I think I like the layout of the text data within the view a little better.
• The program is obviously inspired by RockSim. The general arrangement of the screen elements is the same.
• I do like the illustrated buttons in the component selection section. :)
• There is not a database of pre-defined components, so each time you create a design, you have to feed the dimensions into the dialog for that component. :(
• The version I downloaded (0.9.3) has no motors defined, so you cannot run a simulation. :(
• I like the graphic simulation of components that RockSim only hints at with "(M)" symbols. The dashed rectangles provide a better visualization of where the component winds up inside the body tube.
• The saved rocket files have an interesting three-letter extension -- ork, for Open RocKet...

The program has a long way to go, but I think the developer is on a good path. If he would change the program from an interpreted language (Java) to a true compiled language, such as C++ or Free Pascal & Lazarus, the program would run faster; it would still be cross-portable to Mac, Linux, and Windows machines using a compiled language, it just requires multiple binaries. Not really an issue.

I'll keep an eye on it, for sure. :D

It is supposed to have motors from thrustcurve.org with it. Maybe he accidentally left it out of the .jar file.

Sounds like it might become a great little program. I hope he keeps improving on it and I also hope some folks take the source code and start tweaking. That's one cool thing about open source programs. :cool:

Craig,

I appreciate your input since I am not a RockSim user (yet).

Here is a screen shot of a design with the flight sim (some how mine had the motor data).

Greg

Greg,

I looked (again) at the sourceforge site, and it does indicate the motor files are supposed to be included. I'll dig into it deeper to see if I've missed anything in setting it up.

RockSim is still my choice at present, but a having a good "underdog" alternative would make things very interesting...

IIRC, I think to get the motor you had to specify on the tube that it had a motor, like a check box or something like it.

At least with OpenRocket, no one can argue that the price is right! :) For a free program it seems to do a lot. However, for more complex designs it would appear that RockSim is the way to go.

Greg

No Java that I know of interprets frequently executed and/or long running methods in a program. They are dynamically compiled at runtime. http://blogs.azulsystems.com/cliff/...ance-again.html has an interesting discussion of Java performance by Cliff Click, a smart guy and real Java compiler/performance expert.

Also, use the server VM for longer running apps, it provides significantly better performance that the standard VM, a point made in the above post and something I've observed in my own work.

Sam
Java bigot (but who still thinks computer engineers should learn to program in C.)

I like this thing. Rocsim is better, no question, But this is a wonderful tool in it's own right.
As for the motor, go to the editor and select the tube you have as a motor tube. click the tab labeled "Motor" and chk the box marked "This component is a motor mount". Now you can hit the "Select Motor" button and select your motor and delay. The major problem is that in order to change the motor you have to go back to the motor mount tube editor. Additionally, when you change the motor it futzes with the data from the first sim run. The sim data is good but it would be helpful if it showed wheather the deployment was pre or post apogee. I do like that there is an option for choosing the CP display. I wave mine set to Caliber. Stability at a glance, gotta love it. It would be nice to know by what means the CP is calculated. As this is a Beta version I can't complain at all! There is a link on the download site to report "Problems" or sugestions. I think in short order this will be a most indespensible tool.

Sam, that's just a fancy phrase for interpreted scripting. Java is 'pre-compiled' into an intermediate form. But it still means the computer is trying to digest pseudo-code at the instant the program is being run. Conversion from p-code into machine code is still interpretation in my book.

Java may be faster than a 'true' interpreted language, like the early BASICs found on many old machines, but nothing can beat the speed of good compiled code except pure machine code.



I'm a C and C++ zealot, so I do have a bias. :D

However, I am trying to comprehend Pascal, and I still have great respect for assembler code...

Java VMs actually have a compiler that is invoked at runtime on "hot" procedures to produce native, binary code. It is only done on hot procedures so as to maximize the benefits of doing a compile into native code while minimizing the overhead of compilation. Javac does compile Java source into bytecodes, which are, in most VMs initially interpreted (although IBM Research's Jikes/Jalapeno immediately did a fast translation to binary form) before being translated to native form. http://suif.stanford.edu/~jwhaley/p...avagrande99.pdf gives a good overview of the IBM Jikes/Jalapeno VM. (Just to confuse things, there is also a Jikes Java source to bytecode compiler that also originated at IBM Research.)

Python (from my understanding) follows the example you give of compiling into a faster-to-interpret bytecode form, and not going any further.

Sam

The "C" languages should have been outlawed from college classes before they even started. It is one of the most convoluted pieces of crap I have ever seen. And it compiles 10 times bigger files than any language I've ever used.

I wouldn't doubt that is half the problem with newer versions of Windows. Never occurred to Microsoft (when trying to create a new OS) to go back to assembly code...

I apologize for the thread drift, and unless I encounter a moment of weakness this will be my last post on the subject. Time is better spent building rockets than talking about programming languages. :D

C on a decent operating system has its place. As an instructional language, it offers the advantage and disadvantage of making students understand memory, addresses and pointers. As with everything real, there are trade-offs, and different compilers, linkers and OSes make different trade-offs and fill different needs.

C was developed to implement Unix. In "The Mythical Man Month", Fred Brooks explains how OS/360, at around 6 million lines of assembly code, almost killed IBM. I started at IBM Research in the fall of 1991 after their first "one-time" billion plus charge. Sometime during the next two years as IBM flirted with bankruptcy, Fran Allen (who was my second line manager) explained to me that things had been much worse during the OS/360 days. In contrast, XP had 45 million plus lines of code, and while it was late, no one talked about Microsoft going under. In my opinion, the difference between the two was the use of modern languages (largely C and C++) and development tools that enabled a more distributed development model.

Sam

Sam,

Don't apologize! This is the right forum for this kind of discussion, even if the thread started out about OpenRocket. (And I can say that, since I'm the moderator of this section... :D ) If it gets too technical (this is a software thread in a computer section of a rocketry forum, after all...) we can always bump it to a new thread. But for now, I'm comfortable with it. :)

I've enjoyed listening to your posts about the differences in Java (compared to what I remember from way back when it was the 'new kid on the block' in programming languages), and from your description, the language has changed a little over its life. Always something new to learn!

I'm thrilled to see OpenRocket, even though it has a long way to go (and a short time to get there...). While I love RockSim and appreciate the power and flexibility it offers me, even so it has a few minor issues that I don't think have been properly ironed out. We've mentioned some of those issues around here from time to time. This new package might build a fire to get some additional action on the software front, whether that is from Apogee or even someone else.

Thanks for comments. And competition is good - both in languages and rocket simulators!

Sam

I've started playing with this..... anyone have any better idea for modeling the weight of a finish than just overriding the weight of the BT, fins and nose cone by some amount?

I modeled the BMS School Rocket and am getting plausible results from the simulations, though the deployment timing vs. apogee seems to be just a little off compared to actual flights. Too bad there's no weightless altimeter I could put on my rocket so as to compare results directly..... Maybe I'll have to model the Estes Star Stryker, for which I have altitude data via the How High.

One other comment: there are the WECO (German) motors available it its motor menu, but they're not on Thrustcurve.org. It makes me wonder where the motor data really came from.

WECO A8-3s are what I got when I ordered a bag of 25 A6-4s from Quest....and, except for the really dirty ejection charges, I like them better than the A6-4s. But that's the subject of another thread :).

Sorry for the delayed post -- I was scanning the forum in search of information on Openrocket when I can upon this last post. As I understand it, thrustcurve.org is a voluntary effort to provide a comprehensive sport rocketry motor reference site. The motor thrust curves are only part of it, albeit a big part. It also has very helpful search tools, simulation tools and other features. It is independent from and not affiliated with any of the rocket motor manufacturers or with any of the certification entities. Therefore although it is an enormously helpful site, it is not an "official" repository of motor data, nor is it always completely up-to-the-moment current. I don't think that the site does its own testing; instead it pulls its data from motor certification documents from the "official" motor testing organizations (NAR, TRA and CAR). Each organization tests and certifies a certain subset of the available motors, and no single motor certification committee tests all motors. (As a general rule, all motors from Estes-Cox and Quest, for example, are tested by NAR, while it appears that many, perhaps even all, of CTI's and HyperTek's motors are tested by CAR. NAR's S&T and Tripoli's TMT pretty much divvy up the rest between the two of them for testing, from what I can tell.) All three organizations have reciprocal arrangements with each other to accept the motor certifications of the other two organizations. Together, they compile a combined list of certified motors, which is updated once or twice a year, I think. All three testing committees collect data on a common set of variables, but each entity may also publish additional data on the motors it tests that may be of interest to its organization's particular membership. As a result, the cert. documents and data don't look exactly the same from each committee, but the data that is relevant for certification purposes is always there in every committee's documents.

This page at the NAR website provides a link to the CAR/NAR/TRA Certified Motor List, as well as a detailed listing of the motors that are currently certified by NAR's Standards and Testing (S&T) Committee. (The other two organizations have similar pages at their websites.) Scrolling down to the "A" motor section, you can find a listing for the Quest A8-3 motor, which is the WECO-made motor that you have, along with a convenient link to its certification document. Since your post was made so long ago, I suspect that you have by now found all of this information already, but I thought that I would add it here just in case. In all likelihood the author of Openrocket used the data from NAR's certification document to create the motor file for the Quest A8-3. (A listing of the raw data that was used to create the curve is usually included on the second page of the document, in case you want to plot your own curve. I use that data on very rare occasions to create motor definitions that aren't in my set of files for RockSim, using the EngEdit utility.)

MarkII

Mark,

Yes, I know of the NAR cert data and frankly have not delved into how that gets translated into something any simulator can use. I had poked both the NAR cert folks and Quest about these WECO motors since I had them in hand, and they bore the NAR-certified logo, but were not listed until a couple of months later.

I still think it interesting that WECO motors are in the OpenRocket distribution and that they are identified as such (not as Quest motors). This was before the NAR data were available.

I also see that Quest A8s, as certified by the NAR, are now on Thrustcurve.org.....

The author of the software is from Finland so there's a good chance he saw those motors long before they came over here. He lists the source of the data and the WECO engine data came from a website in Germany.

I tried out OpenRocket and I like it.

I've been using OpenRocket off and on. While a few additions would be nice, I can't complain about a free program!

LPR motor weight errors....
 

I was using OpenRocket 0.9.6 to show the effects of some changes to a given design (BMS School Rocket - a BT-50-based 4FNC) to some students on Friday and wondered why OpenRocket gave me better stability margins with an Estes B6 than with an A8.

After a little scrutiny I figured out that the weights of the two motors - which come from Thrustcurve.org and to them from NAR cert data - are wrong. Both the full and empty weights of the B6 are understated and show up as lower than for an A8.

A closer look shows errors (relative to weights I've taken myself) in many of them. Some are slight and some are not so slight.

Through a circuitous path that involved editing the thrust curve files within the archive (using jZip on the .jar file) I have been able to get the weights that are consistent with my own measurements into my copy of 0.9.6. I had to change the existing files in the package, not add others, to get it to work.

But that really begs the question of how one gets the correct data in these online sources. Any ideas??

Also, I think there is an issue in that in the RASP file format "propellant weight" really is the weight of everything that gets burnt, but in the NAR cert data it literally the propellant weight, not that of the delay element or the ejection charge, and in little black powder motors that distinction can make quite a difference percentage-wise....

After looking at the cert data on the NAR site for Estes A8, B4, B6 and C6 motors and my own weights it looks to me as if this difference in interpretation of "propellant weight" may be a key bit. Now I need to go back to Thrustcurve.org and see what happened there.


On WECO motors - a tooltip pops up when selecting them in OpenRocket (maybe it's been added recently) which explains where the data came from - a combination of a different site and the author's own weights.

And on these as Quest A8-3s - the NAR cert info shows the propellant weight as 3.6g but in the RASP file it is shown as 0.0063 kg. Doing the calcs based on samples of spent cases and new motors in hand.... that latter value is close enough. Hmmmmmm........