I'm working with a club (not a class - so more flexibility in design) to create a payload for a rocket. For now the only desire expressed by the rest of the team is for a camera to be on board, the rest of the design (goals and fabrication/coding) are up to me (ideas are welcome/encouraged)
I have some hardware from my personal projects, but nothing I'm upright willing to give up if this rocket fails. Let's say there's a $200 budget to do the following:
Video Capture (all data from the rocket is downloaded after landing)
9DOF IMU (SparkFun has one with I2C I'm familiar with/worked with)
Barometer
Temperature Sensor
down-ward mounted laser? - I'm wondering if there might be anything that could get me a distance reading from the ground if it's solidly mounted on the rocket
GPS? - I have to wonder about the units I've seen - they can't get a reading indoors, I'm a little dubious they'll be able to capture a reading while hurtling through the air
The rocket is required by law to be unguided, so no servos. I'm planning to do all data processing after the fact, so for now I'm only looking at the data storage and the battery at this point. I'm presuming the max weight will be the batteries, so I was hoping to have five AAA's in series for 7.5V (since that's what most Arduino products shoot for as a min)
I'm thinking that most Arduino's have limited SRAM memory, and doubly limited EEPROM, so I figured to store a sufficient amount of data (10Hz on 3dof on 3 sensors + 2 signal channel sensors * 60sec/min * 10min (launch to recovery) = 0.5GB space), I'd probably need a memory card
I'm not sure where to go to look for a good camera for such a project, I'd prefer it record to something like an SD card or a thumb drive rather than transmitting live since that kind of video quickly loses quality with altitude.
GPS? - I have to wonder about the units I've seen - they can't get a reading indoors,
Well, no, a 50W transmitter 18000 km away is going to have difficulty penetrating most building materials.
A hand will usually stop the signal pretty effectively.
Will it work on a rocket? Should do, but most reasonably-priced units are limited to a 1Hz update rate.
About the only thing an Arduino could do with a camera is trigger it, or turn the power on/off.
A decent GPS will work fine for most rockets. If you're going supersonic (specifically, faster than 1000kt) or very high (> ~20km/60k') you need to be careful with your GPS selection.
I really don't think you're going to be doing any laser rangefinding with a $200 budget.
Make sure your code stops writing data when the storage medium is full, in case recovery takes longer than you expect. You wouldn't want to overwrite flight data with a bunch of boring data of the rocket lying on the ground or hanging in a tree.
You may want to have a look at the Teensy boards: http://www.pjrc.com/teensy/
Paul also has tiny SD adapter board that can be mounted directly
to one of his Teensy boards: http://www.pjrc.com/store/sd_adaptor.html
That will give you plenty of storage capability in a very small and light package.
About the only thing an Arduino could do with a camera is trigger it, or turn the power on/off.
...you could do video overlay. Would be more interesting way of looking at the data than a bunch of spreadsheets but a lot of bulk and coding I suppose.
You should supply a few more details about the intended flight; how long will the rocket burn, is it single or multi-stage, maximum g force expected, what altitude you hope to reach, is the instrument compartment open to the atmosphere, how you will return (parachute?), total expected time from launch to landing and orientation of the camera.
The flight time will give you data storage requirements.
I would keep a record of the time plus raw data readings from gyros and accelerometers and key events such as ignition, parachute deployment etc.
I am not sure about temperature and pressure it depends how quickly the temperature sensor reacts and if external air pressure can be read in a fast moving rocket (you will be able to read a pressure but it might not represent altitude).
Write the raw data onto the SD card without buffering it and process it after the flight, that way any errors in processing the data can be corrected. With data on time, orientation, acceleration and rocket mass you should be able to calculate the flight path followed, thrust achieved and so on.
The information on key events may be useful either to pat yourselves on the back on how everything went exactly as planned or for a post-mortem.
I am not sure about temperature and pressure it depends how quickly the temperature sensor reacts
Depends on the sensor. Thermocouples are reasonably fast.
and if external air pressure can be read in a fast moving rocket
Sure it can - that's the typical way of measuring altitude in high power rocketry.
(you will be able to read a pressure but it might not represent altitude).
The trick there is to make sure you have a static pressure port - i.e., the hole is perpendicular to the surface of the rocket and the direction of travel.
If the port is no perpendicular (e.g. on the nosecone), then there is a dynamic component to the pressure measurement that is a function of velocity.
One of our rocket teams did an experiment with multiple pressure sensors on the nose to measure velocity and angle of attack. I saw the hardware, but never talked to the team so I'm not sure what the results were.
If you put a radio transmitter on the rocket that makes a constant tone then spaced receivers can record the tone and infer velocity and direction from the doppler data. One receiver under the launch rail and 3 or 4 others spread 100+m out should do.
OTOH with a transceiver you could ping the rocket from ground at one station and collect both ping and return at other stations and if the receive-transmit delay is very short, infer position.
When it comes to specific impulse, Grams count. Think about using watch batteries.
Work with your aerodynamics team before going to this amount of trouble. I was thinking like this on a project, and was informed they'd be using ballast in the nose to get the CG right. Turns out I could use a simpler (larger battery, COTS boards, etc) system, shorten my development effort, and reduce the amount of CG correcting ballast they'd need (my less than miniaturized payload also provided needed mass).
Of course, we still don't know if he's flying an A motor or an O ...
The trick there is to make sure you have a static pressure port - i.e., the hole is perpendicular to the surface of the rocket and the direction of travel.
I am not in a position to argue with you (he said frantically searching the net for info with which to argue). However I am not convinced that either temperature or pressure would be easy to measure in a way not affected by the rocket. I am sure the readings would be problematic in supersonic rockets, but I would have thought there would be issues even on rockets traveling at less than the speed of sound. With a static pressure port as you describe will there not be effects caused by the air flow much like when you blow over the neck of a bottle and is the whole rocket not traveling in a sort of bubble of air compressed by its motion?
The trick there is to make sure you have a static pressure port - i.e., the hole is perpendicular to the surface of the rocket and the direction of travel.
I am not in a position to argue with you (he said frantically searching the net for info with which to argue). However I am not convinced that either temperature or pressure would be easy to measure in a way not affected by the rocket. I am sure the readings would be problematic in supersonic rockets, but I would have thought there would be issues even on rockets traveling at less than the speed of sound. With a static pressure port as you describe will there not be effects caused by the air flow much like when you blow over the neck of a bottle and is the whole rocket not traveling in a sort of bubble of air compressed by its motion?
IIRC, an orifice orthogonal to a wind will have a vacuum pulled through it. Could be wrong tho.
That's a great way to do it, if you happen to have a radar ground station network like NASA.
Your link (and another poster's link to Apogee) refers to a visual method for schoolkids to track their Estes rockets, which are too small to carry an altimeter.
For NASA's Student Launch Initiative student teams are required to use a pressure-based altimeter for the altitude of record, and altitude is part of the competition.
For TARC altitude is also part of the competition, and the required altimeter is pressure-based.
Pressure altitude works just fine on subsonic high-power (H motors and up) rockets. It works with a few caveats on supersonic rockets (static port placement is crucial, IIRC, and beware the transonic flight regions).
A single static port will work, although three spaced equidistantly are recommended.
radman:
With a static pressure port as you describe will there not be effects caused by the air flow much like when you blow over the neck of a bottle and is the whole rocket not traveling in a sort of bubble of air compressed by its motion?
When the rocket reaches apogee it's not moving very fast. The thing is, did the rocket read that it was higher when below?
I'm not a fan of pitots as an absolute gauge of height or speed. We can do better with radios and computers.
NASA's Student Launch Initiative requires all the rockets to have the same altimeter so they can be compared relative to each other but the absolute altitude may not be correct. The apogeerockets articles were comparing different methods of determining altitude and seemed to favour the visual method.
GoForSmoke was probably right that a pressure altimeter is fine near apogee (ignoring high and low pressure weather systems).
A popular product made by COMPANY B, has both baro and accel sensors. A flight at LDRS, where a rocket turned parallel to the ground at 2000' while still under thrust, showed that they do not sense the baro sensor until the accel has picked off apogee...the accel profile DID NOT trigger the apogee device, and the rocket sailed over the horizon and crashed.
ParallelLogic:
I'm presuming the max weight will be the batteries, so I was hoping to have five AAA's in series for 7.5V (since that's what most Arduino products shoot for as a min)
I'd design it to run off 4.5v (3 x AAA cells) or 3.3v (3 x AAA cells and a 3.3v LDO regulator). Most of the GPS units I've seen need 3.3v, so if you run the Arduino at 3.3v too then interfacing to them is easier. For reliable operation the clock speed should be reduced to 8MHz. You could use the 3.3v version of the Arduino Pro Mini.