Launch rail velocity - simulated vs actual

[Donnager]

OK then; sunlight it is!

 

[jqavins]

I don't know for sure, but I think that RockSim's determination of when the rail exit occurs is simply when the rocket rises by the rail length (8' here) from its initial position, i.e. when it reaches said altitude. That would be very hard to measure with a break beam, and pretty hard with video.

I wonder what it would take to put a kilosample/sec acceleratometer on the rocket? That really should do the trick.

 

[UhClem]

I also wondered about the position of the rail buttons on the rail, but there's no data entries for this with Rocksim and I don't know what is used in the program.

You are making this much too difficult. So far as Rocksim is concerned a rod/rail is an all or nothing thing. If you tell it the rail is 8' then after the rocket moves a simulated 8' Rocksim assumes that the rocket has left its rigid guidance. So use an appropriate distance.

 

[Richard Dierking]

ou are making this much too difficult. So far as Rocksim is concerned a rod/rail is an all or nothing thing. If you tell it the rail is 8' then after the rocket moves a simulated 8' Rocksim assumes that the rocket has left its rigid guidance. So use an appropriate distance.

OK, I appreciate the help on this.

I re-ran the sim at 100 F and 88.5" for the launch rail. This is how far the bottom button traveled from start to the top of the rail and the sensor.

The sim shows 107.4 ft/sec for launch guide departure.

If I use the mid-point between the two rail buttons at 78.5" the launch guide departure is 101.4 ft/sec.

I guess the point is, the simulation is about twice the velocity as the sensor reading indicated.
I would like everyone to help with this and appreciate the input so we can determine a standard of testing and continue to understand why it would be different.

 

[user 30299]

OK, I appreciate the help on this.

I re-ran the sim at 100 F and 88.5" for the launch rail. This is how far the bottom button traveled from start to the top of the rail and the sensor.

The sim shows 107.4 ft/sec for launch guide departure.

If I use the mid-point between the two rail buttons at 78.5" the launch guide departure is 101.4 ft/sec.

I guess the point is, the simulation is about twice the velocity as the sensor reading indicated.
I would like everyone to help with this and appreciate the input so we can determine a standard of testing and continue to understand why it would be different.

Rocksim can tell you the distance the rocket travels to meet your 50 f/s condition - so does that help you with your calculations?

 

[manixFan]

You do need to have the camera much closer to the pad.

Unless it has changed, Rocksim does not use the location of your rail guides to compute speed off of rail. According to tests done several versions ago, it computes the 'speed off the rail' as the velocity when the rocket has moved the length of the rail. A simple way to test this is to remove the rail guides and then rerun the simulation and see if the speed changes.

A very useful test would be 3 flights in a row using the same rocket and motor and comparing that data, rather than using a different rocket and motor.


Tony

 

[jderimig]

Easiest and best way (IMO) put two switches about 3-6" apart at the end of the rail and measure time it takes between switch actuations. The switches could be activated by the rail button (microswitch) or if you want get fancy put a magnet on the airframe and use 2 hall effect switches on the rail.

 

[Richard Dierking]

Rocksim can tell you the distance the rocket travels to meet your 50 f/s condition - so does that help you with your calculations?

RockSim simulation details states that user specified minimum velocity for stable flight is 44 ft/sec and this should have been achieved at 17.2". This didn't happen.

But, does RockSim take into account that as soon as the rocket goes over 1:1 weight to thrust that rocket is going to start to move? All solid rocket motors take varying time to fully pressure up. So, the G's don't go immediately to like 4 G's, it goes up to 4 G's. See what I mean?

A very useful test would be 3 flights in a row using the same rocket and motor and comparing that data, rather than using a different rocket and motor.

Please keep in mind that this project is self-funded with help from the social security administration. ;-)
I don't know how much use I'm going to get from this sensor set-up, but I would like to continue using it or a replacement for at least one year. I will be checking other rockets if people are willing to have the set-up used for their flights. However, I will only be checking commercial motors where there is established motor files to use in RockSim 9.

Easiest and best way (IMO) put two switches about 3-6" apart at the end of the rail and measure time it takes between switch actuations. The switches could be activated by the rail button (microswitch) or if you want get fancy put a magnet on the airframe and use 2 hall effect switches on the rail.

I would like others to conduct tests using different methods and we could compare. I was reluctant to use any mechanical switches or make additions to rockets (because they could belong to others). That's why I decided to use existing rail buttons to conduct measurements.

Also, please consider that I am currently working on other complex rocket projects (ones that have yet to blow up) and just added another (recovery using lifting body).

 

[UhClem]

I wonder what it would take to put a kilosample/sec acceleratometer on the rocket? That really should do the trick.

See graph in previous post. Teensy 3.6

 

[UhClem]

But, does RockSim take into account that as soon as the rocket goes over 1:1 weight to thrust that rocket is going to start to move?

Rocksim takes the thrust curve and applies that. F=ma. Where F is the sum of all forces. You can plot both thrust and acceleration where (depending on the thrust curve of course) you can see where there is zero acceleration but non-zero thrust.

 

[Richard Dierking]

We'll see what the next measurement is. The Redline will not pass avg thrust as quickly as the White Lightening. Hopefully, this will be on October 3rd, but I still need to receive the kit and build the rocket.

I also need to figure out how to get the GoPro closer to the pad and near level at the top of the rail.

Until then, I suggest starting to consider the possible reasons why the sim and actual would be different. It makes sense actual velocity would be less, but how much less?

What other information should I be noting during the test? For the simulation, what should I enter for the rail length? Are we good with the midpoint between the buttons to the top of the rail?

 

[Richard Dierking]

A very useful test would be 3 flights in a row using the same rocket and motor and comparing that data, rather than using a different rocket and motor.

Here's a photo from the launch video sequence. It shows why I am changing to a different rocket.
This new rocket will be used next time and hopefully many times after that. However, I'll be starting to make motors for it (taking a motor building class at FAR). I will make several motors, static test at least one, enter the data into a motor file for RockSim and use the simulation data to compare with actual exit velocity.
I need to combine projects because I just can afford a bunch of commercial motors just for the exit velocity project.

What other information should I be noting during the test? For the simulation, what should I enter for the rail length? Are we good with the midpoint between the buttons to the top of the rail?

 

[Kelly]

Until then, I suggest starting to consider the possible reasons why the sim and actual would be different.

I think the biggest source of difference will be between how your actual motor is starting up vs. what the thrust curve says it does. The initial thrust of the motor will depend upon how much of the surface area of the propellant is actually burning. It would be nice if the entire surface starts burning all at once - which is what burnsim or opensim assumes - but in real life the burn would generally start at one point and quickly spread. What it actually does, depends on what igniter was used, age and surface condition of the propellant, and a host of other factors. The startup in your motor could look significantly different than what was measured when the rocket was tested on the manufacturer's test stand when the thrust curve data was gathered. The entire launch - from when the rocket first starts to move, to when it clears the rail - occurs over a miniscule portion of the overall launch curve. a bit of variance here from 'ideal' looks like nothing in the overall curve, but has an enormous effect upon rail velocity.

As a worst case example, consider a chuff. During a chuff the entire exposed surface of the motor is not burning, and it's not generating anywhere near the initial thrust indicated by a curve. Sometimes it generates enough thrust to lift it up the rod quite a bit (I've never seen it come completely off the rail, but I suppose it's possible.) Imagine an ignition that started as a chuff, lifted the rocket a bit, and quickly turned into a complete ignition. Your launch velocity off the rail could be very close to zero.

 

[Richard Dierking]

Thank you Kelly. I've wondered if the orientation of the motor during static testing vs actual use for launching changes the start up. The majority of the time, the motors are tested vertical down because it's easy to obtain load cell readings and also secure the motor for the static fire.
For one thing, I wonder if the cap supplied with the motor is used for this testing? It probably wouldn't be necessary because the igniter would sit in the motor without falling out of course if the motor was tested vertical down. I believe that how the igniter is secured in the rocket motor on the pad would change the start-up.

For my testing, I will be using the igniter supplied with the motor along with the cap cut on an edge to allow for the insertion of the igniter lead. If I have to recycle the igniter, I will use the same kind from the manufacturer. I'll get a close up photo next time.

Also, I'm planning on conducting many launch velocity checks over an entire year, so things like ambient temperature might affect the startup.

I will try and keep the launch rail in good condition and clean it each time. When it becomes worn or damaged, I have a spare new rail. But, I would also like to launch a few rockets off of dirty rails.
I need to make a sensor set-up for a 1515 rail.

When you all are placing your rocket on a rail in the future, please consider how it's going on the rail and if the button could bind/resist during launch. Let's say, from a bit of thrust vectoring from the motor depending on the grain configuration or even the wind. Or, how about the rocket thrust hits the blast deflector and jogs the pad to either side during the launch.

 

[jqavins]

I think the biggest source of difference will be between how your actual motor is starting up vs. what the thrust curve says it does...

That, sir, sounds like an amazingly good point.

Does anyone know if CTI's ignition pellet helps in this regard? Whether due to the pellet or not, do folks get any less or more chuffing with CTI motors than with AT motors? (I am assuming that prevalence of chuffing is an indicator of lesser starting issues.)

 

[Richard Dierking]

I'm looking forward to hearing responses to Joe's question.
BTW, for reference, in the latest NAR Electronic Rocketeer (Sept 2020) there's a short article by Stephen Lubliner, Safety Committee Chairman, titled Safety First - Getting a Safe Liftoff.

 

[jqavins]

I wonder what it would take to put a kilosample/sec acceleratometer on the rocket? That really should do the trick.

See graph in previous post. Teensy 3.6

OK, the Teensy line looks nice, and certainly faster than Arduinos. However, an Arduino is fast enough for 1 k sample/sec on an analog input. The trick is finding an accelerometer with an analog output (since that can be sampled at an arbitrary rate, unlike modules with serial outputs) and capable of the the peak acceleration that would be needed.

As to the graph, I assume you mean post #89. That's altitude, and probably from a barometric sensor, not an accelerometer. Differentiating that for speed amplifies noise in the readings. Also the text in the lower left gives the number of samples, and dividing that by the end time from the axis gives 20 samples per second, where I'm looking for 1000. (More would be better. For a lot more I'd need something fast, such as a Teensy.)

 

[UhClem]

As to the graph, I assume you mean post #89.

Nyet

 

[jqavins]

OK, to which "graph in previous post" are you referring?

 

[manixFan]

OK, to which "graph in previous post" are you referring?

Dave likes to be clever. His answer is a link to the correct graph, which is post #51:

https://www.rocketryforum.com/threads/launch-rail-velocity-simulated-vs-actual.160656/post-2032952(Ignore the preview text, it does not accurately reflect the link.)


Tony

 

[AllDigital]

Richard, this is a very cool project. I'm coming in late to the conversation, but I have a few ideas to add.

I really like your test approach. I think a single sensor at the top of the rail triggered by two launch lugs should give you an indication of launch rail velocity, but given how much it is accelerating, the speed two feet lower or two feet higher could be significantly different. You should confirm with Apogee (RockSim) how they calculate, but it seems to me that if you are using (hypothetically) a 10 ft rail, but your center-to-center lugs point is at 3 feet then you would compare to a 7 foot rail in the sim (e.g., rocket travels 7 feet to capture the average velocity between the two lugs). I didn't catch your sample rate on the Arduino, but obviously high resolution sampling matters in this case (>1000 Hz / 10K Hz better), since the distance and time intervals are so short.

That said, it doesn't surprise me that the real world number is slower than the sim. I would expect the sim to be a best case number, since it likely doesn't account for rail friction, slower ignition, etc. But, it does raise a lot of questions if you are consistently off by orders of magnitude.

In my experience with static testing motors (load and pressure), the real-life curves never look as good as the published or predicted curves, especially in motors with 2+ grains. As others have said, it just takes longer for all the surface area and ends to ignite and for the rocket to fully come up to pressure. "Longer" in this case could only be milliseconds, but it is enough to start the rocket moving up the rail, just not as fast. It might be at half the sim speed at 8 feet but then full sim speed by 10-12 feet.

It is hard to understand the real-world results with just one data point. Launching the same rocket over and over gets time consuming and expensive. The other hack that would be interesting would be to use the Newman 20 foot rail at FAR and put three sensors, so you see the velocity at three different points in the launch. There is no end to how far you could take this

 

[jqavins]

Dave likes to be clever. His answer is a link to the correct graph, which is post #51:https://www.rocketryforum.com/threads/launch-rail-velocity-simulated-vs-actual.160656/post-2032952

Thanks. UhClem, would you be so kind as to share the raw data?

That said, it doesn't surprise me that the real world number is slower than the sim. I would expect the sim to be a best case number, since it likely doesn't account for rail friction, slower ignition, etc. But, it does raise a lot of questions if you are consistently off by orders of magnitude.

Not rail friction, but see below.

In my experience with static testing motors (load and pressure), the real-life curves never look as good as the published or predicted curves, especially in motors with 2+ grains.

Predicted, yes that makes sense. But the published curves are from tests. While ignition timing down to milliseconds could surely introduce variability, the published won't be consistently better than any other test run (including test runs where the test bed with fins and stuff moves) as sims might be.

 

[UhClem]

Thanks. UhClem, would you be so kind as to share the raw data?

It's big. Over 30MB zipped so if there is something in particular you want maybe I can cut that down a bit.

 

[Kelly]

the published won't be consistently better than any other test run

If you're saying that the thrust curve published by a manufacturer won't be consistently better than an 'in the field' test run, I might disagree. I have no doubt that for a qualification test, the manufacturer ensures that a fresh motor is used, from a known good lot, and the best possible igniter is used. These might consistently provide better results.

 

[jqavins]

Aging, yes, that's a point. Known good lot: sure, but there's no point is discussing bad lots at all for this topic; when certification is done there haven't been enough lots made to know if one lights significantly more easily than another, so the certification sample is as likely to be from barely OK lot as it is from an uncommonly good one. And I confidently assume that the igniter in the test is the same type as the igniter packaged with the motor, because the product for sale is the combination of the two, and it's the product being certified.

It's big. Over 30MB zipped so if there is something in particular you want maybe I can cut that down a bit.

The first quarter second after T₀ should be plenty. Do you know why these happen?

It looks like ringing in the sensor or the circuitry after a sudden change, but if you know, knowledge is better than guesses. That third one looks especially odd, since one would expect the motor to be burning quite steadily by then, and one wouldn't expect such a "great disturbance in the force." Anyway, I should be able to dig out my old DSP textbook and clean things up a bit.

 

[jderimig]

If you're saying that the thrust curve published by a manufacturer won't be consistently better than an 'in the field' test run, I might disagree. I have no doubt that for a qualification test, the manufacturer ensures that a fresh motor is used, from a known good lot, and the best possible igniter is used. These might consistently provide better results.

I may be mistaken but I think the certification thrust curve is taken at the 5% and 95% levels of the burn. Any anomalies before the 5% point is ignored an not shown.

 

[Richard Dierking]

The new rocket (modified LOC 2.26" Tomahawk) is done and ready for the second rail exit velocity test. The two black stripes are 12" apart. The black stripe on one of the fins is so I can watch for roll after launch.
This time the motor will be a AT I218R which starts out slower than the I180W. I haven't completed putting the design into Rocksim, so I'm going to do the rail measurement and video before obtaining the sim value.

 

[UhClem]

If you want to compare your video data then the stripes should be at the same location as the buttons. If you want to watch for roll, you need a roll pattern.

 

[Richard Dierking]

Unfortunately, the break beam sensor didn't work correctly yesterday. The reading was 1 ms. Don't know what happened, so I brought the set-up home to take a look.

I need to create a easier and more compact set-up for a 1515 rail (5/16" rail buttons).
Having the rail button set-up and measurement as the major part of the launch is going to be a drag, so I need to streamline the set up and process.

If you want to compare your video data then the stripes should be at the same location as the buttons. If you want to watch for roll, you need a roll pattern.

I thought about that but decided to just simplify the painting process with the location of the stripes. The video is more of a back-up to the sensor than a comparison. I did all the comparisons during the drop tests.

What I would like to see more than anything else is other people taking video and maybe using their own sensor equipment and posting some results.
I've decided to focus on some other projects like my HL-10 scale lifting body and just have the rail exit velocity research as a small side project.

Downloading the video for analysis today and will post some frames with the results.

 

[Richard Dierking]

I still need to complete the Rocksim file and run the sim for the new rocket. It was lighter than the first rocket at 3.17 lbs with I180W vs 2.13 lbs with the I218R motor for this test. To me, this second rocket looked quicker off the rail and the video analysis seems to show that it did. Rocket looked very stable and went to 3718'. It was about 90 F with no wind.

Take a look at the two frames below. The camera was at 239.8 frames/sec. The rocket moved one foot referenced at the top of the 8' rail in 0.0125 second. So, 80 ft/sec at that point in the launch. The black stripes on white background work well for the video analysis but it would be better if they were farther aft with the bottom stripe at the bottom rail button. I'm considering repainting that part of the rocket.

Again, the break beam sensor didn't display a good reading for this launch. It showed 1 ms. Presently, I don't know why.

I need to make the break beam sensor set up easier to set up and eliminate the long cable going down the back of the rail. Also, I'll be creating a 1515 rail version.

Following tests for 1010 and 1515 rails will use existing rails; cleaned but they show use.


Frame 1862: First stripe at the top of the rail.


Frame 1865: Second stripe at the top of the rail. So, 3 frames at 239.8 frames/sec. 12.5 ms for 12" of travel. 80 ft/sec.
I think I'm going to move the camera closer for the next test. But, these video frames are pretty clear. This would not be possible at something like 30 frames/second. I took video with another camera at that speed.