Scientific Validity of the software

[Achronia]

Dear people,

I am a new user and my goal is to precisely simulate the flight of a rocket to 100km. I will have to also simulate the whole thing in MATLAB as well. I was just wondering how scientifically accurate and reliable this rocket simulator (Open Rocket) is based on giving accurate acceleration, velocity, pressure, etc.
I would appreciate a response.
Thanks

 

[Nytrunner]

Which rocket simulator?

 

[Achronia]

Open Rocket

 

[Steve Shannon]

Dear people,

I am a new user and my goal is to precisely simulate the flight of a rocket to 100km. I will have to also simulate the whole thing in MATLAB as well. I was just wondering how scientifically accurate and reliable this rocket simulator is based on giving accurate acceleration, velocity, pressure, etc.
I would appreciate a response.
Thanks

None of them are perfect and any expectation of such precision will be quickly dashed to the rocks. The problem isn’t so much the software as your ability to construct an accurate model (garbage in -> garbage out). If the first few times you use one you come within 5% you probably just got lucky. But, by flying a real rocket multiple times and tweaking the model until the results with that model come as close as possible for at least two or three different models, you will end up with a model that you can use with some confidence.

 

[mikec]

But, by flying a real rocket multiple times...

Good advice, but I'm not seeing any evidence that the OP is ever going to fly a real rocket to 100 km.

If you want validation for flights anything like that, RASAero is a better choice, as its documentation shows comparisons of sims and actual flights for fairly similar profiles.

OR does pretty well for most of what we do in amateur rocketry but it might be challenged by a 100 km flight.

 

[Achronia]

Good advice, but I'm not seeing any evidence that the OP is ever going to fly a real rocket to 100 km.

If you want validation for flights anything like that, RASAero is a better choice, as its documentation shows comparisons of sims and actual flights for fairly similar profiles.

OR does pretty well for most of what we do in amateur rocketry but it might be challenged by a 100 km flight.

Thank you but what do professional rocket teams do to simulate the rocket flight. I am sure NASA has some advanced software to do that.
My goal is to get pseudo data for acceleration so I can test my apogee detection system. That's why I am planning to simulate the whole flight and apply a Gaussian noise to generate data for acceleration. The data will then be fed to the flight computer to see if it correctly detects apogee.
Could you please share your opinion?

 

[mikec]

Openrocket or RASAero will be fine for doing that. Of course your accelerometer noise is unlikely to be Gaussian, will probably have a bias, effects of misalignment, etc.

Apogee detection has been discussed many times on this forum, do some searching.

 

[Funkworks]

You might want to review author's documentation:
https://openrocket.info/documentation.html

 

[UhClem]

My goal is to get pseudo data for acceleration so I can test my apogee detection system. That's why I am planning to simulate the whole flight and apply a Gaussian noise to generate data for acceleration. The data will then be fed to the flight computer to see if it correctly detects apogee.
Could you please share your opinion?

Noise is the least of your worries as all acceleration based apogee estimation schemes integrate the data which is a natural low pass filter.

You will have larger errors from things you can't simulate easily. For the typical algorithm that is variation of rocket attitude from perfectly vertical.

Noise is a bigger problem with barometric systems.

 

[hartlch]

So what is your actual goal? You gave two:
1) my goal is to precisely simulate the flight of a rocket to 100km
2) My goal is to get pseudo data for acceleration so I can test my apogee detection system

As others pointed out, precision is limited for assorted reasons. If your actual goal is #2, then I would not bother with the flight simulator. You have Matlab available, so it will be a lot easier to tinker with acceleration profiles in that. Other than the limitations of using acceleration for velocity detection noted in posts above, you will want to be adding noise/glitches to your acceleration data that you won't be able to get from open rocket.

 

[Kelly]

But, by flying a real rocket multiple times and tweaking the model until the results with that model come as close as possible for at least two or three different models, you will end up with a model that you can use with some confidence.

Not to derail the thread, but how exactly does one tweak a model? What parameters would you change to get the model to match the observed performance? Just add drag elements, or ???

 

[mikec]

Surface finish is the main tweakable parameter in OR, once you have the weight correct. Some programs allow you to modify the Cd directly, but OR doesn't.

 

[Off Grid Gecko]

OP, you can get motor data directly from thrustcurve.org
That would probably be more acurate than trying to fit a curve to the motor. Adding noise does nothing to make things more predictable.
Likewise, you will probably want to do interpolation between altitude points for your air density (I assume calculated with an expected temperature and humidity?) at regular points. There's an online calculator for this as well that you might use as a model, can't remember where the website is at the moment.
Another problem that needs tackling is drag profile. If you are shooting for the Karman line, then you will likely have speeds in excess of Mach 4, so you need to take into account Mach effects also (to be accurate) and nose cone profiles/fin shapes that are better suited (good luck finding quantitative data there).
I'm running into many of these same issues designing my flight simulator. As the engineer/programmer/ceo/decision maker, I have to make a decision what can be sacrificed while still providing the end-user with a "good enough" simulation.
As @UhClem pointed to, your biggest issue is going to involve angle of attack changing the CP and CD of the rocket while it's accelerating. Also oscillations caused by that, fin flutter, and spin. Those are going to eat your motor's lunch for thrust efficiency.
If you want to do it the easy way by putting in some coefficient that jumbles all of that into "noise data," then why ask about accuracy? Just curious, not trying to be snarky though I can see how that would come off that way.
That said, some of the above can be modeled and some can be added to an unknown noise constant (spin is often very unpredictable, buy you can gauge the spin of a "good" build by watching some youtube rocket vids). I'm hoping to model some of the launch effects with my program to a slight degree of accuracy as a failure prevention warning. Wind effects on long rockets can be approximated at slower speeds and they do have an effect on performance.

#EDIT: OR is also open source. You can download their code from GIT (I assume) and look at it yourself to see what they are doing.

 

[JohnCoker]

Not to derail the thread, but how exactly does one tweak a model? What parameters would you change to get the model to match the observed performance? Just add drag elements, or ???

The simplest way is to change the "coefficient of drag" (since drag is the largest force retarding the ascent for our rockets).

 

[JoePfeiffer]

Yes, the OR source code is freely available at https://github.com/openrocket/openrocket

 

[Steve Shannon]

The simplest way is to change the "coefficient of drag" (since drag is the largest force retarding the ascent for our rockets).

That’s exactly what I had in mind.

 

[vcp]

6-DOF motion implemented via quaternion math is commonly a feature of high-end simulations.

 

[PatD]

6-DOF motion implemented via quaternion math is commonly a feature of high-end simulations.

Do you speak English?
Edit: Sorry kind of a reflex smartass reaction. Thanks for the contribution.

 

[mikec]

That’s exactly what I had in mind [changing Cd]

Except, as I noted in post 12, there's no way to do that in OR directly.

 

[Maxwelljets]

Thank you but what do professional rocket teams do to simulate the rocket flight. I am sure NASA has some advanced software to do that.
My goal is to get pseudo data for acceleration so I can test my apogee detection system. That's why I am planning to simulate the whole flight and apply a Gaussian noise to generate data for acceleration. The data will then be fed to the flight computer to see if it correctly detects apogee.
Could you please share your opinion?

The data that these programs generate for acceleration, velocity, and altitude will be plenty good for the purposes of testing apogee detection. As the others are saying though, getting an accurate simulation for the purposes of determining performance of an actual rocket will be quite a bit more difficult. However, if the only thing you're currently doing is testing apogee detection, I don't think there's much here that you need to worry about in terms of absolute accuracy.

 

[SpaceManMat]

Except, as I noted in post 12, there's no way to do that in OR directly.

No but a plugin will let do this, you can modify it the CD by a percentage or load you own CD profile.
Details here:
https://www.rocketryforum.com/threads/changing-cd-in-openrocket.139708/Download is at the end.

 

[Off Grid Gecko]

6-DOF motion implemented via quaternion math is commonly a feature of high-end simulations.

Also used quite frequently in video games. Quats are a bit weird at first but so much better suited for first-person shooters and enemy tracking because you are manipulating a matrix instead of needing to keep track of a bunch of extra vectors as in Euclidian space.
In the end though, you can do 6-DOF without quaternions, it's just slightly more cumbersome and requires a certain order of operations to keep stuff from getting tangled into oddly pointed directions. Since rockets (typically) are symmetrical around the long axis, it's hardly a necessity. Planes, helicopters, tennis rackets, and other objects that aren't radiallly symmetric are easier in the long run by learning quat math, or by taking some other shortcut.

 

[neil_w]

Surface finish is the main tweakable parameter in OR, once you have the weight correct. Some programs allow you to modify the Cd directly, but OR doesn't.

Changing fin thickness is another quick hack to affect drag, also fin edge treatment (square/rounded/airfoil).

 

[Off Grid Gecko]

The data that these programs generate for acceleration, velocity, and altitude will be plenty good for the purposes of testing apogee detection. As the others are saying though, getting an accurate simulation for the purposes of determining performance of an actual rocket will be quite a bit more difficult. However, if the only thing you're currently doing is testing apogee detection, I don't think there's much here that you need to worry about in terms of absolute accuracy.

so...you plan on feeding the flight computer altimeter data that you calculate from the model? Or gyro sensor data? Both have certain issues in real life that the simulation might not model. Breaking Mach speed messes with the air pressure read by altimeters. A mems gyro along the vertical axis can detect if the rocket is under thrust or slowing down. The data can be used together to make a "safety net" for deployment (apogee detection is typically used as a trigger for popping the chute). Depending on what sensors you will be using, you would want to make use of all of them so that a bad altimeter reading doesn't give you an early deploy or similar. IOW, I'm not sure that sim data would mimic those events accurately, though I guess it could if you put a lot of working into converting the data properly to your sensor inputs.
"Noise," as I've seen, is generally taken care of by doing a running avg. Instead of sensing "is the current altitude higher or lower than the last one" you would compare the average of the last five readings, possibly dropping the highest and lowest measurement before computing, or something similar. altusmetrum.org has open-source software and might be useful for setting up a flight computer, as their system could clue you in to some of the events you would really need to worry about and how they get around them.

 

[Maxwelljets]

so...you plan on feeding the flight computer altimeter data that you calculate from the model? Or gyro sensor data? Both have certain issues in real life that the simulation might not model. Breaking Mach speed messes with the air pressure read by altimeters. A mems gyro along the vertical axis can detect if the rocket is under thrust or slowing down. The data can be used together to make a "safety net" for deployment (apogee detection is typically used as a trigger for popping the chute). Depending on what sensors you will be using, you would want to make use of all of them so that a bad altimeter reading doesn't give you an early deploy or similar. IOW, I'm not sure that sim data would mimic those events accurately, though I guess it could if you put a lot of working into converting the data properly to your sensor inputs.
"Noise," as I've seen, is generally taken care of by doing a running avg. Instead of sensing "is the current altitude higher or lower than the last one" you would compare the average of the last five readings, possibly dropping the highest and lowest measurement before computing, or something similar. altusmetrum.org has open-source software and might be useful for setting up a flight computer, as their system could clue you in to some of the events you would really need to worry about and how they get around them.

It sounds like he wants to make an algorithm to detect apogee based solely on acceleration, which is how most super high altitude projects do it. Both CSXT and USCRPL used this method for their spaceshots. They're above the altitude where civilian GPS works, and there's not enough pressure for baro data to be worth anything. Since it's accelerometer based, there's no need to worry about mach effects messing up the pressure data and triggering early deployment. The main issue accelerometer based systems have is that they can't distinguish between upward acceleration and sideways acceleration, so if the rocket is slightly off vertical (which it definitely will be at some point) it won't calculate the correct apogee, and will be several seconds off. This sounds really bad, but in practice when you're that high up there's not enough air to make fast deployments a problem.

 

[Steve Shannon]

It sounds like he wants to make an algorithm to detect apogee based solely on acceleration, which is how most super high altitude projects do it. Both CSXT and USCRPL used this method for their spaceshots. They're above the altitude where civilian GPS works, and there's not enough pressure for baro data to be worth anything. Since it's accelerometer based, there's no need to worry about mach effects messing up the pressure data and triggering early deployment. The main issue accelerometer based systems have is that they can't distinguish between upward acceleration and sideways acceleration, so if the rocket is slightly off vertical (which it definitely will be at some point) it won't calculate the correct apogee, and will be several seconds off. This sounds really bad, but in practice when you're that high up there's not enough air to make fast deployments a problem.

There are civilian available GPS receivers that are capable of recording high altitudes, such as this:
https://www.highaltitudescience.com/products/eagle-flight-computer

 

[Maxwelljets]

There are civilian available GPS receivers that are capable of recording high altitudes, such as this:
https://www.highaltitudescience.com/products/eagle-flight-computer

That GPS has a maximum altitude of 80,000 m, according to the page that you linked. So a true spaceshot (≥100 km) would still be unable to use that GPS for apogee detection.



It's also worth noting that most GPS chips also include a separate lockout above a certain speed, typically far less than the max speed of most amateur high altitude shots. So you'll lose GPS signal for that reason as well. The GPS you linked is meant for high altitude balloons, which don't move anywhere near fast enough to trigger the speed lockout, so odds are very good that this GPS also has the speed lockout and it just isn't listed on the page.

 

[VernK]

The GPS in Kate 2.0 has no altitude limit. It does have a velocity limit but that will not be in play at apogee. Therefore, it can be used to record max altitude all the way into space. More info is at www.multitronix.com

 

[Steve Shannon]

That GPS has a maximum altitude of 80,000 m, according to the page that you linked. So a true spaceshot (≥100 km) would still be unable to use that GPS for apogee detection.

View attachment 415368

It's also worth noting that most GPS chips also include a separate lockout above a certain speed, typically far less than the max speed of most amateur high altitude shots. So you'll lose GPS signal for that reason as well. The GPS you linked is meant for high altitude balloons, which don't move anywhere near fast enough to trigger the speed lockout, so odds are very good that this GPS also has the speed lockout and it just isn't listed on the page.

You’re right; I missed that maximum altitude. The high speed lockout typically isn’t a problem for apogee though.

 

[Achronia]

Thank you guys for your messages and apologies for late reply.

I know I can use recorded data from the flight of other rockets to test the code for apogee detection. However, I just want to be on the safe side and use the data that is directly related to my rocket. That's why I wanted to simulate the whole thing and generate acceleration data and feed it to the code. Yet, if you still think this is unnecessary, please let me know.

Also I was wondering if anybody was able to publish a paper out of their work on rocket acceleration.