OpenRocket: negative accelleration at T=0?

[Grant_Edwards]

In OpenRocket simulations, my rockets all seem to have a significant negative acceleration at T=0 (the green line in the plot below):


The left axis ticks are labelled for velocity — in the simulation above the acceleration starts out at about -8 m/s².

Any ideas on am I doing wrong?

 

[waltr]

Gravity's acceleration is -9.8m/s² so this is what is reported.

 

[neil_w]

Gravity's acceleration is -9.8m/s² so this is what is reported.

Yeah but the rocket is not being dropped from a height at t=0, it’s stationary. Acceleration should be zero. I’m going to have to play with this.

@Grant_Edwards can you post the ORK file?

 

[Sandy H.]

Is there an 'Astra Aerospace' checkbox in the preferences?

Sandy.

 

[waltr]

Just checked attached ork file. With the G53 motor pre-ignition acc is -9.8.
This is the Acceleration of any object at rest on the ground. Yes, I do remember this from my physics courses. It is this acceleration that causes 'weight' that can be measured with a scale.

 

[Grant_Edwards]

Yeah but the rocket is not being dropped from a height at t=0, it’s stationary.

Well, mine certainly are.

Acceleration should be zero.

That's what I expected. I was wondering if I was doing something wrong — which might mean that the other sim results (e.g. velocity at top of launch rod) won't be useful.

I’m going to have to play with this.

@Grant_Edwards can you post the ORK file?

Attached. The "simple model rocket" example included in the download has the same "feature".

 

[waltr]

Interesting, the sim of your red max is showing acc = zero at ignition.
Added a C6 motor and the sim show -9.8 acc. The B6 sim is still zero acc.

Now I don't know what to say!!

 

[Grant_Edwards]

Gravity's acceleration is -9.8m/s² so this is what is reported.

That only makes sense if the rocket is in freefall at T=0. It is not. It's stationary — sitting on a launch pad. While sitting on the launch pad before ignition, the force due to gravity is counteracted by an upward force from the launch pad.

If the rocket's acceleration is -9.8m/s² at T=0, and velocity is 0 at T=0, then velocity should be trending negative and the height should be dropping below 0. It is not (according to the plot).

 

[UhClem]

Yeah but the rocket is not being dropped from a height at t=0, it’s stationary. Acceleration should be zero. I’m going to have to play with this.

If you create a free body diagram, it is correct. You have gravity pulling down at 9.8m/s and no rocket motor thrust.

Handling the launch transition is tricky. Once off the pad then this is obviously correct. On the pad it seems a bit odd. Assuming that the motion is constrained to not allow negative velocity before first motion, it will work.

 

[Steve Shannon]

That only makes sense if the rocket is in freefall at T=0. It is not. It's stationary — sitting on a launch pad. While sitting on the launch pad before ignition, the force due to gravity is counteracted by an upward force from the launch pad.

If the rocket's acceleration is -9.8m/s² at T=0, and velocity is 0 at T=0, then velocity should be trending negative and the height should be dropping below 0. It is not (according to the plot).

In this case acceleration is a constant and motion is constrained until the thrust exceeds the gravitational force. Velocity and height will then start to change.

 

[Kelly]

If you create a free body diagram, it is correct. You have gravity pulling down at 9.8m/s and no rocket motor thrust.

But you also have the launch pad pushing up with the same force (9.8m/s * the mass of the rocket) thus the FBD shows 0 net force on the rocket, and thus there should be zero acceleration.

The definition of acceleration is \( \delta v/\delta t \), or \( \delta^2 x/ \delta t^2 \). Neither the velocity nor the position of this rocket is changing, so the acceleration is 0.

 

[lakeroadster]

It's assuming the motor is "chuffing" a.k.a "pogo effect"... <-- that means I'm kidding...

 

[UhClem]

But you also have the launch pad pushing up with the same force (9.8m/s * the mass of the rocket) thus the FBD shows 0 net force on the rocket, and thus there should be zero acceleration.

It is a transition problem. As soon as the rocket starts moving the pad force vanishes. You could model that but then you have to decide when acceleration from motor thrust exceeds 1G so you can drop the pad force. Worse, you have to ignore the motor thrust until it would result in more than 1G of acceleration.

Write your simulation whichever way you prefer.

 

[Steve Shannon]

But you also have the launch pad pushing up with the same force (9.8m/s * the mass of the rocket) thus the FBD shows 0 net force on the rocket, and thus there should be zero acceleration.

The definition of acceleration is \( \delta v/\delta t \), or \( \delta^2 x/ \delta t^2 \). Neither the velocity nor the position of this rocket is changing, so the acceleration is 0.

It looks like the programmers took a shortcut. The equal and opposite force will always be whatever it takes to prevent downward travel due to gravity. So, as long as the thrust doesn’t exceed the full weight of the rocket they just left it out of the acceleration value shown on the graph.

 

[neil_w]

It is a transition problem. As soon as the rocket starts moving the pad force vanishes. You could model that but then you have to decide when acceleration from motor thrust exceeds 1G so you can drop the pad force. Worse, you have to ignore the motor thrust until it would result in more than 1G of acceleration.

I now understand exactly what you're saying.

Nonetheless, I would argue that the reported acceleration should indeed be dv/dt, and at t=0 that would be zero. If it requires a bit of special case code to zero out the acceleration value before lift off then I personally would prefer it do that.

 

[Grant_Edwards]

In this case acceleration is a constant

And until the rocket starts moving, that constant is 0 because the net force on the rocket is 0.

and motion is constrained until the thrust exceeds the gravitational force. Velocity and height will then start to change.

Correct. That happens when the net force on the rocket is non-zero and the acceleration is therefore non-zero.

This is obviously a problem handling the boundary condition where T ≥ 0, altitude = 0, and engine force < rocket weight. As long as it doesn't actually affect the non-boundary results (e.g. velocity vs time and altitude vs time for T > liftoff), then it can probably just be ignored. My concern was that there was something wrong with my simulations, and that the two numbers I generally care most about (velocity at top of launch rod and optimal deployment delay) were not usable.

 

[cerving]

I think the negative acceleration is due your motor $$$ being sucked into the void...

 

[Grant_Edwards]

Model rocketry (at least so far) is a pretty negligible money sink compared to golf, RC aircraft, scuba diving, and my motorcycle...

 

[JoePfeiffer]

Yes, it's basically that the code takes the easy way out. What's going on is the code takes one complete simulation step, and then looks at conditions that may have been satisfied during the step (did a stage ignite? Did we leave the ground? Did we fire an ejection charge?) and marks those events as they occur. One of the things it looks for is "have we left the ground yet?" If not, it patches up the acceleration, velocity, and altitude. The new values have already been recorded at that point, so we see a negative acceleration until the motor's thrust is greater than the weight of the rocket.

What we'd sort of expect and prefer would be to clamp either the force on the rocket at 0, or the acceleration at 0, if we're still sitting on the ground during the simulation step. The problem is this would have the check for that condition occurring during the simulation step, so the code would have some of those checks to after the step and some of them (at least one, anyway) during the step.

It would avoid that little surprise, but it doesn't make any sort of significant difference to the simulation results.

 

[BBB]

Going back to the original plot you uploaded - it appears that the velocity and altitude never go below zero. Way back in the 1980s I did a model rocket sim in Basic and had a similar situation. Once the thrust begins it has to exceed the weight of the rocket before it starts to climb. If the programmer locks the initial velocity and altitude at zero then acceleration should be -9.8 m/s at ignition and increase with the thrust curve of the engine. It may take a time step or two for thrust to exceed weight, but as long as velocity and altitude remain at zero until that point the simulation is correct.

 

[John Beans]

The reference that most people use for acceleration (and velocity and altitude) is the earth, since we are standing on it and it's "fixed" relative to us. That's always the most reasonable reference to assume unless someone specifies another one.

When a rocket is sitting on a pad, its acceleration and velocity relative to the earth are zero.

Once thrust exceeds the weight of the rocket and the friction of the rod/rail, it begins to accelerate upwards relative to the earth. Usually (but there's no hard rule for this) we log that acceleration as a positive number. You could label it negative if you wanted—you're free to define reference directions as you wish—but then in that reference scheme we'd have to log the velocity as negative, and it would seem kind of odd to say, "My rocket reached -250 mph."

I've read plenty of discussions where people like to say, "At rest, gravity is accelerating the rocket -9.8 m/s, and that's why it presses down against the pad." Describing acceleration like that tends to confuse people that (reasonably) use earth as a reference. "How can it be accelerating if it's not moving?" they might think.

A less confusing way to say it would be that gravity is an attractive force that two masses feel towards each other. The rocket presses down on the pad not because it is accelerating towards the earth but because it is attracted to it. In order for the rocket to accelerate upwards, the rocket has to generate at least enough thrust to counteract that force.

Physics gets harder to understand when people use a vague or shifting or non-earth reference frame (to wit: suggesting that that frame changes once the rocket lifts off the pad). Honestly, that is not helpful—just use the launch site as the reference. In that way, acceleration/velocity/altitude all make sense in a way that we generally understand and discuss.

Yeah, a bit of a rant, sorry.

 

[Grant_Edwards]

If the programmer locks the initial velocity and altitude at zero then acceleration should be -9.8 m/s at ignition and increase with the thrust curve of the engine.

No, accelleration is dv/dt. If velocity is a constant 0, then acceleration is, by definition also 0.

It may take a time step or two for thrust to exceed weight, but as long as velocity and altitude remain at zero until that point the simulation is correct.

The simulation of velocity and altitude is correct. The simulation of acceleration after liftoff is correct. The simulation of acceleration before liftoff is incorrect, but everybody agrees it doesn't really matter.

 

[waltr]

First, we agree that whatever OR calc's and plots before lift-off doesn't matter.

On some of the other points in this thread:

1- The rocket's weight is its Mass times the Gravitational pull (-9.8m/s/s at Earth's surface). This makes the acceleration of -9.8m/s/s correct even when fixed on the ground in the pure calculations of Physics.
The Velocity is constrained to not be negative.

2- If you have an Accerometer chip in your rocket then it will measure an acceration of -9.8m/s/s when the rocket is sitting on the pad. Another proof this thinking is correct.

3- Calculating the rockets motion one starts with the Thrust as applied to the Weight (Mass times
Gravity) of the rocket. Once Thrust exceeds weight then there is motion and Velocity can be calculated. NOT the other way around (Acc = dv/dt is not done although mathematically correct).

Yes, I have written rocket simulation code and after finding Open Rocket I compare the results are the same in both.

 

[UhClem]

2- If you have an Accerometer chip in your rocket then it will measure an acceration of -9.8m/s/s when the rocket is sitting on the pad. Another proof this thinking is correct.

+9.8m/s/s

 

[Grant_Edwards]

1- The rocket's weight is its Mass times the Gravitational pull (-9.8m/s/s at Earth's surface). This makes the acceleration of -9.8m/s/s correct even when fixed on the ground in the pure calculations of Physics.

Acceleration is dv/dt or F/m (the two are defined to be the same in classical physics). In the frame of reference we're using (the launchpad), velocity is 0 and unchanging before liftoff. Therefore acceleration is 0. Prior to liftoff, the net force on the rocket is 0, therefor acceleration is 0. Claiming that acceleration (within a given frame of reference) is non-zero when velocity is unchanging (within that frame of reference) is wrong.

The Velocity is constrained to not be negative.

Prior to liftoff, acceleration is zero because the launch pad exerts an upward force equal to the weight of the rocket minus the engine's thrust. Before liftoff, net force is zero, therefor acceleration is zero, and and velocity is unchanging. The OR simulation engine appears to ignore that upward force and applies constraints to position/velocity to try to hide that omission without also constraining acceleration.

2- If you have an Accerometer chip in your rocket then it will measure an acceration of -9.8m/s/s when the rocket is sitting on the pad. Another proof this thinking is correct.

That is measuring the force of gravity, and the sign of that value is positive (the same as the acceleration produced by the engine thrust). The "extra" acceleration value shown by OR has a negative sign. In the frame of reference we are using (the launchpad), what is measured by the accelerometer chip when at rest is not acceleration — though it is indistinguishable from acceleration from the accelerometer's frame of reference. That value should be zeroed out before flight if you want to know actual acceleration in the launchpad frame of reference.

3- Calculating the rockets motion one starts with the Thrust as applied to the Weight (Mass times Gravity) of the rocket. Once Thrust exceeds weight then there is motion and Velocity can be calculated. NOT the other way around (Acc = dv/dt is not done although mathematically correct).

Your simulation appears to be ignoring the upward force exerted by the launchpad before liftoff. If you do that, you end up with pre-liftoff downward acceleration as shown by OR. Displaying non-zero acceleration that doesn't produce any ∆v makes no sense. We know why it does that, and we know it doesn't affect post-liftoff results, so I'm happy to ignore it. But I'm not going to admit that it's "right".

Yes, I have written rocket simulation code and after finding Open Rocket I compare the results are the same in both.

Agreement is not the same thing as correctness.

If in your definition of things, F ≠ ma, a ≠ dv/dt, and ∆v ≠ ∫a dt,
then this discussion is rather pointless.

 

[BBB]

Model rocket simulations are driven by the forcing function - the engine thrust curve. In these simulations velocity is the integral of acceleration NOT the derivative of velocity. Also, Newton said force on an object was equal to rate of change of momentum, F=ma only if mass is constant, which is not true during thrust for a rocket.

 

[cerving]

The tricky thing is that a MEMS accelerometer is like a weight between two equally loaded springs, connected to a fixed frame. Imagine it moving horizontally instead of vertically, with no force in that direction there will be no movement and the weight will be centered equally between the springs... that will be zero. If you move/accelerate the frame left, the weight will react and move to the right, with a displacement dependent on the acceleration (since F=ma) until the two spring forces and the ma force are equalized. So, if you turn this thing 90 degrees so that "left" becomes "up", there will be a constant displacement of the weight "down" due to gravity while the frame is sitting still, i.e. on the pad. When you accelerate the frame (rocket) "up", the weight will move "down" in reaction. So, we actually have to subtract the acceleration due to gravity from the total displacement-derived acceleration to get the "up" acceleration of the frame (i.e. rocket).

 

[Grant_Edwards]

Model rocket simulations are driven by the forcing function - the engine thrust curve. In these simulations velocity is the integral of acceleration NOT the derivative of velocity.

Huh?

Yes, velocity is the integral of acceleration. The OR simulation shows non-zero negative acceleration prior to liftoff. That means that the velocity curve should have a negative slope during that period of time, and the velocity should be a negative number until acceleration has gone positive and remained so until the area under the postie portion of the acceleration curve equals the area under the negative portion of the acceleration curve.

Also, Newton said force on an object was equal to rate of change of momentum, F=ma only if mass is constant, which is not true during thrust for a rocket.

F = ma is always true in non-relativistic physics.

It doesn't matter which terms are changing, the equality holds at all points in time. If you prefer, you can take time into account explicitly and spell it

F(t) = m(t) * a(t)

 

[neil_w]

I will repeat the disclaimer that we can agree this doesn't really affect anything, more of a philosophical discussion at this point.

For those of on this side of the discussion, the point is that the internal calculations of the sim program (or the internal mechanisms of the accelerometer) are the developers' problems, not the users. The developers should not be foisting their problems on the users. I encounter this sort of thing all the time, including here at work, where the easy way around a problem is often just to give the users another option that they won't understand how to use, or maybe write some documentation about why something doesn't behave the way they'd expect.

In this case, I believe rather strongly that most users would expect that in the plots, a = dv/dt, where v is w/respect to the ground, and therefore a stationary rocket has acceleration=0 until it starts moving. It's as simple as that. If the internal calculations naturally lead to anything different, then it is the developer's job to modify the presentation of the data to make more sense.

I'm going to file an issue with OpenRocket to fix this, sometime in the future (who knows when).

 

[Grant_Edwards]

The tricky thing is that a MEMS accelerometer is like a weight between two equally loaded springs, connected to a fixed frame.[...]So, we actually have to subtract the acceleration due to gravity from the total displacement-derived acceleration to get the "up" acceleration of the frame (i.e. rocket).

Right. The force on the accelerometer's weight due to gravity has the same sign as the force due to upward acceleration of the rocket. In the coordinate system used by OR, they are both positive. The "raw" output of an accelerometer attached to the rocket would start out at +9.8m/s² before liftoff, and then increase from that value as the rocket accelerates upward.