Launch rail velocity - simulated vs actual

[Richard Dierking]

Here's an image of the showing the ascent on 10-03-20 using 15 FW GPS data points . At apogee, I lost the signal due to a disconnected battery. I rebuilt the holder that goes in the nose today to prevent this from happening again.
The upward track to 3718' AGL is very straight and above the launch site. Surface wind was 0 to 3 mph. Lots of smoke in the air but otherwise a great day to fly rockets.

 

[Richard Dierking]

I repainted the test rocket. Now, there's a stripe at the base and going forward, a stripe at 12" and one at 18.56" (one of the original stripes). So, from now on, I'll use that two stripes at the base and 12" for video analysis. The aft rail button is at the midpoint in the base stripe.



I completed the Rocksim file for this new rocket. Had a glitch from an incorrect rail angle setting, but corrected that. I used the midpoint of the two original stripes to the top of the rail for the guide length (83"), and set other parameters to the conditions at the time of launch. With the AT I218R motor, the sim showed 4119' and velocity at guide departure of 90.9 ft/sec. The altimeter data showed 3718' and video analysis at 80 ft/sec rail exit velocity.

Actual isn't too far off sim this time.

I'm continuing to make a new IR break beam sensor set up so all the electronics will be positioned at the top of the rail, so no long data cable to deal with. Also, this set-up will be for 1010 and 1515 rails and also the custom rail for my new launch pad.

 

[jqavins]

I've just had an idea for another way to approach this. Someone earlier suggested using microswitches and your reply, if I' remember correctly, was that you couldn't modify your club's rail or impose the test on other flyers who didn't want to take part.

So what it you made a small section of rail that contains two microswitches and can be added to the top of a club rail without modifying it? Other flyers can go off of other pads, or you can remove it if needed.

The lever type switches, or better yet lever with roller type switches, take very little force to activate, so they really won't interfere with flight.


They'll bounce when a rail button goes by, which is why you use two of them; the first contact made is the moment the upper rail button makes contact. After that it doesn't matter how the switch bounces or when the second button hits it; all that matters is the time from when the lower switch is hit to when the upper switch is hit. The first switch kicks off a fast counter and the second switch stops it.

 

[Richard Dierking]

I like this approach for the rail and pad I'm making. I'll send a photo showing the rail compared to a standard 1515 rail. The switches may be able to be installed inside the rail.

Do you think there would be too much bounce to record the second button if it was about 24" from the top (forward) button? This way it would be a measurement of the velocity at the aft end of the rocket when it departs the rail.

Maybe I could even add something like a spring return to control bounce and quickly return the switch to open position.

 

[jqavins]

I would bet bounce will be a problem if you're trying to catch both rail buttons with a single switch. I wouldn't bet much on it, as it depends on many factors, such as the switch's internal bounce characteristics and the time allowed between buttons (i.e. how fast the rocket is going). I suggested two switches rather than looking for two hits on one switch for exactly the reason that I don't think you can count on one switch not to bounce.

By the way, do you know what I'm referring to when I speak of switch bounce? No offence meant, but I got the impression that you may be thinking of the lever on the outside bouncing, and I don't know your background or experience level. So I have to ask. If I'm trying to educate the educated, or lecturing to the professor, please skip the following paragraph.

What I'm talking about is bouncing within the switch, which is pretty much inevitable. The keyboard attached to your computer has key bounce, and uses circuitry and/or software to compensate. Such measures slow down the response of the switch. Leaving such measures out gives you a more accurate indication of the moment the switch is hit, but also means that everything after that for an unknown amount if time is useless. This looks like a pretty good explanation (though I haven't read it carefully.)

Also, when it comes to keeping the rocket pointing up, the moment that the forward button leaves the rail is the most important thing. So if the second switch is as close to the top of the rail as you can manage and the first is, let's say, a foot below it, then I think you'll have good results.

 

[Richard Dierking]

Also, when it comes to keeping the rocket pointing up, the moment that the forward button leaves the rail is the most important thing. So if the second switch is as close to the top of the rail as you can manage and the first is, let's say, a foot below it, then I think you'll have good results.

Good point Joe.

I was actually considering both types of bounce; electrical and mechanical. But, two switches would handle that problem nicely.
And, I always appreciate your expertise on electronics, so never offended by your explanations.
I was thinking that the rocket and therefore the rail buttons are really going to be hauling down the rail track. What's going to happen to a microswitch lever and button when it's impacted by something going 50+ ft/sec? I've never done that to these kinds of switches. And, the position of the buttons in the track is really not that tight. There's some tolerance for lever switch activation, but I would need to experiment a bit to get it right.
I guess if the switch lever was just impacted at the very tip it would snap closed.

 

[jqavins]

I haven't any experience with such switches at such speeds either. What I expect is that with the low angle of the lever, if it's positioned so that the action does not bottom, then it should be OK. Of course, "should be OK" are dangerous words. So yeah, it bears testing.

 

[UhClem]

Are those switches sealed against all the chlorine containing combustion products they are going to see?

In any case, going to a mechanical system seems like a step backwards.

 

[jqavins]

Ooh, good question about the exhaust. I'll bet some are, and that's certainly something to wach ot for when selecting parts.

 

[Richard Dierking]

Are those switches sealed against all the chlorine containing combustion products they are going to see?

In any case, going to a mechanical system seems like a step backwards.

Yes, great point. I brought home and cleaned the rail today. It's only been used two times, and you would be surprised how dirty/worn it has was after just two rockets. And, the white lightning and redline are not "dirty" motors.
I was an equipment manager for about one year for a club and I've cleaned a lot of rods and rails, but I didn't realize the abuse of just one or two motors on a rail. And, the sensor was showing it too.
For the new sensor arrangement, I have some FR4-G10 shields for the LED and Sensor. On the 1515 rail, I'll be using K's and L's and I bet it's going to be tough on these electronics. Anything mechanical will be effected quickly. It might even mess it up on the first rocket.

With experience, I'm seeing that a more remote sensing arrangement or the video analysis method might be the most practical. Although, from the drop testing, using the GoPro at 240 frames/sec will not be as accurate as the break beam.
Or, maybe even rocket accelerometer data, although I don't have the expertise to obtain good results for that method.

I'm considering a better high speed video camera. I would greatly appreciate some guidance on that.

There's another thing I'm thinking about when I cleaned the rail; the wear (pitting) and the deposits from motors might be a big factor in slowing rail velocity. So, it's going to be interesting when I start using used rails.

Sorry I'm going on a bit. But, I think it would be interesting to take a 2' long block of wood, install a couple of new rail buttons on it and run it through the track of new and used rails. When you are loading a rocket, the mass of the rocket moving on the rail may mask the amount of resistance the rail is putting on the launch guide. And, like I mentioned previously, there could be significant binding because of lateral movement of the rocket during the launch, like from wind or from lateral movement of the pad from supersonic exhaust hitting a blast deflector.
Dirty/worn rail, rail buttons that have lots of play, and lateral movement causing binding may significantly affect the rail exit velocity.

 

[UhClem]

Dirty/worn rail, rail buttons that have lots of play, and lateral movement causing binding may significantly affect the rail exit velocity.

Of course. Friction being proportional to normal force.

A simple test is to hang a rocket under a horizontal rail and then slowly increase the angle of the rail. What you want to find is the angle where the rocket just keeps sliding once in motion. The angle tells you the dynamic coefficient of friction. This assumes that the rail button positions aren't so odd that you get weird torque effects. Like both over 2 feet from the CG.

(Remember that old high school physics experiment with the inclined plane?)

 

[Richard Dierking]

Good discussion. I don't wish to take this "off the rails" but it's good to consider the possible reasons for lower rail exit velocity than expected and maybe come up with some solutions.

From what I see cleaning rails, the added friction of wear and deposits is greater at the bottom of the rail and decreases, so it's not uniform. Because the rocket velocity is increasing you would expect this. Keep in mind that it's a lot easier cleaning a polishing the outside surface of the rail. The inside of the track is a lot more difficult to clean. We used to soak the rails in vinegar to help soak off the deposits in the inside of the track. But, the pitting remained.
And, maybe which direction the rail leans would affect the amount of resistance. I would think that many times, rails lean back away from the flight line so you can see the rocket without the rail in the way. But, from a friction reduction standpoint, is this the best way to lean the rail?

I know moving the wood block with the buttons along the rail is highly subjective, but it might provide some clues. And, many people could do this using their club's rails for examples. Also, might indicate that it's time to rotate the rail to another side or retire the rail.

So, what do you think about high speed cameras? I don't want to use my iPhone because it's busy with the FW GPS application when I'm launching rockets.

 

[Richard Dierking]

I took a close look at the first IR break beam sensor arrangement and results of exposure to the rocket motor exhaust are obvious. The LED has a glaze on the surface and the sensor also has a film/cloud on the surface even when it was protected by the brass tube. This was after two tests and the 2nd test failed. In this second test, I determined that the sensor only detected one rail button, and that's why the reading was 1 ms.

I don't want to have to disassemble the break beam and clean it every time I use it. If I use the laser break beam which is still a light source and optical detector or switch to mechanical devices, the system is still going to suffer from degradation from the extreme environment. It just will not be reliable. I'll take another look in the morning and consider the new set up I created, but now I think I pursued a method to a conclusion and it's time to break up.

Parting is such sweet sorrow that I will say goodnight till it be morrow.

 

[Richard Dierking]

Yup, I'm going to scrap the break beam sensor arrangements for rail buttons and switch to video analysis for the primary way to measure rail exit velocity.

Using microswitches may work, but that would take some time to build and work out the bugs. Plus, I would need to make at least two for the different sized rails.

I did some checking this morning and the only camera I can find at 240 frames/sec or better is the GoPro. There are better cameras but they are way out of my budget. So, I'm going to stick with GoPro 8 until something better comes along. I would like about 500 frames/sec with good resolution.

I think it's good to keep in mind that the primary objective of this thread is determining actual exit velocity and comparing results to simulated value. So, the methods can change.

And, if anyone else wishes to post their results that would be cool to see.

I need to refine my technique using the GoPro 8. I need to paint a 1" wide stripe at the top of the rails I'll be using to make it easier to see in the video. I need to determine the best lighting. Perhaps morning with the rocket facing the Sun and camera at enough angle to see the rail behind the rocket.

The accuracy is going to be less than the break beam when it's working well. We'll just have to see how much difference there is between actual and sim.

I appreciate the continued comments and suggestions.

 

[GalantVR41062]

I have been going over a plan for a while on how to accurately document the actual rail exit velocity for model rockets.

A Chronograph as mentioned early on in this thread is a good option.



I feel this has some limits and possible complications in the field trying to document data.

The rocket will need to be small enough to pass through the Chronograph. I might experiment with different shape and length rods for the light reflectors.

I also plan to shield the Chronograph from direct sun light via cardboard box or a piece of 16" sono tube if I think it's causing issues gathering the data.

I fabricated a mounting system to go on the top of a standard 1010 rail.



I can adjust the overall height and offset from the rail of the Chronograph. I want the nose cone to brake the beam as soon as it clears the top of the rail, with in wind and vibration limits. I can wiggle the rail a bit before the device says E for error.

The device is a cheap one off Amazon but is rated for 5-6500fps. It can also display M/s and joules.

 

[Steve Shannon]

Drill two holes one foot apart at the top of the rail. Mount an LED and photo eye in them (or use two hall sensors triggered by the screws in the rail buttons). Measure the elapsed time between the last two pulses. Invert it and it’s feet per second.

 

[shockie]

This. :
https://www.apogeerockets.com/education/downloads/Newsletter292.pdf
Plus this:

https://physlets.org/tracker/
Would provide you with the velocity information you need.

Plus this:

A FlightSketch altimeter

The 1st two in combination would be very accurate, and have been used in the past to determine piston velocity.

Add the FlightSketch or other similar altimeter and the accuracy and precision would be high.

 

[Rex R]

I recall folks using bullet Chronos to measure muzzle speeds of 2" cal potatoes from launchers. And I recall folks using magnetic coils with a tape recorder(take the tape home and feed it to a computer), provided you use ferris screws on your rail buttons that should work too.

 

[Richard Dierking]

Going to be interesting seeing some data. Really looking forward to it.

 

[jqavins]

It can also display M/s and joules.

Joules? Do you enter the mass somewhere?

 

[GalantVR41062]

I have been working on and off on this project and am here to report some data.

I decided to use the Chronograph as pictured mounted to the top of my shorter 1010 launch rail. I had a calm evening and the sun was just below the horizon.



I decided to modify my Magician a little by adding rail buttons and updating the OR sim file for all the details on the rocket and flight profile.

I decided on a Aerotech D15T-7 reload for the test. I layed the rail/Chronograph and rocket horizontal and measured the rail button location at rest, first beam and 2nd beam.

So this is not measuring the actual rail exit velocity as the rail buttons are still on the rail as the nose cone goes through the Chronograph. So I changed the simulation configuration for 2 different rail/rod lengths. I measured to beam 1 at 22 1/2" and beam 2 at 33". I verified with the tape marks on the rail and rail button location. Rocket weight on the pad is 5.64oz or 159.89grams.





I had a Flight sketch mini on board but the flight did not record properly, could have been a bad battery. But the simulation shows 880', rail exit velocity for 33" is 57.9fps and 22.5" 47.2fps. I also ran the numbers for actual rail length of 43" and 67fps. The wind was from the south/south west. The rocket did angle to the north just a little on the way up. And landed about 750' from the launch pad.

I have some screen shots from the video and the fruit of this labor here:



46.6 fps, I did not look at how or if the unit can actual display joules.

Thank you for the energy calculation and now we could figure that out based on model weight.

½×0.3525 lb×(46.6 m/s)² ÷ 32.2 ft/s² = 11.9 ft∙lb

 

[jqavins]

I did not look at how or if the unit can actual display joules.

It can't possibly display energy unless you enter the mass. ½v² is the specific energy, i.e. the energy per mass, and that's so easily done that I don't see much point in having the chronograph display it. So, for energy,
½×m×(46.6 ft/s)² is the energy. Unit selection and conversion to end up with Joules is LFS.

More importantly, are you satisfied with the result? The point of the project from the beginning was to answer "how well does the rail exit speed in reality match that in simulation?" From a sample of one, it seems like a pretty good match. It would be better to run the test multiple times, with multiple motor motor batches, and ideally for a few different rockets and motor choices. But, as that would be expensive and time consuming and would get lots of exhaust schmutz on your chronograph, are you satisfied with this result?

 

[GalantVR41062]

I would say overall yes I am satisfied with the results.

I have been going over the details on the test and only slightly disappointed in a few things.

With a sample size of 1 the simulation was only off by 23.5% from the long number 33" and 1.2% of the short number 22.5".

I also realized early on this would be a average number like a trap speed in drag racing cars as the rocket is still accelerating through the Chronograph.

I was hoping to have the flight sketch data and look at the G graph and do some calculations and make my own thrust curve for this load. I have flown plenty of D15 loads and overall they have been consistent. The burn time was spot on, almost instant on and accurate delay time.

I do plan to use this some more as my 10 year old daughter is excited about rocketry and can not wait to be junior L1. I can test with a D9w, B6, C5, E12 and for a higher number F44w, F35w, F51 but I need more recovery room for a test like that.

I updated my previous post with rocket weight and energy calculations.

 

[jqavins]

Thank you for the energy calculation and now we could figure that out based on model weight.
½×5.64oz×(46.6 ft/s)² = 6134.657
½×159.89grams×(46.6 ft/s)² = 173,605.3642

159.89 g = 0.15989 kg. (The joule as the unit of energy is part of the MKS system, so mass needs to be in kg.)
46.6 ft/s = 14.2 m/s.
½×0.15989 kg×(14.2 m/s)² = 16.1 J.

Or, if you prefer,
5.64 oz = 0.3525 lb
½×0.3525 lb×(46.6 m/s)² = 382.7 lb∙ft²/s², which looks really weird until you remember that technical calculations with English units of mass and weight often require extra factors of 1 gee here and there. (And then you know the real reason that metric units are so much better; it's not the moderately convenient decimalization, but rather the clear, unambiguous distinction between mass and weight [force].) So, to take lb∙ft²/s² and get ft∙lb, we need to divide out 32.2 ft/s².

½×0.3525 lb×(46.6 m/s)² ÷ 32.2 ft/s² = 11.9 ft∙lb.

And now you also know the importance of keeping your units straight. the 6134.657 and 173,605.3642 above don't mean anything (unless you feel like tracking all the units through and applying appropriate conversions, but it's a lot easier to apply the conversions before the squaring and multiplying.)

 

[shockie]

I dunno, I find it all kinda fascinating. I just spent a month on a job in Montana, much of it on standby, swapping "war stories" with my data acquisition engineer, who spent a lot of his career in high speed data acquisition, where you're acquiring photos and other data an 10,000 fps or more for crash analysis, airbag deployment, performance, handling etc. Now THAT would be something to see! (Side note, he was amazed I needed data points only every 15 minutes, and even that was a bit extravagant on my part!)

When I first started into rockets over 50 years ago, as a (dim memories...) maybe 10 year old or so, the idea that we'd be launching digital video recorders, GPS sensors, and so on in our rockets was of course completely unheard of. Recall the old Estes Camroc with the disc of film you had to attempt to mount in complete darkness by feel in the field with some sort of bag over your arms?

One thing that I really liked as a youngster was discovering how you could design these things using mathematics. But transients are difficult! So what we want to do is draw the youngsters in, and I think there is no better way than to give them a very exciting demonstration of F=ma. See how close the measured weight and the thrust curve matches those first few feet, etc. Do two, three or four flights using the same engine compare well? Always, the better we can calculate and predict, know our "scatter", etc. the better off we are.

Then you can get into all sorts of things - rod bending & whip, the possibility of rail chatter, esoteric things like that that may be moot or seemingly useless, and may well turn out to be so... is it overkill? You bet! But as various folks among us ferret out these little things pursuing the application of their passions, we all benefit.

EXACTLY!

 

[GalantVR41062]

I did make it out for another launch with the Chronograph.



The same rocket, weight, reload and launch setup as last time. It was colder and windy for attempt #2.

The FSmini recorded and everything looks good. The rail exit velocity was 5% less then last time, the rest of the flight profile was within 2% of the simulation.

 

[jqavins]

The rail exit velocity was 5% less then last time, the rest of the flight profile was within 2% of the simulation.

Well under the allowed variation in motor performance. I would call this a nail in the coffin of the "sims are wrong" theory.