Cesaroni has again come out with some new motors which will be available for the first time in the US at LDRS (as I understand it). Since they are so new I don't know if anyone has created any .eng files for them and thought, maybe, I'd take a stab at doing so.
Looking at the motor information and thrust curve posted on the CAR web site one question immediately comes to mind: What time interval is minimally required for a representative .eng file for computer simulation software (specifically RockSim)? The K660 thrust curve has .4 second intervals on the graph and it seems it would be relatively easy to interpolate the pounds of thrust from this graph. Would four tenths of a second time intervals produce an accurate enough .eng file?
Pete, The samples don't need to be evenly spaced (unlike is common in digital signal processing). Instead, you are limited to 16 or 32 total sample points. I think 16 for wRASP, 32 for Rocksim, IIRC. Otherwise the file formats are the same.
Anyway, the key is to pick out 16 points which best fit the curve. It's frustrating doing it by hand. I've wondered how the NAR does it. They seem to be the only testing agency providing the data in this form.
Anyway, I've tried to think up a computer algorithm which might be used to massage the huge firing files down to the desired 16/32 data points. In signal processing, we have things like decimation- in-time filters, but they'll change the shape of the curve since they're locked into fixed sampling intervals. A more sophisticated scheme would be needed to pick out all the key peaks and valleys and then fill in from there, but establishing the criteria for what is "key" is totally arbitrary, and prone to generating too many sample points.
Here's an idea: Maybe we can ask S&T if they would provide a service of taking TMT and CAR files and generating wRASP files for us :)
Seriously, even then, I wonder how good the data is. If all you have is one firing file for a motor, you can't help but wonder how "typical" it is for that motor type. You'd really like to have at least three files averaged together. Ideally, three files, one each from three different production batches.
I've done it using graphical techniques, reading the measurements off a ruler, then scaling them in a spreadsheet, but there's lots of ways this is error prone.
OTOH, you wonder if that's really any worse than not having multiple test files...
If there was a way to view the firing file data in a graphical form, then pick out key points (using the computer), that'd be great. But if you try to open a file like that in Excel, the graph blows up. You would need a special graphing tool better suited to the task.
Ya know, tho, Rocksim's engine editor could be morphed into such a tool. If it could read the firing file, then allow the user to select the key sample points, then show the comparative data (impulse, avg thrust) for the two sets of points (ie, set and sub-set), the user would be able to get a feel for the error. The tool could even calculate the mean-squared-error to assist the user in placing the points.
I have an excel spreadsheet that I use posted here:
formatting link
The instructions are very poor but if you can figure it out it works great. I just capture the screen, paste it into Paint and use the cross hair (and numbers in the lower corner) and convert to real points.
On Wed, 16 Jul 2003 14:45:11 -0500, "Pete Lilja" wrote:
;FILE FORMAT: ; No tab characters. ; No blank lines. (Note, blank lines at the end of the file ; are a common problem ; ";" character in column 1 denotes a comment line. ; At least one comment line that is otherwise blank must ; separate each motor type. ; ;DATA FORMATS: ; General: ; No particular column spacing is required. ; Space delimiter between fields. ; Simple decimal numeric format; leading/trailing zeros are ; don't care. ; Scientific notation is not supported. ; No comment lines may intrude between any data lines of a ; motor type. Comments lines may appear before or after ; a motor's data set. ; Each motor listing consists of a header line, followed by a ; number of time/thrust data lines. The maximum number ; of time/thrust points is not specified and will be limited ; by the particular simulation program using the file. ; ;EACH INDIVUDUAL MOTOR:==================================== ; Header Line: ; Size (mm) Delays Weight (Kg) ; Type Dia x Len (sec) Fuel Total Mfg/Notes ; ; Time/Thrust lines: ; Timepoint (sec) Thrust Level (Nt) ;========================================================== ; ; Header Line Format Notes: ; The type, Delays, and Mfg/Notes fields are any ASCII text with no ; embedded spaces. Other fields are numeric ASCII only. ; ALSO: Plugged motors use a delay of 37 as a space filler (and plug code). ; NOTE: heaviest motor of each type is used for basic mass. ; The Diameter and Length fields must be an integers! A decimal point ; is not allowed. (A decimal point in the Diameter field will ; cause a load error; a decimal point in the Length field will ; allow the file to load, but the data will be parsed incorrectly.) ; This is probably only particular to wRasp, I doubt that other ; sim programs would have this limitation. The other numeric ; fields are real numbers. ; ; Time/Thrust Format Notes: ; No zero thrust level may appear before burnout. ; Time/thrust points must be in chronological order. ; If a timepoint of zero appears, the corresponding thrust level ; must be greater than zero (this is typical of data derived ; from ALT4 motor files). ; If the first timepoint is greater than zero, a thrust level of ; zero is assumed at time zero. ; DOS RASP89 and wRASP up to v1.6 are limited to 32 time/thrust pairs per ; motor. ; wRASP v1.61, v2.0 and v2.1BW are limited to 64 time/thrust pairs per motor. ; wRASP v2.1 is not limited per motor, but has a maximum of 16384 time/thrust ; pairs for the entire motor database. ;
Take a look at R. Dh8's response and the spreadsheet of his. It seems to do just what you're talking about - allowing points to be grabbed off the thrust curves profile so readily available. It is simple, yet effective - I hope!
Thanks again, Robert. By using your spreadsheet and technique I just created a very believable simulation with one of the new Cesaroni Pro54 motors.
For all of you computer sim users try this very clever technique. I think Robert has come up with the first easy method to create .eng files from a thrust profile.
Thanks again!
Pete "the corn hatin', .eng file maker from analog data, RockSim user" Lilja
and opened it in M'soft Paint. I then got the x & y coordinates for zero and max thrust (on the chart-watch out for the pounds/newtons conversion trap - RockSim requires Newtons in the Engine Editor program) as well as the coords. for zero and maximum time as displayed in the lower right corner of the Paint window (it looks like the: 77, 94). The starting/ending coordinates are entered into the spreadsheet in the top two boxes of Robert's spreadsheet which he provides on his web page. To fill in the thrust profile I used the crosshair cursor to grab points and their coordinates and then entered those in the same way into the lower boxes. The spread sheet gives the appropriate time and thrust points to enter into the 'Thrust Data Info" window of the Engine Editor. You then have to run the Engine Data Compiler program and also 'reload the engine data' in RockSim itself.
I used 20 points that I grabbed from the thrust profile that seemed appropriate based on nothing other than guesswork and what I thought would approximate the displayed curve. While I cannot guarantee that it is an accurate .eng file the resultant sim I ran from the newly created Pro54 K660 compares appropriately well to the K550 sim and that .eng file came from Apogee in v. 6.0 of RockSim. The K550 sim closely approximates what my recording G-wiz altimeter displays so my confidence level is rather high in using Robert's clever technique.
It is late and I'm not sure I've explained this as well as I could. Any other questions - please feel free to ask.
I hadn't realized you could read the coordinates off the screen in Paint.
This method is about halfway between the drafting method and what I deem ideal. You're able to use the computer to read off coordinates, but you're still prone to introducing errors. If you're careful, they'll be small, and shouldn't have any significant effect on the sim results.
One difference is the (still ethereal) method I described lets you highlight a point on the curve, so you get the coordinates of that point, and not of the cursor. It's a subtle difference, I know, but, hey, it's a computer, it ought to be able to do that, right
Anyway, the other key is that the computer will automatically read the datapoint without you needing to manually transfer it.
I've used Robert's flow much as you described starting with a graphics file, but, in on case, the file had been printed, copied and scanned too much.
The image had key-stoned (due to the imperfections of the Xerox process) and as a result, the axes were no longer at 90 degrees. Here, you have to do some guesstimation.
The ultimate goal is to automate the process. You may find this ironic, but there was alao a pdf file next to the jpeg on the CAR site. I can open that pdf in Illustrator, and see the dots which make up the curve. Theoretically, all those dots are defined by numbers which should be somehow extractable from the pdf - no need to do any eyeballing for numbers, they're already there, if we can figure out how to read them.
You're question got me wondering about what "typical" is in regard to these published thrust profiles.
Since I've been using the data from the CAR web site I poked around a bit and looked at their Motor Testing Manual available here in PDF form:
formatting link
CAR minimally requires three motors for initial certification testing and these thrust profiles are then overlaid with the one most representative of the three chosen as "typical" (see p. 21 of the manual). Of course I don't know just how this particular profile is chosen (eyeball, arithmetically or what) but it is, hopefully, more representative than a single firing. I'll have to leave to others more well versed in sampling if this is a truly acceptable method. I'd further guess that they are not from different production batches - especially on brand new motors. However this testing procedure is done it seems to have worked for a number of years.
With only three motors tested, your best procedure would be to model each motor tested, and run your simulation three times with each motor data set. Then look at the mean resulting performance, and worst case expected performance.
(I can't access your post, so I'm replying via Alan's.)
The certification testing has been debated here before. While I don't think it's sufficient for it to come up with a truly robust model, I understand and support it for certification purposes. I recognize the need to make the testing less demanding for the sake of expediency.
But the test is non-trivial, and therefore, I think, ensures reasonable quality. Without getting into a bunch of math I'm really, really rusty at, I see it this way: If the manufacturer can submit 3 motors which all meet the specs, then he likely has his stuff together.
Remember, motor testing is destructive testing, so he can't test 3 motors on his test equipment, then resubmit them. He must instead submit other motors, and must be confident that his processes are yielding with enough consistency that these motors will be so close to the others as to be indistinguishable.
So, I think cert testing is good for validating the product.
But for coming up with sim models, I think we need to average over several batches. Ideally, they won't vary widely from batch to batch, but in the real world, I think they can vary enough, for example, to make you wish you'd chosen a different delay for a given situation.
Or maybe the center moves, and the typical production motors all average 8% less impulse. Again, here's where using thrust curves from many batches over a long time will help keep the model more realistic.
All that said, now that you've got me thinking about it this much :) as long as the motor's sim model is only reasonably close, it should be OK. There are so many other variables, and lady luck, too, that getting the motor file too close is overkill. It's like paying for high precision resistors and then mixing them in with your 5% parts. The rest of the rocket (sim) model (and environment) isn't accurate enough to justify getting the motor model that close.
Actually, I have already rendered most of the new motors for .eng files. It's been a very busy weekend or I would have had it done by now. I'll be posting the completed .eng files on my website hopefully by Wednesday. I'm including the Pro75 motors this time as well, which will mean that the only one missing is the Pro150 (but I'll get that one done soon). You can see the already existing data in the downloads section of
formatting link
.
Before, I'm asked again - No, I don't have the 62.5g Pro38 data. If anyone out there has this, please send it along and I'll include it on the web site.
If the writers of Rocsim would allow you to import a BMP and display it behind the engin editor it would be simple. You put it in the background , move and scale it to fit the axis then plot the points over the graph.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.