Jump to content
43oh

Wireless model rocket telemetry


Recommended Posts

This is a continuation of a thread I made here: http://forum.43oh.com/topic/3973-mcu-wireless-networking-question/#entry36033

 

Since we ordered hardware, I figured it was time to start documenting the build.

 

Background:

We applied for (and received) a small grant from NASA to build an educational activity for high school kids about the physics of rocketry.   The idea is to allow the kids to design, build and test their own rockets and provide them real time feedback on the performance.  Using this, we will teach them about the concepts of ballistic motion, force, impulse, thrust, etc...

 

We want a way to measure, log and graph the various forces acting on the rocket during flight without the measuring, logging and graphing getting in the way.  So we decided the best way was to wirelessly transmit a data stream from the payload to a base station which could read, process and graph the data in real-time, maximising the time the students have to conduct experiments.

 

Design:

There are two main components to this project, the payload that is contained in the rocket and the base station;

 

The payloads:

The current plan for the payloads is going to be a TI sensor tag (thanks @cde) with custom firmware broadcasting a data stream over a Xbee-Pro XSC radio back to the base station.  The payload will be mounted in the nose of the rocket, so room is going to be tight.  I am planning on making an adaptor board to connect the two modules together along with an extended battery pack.

 

The sensor tag contains:

  • IR temperature Sensor
  • On chip temperature Sensor
  • Humidity Sensor
  • Pressure Sensor
  • Accelerometer
  • Gyroscope
  • Magnetometer

 This is information overload, but should allow the kids to have tons of room to experiment.  The extended range of the radio will also allow the payloads to be used in other experiments or possibly even in higher altitude rockets.  With a little hacking, the sensor tag should also be able to be modified to break out the i2c bus for adding additional sensors (e.g. GPS).

 

The Base Station:

To keep it simple and safe, we decided to forego traditional chemical motors and instead use a compressed air system that will consist of a small compressor attached to a pressure vessel.  Attached to the vessel will be an electric solenoid and a length of PVC pipe.  The rockets will be modified (by removing the engine mounts) to slide down over the PVC pipe, and will be fired by opening the solenoid valve. 

 

The base station will have dedicated electronics to monitor and control the pump and solenoid, and we are considering a stepper driven belt drive to adjust the launch angle.  Even though it is a low pressure system and there will be interlocks and blow off valves in place, we want to operate it from a safe distance.  Currently we are planning on using a Phidget board controlled by labview to run everything on the base station.  The idea is that the students can adjust the launch angle and pressure, launch their rocket, and see in real time what those changes made to the launch characteristics.  The pressure based launcher also limits the range to several hundred feet, so we don't need to worry about recovery systems or losing rockets when it is windy...and it will be usable in large lecture halls.

 

 

Communication:

To communicate with the payloads, we will have a stellaris launchpad with another Xbee-Pro radio mounted on the base station that will act as a hub, aggregating data streams from all transmitting payloads and rebroadcasting them over serial to the main computer, which will handle logging and display.  Because the sensor tag unit in the payload is low power BT enabled, we plan on having a BT dongle on the base station to detect and identify the rocket loaded into the launcher.  This info will be read by the computer logging the data and used to automatically bring up that rocket's data stream.  The BT connection might also be used to wake up the radio out of sleep mode, so that the modules conserve power when not in use. 

 

 

Right now the project is still in the planning stage.  Parts have been ordered and should be here on Monday except for the sensor tag boards, which are backordered for another 2 weeks.  Once the radios are here, we will start prototyping the network building the base station.  I will update with pictures and updates as the project progresses.

 

 

Link to post
Share on other sites

Yes we have.  We already do a similar activity that is completely uninstrumented, so the mechanics of the launch system have been ironed out through trial and error.  We aren't sure what the weight of the boards are going to be, so there will be some design considerations on the rockets to account for CG.  Actually, that is one of the things we will talk about during the 'design' phase when the kids build their rockets and one of the parameters they will be able to tweak in their design.

 

We did think of data logging to SD card, but we decided on wireless to simplify the actual experiment.  Less time spent pull and loading SD cards is more time spent launching.  There is also something exciting about watching the data plot in real time

 

I take it from your username that you've done something similar?  

Link to post
Share on other sites

I have done something similar, and what really surprised me was just how much of an effect weight has on altitude.  I am well aware of how weight effects actual rockets, but I assumed that because these are actually projectiles, the additional mass would store energy and not be as much of an issue.  Unfortunately this is not the case.  Even with an exceptionally lightweight avionics bay, my altitudes were dropping from over 1000 feet (no av-bay) to just a few hundred feet with the av-bay.  And the additional weight means that you are going to have to have a parachute or a pneumatic shock absorber.  And even with a pneumatic shock absorber, you are going to have some serious G-forces to contend with. Long story short, it was *much* more difficult than I had anticipated.  And this is coming from someone who has already done substantial work developing hand-rolled paper tubes to take the stresses of homemade MPR motors.

 

In any case, I suggest you mock-up a non-functional av-bay to get the size and weight in the ballpark and launch that.  If you are still getting sufficient altitude and surviving landing, great!  But my guess is that you're going to be surprised here.

Link to post
Share on other sites

If I'm thinking about it correctly, I believe a pneumatic system won't be as touchy about weight as a chemical rocket.  With the pneumatic system, the rocket is accelerated by the pressure gradient between the atmosphere and the inside of the rail.  This force will exist as long as the rocket is still on the rail...so if the rocket has higher mass, it will accelerate more slowly and spend more time on the rail.  It's the equivalent to using a higher impulse engine to compensate for increased mass.  Now...I haven't done the math, but I believe it will be fairly conservative.  

 

We are currently working on a mechanical design for the mounting and impact protection, and will probably break a few prototypes in testing before we get it figured out, but we are hoping for this initial version that the impact velocities (at least on a grass field) won't be too extreme.

 

We do plan on doing full mock-ups and testing, but just aren't quite to that point yet.

Link to post
Share on other sites

If I'm thinking about it correctly, I believe a pneumatic system won't be as touchy about weight as a chemical rocket. 

 

Yes, that is what I thought, but I was wrong.  

 

Another problem you may have as you add weight is that pressure inside the rocket will increase dramatically before it clears the pad, leading to blowouts in your tube or forward bulkhead.  You are going to be seriously limited here if you are using Estes-style tubes.

 

In any case, just giving you some heads-up as to what you are up against, and knowing your weight limits up front is going to be a *huge* help when spec-ing out the electronics and designing your av-bay.

 

You may wish to consider switching to water rockets.  Quite a number of people have integrated some rather clumsy electronics into these without reporting serious altitude issues.  The design issues surrounding water rockets are actually much closer to "real" rockets than stomp/pressure rockets which are actually ballistic projectiles.  I have not gone the water rocket route yet myself, but at this point, I do believe it may be the preferred choice.  Again, just something else to consider.

Link to post
Share on other sites

I was using a combustion launcher (metered propane injection) so it would be difficult to relate that to compressed air.  According to what I have read in the spud-gun forums, compressed air is capable of much better performance than combustion.  I went the combustion route because I didn't want to have to bother with carrying a compressor out into the field.  Nonetheless, my results have been far superior to the several people I know who are using compressed air.  As I mentioned, my basic projectiles clear 1000 feet while everyone using compressed air has maxed out at 200-300 feet.

 

In combustion cannons, total energy is closely related to the volume of the combustion chamber.  There is surprisingly little difference between the richest and leanest mixtures that can be ignited.  I have two different combustion chambers and multiple barrels, all of which can be mixed and matched with threaded fittings.  The smaller combustion chamber is 2" PVC x 6" length and the larger combustion chamber is 3" PVC x 10" in length.  The actual volume with end caps and reducers is somewhat larger.  Barrels are 3/4" and 1" PVC, multiple lengths.

 

Projectiles are minimal-diameter tubes formed around PVC mandrels.  Obtaining a tight fit is critical for performance.  Achieving this is incredibly difficult, because my paper composites derive their strength by compressing on the mandrel as the glue dries.  The forward bulkhead is 3mm aircraft ply epoxied in place with generous fillets.  Very small fins are sufficient.  Landing is cushioned with pneumatics.  I wrap a tube around the main body tube, again to achieve a tight fit.  This gets a much lighter forward bulkhead.  As yet, I have not been bothering with nose cones.  On launch, the outer section slips over the base just a few inches.  The air between the bulkheads compresses on landing protecting the main tube.

 

The 3/4" (PVC mandrel size) main bodies are around 18" in length and the 1" ones are 24" in length.  The pneumatic damper on the 3/4" version is about 8-10 inches in length, and about a foot on the 1" ones.

 

Unfortunately, everything is packed away in a storage unit so I cannot provide pictures or weights at the moment.   IIRC, the av-bay roughly doubled the weight of the projectile.

Link to post
Share on other sites

If you are having a problem with the size, there is a way out.  You can remove a lot of the PCB with a Dremel.  The size of the XBee has a lot to do with providing an ample ground plane for use with a monopole antenna, but you can use a dipole instead and say "to hell" with ground plane issues.

 

If you do that, you'll need to solder-on a wire-dipole antenna where the SMA connector would go, but that should be able to fit inside a rocket tube easily.  The antenna will use about 15cm of wire at that frequency.  Grok half-wave dipole, there's a ton of information online.  Just keep in mind that you'll probably want to change the length of the half-wave by ~0.8 (or so) due to imperfections in the material and such.  Experiment to see what length gets you the best range.

Link to post
Share on other sites

Size shouldn't be too bad.  If you look in the picture I posted, the radios we are using are on top mounted on their black shipping foam.  The PCB is pretty much the same size as the radio module on the back, so there isn't much I can trim.

 

I think we are planning on a 1.5" ID cone, and both the radio module and the sensor board are 2.5 cm wide, so I think with some careful mounting, it should work out well.

Link to post
Share on other sites
  • 2 months later...

I'm stalled for the moment.  The sensor tags were back ordered and took forever to arrive.  Now I'm in the process of trying to wrap up a PhD dissertation and a Master's thesis by the beginning of October, so I'm writing 24/7.

 

The launcher is mostly done and I have the parts to work on the rest of it.  The sensor tags are actually quite an interesting platform and I should be able to combine it with the XBee radio into a fairly compact package.  Right now I need to write new firmware to include the radio and figure out how I'm going to actually mount the two pieces together and tie in the power.  

 

I'd like to get to it sometime, but it's looking like it will have to wait until after I move at the end of October.

Link to post
Share on other sites
  • 3 months later...

With the long weekend, I finally started making some progress on this.  I've decided to ditch the BTLE stack that TI provides for the CC254x chips and write my own framework.  The stack is written with an OS abstraction layer with a ton of abstraction at the lower levels.  My original plan was to modify the sample firmware for the sensor tag, but after playing with a few days I realized that enabling USART0 was much more complicated than writing up a new service....so the stack is going.  This means that I'm giving up on using the BT functionality of the chip, but I'm okay with that.  It was extra power I probably didn't have room for anyway.  I did manage to scavenge part of the HAL code, which is making interfacing the i2c sensors a little easier.  However...since the intended purpose of this chip is to run the BTLE stack, there isn't a lot of "high level" documentation that isn't focused around the stack, so this is quickly turning into a lesson in reading register map tables.

 

So as it stands, I have figured out most of the incantations to initialize the chip, configure pins, enable interrupts, etc and have both the i2c and uart at least passing data.  I can also talk with most of the sensors, but have only been able to get the magnetometer to return updated readings.  I'm going to have to sit down and dig into the individual data sheets and reverse engineer the example driver code a little more.  Once I can get numbers off the sensors, then it's just a matter of writing the state machine to handle the polling and designing the interface board to hold the radio.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...