[RFC] Rocketry Workbench

[johnwang]

Windows, what OS are you using and where do you have it installed?

Windows. add on manager does not work.

[grandcross]

Windows, what OS are you using and where do you have it installed?

Windows. add on manager does not work.

At all? Or just for this? This project hasn't been submitted as an add on yet. That's still a bit early given things like shape structures may change significantly.

I've successfully used add on manager for other work benches. And I'm running out of the user app data directory fine. I've done a git checkout into the Mod dir and it loads on startup

user app dir.png (57.58 KiB) Viewed 1758 times

[grandcross]

Some discussion on twitter about using the Cambridge Rocketry Simulator for simulation https://sourceforge.net/p/camrocsim/cod ... ster/tree/

A good overview is available here:
https://openresearchsoftware.metajnl.co ... /jors.137/

Currently it uses OpenRocket as the GUI, with a separate visualizer. Written in C++ and Python, so it should be possible to integrate. I don't think this project is at the point where integration is possible now, but maybe our long term goal could be rolling this in. I had been thinking more along the lines of porting Open Rocket, but this might be better.

[Kunda1]

Some discussion on twitter about using the Cambridge Rocketry Simulator for simulation https://sourceforge.net/p/camrocsim/cod ... ster/tree/

Thanks for sharing this.

[johnwang]

The GUI of the Cambridge Rocketry Simulator is in java, it generates a SimulationInput.xml.
The cpps (rocketc.exe) reads the SimulationInput.xml and an Uncertainty.xml to generate a SimulationOutput.xml.
Then the python (FlightPlotter.py) reads the SimulationOutput.xml to generate plots.
Here is the FlightPlots:

SimulationOutput.xml

(107.85 KiB) Downloaded 56 times

Figure_1.png (75.93 KiB) Viewed 1665 times

Figure_2.png (29.71 KiB) Viewed 1665 times

Figure_3.jpg (60.39 KiB) Viewed 1661 times

[grandcross]

As it turns out, non-conical transitions are hard! All the geometric permutations were making my brain hurt, so I switched to something a little easier.

Presenting body tubes, bulkheads, and centering rings. Lots of options for each!

BodyTube.png (27 KiB) Viewed 1660 times

Bulkhead.png (58.32 KiB) Viewed 1660 times

CenteringRing.png (78.05 KiB) Viewed 1660 times

I also have some ideas for creating fin cans, or fin sets for simply arranging fins around a body tube, but that may get more involved. As such I may save it for a second release. I really want to flesh out these basic components for an initial release.

If you're wondering about the odd dimensions for the body tube, these are the dimensions for a standard BT-50 body tube. Some thought will have to be given to suitable defaults for all the components at some point. Perhaps choosing defaults that match a common rocket

Now back to transitions...

[grandcross]

The GUI of the Cambridge Rocketry Simulator is in java, it generates a SimulationInput.xml.

According to the developers it's based on Open Rocket, so it shouldn't be much different from an integration point of view. But that's a few steps ahead still...

We could add our own data visualizers as well.

[grandcross]

Non-clipped versions of all transition shapes are now posted. Clipped versions should hopefully be later today.

[grandcross]

Wow! That was painful! Clipped transitions are now merged.

In case you're wondering what that is, it changes the shape of a transition depending on the shape you've chosen. For example, there are two ways to draw an elliptical transition:

ParabolaClippedVsNon.png (16.84 KiB) Viewed 1558 times

The easy way is to use the narrow radius as the centerline of the ellipse. In the diagram this is the horizontal red line at Y=10, The resulting curve is shown in the orangeish yellow. The more difficult method is to extend the shape using the X=0 centerline and "clipping" off the nose. This is shown as the blue curve. The challenge is ensuring the forward radius matches. As it turns out drawing the curve is fairly easy. Selecting the correct segment of the curve and ensuring it's placed correctly will make your head spin. This is by far the most difficult feature I've implemented thus far.

For some shapes clipping doesn't make sense. For example, consider the ogive:

OgiveClippedVsNon.png (14.8 KiB) Viewed 1558 times

In the case of an ogive, cone, and some others, clipping results in the same shape. Given that it's computationally more expensive, the option to clip is not offered for these cases. Diagrams generated using pyplot while I was trying to figure out what was going on

At this point, I'm declaring a feature freeze for a first release. There is some code I want to clean up, and testing to do, but essentially what you see now is what you'll get. Expect bug fixes, UI tweaks, and performance enhancements only. Once I'm happy, I'll submit this to be included in the list of add ons. This should satisfy a lot of 3D printing, laser cutting, and CNCing people.

Once this is out the door I'll resume work on an OpenRocket importer so we can play with complete rockets. Some other components may be created or ignored in the process.

[Kunda1]

amazing work!