P17105: HABIP-DAQC
/public/

Preliminary Detailed Design

Table of Contents

Team Vision for Preliminary Detailed Design Phase

During the third phase, a preliminary detailed design is developed, to be completed in the fourth phase. The goals for this third phase are outlined below:

The above goals were completed as fully as time could allow. How each of these goals was completed can be seen, outlined below:

Updated High Level System Diagram

Much of the system diagram remains the same. The actual interfaces between the sensors and boards are more defined. For redundancy, each of the Raspberry Pi's, the MSP430 host controller and the motor controller will have their own independent power supplies. This will help limit the possibility of failure across the entire system. The MSP430 will also have a built in SD card to record all IMU and temperature data.

 High Level System Diagram Revision 2

High Level System Diagram Revision 2

Updated Engineering Requirements

Small changes to the Engineering Requirements include updating the camera requirements.
 Updated Engineering Requirements

Updated Engineering Requirements

Prototyping, Engineering Analysis, Simulation

Weight Analysis

 DAQCS: Weight Analysis

DAQCS: Weight Analysis

Reaction Wheel Prototyping

Very early stage prototyping of the reaction wheel was conducted during this design stage. Basic test stands were made to allow a platform to rotate freely. A geared DC motor with a sample reaction wheel attached was mounted upside down in a foam platform. Using an Arduino Uno and a H-Bridge motor driver board, the motor was able to be controlled manually. The motor speed, direction and acceleration was able to be controlled. Using this setup, 6lbs of weight was added to the platform. Accelerating the motor allowed to prototype the motors ability to rotate a stationary platform. Due to using a geared motor, the RPM of the motor is limited. Therefore, the motor is not able to apply a continuous torque for an extended amount of time. This resulted in the platform only being able to move in small increments. This experiment demonstrated the need for not only high torque, but also a high RPM range.

 Reaction Wheel Test Setup

Reaction Wheel Test Setup

The following link below includes a video of this reaction wheel test setup.

Video: Reaction Wheel Prototyping Demo

DC Motor Control with MSP430 and IMU

The goal of this prototyping was to ensure the ability to interface the MSP430 with the IMU. In order to test this, IMU data was sampled and used to control the direction and speed of the motor. The IMU angular velocity was detected around a single axis (z-axis). This measurement parameter was requested by the MSP430 over SPI to the IMU. The IMU would then return the requested value to the MSP430. This data was used in a control loop to control the rotation of the motor.

To determine which direction the IMU is turning a stationary angular velocity value is determined. This baseline measurement is then used to determine which direction the motor is turning. Values less than the baseline correspond to a counter-clockwise rotation and a value greater than the threshold corresponds to a clockwise rotation around the z-axis.

Once the direction of IMU spin is known, a GPIO pin on the MSP430 will be used to control the motor controllers’ direction. The speed of the motor is controlled via a PWM signal. Using the built in real time clocks on the MSP430, a PWM signal is generated using the GPIO pins. The greater the duty cycle of the PWM, the faster the motor will spin. If the IMU is not moving, a GPIO pin enabling the motor controller to function, will be set to low, and stopping the motor.

 MSP430 Interfacing with IMU and Controlling DC Motor

MSP430 Interfacing with IMU and Controlling DC Motor

The real motor that will be used in the final design will be a brushless motor. Brushless motors required a more advanced controller than the basic H-Bridge controller used in this experiment. The control interface for the real motor controller that will be used will be very similar to this experiment. Velocity will be controlled via a PWM signal and direction will be controlled via GPIO signals. In addition, the motor and motor controller we will be using will provide additional feedback that could be used for more accurate control techniques.

The following link below includes a video of this IMU and Motor control setup.

Video: MSP430 Reading IMU Data and Driving DC Motor

Raspberry Pi Zero Single Wire Temperature Sensor Acquisition

Two one-wire sensors were connected to the Raspberry Pi. The setup can be seen below. Python scripts were written to acquire the temperature decoding from the single-wire protocol. This temperature information was then polled at one second intervals from both sensors and stored in separate csv files pertaining to each sensor. The csv files opened in Microsoft Excel can be seen below the prototype picture with some minimal formatting.

 Raspberry Pi Zero Prototype

Raspberry Pi Zero Prototype

 One-wire sensor 0

One-wire sensor 0

 One-wire sensor 1

One-wire sensor 1

Drawings, Schematics, and Simulations

Host Controller Schematic

 DAQCS Host Controller Schematic

DAQCS Host Controller Schematic

Above is a detailed schematic outlining all of the necessary interfaces between the MSP430 LaunchPad Development Board. There are UART interfaces between all of the DAQCS Raspberry Pi’s and the MSP430. A SPI interface is used for communication the IMU. Another SPI interface is used to communicate between the MSP430 and the COMMS Raspberry Pi. The built in SD card reader also uses a SPI interface and 3.3V from the Launchpad, which will be used to store IMU data. Currently, the Maxon ESCON 70/10 is the brushless motor of choice. To interface with this, 4 GPIO pins are responsible for driving a combination of 2 PWM signal (to control speed and current limitation) and 2 TTL signals to determine direction and enable the controller. Another two GPIO pins are used acquire an analog signal using the built in ADC’s. These analog signals represent the feedback speed and current from the motors hall effect sensors. The Maxon controller is powered by its own high capacity 22.2V LiPo battery.

 DAQCS Host Controller Configuration

DAQCS Host Controller Configuration

Below is the current schematic representing the sensor acquisition side of DAQCS. There will be three single wire temperature sensors all utilizing one GPIO pin. One of these sensors will be inside the enclosure near the raspberry pi, while the other two will be outside of the enclosure measuring the outside temperature. In addition to this there will be a I2C pressure sensor that will be inside of the enclosure. These sensors will continuously be polled throughout the flight storing the data in a csv file. This configuration will be replicated 4 times with the addition of each camera in the future.

 Raspberry Pi Zero Schematic

Raspberry Pi Zero Schematic

MSP430FR5994 Launchpad Modifications

The MSP430FR5994 Launchpad development board will be used as the host PCB. This eliminates the need to create a custom PCB, since the development platform can be modified to pin-out all of the required interfaces. The below table outlines the critical communication interfaces needed, their used pins/headers, and any modifications to the launchpad that need to be completed. The table is followed by detailed rework instructions for completing the board modifications.
 Launchpad Modifications List

Launchpad Modifications List

 Launchpad Modification Diagrams

Launchpad Modification Diagrams

Bill of Material (BOM)

 Bill of Materials

Bill of Materials

The image above shows an updated bill of materials. The majority of the items needed are located in this list, to be completed in full at the end of the next phase.

 Updated Budget

Updated Budget

The image above shows the updated budget. It can be seen above that the team is going over the budget; however, the team may have a sponsorship that will cause a significant decrease in cost for the motor and its controller. An updated budget will be created in the next phase to reflect the outcome of the possible sponsorship.

Test Plans

Reaction Wheel Movement Test Plan

Background

The purpose of this procedure will be to outline the test of the reaction wheel design on an example or physical model of the instrumentation platform. Both components, the flywheel and the motor, will be experimented with in order to supplement the mathematical kinematic analysis already completed. This will allow for the team to make a decision in the buying of a motor and materials, as well as the final design for the flywheel. This will also allow for the algorithm for the control systems to become more complete.

Materials Needed

Several different motors with varying torques and RPM speeds Different flywheel designs (varying in radius, weight, attachment points, etc.)

Standards to be Followed

This test plan will not be modeled after any standards (i.e. ASTM) as this will be learning the ability of the motor to rotate a physical model of the instrumentation platform.

Test Procedure

 Motor Test Stand

Motor Test Stand


The figure above shows one platform that will be used in the testing of the reaction wheel. The motor, attached to the top portion of the prototyped instrumentation platform, is set upon the plates. There are two plates, attached with bearings, which allows for smooth rotation. The test setup can be seen below:

 Motor Test Setup

Motor Test Setup


The first test setup above allows for the team to ensure that the motor and its controller are functioning properly.

A second setup will be created in which the entire instrumentation platform is held up vertically by a fishing line, which allows for simulation of the high altitude balloon as closely as possible without the actual balloon and flight. Testing and creation of this platform will be completed in the next several weeks once weight and structure design is completed.

Desired Outcomes, Time of Completion, & Measurements

It is hoped that the reaction wheel is able to move the entire instrumentation platform around the z-axis. It should also help to move the instrumentation platform back to its original position. The desired outcome of this experiment is better controller, as well as the needed characteristics of the motor. Once the motor and controllers are received, the amount of time to complete this test will be several days.

The active working document can be found here.

Reaction Wheel Controller Test Plan

Background

The purpose of this procedure will be to outline the test of the reaction wheel controller designed on Simulink on an example or physical model of the instrumentation platform. All components will be configured as they will while in flight, with communication from the sensors and MSP430, as well as with the motor controller. This experiment will supplement the theoretical model created on Simulink to support it and to make the necessary changes to ensure the success of the reaction wheel.

Materials Needed

Standards to be Followed

This test plan will not be modeled after any standards (i.e. ASTM) as this will be focusing in on the constants needed for the PID controller. Similar procedures were followed in Classical Controls within the mechanical engineering department.

Test Procedure

Following the testing procedure entitled “Reaction Wheel Movement Test Plan,” the model of the instrumentation platform will be placed as it is in the second setup. This will allow for the controller and the instrumentation platform to be simulated as closely as possible to the actual conditions that will be seen by the high altitude balloon.

Upload the controller from Simulink as C code onto the MSP430. Then, rotate the entire instrumentation platform to take data from both the hall sensors on the motor, as well as the IMU on the entire platform. This will allow feedback and data to be taken in order to allow for further analysis of the controller. Change the PID constants as needed until the controller fits within the specifications given by the engineering requirements.

Desired Outcomes, Time of Completion, & Measurements

It is hoped that the reaction wheel is able to move the entire instrumentation platform around the z-axis so that it counteracts its original movement and returns to its original position. The desired outcome of this experiment is better controller that is able to accurately and effectively move the entire instrumentation platform. Measurements acquired will be the angular velocities of the instrumentation platform and the motor. Once the motor and controllers are received, the amount of time to complete this test will be several days.

The active working document can be found here.

Reaction Wheel Environmental Test Plan

Background

The purpose of this procedure will be to outline the test of the reaction wheel and its controller in the environmental conditions that it will undergo in flight. All components will be configured as they will be while in flight, with communication from the sensors and MSP430, as well as with the motor controller. This test plan will ensure that the reaction wheel subsystem will still be able to move adequately under the temperatures and pressures it will see above 60,000 feet.

Materials Needed

Standards to be Followed

An updated test plan will be created and will most likely be loosely based off of an ASTM standard. The ASTM standards that will be used will have to do with the cycling of motors and electrical components, as well as cycling components through atmospheric conditions.

Test Procedure

Place the instrumentation platform and reaction wheel in the setup outlined in the test plan entitled “Reaction Wheel Controller Test Plan.” The entire setup should then be placed in one of the altitude or thermal chambers in Slaughter Hall. Cycle the chamber through the necessary temperatures and pressures to ensure that the entire set-up is exposed to accurate environmental conditions. Be sure to collect data for the angular velocities of the reaction wheel, as well as the instrumentation platform. Check the data and sensors to ensure that everything is working correctly.

Desired Outcomes, Time of Completion, & Measurements

It is hoped that the reaction wheel is able to move the entire instrumentation platform around the z-axis so that it counteracts its original movement and returns to its original position even as it is exposed to the environmental conditions that it will see during flight. The desired outcome of this experiment is an instrumentation platform and reaction wheel that are able to withstand the thermal and pressure conditions of the environment. Once the motor and controllers are received, the amount of time to complete this test will be several days, assuming that multiple tests, several hours apiece, will be completed.

The active working document can be found here.

DAQCS System Power Consumption Test Plan

Background

The purpose of this procedure will be to outline a test to ensure the DAQCS has enough battery capacity to last for the entirety of the mission all environmental conditions it will undergo during the flight. All systems will be configured within the instrumentation platform structure as they would during a mission. The system will be tested at appropriate temperatures and pressures to ensure nominal values and capacity of the battery remain optimal.

Materials Needed

Test Procedure

Ensure all batteries of the DAQCS are fully charged. Assembled all of the components in their appropriate locations within the current instrumentation platform insulated structure prototype. In typical room temperature conditions and sea level atmospheric air pressure. This test will be completed a minimum of three times. Start all subsystems and begin data acquisition. An additional Raspberry Pi will be used to test the polling the host MSP430 for data over the SPI interface. If possible, a larger or more permanent source of power will be applied to this COMMS Raspberry Pi to ensure this battery will not die before the DAQCS dies. This will allow the DACQS to be tested completely independent of the COMMS system.

The GRSS will execute its typical function of periodic flashing of the LEDs and buzzing. A separate microphone module will be placed near the platform during test to measure the decibels being emitted by the buzzer. This will be used to record the start and stop time of the GRSS.

The Raspberry Pi Zeros will begin recording video and capturing sensor data at startup. All of this data will have a relative timestamp. The Raspberry Pi’s will also send sensor data over UART when requested by the host MSP430 board. This functionality will continue until the batteries are depleted and the Raspberry Pi’s turn off. The captured data on the SD cards will determine the overall operating time of each Raspberry Pi.

The host MSP430 will start acquiring IMU and temperature sensor data and will write it to the uSD card. It will use the IMU data and feedback from the motor controller to send speed and direction commands to the motor controller. The MSP430 will send and receive UART commands to and from each of the Raspberry Pis. The MSP430 will also over SPI with the demo COMMS Raspberry Pi Zero. The operation time will be measured by the relative timestamps of the data on the uSD card.

The reaction wheel power consumption will be tested by having the motor continuously operating to spin the entire platform back and forth between two different angles. An external timer will be started upon reaction wheel startup. The wheels operation time is not projected to be very long, therefore the reactions wheels motion will be physically observed until it stops to measure reaction wheel operation time.

The test conditions stated above will be repeated for while the instrumentation platform is tested in a temperature and pressure chamber. The temperature and pressures applied will mimic the conditions the HAB will experience on an actual mission.

Desired Outcomes, Time of Completion, & Measurements

The GRSS system should be able to last for a minimum of 3 hour in all conditions of test. This test should take a minimum of 3 hours to complete with a max of 10 hours. The performance of the GRSS will be measured by the decibels that are being emitted.

The Raspberry Pis should be able to capture all data for a minimum of 3 hours. The test will therefore take 3-5 hours to complete. The operation time will be recorded by data timestamps written to the uSD card.

The Raspberry Pis should be able to capture all data for a minimum of 3 hours. The test will therefore take 3-10 hours to complete. The operation time will be recorded by data timestamps written to the uSD card.

The reaction wheel system should be able to operate for a minimum of 15 minutes. The test will therefore take 0.25-2 hours to complete. The operation time will be recorded by physically observing the platforms motion for the entirety of the test.

The active working document can be found here.

GRSS Test Plan

Background

The purpose of this procedure will be to outline the test of the Ground Recovery Signalling System (GRSS). There are four areas of requirements that the GRSS will need to be designed to fulfill. These requirements are in the area of the distance one can see the GRSS with the LEDs, the distance one can hear the GRSS via the buzzer, the length of time the GRSS lasts before the battery is drained and the performance of the components in a near-space environment. This experiment will assess the former two since the latter two will be tested in the “DAQCS System Power Consumption Test Plan.”

Materials Needed

Standards to be Followed

This test plan will not be modeled after any standards (i.e. ASTM).

Test Procedure

Following the testing procedure entitled “Reaction Wheel Movement Test Plan,” the model of the instrumentation platform will be placed as it is in the second setup. This will allow for the controller and the instrumentation platform to be simulated as closely as possible to the actual conditions that will be seen by the high altitude balloon.

Upload the controller from Simulink as C code onto the MSP430. Then, rotate the entire instrumentation platform to take data from both the hall sensors on the motor, as well as the IMU on the entire platform. This will allow feedback and data to be taken in order to allow for further analysis of the controller. Change the PID constants as needed until the controller fits within the specifications given by the engineering requirements.
 GRSS Schematic

GRSS Schematic

Desired Outcomes, Time of Completion, & Measurements

It is hoped that both the buzzer will be heard and the LEDs will be seen past a distance of 50 feet away from the platform. The desired outcome is to find out if there is tangible need to acquire new parts to fulfill the requirements. This test will take 1 hour and will be measured in feet.

The active working document can be found here.

DAQCS System Power Consumption Test Plan

Background

The purpose of this procedure will be to outline a test to ensure reliable communication between the DAQCS host microcontroller (MSP430FR5994) and the COMMS host controller (Raspberry Pi). Multiple levels of tests will need to be commenced to ensure data transmissions will be reliable and will not affect the overall performance of the platform. The system will be tested at appropriate temperatures and pressures to ensure proper operation in all conditions.

Materials Needed

Test Procedure

Ensure all batteries of the DAQCS are fully charged. Assembled all of the The first low level test will consist of just the MSP430 being interfaced to the COMMS Raspberry Pi over SPI. The COMMS Pi will send a specified command to the MSP430. The MSP430 will have an array of “fake” sensor data that will be packaged and sent back over SPI to the COMMS Raspberry Pi. This test will be conducted at multiple request intervals ranging from four times a second to once a minute. Develop software on the Raspberry Pi that will request data and ensure the data is received by a particular deadline. If data is not received by deadline, flag an error.

The second step to this test procedure includes having the MSP430 also interface with the DACQS Raspberry Pi’s to periodically receive updated data. The COMMS Pi will send a specified command to the MSP430. The MSP430 will acquire sensor data that will be packaged and sent back over SPI to the COMMS Raspberry Pi. This test will be conducted at multiple request intervals ranging from four times a second to once a minute. Develop software on the Raspberry Pi that will request data and ensure the data is received by a particular deadline. If data is not received by deadline, flag an error.

The third part of this test includes having the DAQCS also implementing the reaction wheel control. Run all systems of the MSP430 while sending and received commands from COMMS Raspberry Pi. Develop software on the Raspberry Pi that will request data and ensure the data is received by a particular deadline. If data is not received by deadline, flag an error. The deadline will be defined by the maximum transmission time without affect reaction wheel performance.

The test conditions stated above will be repeated for while the instrumentation platform is tested in a temperature and pressure chamber. The temperature and pressures applied will mimic the conditions the HAB will experience on an actual mission.

Desired Outcomes, Time of Completion, & Measurements

For the first part of the test, all data should be received at all transmission intervals and in all environmental conditions. This test should take roughly 3 hours to complete if including testing the environmental conditions. All received data should be identical to the sent data.

For the second part of the test, all data should be received at all transmission intervals and in all environmental conditions. This test should take roughly 3 hours to complete if including testing the environmental conditions. All received data should be identical to the sent data and all deadlines should be met.

For the third part of the test, all data should be received at all transmission intervals and in all environmental conditions. This test should take roughly 3 hours to complete if including testing the environmental conditions. All received data should be identical to the sent data and all deadlines should be met. The reaction wheel performance should not be hindered by data transmissions.

The active working document can be found here.

Design and Flowcharts

Design of Reaction Wheel

The first step in determining the design of the reaction wheel was calculating the necessary torque and angular velocity required to overcome the instrumentation platform's movement. The calculations may be seen below:

Motor Acceleration & Torque Calculations

Motor Acceleration & Torque Calculations


Motor Angular Velocity Calculations

Motor Angular Velocity Calculations


A MATLAB script was then written in order to create plots that would allow the team to design an optimal reaction wheel and find a motor that will work. It can be found here.. The plots that were generated for steel can be seen below:

Torque [Nm] vs. Mass [kg] Plot

Torque [Nm] vs. Mass [kg] Plot


Torque [Nm] vs. Radius of Flywheel [m] Plot

Torque [Nm] vs. Radius of Flywheel [m] Plot


The material used in the above plots is steel, which was found in the shop when speaking to a subject matter expert. The torque and radius values were found to be 0.4157 Nm and 1.23 inches, respectively, if the ramp up time is taken to be about 0.35 seconds.

After researching online, it was determined that a Maxon motor would be the best fit for the reaction wheel. However, these motors are very expensive, so the team reached out to Maxon. Currently, the team is still in discussion with Maxon Motors; however, it appears that a sponsorship agreement may be made that would allow for the team to obtain a motor and controller at a reduced price.

EC Brushless Motor

EC Brushless Motor


ESCON Motor Controller

ESCON Motor Controller


After determining which motor was to be used, a 3D CAD model was then created, which can be seen below:

CAD Model

CAD Model


The image on the right-hand side above is a drawing of the motor and flywheel in the positions they will be located in on the instrumentation platform. After some discussion with two other subject matter experts, one in vibrations and the other in control systems, it was determined that the best way to mitigate vibrations disrupting the instrumentation platform and causing issues was to create a notch filter in the control system controlling the reaction wheel.

Controller Design

Controller Design


The controller shows that the inputs and feedback will be the angular velocities of both the instrumentation platform and the motor, which will be found via IMU and Hall sensors.

Raspberry Pi Zero High Level Software Flow Diagram

The main task of the Raspberry Pi is to acquire temperature, pressure, and camera sensor data. Although the goal of the Raspberry Pi system is to send data to the COMMS host when requested, the Raspberry Pi can log data autonomously. So if the communications link goes down, the Raspberry Pi will continue to log data. For this reason, four processes are run during the mission. These processes are independent of each other and include: temperature logging over 1-Wire, pressure logging over I2C, photo/video logging over MIPI, and a UART control Monitor. A higher level monitor will make sure that these four processes are constantly running in parallel. If any of the processes terminate, the high level monitor will attempt to restart the process (and eventually reset the CPU if process restart is unsuccessful). The UART process is responsible for listening over the UART interface for commands requested by the MSP430. The MSP430 commands are relayed commands from the COMM's CPU and include actions (such are hard/soft reset, and changing camera frame rates) and data requests to pull the most recent copy of sensor data. The below flow diagram outlines this process is greater detail:
 Raspberry Pi Zero SW Flow Diagram

Raspberry Pi Zero SW Flow Diagram

Risk Assessment

The risk assessment document from this phase is the same as last phase, aside from one change: the likelihood of moisture or condensation causing issues and possible inability of the platform to function has decreased from 6 to 3. This caused the importance level to reduce to 27. It can be found here.

Design Review Materials

Preliminary Detailed Design Review presentation can be found here.

Plans for next phase

Detailed Design Phase Gantt Chart

Detailed Design Phase Gantt Chart

Detailed Design Phase Gantt Chart

Individual Plans

Sydney Kaminski's Three Week Plan: Sydney's Goals

Steven Giewont's Three Week Plan: Steven's Goals

Lincoln Glauser's Three Week Plan: Lincoln's Goals

Chris Schwab's Three Week Plan: Chris's Goals


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design | Component Schematics and Drawings

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation