Scientific Validity of the software

[Achronia]

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.

Thank you. What I meant by accurate was a simulator that can generate data that is affected by realistic noise. Of course, this presumes predictability of noise on the accelerometer but I have read in a paper that at high frequencies, the noise is almost always Gaussian and at low frequencies it's f type noise. I guess I have to study more on this.

 

[UhClem]

so if the rocket is slightly off vertical (which it definitely will be at some point) it won't calculate the correct apogee,

The magnitude of the error depends on the rockets acceleration. Acceleration at apogee is so near zero that any variation in attitude from vertical there has almost no effect. Oscillations in vehicle attitude during and shortly after motor operation on the other hand, are a problem. (and triggered my work on Kalman filters)

 

[heada]

The magnitude of the error depends on the rockets acceleration. Acceleration at apogee is so near zero that any variation in attitude from vertical there has almost no effect. Oscillations in vehicle attitude during and shortly after motor operation on the other hand, are a problem. (and triggered my work on Kalman filters)

If I understand correctly, true for rockets with near vertical trajectories. If for some reason (wind, fin alignment, launch angle, etc) the rocket is on a non-vertical trajectory at apogee, there will be some lateral acceleration still, correct? Does apogee detection change with Z axis only vs X, Y and Z axis integration?

 

[Maxwelljets]

The magnitude of the error depends on the rockets acceleration. Acceleration at apogee is so near zero that any variation in attitude from vertical there has almost no effect. Oscillations in vehicle attitude during and shortly after motor operation on the other hand, are a problem. (and triggered my work on Kalman filters)

Right. The errors I'm talking about are due to off-vertical trajectories during boost. Most spaceshots have very long burns (relative to most HPR rockets) meaning there's ample time for them to gravity turn during boost. Even a degree or two during boost can cause errors of several percent in the actual value of apogee, and since the apogee is so high, that means it will be off by a couple thousand feet.

 

[Off Grid Gecko]

I haven't used OR in a bit, but I was certain that you could export your flight data to a CSV file or something similar. On the matter of the accuracy of accelerometer data, I did the data-monkey side of deep core drilling for a long time, and we would take survey measurements miles below the ground. We used pipe-length (or wire for wireline services) for our distance tracking, but it's worth noting that in a curved borehole, you need to know where "up" is to take a directional survey shot, even if you know how much pipe you have expended. We used a combination of six sensors onboard to do this, due to various problems that had to be overcome. Three accelerometers and three magnetometers working together can do a lot to keep you oriented correctly. By adding the magnetometers, you can get the B vector of the magnetic field which can give you a baseline for judging the rocket's orientation and angle from vertical. Over a single flight, the field shouldn't change very much at all, so if you know the field direction at any point it can clue you in. A gyro is another option that shouldn't be ignored. You can get tiny motors and bearings these days so building something small and fairly light may work, but that's a weight penalty most likely. MEMS gyros are another possibility and can be had for cheap, plus they are super light compared to a spinning flywheel.
In any case, I think Apogee would be detected at a minimum vector from 3 accels after takeoff, and at such a point your Z axis (say Z is along the rocket's length) should be almost 0, and the other two should combine to give you a vector equivalent to gravity.
I'm probably getting off topic here as you are talking about modeling the flight, but figured I would toss some ideas out as they popped into my head.

 

[jderimig]

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?

Huh?

If you are simply going to test your flights computer's ability to integrate an acceleration profile correctly to a zero velocity (which is apogee) its doesn't matter how accurate your rocket flight simulation is right?

Generally this is not the problem. In a real flight the challenge is to get accurate measurement of the rocket's acceleration relative to the earth frame of reference.

 

[Achronia]

Huh?

If you are simply going to test your flights computer's ability to integrate an acceleration profile correctly to a zero velocity (which is apogee) its doesn't matter how accurate your rocket flight simulation is right?

Generally this is not the problem. In a real flight the challenge is to get accurate measurement of the rocket's acceleration relative to the earth frame of reference.

I have to feed real acceleration data to my system to see if it correctly detects apogee. I just wanna be on the safe side getting data of a rocket that has similar specifications (geometry, inertia, engine ,etc) so the acceleration profile would be similar. It's just not possible to find such data. Not to mention that I have to test the code like a 1000 times with different acceleration profiles to be perfectly sure of its functionality before launching a rocket that has the same value as me. That's why I thought of simulation. But please correct me if I am wrong.

As for the problem you mentioned, given that the accelerometer is calibrated, the measurement is not accurate because of presence of noise, right? So, what they usually do is to use a kalman filter which takes the average of measurement value and predicted model value requiring a very precise model. Am I on the right track here?

 

[UhClem]

As for the problem you mentioned, given that the accelerometer is calibrated,

Calibration not required.
Scale errors don't matter because integrated velocity starts at zero and ends at zero.

Offset errors are a big problem but easily handled by measuring until just before first motion. You cannot do this just at power up because it varies with temperature.

It isn't really that difficult. The early accelerometer based altimeters used noisy sensors (ADXL50), slow micro-controllers, and 8 bit ADC's. No Kalman filter. Yet worked reasonably well.

 

[Achronia]

Calibration not required.
Scale errors don't matter because integrated velocity starts at zero and ends at zero.

Offset errors are a big problem but easily handled by measuring until just before first motion. You cannot do this just at power up because it varies with temperature.

It isn't really that difficult. The early accelerometer based altimeters used noisy sensors (ADXL50), slow micro-controllers, and 8 bit ADC's. No Kalman filter. Yet worked reasonably well.

Thank you. Just to understand better lets say the readings of the accelerometer follow y = ax +b in which x is the actual acceleration. You're saying a is not much of a factor but what does that have to do with integrated velocity? Aren't we integrating acceleration here?
b is a factor you say and since it varies with temp during the flight, we cannot apply a simple subtraction and add the bias to all the readings. If that's true then that b would remain unknown after the power up and during the whole flight. Am I not getting something here?

 

[jderimig]

As for the problem you mentioned, given that the accelerometer is calibrated, the measurement is not accurate because of presence of noise, right? So, what they usually do is to use a kalman filter which takes the average of measurement value and predicted model value requiring a very precise model. Am I on the right track here?

No, the onboard accelerometer does not measure the rocket's acceleration relative to the earth, it measures the acceleration relative to the rocket. The acceleration due to gravity is not measured by the accelerometer, you have to provide that and assume the direction of the acceleration due to gravity vector. If your actual flight deviates from that assumed vector then the integration to zero velocity will have error. A flight to 100km this could accumulate alot of error.

Most flight computers assume this vector to be along the axis of the rocket. Statistically this has the lowest probability of being the correct assumption.

 

[Achronia]

No, the onboard accelerometer does not measure the rocket's acceleration relative to the earth, it measures the acceleration relative to the rocket. The acceleration due to gravity is not measured by the accelerometer, you have to provide that and assume the direction of the acceleration due to gravity vector. If your actual flight deviates from that assumed vector then the integration to zero velocity will have error. A flight to 100km this could accumulate alot of error.

Most flight computers assume this vector to be along the axis of the rocket. Statistically this has the lowest probability of being the correct assumption.

I think you're referring to the slight rotation of the body frame wrt to the inertial frame and how it grows over time. Why not use gyro data to detect the angle of rotation and use Coriolis law to compensate for the misalignment? Do you think that's a good idea?!

 

[jderimig]

I think you're referring to the slight rotation of the body frame wrt to the inertial frame and how it grows over time. Why not use gyro data to detect the angle of rotation and use Coriolis law to compensate for the misalignment? Do you think that's a good idea?!

Yes that is the only way to determine height with only an IMU. The other easier method is to use an unlocked GPS to determine apogee and get your position directly.

 

[UhClem]

Thank you. Just to understand better lets say the readings of the accelerometer follow y = ax +b in which x is the actual acceleration. You're saying a is not much of a factor but what does that have to do with integrated velocity? Aren't we integrating acceleration here?
b is a factor you say and since it varies with temp during the flight, we cannot apply a simple subtraction and add the bias to all the readings. If that's true then that b would remain unknown after the power up and during the whole flight. Am I not getting something here?

Integrate acceleration and you get velocity.

Carefully record the acceleration on the pad. This is the value for 1G that is subtracted from every reading during flight. Do this poorly and the error grows with time.

You probably should read the flight report from 2012 on the Aeropac entry for the John Carmac 100K challenge.

 

[alexzogh]

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.

If you would like actual raw telemetry data from a few launches (GPS + Baro + 6 DOF accel), I'm happy to provide it. I keep it around all the time to test Kalman filters, GPS vs. inertial nav calculations, etc...

There is a TON of published work out there, and most of it is accessible to anyone with good (don't need great) math skills. For example, I can never remember what things like "k" mean in quaternion, but then I look at the code and remember, "oh, that's a 180-degree rotation around the y-axis". Do what calculation I needed to be done, then quickly forget once again what k stood for...

How deep down this rabbit hole do you want to go?

I would start with the only current patent in Apogee detection via acceleration: https://patents.google.com/patent/US9677864B1/en it's written well written, and has great citations all the way back to GE's work in the 1960s.

You can also look at someone else's code to see how they are doing it. Altus Metrum's code is excellent, and open source (https://altusmetrum.org/AltOS/), better yet, there are some websites that both show the code, and discuss the theory, like this one: https://shanetully.com/2016/07/inside-the-construction-of-an-amateur-rocketry-flight-computer/ - it's also all open source, and available on Github

 

[Achronia]

If you would like actual raw telemetry data from a few launches (GPS + Baro + 6 DOF accel), I'm happy to provide it. I keep it around all the time to test Kalman filters, GPS vs. inertial nav calculations, etc...

There is a TON of published work out there, and most of it is accessible to anyone with good (don't need great) math skills. For example, I can never remember what things like "k" mean in quaternion, but then I look at the code and remember, "oh, that's a 180-degree rotation around the y-axis". Do what calculation I needed to be done, then quickly forget once again what k stood for...

How deep down this rabbit hole do you want to go?

I would start with the only current patent in Apogee detection via acceleration: https://patents.google.com/patent/US9677864B1/en it's written well written, and has great citations all the way back to GE's work in the 1960s.

You can also look at someone else's code to see how they are doing it. Altus Metrum's code is excellent, and open source (https://altusmetrum.org/AltOS/), better yet, there are some websites that both show the code, and discuss the theory, like this one: https://shanetully.com/2016/07/inside-the-construction-of-an-amateur-rocketry-flight-computer/ - it's also all open source, and available on Github

Jesus, you're knowledgeable. I really appreciate you sharing all this with me.
I am ready to take the red pill and go down the rabbit hole but please note I am not bad at the mathematical theory as I have taken a few graduate courses on spacecraft dynamics and control. What I lack is hands-on experience which is infinite times more important than theory in my situation.
On a different note, this paper you sent is fascinating and will definitely help. I am also thinking of maybe publishing a paper out of my work. Do you think if the apogee detection and deployment task is done successfully, there'll be chance for publishing the results in a paper? Have you had such experience yourself?

 

[Achronia]

If you would like actual raw telemetry data from a few launches (GPS + Baro + 6 DOF accel), I'm happy to provide it. I keep it around all the time to test Kalman filters, GPS vs. inertial nav calculations, etc...

There is a TON of published work out there, and most of it is accessible to anyone with good (don't need great) math skills. For example, I can never remember what things like "k" mean in quaternion, but then I look at the code and remember, "oh, that's a 180-degree rotation around the y-axis". Do what calculation I needed to be done, then quickly forget once again what k stood for...

How deep down this rabbit hole do you want to go?

I would start with the only current patent in Apogee detection via acceleration: https://patents.google.com/patent/US9677864B1/en it's written well written, and has great citations all the way back to GE's work in the 1960s.

You can also look at someone else's code to see how they are doing it. Altus Metrum's code is excellent, and open source (https://altusmetrum.org/AltOS/), better yet, there are some websites that both show the code, and discuss the theory, like this one: https://shanetully.com/2016/07/inside-the-construction-of-an-amateur-rocketry-flight-computer/ - it's also all open source, and available on Github

I was wondering if you would kindly provide me with the telemetry data you told me about if possible. That would definitely help me.

 

[Achronia]

The magnitude of the error depends on the rockets acceleration. Acceleration at apogee is so near zero that any variation in attitude from vertical there has almost no effect. Oscillations in vehicle attitude during and shortly after motor operation on the other hand, are a problem. (and triggered my work on Kalman filters)

Can I use Low-high pass filters to filter out the accelerometer noise?