Model rocket datalogger and data analysis
Ductapemaster
Posts: 90
A while ago I ame up with this idea that I wanted to build a model rocket datalogger so I could determine the altitude, velocity, and acceleration of the rocket on its flight. I plan on using a 1 axis accelerometer (I really want a 3 axis, so I could get a 3D graph of the rocket's trajectory, but I will start here) that measures the upward (z axis?) acceleration. I am going to store the values obtained in an EEPROM and then download them to a laptop on the ground to be analyzed. Now, I can do all that without a problem, but my real question is what program do I use to do the analyzing/graphing of the data. I need to take the data, put it in a graph (acceleration v. time), take the integral of the graph, graph it (velocity v. time) and take the integral of that graph and graph it (position v. time). People have used MATLAB and Maple to do it, but I'm 17 and I don't have the funds for either of those programs or a place where I can use them nearby. I did find one program that does half of what I want. It graphs the integral of the data I input to it, but I can't graph the second integral. And, not to mention, it comes up with about 5 or 6 different memory errors when you try to use it. (If anyones interested, the program's called RT Plot) Can anyone help me find a suitable program for this? Freeware/open source is the best, but something relatively inexpensive will do also.
Thanks!
-Dan
Thanks!
-Dan
Comments
I haven't tried doing integration/derivation in Excel, but it sure makes purty graphs! [noparse];)[/noparse]
Oh ya, openoffice is free...google it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<FONT>Steve
What's the best thing to do in a lightning storm? "take a one iron out the bag and hold it straight up above your head, even God cant hit a one iron!"
Lee Travino after the second time being hit by lightning!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Thanks!
-Dan
First, graph the acceleration data that you've collected. Then find the best-fitting curves for the various parts of the flight. Rocket engines do not provide a constant thrust, so you'll find that your data vary with the thrust curve of the motor you're using, roughly. There's a number of ways of finding those best-fitting curves, including Excel, SPSS, and probably quite a few free statistical programs. Keep your functions simple - constants, straight lines, simple curves, etc. You can do that by picking appropriate segments of the data , and keep in mind that you don't have to be exact. You might even be able to get by with just lines.
Once you've got the curves, you don't need a program to do the integration - you can do it by hand (or anyone who has had one semester of calculus can, anyway), figuring it separately for each part.
If you want to see what I did, drop me a private message.
What kind of rocket/engine are you using? Mine was a 16-pound, 5.5" diameter scratchbuilt, flying on an AMW K800. I got 3800 feet at about 410 miles per hour.
Also, I'm not using this on a large rocket. I haven't quite gotten into the larger scale stuff yet plan to eventually though) so I'm still launching Estes rockets and my own creations (heh, nicknamed "the illegal rockets"). The datalogger is going to be put into a 36D^2 rocket (dual "D" powered) which has an optional payload bay.
I was browsing the parallax site and I found a USB flash drive datalogger module, which would be perfect for this. I could store multiple launches on a single (32mb?) drive and the data is stored as a format that excel can read, so it will work perfectly. Just another item on my christmas list...
Thanks for the suggestions. I will definitely try that out.
I've got a little dual-axis accelerometer I'd like to fly, set up to transmit the data back to the ground through an XBee Pro module. But since the function needed is f = a(t) (that is, a function of time), the data points will have to be associated with specific points in time. When I did this in March, I flew a big honking Vernier Labpro unit, which recorded all of that for me, but now I want to fly a much smaller setup using Stamp modules·- something that I could put into a 3" diameter rocket and fly on H and smaller motors. Right now I'm expecting to use a 2pe unit.
An alternative would be to look at the acceleration and compare it with the motor's thrust curve (in particular, the known burnout point) and use that as an estimate of time. But that'd add perhaps quite a bit of additional error.·A good real-time clock marking time would be very helpful.
Of course I could set the program to sample every Nth fraction of a second (say, 10x/second, which by the way should give you a reasonable set of data to work with), and test it for accuracy on the ground against some timepiece here. What do you think?
The thrust curve idea is one of those "good on paper, bad in practice" things. Rocket motors aren't especially known for consistent performance, so there would be some deviation from the rated specs. How much, I don't know, but from what I read it can be a lot (think 20+%). I don't know how the larger motors (bigger than "E") perform, but I suspect that they have the same characteristics due to manufacturing inconsistencies.
You might be interested in this page: http://www.rocket-roar.com/rap/alt.html
That is where I got this whole idea from. I'm obviously changing/improving his setup, but what he did seems to work fine.
You might consider looking into the SX. They are easy to program (slightly more difficult than the Stamps, but it's still BASIC), very fast and adjustable processor speed, and they're really cheap if something happens to the chip. And, it's only slightly more expensive to get started with them than the cost of a new Basic Stamp.
Let me know if you need anything else!
-Dan
Agreed re. the crudeness of using thrust curves - it's not any better when you're using large (I, J, K) motors than when you're using A, B, C, or D motors. Lots of variation. It'd be a last resort. I think they typically tell us that the variation is +/- 10%, but the variation in delays (when you're using motor ejection) is obviously a LOT higher than that, and I have to believe that there's the same kind of variation in things like burn time.
I've been considering getting into the SX chips, and obviously the interrupts thing is a good reason to do so. I almost ordered some a couple of weeks ago, but I saw that "end-of-life" warning on the SX-Key, and thought I'd hold off a while. I've got plenty of projects going already here.
Also, about the SX key, parallax is phasing out the serial version and thats why it's labeled with "end-of-life". They're coming out with a USB version, like the SX blitz. Personally, I would wait for it. USB is so much better than serial!
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
http://parallax.com/ProductInfo/Microcontrollers/BASICStampSoftware/tabid/441/Default.aspx
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Integration: Once you have your data imported into EXCEL, it will be a sequence of acceleration values in one column. If it is not acceleration, but something like voltage, then you need to make another column that has a formula to get to acceleration. You can make a graph of acceleration vs time ticks. So now you have a column (column A say) with an acceleration for each tick of the clock produced by your accurate DS32Hz/SX interrupt system. Say the time tick is 1/4 second. Now in the next column make a cumulative sum of the acceleration column, as follows. In cell B1, write (=A1/4), and in cell B2, write (=B1 + A2/4). Copy that formula into the rest of column B, so each cell is the sum of the one above it plus the one to its left. The /4 comes from the the area of a little bar that is 1/4 second wide times the acceleration at that instant of time. (but of course use your time tick value!) The sum of all those little areas is the integral of the acceleration, and now you can graph it. That's it, integration is just a cumulative summation. There are of course refinements to be had with better instruments and little tricks in the analysis, but hey! These are discrete time samples, and there will be lots of little errors that accumulate, always a problem with dead reckoning inertial navigation. Can you see how to get the second integral, distance traveled, which should of course end up back on the ground?!
PLX-DAQ is for real time import of data into EXCEL. Say you had a radio-telemetry module on the rocket, the xbee pro for examle, you could send the readings in real time back to a ground receiver attached to a PC, and the data would appear in the EXCEL spreadsheet row by row. It is a different matter if you log the data during the flight and retrieve it after. Say the data is a text file on a thumb drive. Then you can put the thumb drive in the PC and open the data file in EXCEL.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Post Edited (Tracy Allen) : 12/20/2007 6:46:18 AM GMT
Also, if someone could help me out with my other question on integrating/sigma-delta ADC's that would be great. I need to decide which ADC to use with this project too...I need a 16 bi one, preferably serial. Any suggestions/example code?
Thanks,
Dan
Sigma-delta ADCs use a capacitor to "integrate" the sum of an input current plus a +/- quantized current provided by a binary output (from the microprocessor). The integration takes place on a capacitor, connected to a threshold detector that detects whether the voltage on the capacitor is > or < a fixed threshold. Through feedback, the voltage is made to hover very close to the threshold, and the feedback comes out through that quantized binary output. If the input current is high positive, as a result the binary feedback will stay low a proportional amount to compensate. The result of the measurement is in fact the proportion, as the microprocessor keeps track of the proportion as it counts the highs vs lows. There has been a lot of discussion of this on both the SX forum and also on the Propeller forum, and you can find examples of code. However, for a variety of reasons, you cannot expect to achieve close to 16 bits of resolution when using one of those micros. 8, 10 or even 12 bits, yes, with careful layout. Another thing is, the more bits you want to measure, the longer you have to wait in order to determine the proportion, and that time is also directly related to the clock frequency.
There are other converters, of course with serial interface. At more than 12 bits, things become kind of specialized. Many converters at that resolution are in fact sigma-delta, but are designed specifically for that purpose and get around the limitations that you would have in implementing it on the microprocessor. For example, a single conversion might take 10 or 20 milliseconds. How often do you expect to sample? Will you need other measurements as well?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
But yeah, 8 bits should be enough resoluion for what I am trying to obtain. I could go to 10, but only if time doesn't become a problem. I plan on sampling about 60 times a second MAX. It may be less than that in the end, but that is my goal. I have to make sure I can write to the USB datalogger module that fast though (I could write multiple measurements at once).
So, I now understand how those ADC's work (I didn't actually expect them to integrate for me, although that would be awesome if it did) but I am still wondering whether they are any better than a normal ADC. What advantages do they have over a regular one? Do I really need one in this application?
Thanks for all the help! It's greatly appreciated!
-Dan
ADCs vary widely in capabilities, and that partly explains the bewildering array of options. One 12 bit ADC I have used is the ADS1000, which is a 12 bit converter in a tiny SOT23 package that can be mounted right next to a pressure sensor, and it contains a x8 programmable gain amplifier. It takes about 8 miliiseconds for it to do a conversion. The similar higher resolution (sigma-delta) ADS1100 or MCP3421 takes anywhere from 8 to 125 milliseconds for one conversion, depending on the resolution required. You don't want the acceleration to change very much during the course of one conversion! You mentioned the AD7705 in PM, but I am not familiar with it. The successive approximation converters that I use most often are much faster, with conversion times at around 10 microseconds, and they also have track and hold circuits, so they can grab a level from a changing waveform. There are several different "topologies" for these converters. I would say that since you are just starting with this, use a converter for which you have example code available for the Stamp or SX. I'd recommend *against* using a sigma-delta routine in firmware in the chip. It will simply require too much calibration and hassle. Experiment, yes, but buy an external ADC for the project.
8 bit converters are quite common, and code is available, but you have to be sure that it will give you enough resolution. That is, how do the acceleration values you expect fill up the range of the converter? Some sensors have a tiny differential voltage output, whereas others have a lot of internal circuitry that brings their output up to a more convenient zero to full scale range.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com