Introduction: Stand Alone Science Mission Directorate
More by the author:
About: Electrical Engineer, control systems, automation, small electronics, home automation, microcontrollers etc.
This is a project I'm working on for a team called LionTech Rocket Labs to track a high powered rocket. The goal of the product is to track the atmospheric data during flight, but we are going to amp it up and add some microcontrollers to the mix. Look at it as a "Smart black box". It will track the vehicles flight and collect and analyze data according to its current status.
There is A LOT going on here, and this tutorial is pretty extensive and detailed. I would recommend going through all the steps first to really understand what is going on. I have tried to include as much detail as I can to allow anyone to re-create the system for whatever application they might want to use it for. The steps sort of follow the design process starting with the requirements, moving through the design, and finally ending with actual construction and testing.
It has quite a bit of requirements as set out by NASA and the Teams Project Maverick which make this project complex.
SAS CRITERIA – CUSTOMER NEEDS
Lion Tech Rocket Labs seeks to implement the Science Mission Directorate to track and analyze the vehicle’s flight post launch. The requirements set by the customer are as follows:
1. The product shall be contained on a single PCB board (and including external equipment)
2. The product shall be powered by a single 9 volt battery
3. All data must be stored for later analysis
4. All data will be wirelessly transmitted once flight has completed
5. The product shall contain all sensors for collecting pressure, temperature, humidity, solar irradiance, imagery, and global position
6. The product shall be completely automated and stand alone for flight
7. The product must collect data from apogee until ten minutes after landing, once every five seconds
8. The product shall fit easily into the vehicle’s body
SAS CRITERIA – MINIMUM REQUIREMENTS
1. Will be fabricated on a single PCB with connections for all external devices such as battery, GPS, camera, etc
2. Will be powered by a single 9 volt battery to sustain at least one hour of continuous run
3. System will contain micro SD cards for storing any collected data or measurements
4. System will implement wireless communication protocol to transmit all data collected during flight back to ground station once mission has completed
5. System will implement sensors for pressure, temperature, humidity, solar irradiance, imagery, and global positioning
a. Data collected shall be within expectations as set by testing procedures
6. System will be controlled by microcontroller units to analyze data collected and determine current mission stage and complete operations based on current stage
7. System will store all data beginning at apogee (one mile altitude)
8. System must collect data no less than at a rate of one sample every five seconds
9. System must automatically shut down ten minutes after landing and after wirelessly transmitting collected data
The objective of the SAS system and means for LionTech Rocket Labs to create this system is to create at Science Mission Directorate that both completes the requirements for SMD as set by NASA and record data that the team can analyze afterward to determine any issues with its vehicle. The requirements and how they are met through the SAS system are as follows:
NASA REQUIREMENTS
Criteria Measurement/Requirement SAS System fulfillment
3.1.3.1. Pressure BMP085 Pressure/Temperature Sensor
3.1.3.1. Temprature BMP085 Pressure/Temperature Sensor
3.1.3.1. Relative Humidity HIH6131 Humidity Sensor
3.1.3.1. Solar Irradiance TEMT6000 Light Sensor
3.1.3.2. Measurement every 5 seconds Baud rate of at least 9600 will allow for
collection at least every 5 seconds
3.1.3.3. Measurement every 60 Baud rate of at least 9600 will allow for
seconds after landing collection at least every 60 seconds
3.1.3.4. Data collection terminate Program will collect data for 10
10 minutes after landing minutes after landing then terminate collection
3.1.3.5. Take 2 pictures during LSY201 Camera system will allow for
descent and 3 after landing all imagery during flight
3.1.3.6. Images shall be oriented Camera will be mounted to vehicle
such that sky is top of gram body to maintain correct orientation
and ground is bottom of frame
3.1.3.7. Data shall be stored onboard All data will be stored on on-board SD cards
3.1.3.7. Data shall be transmitted Data will be wirelessly transmitted
wirelessly after completion before system shutdown
3.1.3.8. Separation of payload not advised Payload will remain with vehicle at all times
3.1.3.9. Payload shall carry a GPS unit LS20031 GPS Unit
There is A LOT going on here, and this tutorial is pretty extensive and detailed. I would recommend going through all the steps first to really understand what is going on. I have tried to include as much detail as I can to allow anyone to re-create the system for whatever application they might want to use it for. The steps sort of follow the design process starting with the requirements, moving through the design, and finally ending with actual construction and testing.
It has quite a bit of requirements as set out by NASA and the Teams Project Maverick which make this project complex.
SAS CRITERIA – CUSTOMER NEEDS
Lion Tech Rocket Labs seeks to implement the Science Mission Directorate to track and analyze the vehicle’s flight post launch. The requirements set by the customer are as follows:
1. The product shall be contained on a single PCB board (and including external equipment)
2. The product shall be powered by a single 9 volt battery
3. All data must be stored for later analysis
4. All data will be wirelessly transmitted once flight has completed
5. The product shall contain all sensors for collecting pressure, temperature, humidity, solar irradiance, imagery, and global position
6. The product shall be completely automated and stand alone for flight
7. The product must collect data from apogee until ten minutes after landing, once every five seconds
8. The product shall fit easily into the vehicle’s body
SAS CRITERIA – MINIMUM REQUIREMENTS
1. Will be fabricated on a single PCB with connections for all external devices such as battery, GPS, camera, etc
2. Will be powered by a single 9 volt battery to sustain at least one hour of continuous run
3. System will contain micro SD cards for storing any collected data or measurements
4. System will implement wireless communication protocol to transmit all data collected during flight back to ground station once mission has completed
5. System will implement sensors for pressure, temperature, humidity, solar irradiance, imagery, and global positioning
a. Data collected shall be within expectations as set by testing procedures
6. System will be controlled by microcontroller units to analyze data collected and determine current mission stage and complete operations based on current stage
7. System will store all data beginning at apogee (one mile altitude)
8. System must collect data no less than at a rate of one sample every five seconds
9. System must automatically shut down ten minutes after landing and after wirelessly transmitting collected data
The objective of the SAS system and means for LionTech Rocket Labs to create this system is to create at Science Mission Directorate that both completes the requirements for SMD as set by NASA and record data that the team can analyze afterward to determine any issues with its vehicle. The requirements and how they are met through the SAS system are as follows:
NASA REQUIREMENTS
Criteria Measurement/Requirement SAS System fulfillment
3.1.3.1. Pressure BMP085 Pressure/Temperature Sensor
3.1.3.1. Temprature BMP085 Pressure/Temperature Sensor
3.1.3.1. Relative Humidity HIH6131 Humidity Sensor
3.1.3.1. Solar Irradiance TEMT6000 Light Sensor
3.1.3.2. Measurement every 5 seconds Baud rate of at least 9600 will allow for
collection at least every 5 seconds
3.1.3.3. Measurement every 60 Baud rate of at least 9600 will allow for
seconds after landing collection at least every 60 seconds
3.1.3.4. Data collection terminate Program will collect data for 10
10 minutes after landing minutes after landing then terminate collection
3.1.3.5. Take 2 pictures during LSY201 Camera system will allow for
descent and 3 after landing all imagery during flight
3.1.3.6. Images shall be oriented Camera will be mounted to vehicle
such that sky is top of gram body to maintain correct orientation
and ground is bottom of frame
3.1.3.7. Data shall be stored onboard All data will be stored on on-board SD cards
3.1.3.7. Data shall be transmitted Data will be wirelessly transmitted
wirelessly after completion before system shutdown
3.1.3.8. Separation of payload not advised Payload will remain with vehicle at all times
3.1.3.9. Payload shall carry a GPS unit LS20031 GPS Unit
Step 1: SAS Requirements and Components
Each sensor has been chosen for maximizing accuracy while minimizing power usage of the system. The table included below shows each sensor chosen to accomplish each of the required measurement. A detailed explanation of each sensor including wireless communication details can be found in the attached pdf.
SAS REQUIREMENTS and SENSOR SELECTION
Information Required Sensor Protocol Mount Type
Main Control System - Sensors Atmega328P N.A. Surface
Secondary Control - Camera Atmega328P N.A. Surface
Pressure BMP085 I2C Surface
Temperature BMP085 I2C Surface
Acceleration ADXL345 I2C Surface
Humidity HIH-6131 I2C Surface
Solar Irradiance TEMT6000 Analog Surface
Camera LS-Y201 TTL Connection
GPS LS20031 Serial Connection
Wireless Communication Xbee Pro 900 Serial Stand-off
Real Time Clock DS1307 I2C Surface
Each main system component also requires several secondary components. These are chosen for the best system performance with frequency response, noise minimization, and power efficiency.
Each component will be calibrated at initial system startup using built-in calibration functions. They will take into consideration current conditions and calibration constants when performing this task. The system will be initialized to set its current position as ground level and perform all measurements based on that positioning.
The system will use the main controller to collect data from all four sensors and the GPS and transmit wireless information. This data will be analyzed and then stored on a micro SD card. The LS-Y201 camera will be controlled using a secondary microcontroller. The secondary controller will use a second micro SD card to store the collected images. A control line will allow the main controller to signal the secondary controller to collect an image. The system architecture has been illustrated here.
A full schematic of the SAS system and PCB footprints will be provided later.
SAS REQUIREMENTS and SENSOR SELECTION
Information Required Sensor Protocol Mount Type
Main Control System - Sensors Atmega328P N.A. Surface
Secondary Control - Camera Atmega328P N.A. Surface
Pressure BMP085 I2C Surface
Temperature BMP085 I2C Surface
Acceleration ADXL345 I2C Surface
Humidity HIH-6131 I2C Surface
Solar Irradiance TEMT6000 Analog Surface
Camera LS-Y201 TTL Connection
GPS LS20031 Serial Connection
Wireless Communication Xbee Pro 900 Serial Stand-off
Real Time Clock DS1307 I2C Surface
Each main system component also requires several secondary components. These are chosen for the best system performance with frequency response, noise minimization, and power efficiency.
Each component will be calibrated at initial system startup using built-in calibration functions. They will take into consideration current conditions and calibration constants when performing this task. The system will be initialized to set its current position as ground level and perform all measurements based on that positioning.
The system will use the main controller to collect data from all four sensors and the GPS and transmit wireless information. This data will be analyzed and then stored on a micro SD card. The LS-Y201 camera will be controlled using a secondary microcontroller. The secondary controller will use a second micro SD card to store the collected images. A control line will allow the main controller to signal the secondary controller to collect an image. The system architecture has been illustrated here.
A full schematic of the SAS system and PCB footprints will be provided later.
Attachments
Step 2: The Program
The SAS system program has been defined based upon the flight plan illustrated here. Each component is defined throughout the flight. On standby the vehicle is monitored for acceleration due to powered ascent. Once the vehicle has lifted off the launch pad the system monitors altitude through barometric pressure. At apogee the system will start to monitor all data at a rate of once every five seconds and store it to the on-board SD card. Once the vehicle has landed the collecting rate slows to once per minute for a duration of ten minutes. After ten minutes has completed all data is transmitted wirelessly and the system is shut down.
Following the first illustration we have developed a program flow to define the program functions to be implemented. The program will provide two function options, TEST mode and RUN mode, for the team to select. In TEST mode, the system will collect data from each sensor, store that data to memory, and repeat. It will continue this process until it is either powered down or switched to RUN mode. In RUN mode the system operates in a state-machine type function. Each flight stage will be represented as a state within the program. Within each state the system will collect the necessary data as defined by the system requirements along with the necessary data for determining the next flight stage. Once the next flight stage is detected it will switch to that state. It will continue this process until the final stage of flight has been completed. Once the vehicle has landed it will complete it's ten minute timer, following by wirelessly transmitting the collected data and shutting down the system. This program flow chart representing this is illustrated here too.
I have attached the code for the final system here along with the libraries used. We originally did the program in Atmel Studio Six but i duplicated it and switched it to Arduino's format because i know there are a lot of arduino fans here. If you use another programming interface you can always switch it to work pretty easily. The code uses a handful of libraries so as long as you can port those correctly it should be pretty easy to use. A library was created for almost every component so it keeps the main code less cluttered.
The program uses a few functions for setting things up and initializing everything. It also has a function just for the RBG LED to set indicators. Finally there is a separate function for the RUN mode. The system operates in a state machine like fashion where it uses case statements to determine which stage it is in and completes inside functions for each state. The states are just integers that are defined in order at the top of the program so the names can be used instead of numbers.
Following the first illustration we have developed a program flow to define the program functions to be implemented. The program will provide two function options, TEST mode and RUN mode, for the team to select. In TEST mode, the system will collect data from each sensor, store that data to memory, and repeat. It will continue this process until it is either powered down or switched to RUN mode. In RUN mode the system operates in a state-machine type function. Each flight stage will be represented as a state within the program. Within each state the system will collect the necessary data as defined by the system requirements along with the necessary data for determining the next flight stage. Once the next flight stage is detected it will switch to that state. It will continue this process until the final stage of flight has been completed. Once the vehicle has landed it will complete it's ten minute timer, following by wirelessly transmitting the collected data and shutting down the system. This program flow chart representing this is illustrated here too.
I have attached the code for the final system here along with the libraries used. We originally did the program in Atmel Studio Six but i duplicated it and switched it to Arduino's format because i know there are a lot of arduino fans here. If you use another programming interface you can always switch it to work pretty easily. The code uses a handful of libraries so as long as you can port those correctly it should be pretty easy to use. A library was created for almost every component so it keeps the main code less cluttered.
The program uses a few functions for setting things up and initializing everything. It also has a function just for the RBG LED to set indicators. Finally there is a separate function for the RUN mode. The system operates in a state machine like fashion where it uses case statements to determine which stage it is in and completes inside functions for each state. The states are just integers that are defined in order at the top of the program so the names can be used instead of numbers.
Step 3: The Circuit
Here is attached images of the actual schematic. There is a lot going on here but i think it is pretty well organized.
The power section will use two LDO voltage regulators to supply 5v and 3.3v from a single 9v battery. There are LED indicators to show both regulators are operating correctly.
Both microcontrollers will be operating simultaneously and thus their reset functions have been connected together. That way when you press the reset button they are both reset. They each have their own serial communication ports and SPI programming ports. Both will operate at 16MHz clock frequency. The main system will also have control switches for switching between test mode, run mode, standby mode, etc. These switches are removable headers for safety of not false switching during setup. There is also a three-way LED indicator for showing the system's current program mode. (TEST, RUN, STANDBY).
The SD communication uses a hex converter to switch the signal from 5v to 3.3v so we don't burn out the cards. There are two SD cards, one for each microcontroller.
All thats left are the sensors, real time clock, and wireless system. All sensors use either I2C communication, serial communication, or analog communication. Each of the sensors are labeled.
I have also included images of the current PCB design, top layer, bottom layer, and component placement. The layout isnt necessarily special. For this system it is set up so the GPS and wireless system can be mounted on top of the board without interfering with other components or extending past the extents of the board. The circle outline of the PCB will allow for easy fit into the rocket's body, but this can obviously be changed for any other vehicle. I have also attached the Eagle files of the circuit and board here if you wanted to make changed to either without starting from scratch. NOTE: you will need to download the Sparkfun component library for Eagle to use the schematic (I like the way they organize everything in their libraries)
I have also attached the BOM here. There may have been a few changes since but it should contain all necessary components. The BOM will tell you what the part is, where it can be purchased and provide a link to that item.
For actually getting the circuit board made, there are a lot of options. We used a company that was recommended called "Advanced Circuits" because they offer a student discount. Other options we used for initial design testing, etc, were itead studio and batchPCB
The power section will use two LDO voltage regulators to supply 5v and 3.3v from a single 9v battery. There are LED indicators to show both regulators are operating correctly.
Both microcontrollers will be operating simultaneously and thus their reset functions have been connected together. That way when you press the reset button they are both reset. They each have their own serial communication ports and SPI programming ports. Both will operate at 16MHz clock frequency. The main system will also have control switches for switching between test mode, run mode, standby mode, etc. These switches are removable headers for safety of not false switching during setup. There is also a three-way LED indicator for showing the system's current program mode. (TEST, RUN, STANDBY).
The SD communication uses a hex converter to switch the signal from 5v to 3.3v so we don't burn out the cards. There are two SD cards, one for each microcontroller.
All thats left are the sensors, real time clock, and wireless system. All sensors use either I2C communication, serial communication, or analog communication. Each of the sensors are labeled.
I have also included images of the current PCB design, top layer, bottom layer, and component placement. The layout isnt necessarily special. For this system it is set up so the GPS and wireless system can be mounted on top of the board without interfering with other components or extending past the extents of the board. The circle outline of the PCB will allow for easy fit into the rocket's body, but this can obviously be changed for any other vehicle. I have also attached the Eagle files of the circuit and board here if you wanted to make changed to either without starting from scratch. NOTE: you will need to download the Sparkfun component library for Eagle to use the schematic (I like the way they organize everything in their libraries)
I have also attached the BOM here. There may have been a few changes since but it should contain all necessary components. The BOM will tell you what the part is, where it can be purchased and provide a link to that item.
For actually getting the circuit board made, there are a lot of options. We used a company that was recommended called "Advanced Circuits" because they offer a student discount. Other options we used for initial design testing, etc, were itead studio and batchPCB
Step 4: SAS Integration
The SAS System is set up to attach to any bulkplate in the vehicle. It has four holes for bolts to attach. In project Maverick it will be located in a clear acrylic tubing which will allow you to see the system as the vehicle sits for launch. A 3D model has been generated to show the board itself and also the board within the vehicle's payload bay. These are shown here.
Step 5: Testing and Usability
Once completing testing, the SAS system will provide a rugged, lasting product that the team can confidently use to track their vehicle with accuracy. All components will complete rigorous testing to prove that they meet the specified requirements and excellent workmanship has been achieved in the production of the product.
Each component of the system will be tested individually to ensure accurate operation along with a full system test to ensure complete and successful operation of the system as a whole. The completed test forms are attached to this step in a pdf booklet.
With complete testing of each individual component and testing of the system as a whole we can ensure successful operation throughout the flight.
ADXL345
The purpose of this test is to ensure the ADXL345 Acceleration Sensor is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The ADXL345 is important in detection of powered ascent during the mission. The ADXL345 is currently undergoing further testing
BMP085
The purpose of this test is to ensure the BMP085 Barometric Pressure Sensor is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The BMP085 is important in detection of the apogee stage and landing stage of the mission. The BMP085 has been fully tested.
DS1307
The purpose of this test is to ensure the DS1307 Real Time Clock is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The DS1307 is important for recording date and time correspondence with all data so it can be later compared to other results such as GPS coordinates or RGG data. The DS1307 has been fully tested.
HIH6131
The purpose of this test is to ensure the HIH6131 Humidity sensor is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The HIH6131 is important for recording temperature and humidity data during the mission which is one of the requirements set by NASA’s SMD requirements. The HIH6131 has been fully tested.
TEMT6000
The purpose of this test is to verify that the analog light sensor TEMT6000 is detecting light levels on the SAS System. The TEMT6000 is important for recording light level data during the mission which is one of the requirements set by NASA’s SMD requirements. The TEMT6000 has been fully tested.
LS20031
The purpose of this test is to ensure the LS20031 GPS Unit is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The LS200031 is important because it is the GPS unit that will track the vehicle’s flight through the mission for later analysis. The LS20031 has been fully tested
XBEE
The purpose of this test is to verify that the wireless communication protocol is working correctly. The wireless communication will allow for all data to be reported back to the team’s ground station during the vehicle’s flight. It is important that this communication is working correctly during flight. The XBEE unit has been tested but will be challenged more for maximum distance recorded.
LED
The purpose of this test is to ensure that the RGB LED component is fully functional. The RGB LED is vital in signaling the user what the system is currently doing when placed in the vehicle and preparing for launch. It will notify if there are any errors, which mode the system is in, and if it is ready for launch. The RGB LED has been fully tested.
MAIN CONTROLLER
The purpose of this test is to determine if the main microcontroller system is working properly. This test is required as the main microcontroller is the center of the SAS system. It and its peripherals must be working properly for the system to function. The Main Controller has been fully tested.
SECONDARY CONTROLLER
The purpose of this test is to determine if the secondary microcontroller system is working properly. This test is required as the secondary microcontroller is responsible for image collecting on the SAS System. It and its peripherals must be working properly for this system to function. The Secondary Controller has been fully tested.
SD 1
The purpose of this test is to determine if the SD card connection to the Main Controller is properly working. SD 1 is responsible for recording all data recorded by the SAS system during flight for later analysis. SD 1 has been fully tested.
SD 2
The purpose of this test is to determine if the SD card connection to the Secondary Controller is properly working. SD 2 is responsible for recording all images taken during flight. SD 2 has been fully tested.
Each component of the system will be tested individually to ensure accurate operation along with a full system test to ensure complete and successful operation of the system as a whole. The completed test forms are attached to this step in a pdf booklet.
With complete testing of each individual component and testing of the system as a whole we can ensure successful operation throughout the flight.
ADXL345
The purpose of this test is to ensure the ADXL345 Acceleration Sensor is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The ADXL345 is important in detection of powered ascent during the mission. The ADXL345 is currently undergoing further testing
BMP085
The purpose of this test is to ensure the BMP085 Barometric Pressure Sensor is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The BMP085 is important in detection of the apogee stage and landing stage of the mission. The BMP085 has been fully tested.
DS1307
The purpose of this test is to ensure the DS1307 Real Time Clock is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The DS1307 is important for recording date and time correspondence with all data so it can be later compared to other results such as GPS coordinates or RGG data. The DS1307 has been fully tested.
HIH6131
The purpose of this test is to ensure the HIH6131 Humidity sensor is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The HIH6131 is important for recording temperature and humidity data during the mission which is one of the requirements set by NASA’s SMD requirements. The HIH6131 has been fully tested.
TEMT6000
The purpose of this test is to verify that the analog light sensor TEMT6000 is detecting light levels on the SAS System. The TEMT6000 is important for recording light level data during the mission which is one of the requirements set by NASA’s SMD requirements. The TEMT6000 has been fully tested.
LS20031
The purpose of this test is to ensure the LS20031 GPS Unit is working properly on the SAS System. Proper operation is necessary for accurate results with the system. The LS200031 is important because it is the GPS unit that will track the vehicle’s flight through the mission for later analysis. The LS20031 has been fully tested
XBEE
The purpose of this test is to verify that the wireless communication protocol is working correctly. The wireless communication will allow for all data to be reported back to the team’s ground station during the vehicle’s flight. It is important that this communication is working correctly during flight. The XBEE unit has been tested but will be challenged more for maximum distance recorded.
LED
The purpose of this test is to ensure that the RGB LED component is fully functional. The RGB LED is vital in signaling the user what the system is currently doing when placed in the vehicle and preparing for launch. It will notify if there are any errors, which mode the system is in, and if it is ready for launch. The RGB LED has been fully tested.
MAIN CONTROLLER
The purpose of this test is to determine if the main microcontroller system is working properly. This test is required as the main microcontroller is the center of the SAS system. It and its peripherals must be working properly for the system to function. The Main Controller has been fully tested.
SECONDARY CONTROLLER
The purpose of this test is to determine if the secondary microcontroller system is working properly. This test is required as the secondary microcontroller is responsible for image collecting on the SAS System. It and its peripherals must be working properly for this system to function. The Secondary Controller has been fully tested.
SD 1
The purpose of this test is to determine if the SD card connection to the Main Controller is properly working. SD 1 is responsible for recording all data recorded by the SAS system during flight for later analysis. SD 1 has been fully tested.
SD 2
The purpose of this test is to determine if the SD card connection to the Secondary Controller is properly working. SD 2 is responsible for recording all images taken during flight. SD 2 has been fully tested.
Attachments
Step 6: Using the SAS System
One of the great features here is the system is being set up to really be used in a lot of different applications or adjustments. The programming is handling a lot of different possible situations and makes decisions or notifies the user. The program can also be adjusted for almost any vehicle if you wanted to use this project somewhere else like a high altitude balloon, etc..
One feature is allowing the user to switch between three modes of use. There is standby mode, test mode, and run mode available to the user. in standby mode the system simple sits and waits. This allows the user to get the system ready within the vehicle and simply activate run mode when the vehicle is ready for launch. In test mode the system simply reads all data, stores it to the SD card, and prints it through the serial monitor. This way small adjustments can be made to sensor calibration when needed. Finally run mode is exactly what it says. In run mode the system will run the full program outlines earlier. These modes are selected using the two pin connectors that were shown in the 3D model in the previous step. This was used instead of a switch so that there isn't any mistakes as to which mode its in. If all connectors are removed the system is in run mode. Each of the two connectors sets either standby or test mode. Standby always takes precedence (meaning you can be in standby mode before entering testing)
One of the other key features is the RGB LED. This has quite a few different notifiers for the user.
Blue Double Stops represents the system is in standby mode
Red Double Stops represents test mode is currently running
Green Double Stops represents the system is currently in run mode waiting for powered ascent (this means it's ready to go!)
Green Solid represents the system has been activated by powered ascent (or another acceleration) and is currently running
Red Solid represents that there as an error somewhere within initialization and calibration of the components.
This way the user can easily and quickly be able to tell what the system is doing and if it's ready for launch. The system also reports conditions and stages through the serial monitor if the user is currently testing. The LED can also be used to make four more color combinations using more than one color at a time if you wanted to add more signals.
One final note is that the voltage regulators are usable up to 16 volts. So if you wanted to adjust the power source you could change it out with anything between 5 and 16 volts. Gives it a little bit of flexibility for application.
Using the system is pretty simple once you understand it. Below I have created a simple step by step procedure for getting the system read for launch.
1. Clear all data from SD_CARD_1 and verify two empty text documents are saved titled “log.txt” and “gps.txt”
2. Clear all data from SD_CARD_2 and verify no files are stored
3. Insert both SD cards into respective slots
4. For TEST program
a. Insert both STANDBY and TEST jumpers
b. Connect fully charged 9 Volt battery to connector
c. LED will illuminate BLUE indicating system startup
d. When LED begins double flash BLUE the system has entered STANDBY MODE
e. When you are ready to begin test readings remove the STANDBY jumper.
f. LED will illuminate RED signifying TEST MODE.
g. When testing is complete remove battery.
h. SD Cards can now be removed and data can be analyzed
5. For RUN program
a. Insert only STANDBY jumper
b. Connect fully charged 9 Volt battery to connector
c. LED will illuminate BLUE indicating system startup
d. When LED begins double flash BLUE the system has entered STANDBY MODE
e. When vehicle is ready for launch, remove the STANDBY header.
f. LED will begin to double flash GREEN indicating the system is now in ONSTAND stage waiting for powered ascent detection. NOTE: If LED is illuminated steady GREEN, the accelerometer has been triggered and the system needs to be reset before launch.
g. Once vehicle has been recovered, remove battery from connecter. SD cards can then be removed for later analysis.
One feature is allowing the user to switch between three modes of use. There is standby mode, test mode, and run mode available to the user. in standby mode the system simple sits and waits. This allows the user to get the system ready within the vehicle and simply activate run mode when the vehicle is ready for launch. In test mode the system simply reads all data, stores it to the SD card, and prints it through the serial monitor. This way small adjustments can be made to sensor calibration when needed. Finally run mode is exactly what it says. In run mode the system will run the full program outlines earlier. These modes are selected using the two pin connectors that were shown in the 3D model in the previous step. This was used instead of a switch so that there isn't any mistakes as to which mode its in. If all connectors are removed the system is in run mode. Each of the two connectors sets either standby or test mode. Standby always takes precedence (meaning you can be in standby mode before entering testing)
One of the other key features is the RGB LED. This has quite a few different notifiers for the user.
Blue Double Stops represents the system is in standby mode
Red Double Stops represents test mode is currently running
Green Double Stops represents the system is currently in run mode waiting for powered ascent (this means it's ready to go!)
Green Solid represents the system has been activated by powered ascent (or another acceleration) and is currently running
Red Solid represents that there as an error somewhere within initialization and calibration of the components.
This way the user can easily and quickly be able to tell what the system is doing and if it's ready for launch. The system also reports conditions and stages through the serial monitor if the user is currently testing. The LED can also be used to make four more color combinations using more than one color at a time if you wanted to add more signals.
One final note is that the voltage regulators are usable up to 16 volts. So if you wanted to adjust the power source you could change it out with anything between 5 and 16 volts. Gives it a little bit of flexibility for application.
Using the system is pretty simple once you understand it. Below I have created a simple step by step procedure for getting the system read for launch.
1. Clear all data from SD_CARD_1 and verify two empty text documents are saved titled “log.txt” and “gps.txt”
2. Clear all data from SD_CARD_2 and verify no files are stored
3. Insert both SD cards into respective slots
4. For TEST program
a. Insert both STANDBY and TEST jumpers
b. Connect fully charged 9 Volt battery to connector
c. LED will illuminate BLUE indicating system startup
d. When LED begins double flash BLUE the system has entered STANDBY MODE
e. When you are ready to begin test readings remove the STANDBY jumper.
f. LED will illuminate RED signifying TEST MODE.
g. When testing is complete remove battery.
h. SD Cards can now be removed and data can be analyzed
5. For RUN program
a. Insert only STANDBY jumper
b. Connect fully charged 9 Volt battery to connector
c. LED will illuminate BLUE indicating system startup
d. When LED begins double flash BLUE the system has entered STANDBY MODE
e. When vehicle is ready for launch, remove the STANDBY header.
f. LED will begin to double flash GREEN indicating the system is now in ONSTAND stage waiting for powered ascent detection. NOTE: If LED is illuminated steady GREEN, the accelerometer has been triggered and the system needs to be reset before launch.
g. Once vehicle has been recovered, remove battery from connecter. SD cards can then be removed for later analysis.
Step 7: Safety and Quality Assurance
Safety and Mission Assurance
The SAS System does not contain many safety concerns for the LTRL team. During construction the team should use caution while using tools such as a soldering iron and do what is necessary to prevent injuries from misuse. The team should also use appropriate ventilation and breathing protection while operating a soldering iron during construction. The SAS System operates on low voltage components and therefore does not pose threat to any electrical shock due to misuse or failure. The team should also use caution should any components heat to an abnormal level but all designs and tests show no concern for over-heating. There are no environmental hazards presented with the SAS system.
Hazards
The only expected hazards are during construction of the SAS System. As stated in Safety and Mission Assurance, the team should use caution and proper breathing protection while operating a soldering iron.
Environmental Concerns
The SAS System does not present any environmental concerns
The SAS System does not contain many safety concerns for the LTRL team. During construction the team should use caution while using tools such as a soldering iron and do what is necessary to prevent injuries from misuse. The team should also use appropriate ventilation and breathing protection while operating a soldering iron during construction. The SAS System operates on low voltage components and therefore does not pose threat to any electrical shock due to misuse or failure. The team should also use caution should any components heat to an abnormal level but all designs and tests show no concern for over-heating. There are no environmental hazards presented with the SAS system.
Hazards
The only expected hazards are during construction of the SAS System. As stated in Safety and Mission Assurance, the team should use caution and proper breathing protection while operating a soldering iron.
Environmental Concerns
The SAS System does not present any environmental concerns
Step 8: Thats It!
and that's the Stand Alone Science Mission Directorate. Originally designed for Project Maverick with LionTech Rocket Labs but I hope with what I have given you here you can easily adapt it to any project you'd like. Feel free to use any of the information here. Please let me know if anything could use more detail or if you have any questions and as always constructive criticism is always welcome.
Thank you
Thank you