Hello all and welcome to my blog. In my blog I plan to look at sensors in interesting applications and how they can be tied with uC for processing or transmission to a remote location for other uses.
I am currently working with a student team from University of Waterloo on a rocket for an upcoming competition. Our team is currently working on a rocket for the 10,000 ft category and being an electrical engineer my sub team is responsible for the for the safe return of the rocket as well as telemetry acquisition and potentially ensuring the rocket does not overshoot the 10,000 ft mark by too much.
For this purpose we will have various sensors on board. We will attempt to use the on board sensors to determine parachute deployment altitude, max altitude obtained as well as projected altitude based on initial acceleration and current altitude. Due to the nature of the competition as well as the altitude of the rockets there are strict standards (at least by University standards) that need to be met. I have therefore taken upon myself to test various sensors with the aid of a toy rocket. This will provide some engine vibration/shock as well as a 10th to a 5th of the projected final altitude. There is also the always present possibility of a very hard landing that the sensors may also be subjected too. I have chosen one rocket for now but this may need to change as I reach the final hardware design.
The sensors I have chosen are three accelerometers, two gyroscopes, two magnetometers two pressure sensors and two temperature sensors. The reason for redundant sensors is so that one board can be made that will test the two best choices against each other. The “best” in this case means sensors that are easy to use and have the range and resolution that we felt would be acceptable for our application. To prevent too many sensors I have chosen only two of each (although some may be redundant by a built in function of another, temperature for example). I will briefly explain the sensors I have chosen.
Accelerometers
I have broken the accelerometers down into two groups one dealing with the beginning and end of the rocket's trajectory and two others for the middle (longer) part of the trajectory. This is due to the different force ranges that the different parts of the trajectory will display.
ADXL78 - Analog Devices single axis accelerometer has ±35g ±50g ±70g setting allowing for initial and final stages of the rocket trajectory to be easily measured. This is an analog sensor, that has is sensor in the plane of the chip making mounting and placement very important.
ADXL362 - Analog Devices 3 axis accelerometer with ±2g ±4g ±8g settings. I personally like ADI even though their sensors are expensive but they are also known for their high quality. This has a sample rate of up to 400 Hz which will hopefully be enough to get the resolution needed for the application.
LIS3DH - ST Micro 3 axis accelerometer with setting ±2g ±4g ±8g ±16g. ST has cheaper sensors and it would be nice to put it against the Analog Devices sensor to see if there is any noticeable differences. The LIS3DH has a data rate of up to 5 kHz which may be helpful if the ADXL362 does not give enough data for the application.
Gyroscopes
Unlike the accelerometers I don’t foresee an extremely high rotation rate on the rocket and therefore have only included two standard gyroscopes.
FXAS21000 - This is Freescale's gyroscope, while I have not used Freescale sensors before I have had them pitched to me. I figured I would try them out and see how they stack up to ST. This gyroscope is has sampling rates of ±200 °/s, ±400 °/s, ±800 °/s and ±1600 °/s which for the application should be more then enough.
L3GD20H - While I have not used this exact sensor before I have had experience with ST sensors (partly why they feature in every sensor group) and have found them pretty easy to work with. While they may not be at the level of ADI, for their price point they do offer a good product. This gyroscope is capable of sampling at ±245 °/s, ±500 °/s and ±2000 °/s I hope to see what ST is capable of with this sensor.
Magnetometers
MAG3110 - Having had the chance to test this exact device (same with the pressure sensor below) in a recent road test and seeing (from preliminary testing) that it appears to have a pretty stable output, I thought I would test it in flight with all that comes with that. the sensitivity of this sensor is 0.01 µT and a has a full range of ±1000 µT.
LSM303D - Ulike the MAG3110 this magnetometer has a selectable range ±2, ±4, ±8 and ±12 gauss (1 gauss = 100 µT). The LSM303D also has a built in accelerometer with ranges of ±2g ±4g ±6g ±8g ±16g, I may try use this instead of the LIS3DH to help reduce the number components in the final design.
Pressure Sensors
MPL3115A2 - I had the fortune to test this in a recent road test and found it to be a reasonably good device and since other members of the team had liked some features of the sensor (altitude output) it became a necessity to test what the MPL3115 is capable of. This is an absolute pressure sensor which means that the outside pressure is compared to a vacuum pressure inside the device. this sensor range is 50 to 110 kPa (1 kilopascal = 10 millibars).
LPS331AP - With not too many pressure sensors on the market (Honeywell is expensive and as a company not easy to deal with) ST became the default sensor to compare against. This is also a absolute pressure sensor with a 260 to 1260 mbar absolute pressure range which fits nicely in the altitude/pressure range we expect to operate at.
Temperature sensors
With temperature sensors there is not much to talk about. I have chosen two in this case just to give a comparison. Again a lot of the other sensors have a temperature sensor built in and I will be looking to see if these two could be replaced by one or a few of the other built in temperature sensors.
ADT7310 - This is a SPI temperature sensor with a range of -40 °C to 105 °C and an accuracy of 0.5 °C. The ADT7310 has a 16 bit resolution and can be read in either continuous mode, one shot or at one sample per second. If a different read rate is needed a timer interrupt on the uC could be used to set the one shot read at the needed interval.
STLM20 - this is an analog sensor with a range of -55 °C to 130 °C but with a lower accuracy of only ±1.5 °C. For some applications this may be a bit of a wide variation but, for our application this will be well within the allowance for maintaining battery temperature and board temperature (our final goal is to fly in a desert). What is important is the delay time that the sensor may experience in reading the true temperature and the repeatability.
MicroController
The uC that I have chosen is the LM4F120H5QR (TM4C1233H6PM) by Texas Instruments. I have chosen it because I find TI easy to work with and a product that has lots of support. I also needed something faster than my usual MSP430 and with more I/Os. At the same time I am hoping to get more exposure to the ARM architecture and an easy to use RTOS.
Principal of operation
For this board the objective is simply to collect as much data as possible and to try verify which sensors perform the best for our application. Therefore the principle of operation here will be to try run either an RTOS that will service all the sensors and dump the data in different files on a SD card (or at least in a way that the different data can be pulled out) or to have an interrupt driven program that will retrieve the data from each sensor and store it to the SD card for later analysis.
This is a seemingly simple project, the difficulties lay in putting a relatively large number of sensors in a confined space (1.3” x 5”) and to connect them all with little to no cross talk. The payload area is currently 1.63”x10” which seems sufficient but with such a narrow board wiring becomes challenging. Another challenge will be to power everything from a small enough battery so as not to impede the rocket but also to allow for all devices on board to work at their close to peak performance. With standard engines I am not sure I will reach my 1500+ ft goal but maybe a few adjustments will allow for this to be possible.
Next time
Next time I plan to go over the board layout and explain the reason for the layout and placements that I have chosen. I also hope to give a better outline for the software operation.
No comments:
Post a Comment