
[[File: \|300px\|center\|alt=]]

Sponsors	NASA Ames Research Center[1] Idaho Space Grant Consortium[2]
Team Name	TARDIGRADES
Duration	FALL 2020 - SPRING 2021
Faculty Adviser	Dr. Feng Li
Client	Avery Brock [NASA ARC]
Team Members	Grace Rosenvall (ME) Joseph Dennison (CompE) Andrew Pilchart (EE) Harrion Thomsen (EE) Lillian Mortensen (MSE) Taegen Williams (CS) Cosette King (CS) Robert Goes (CS) Finan Bryan (ME)

Orbiting the Earth alongside large objects like the Hubble Telescope or the ISS, small satellites, known as CubeSats, are flown for educational or experimental purposes and are about the size of a shoebox. Two integral components of these small satellites are the ADCS, the system that controls the satellite’s position, and the communication module, the system that sends and receives information. Integrated, commercial versions of these systems are generally cost-prohibitive for a CubeSat application. The goal is to instead use individual components to make a cheaper control system and to create a board that will apply existing technology to the CubeSat scale. The solutions we create will lead to better control of the satellite and increased ability to send information to ground. This larger rate of data transfer allows for more complex functionality, like running a Star Tracker, to occur.

Problem Definition[edit | edit source]

Team Tardigrades' first primary goal will be to complete the development of the hardware and software for the Iridium 9523 Satellite Modem and its associated carrier module. This year will be the conclusive year on the project as it was started in the Fall of 2018 by the Capstone research team SCUBEE. The Iridium 9523 is capable of communications in the form of Short Burst Data (SBD) and stream network (RUDICS) modes. It has current use in NASA’s REBR program and The ESA’s QARMAN satellite. By completing this project, the effort put into the 9523 Satellite and its carrier will significantly improve the communication of smaller satellites in use. The design for this project is a fraction of the cost and complexity of standard satellite communication through radio modems. With progress already made on the project through the design team SCUBEE and team FIRE, a final flight-ready unit is a deliverable at the end of the project. If the project can uphold the deadline, the satellite could see a flight opportunity in 2021.

This portion of the project can be broken down into 3 main components:

The software necessary to provide encrypted communication from the ground server to the satellite.
Managing firmware development between the dev board and the SAMD51.
Designing a Radio Frequency power boost converter.

The ADCS sub-team has the complementary goal of developing a modular Attitude Determination and Control system for a 6U satellite. The focus of this group will be to develop a unit with lower cost and lead time compared to a commercial ADCS system. The final ADCS system should have comparable pointing abilities to commercial models, utilizing a combination of instruments (flywheels, magnetorquers) for attitude control and attitude determination (magnetometers, sun sensors, and IMUs). The group is expected to perform component selection, prototyping, and testing of individual components, but not the combined system.

This portion of the project can be broken down into 4 main components:

Consult materials against radiation shielding
Develop control and firmware needed
Development of electronic components and firmware for Sun Sensors, Magnetometers, and IMU
Consult components to research and manufacture including torque rods, PCB Magnetorquers and Reaction Wheels

Background[edit | edit source]

The Nano Orbital Workshop (NOW) department at NASA Ames focuses on finding cost-efficient solutions to small satellite development. This department researches cutting-edge development in computer science and engineering to create novel low-cost technology. The NOW Group has partnered with the University of Idaho's research initiative for many years to introduce students to the innovations in satellite development. These interest groups can complete educational satellites and see demonstrations through flight. With the recent launch of the TES-10 satellite, the NOW group is focusing on the use of GPU processors in space. Some of the current interests in GPU processors can be seen in its ability for autonomous navigation, onboard network communications for data transfer, and guided reentry via Exo-Brake technology. This year, the team will be focusing on the continuation of the use of the TFLOP GPU processors and begin the design and prototype for a new electromechanical satellite system.

Guided Parafoil System (GPS)

A team in 2014 had completed the foundation of the project by creating the guided parafoil system that can move the returning payload to a pre-determined GPS location on its return.

SCUBEE: Space Communication Utilizing Backbone Existing Networks Fall 2018 - Spring 2019

Team SCUBEE had created a carrier module able to control and house the Iridium 9523 modem to integrate into the cube satellite. Team SCUBEE had also created the initial code for communicating over the Iridium satellite network using the Iridium 9523 via short bust data (SBD) messages.

FIRE: Firebox Iridium Re-Entry Fall 2019 - Spring 2020

Team fire built off of team SCUBEE's work by creating a building off of the communication system with the Iridium 9523, added the Canon BP-955 as a power source with a fireproof containment unit. Team FIRE had also re-designed the carrier module to host the Iridium 9523 in a more compact way.

Deliverables[edit | edit source]

Iridium 9523[edit | edit source]

Software / Firmware

Software for encrypted communication from the ground server to the Iridium 9523

Updated firmware for the switch between the SAMD21 to the SAMD51

Firmware for the initialization of power between the SAMD51 and the Iridium 9523

Software to handle unexpected technology behavior

Software for a ground server to communicate with the Iridium 9523

Software to parse and analyze decrypted information at the ground server and on the Cube Satellite

Development Board

An updated schematic for the development board

A Redesign of the Boost Converter

Hookup the Development Board to the SAMD51

ADCS[edit | edit source]

Research

Create a cost benefit analysis for Electrical Engineering components: sun sensors (coarse & fine), magnetometers, Inertial measurement unit (IMU)

Create a cost benefit analysis for Mechanical Engineering components: Torque Rods, Magnetorquers, Reaction Wheels

Research the best control device and firmware needed to control the selected hardware

Select Components

Select the best choice for satellite components and prepare for the assembly of a prototype

Select the best material for ware conditions with predictions on longevity

Select the best material for radiation shielding

AI in the Sky[edit | edit source]

Software

Research and develop an experiment to demonstrate machine learning on an active space craft

Develop software to determine the radiation effects of a running GPU

Develop a low bandwidth slow-paced interactive program to demonstrate GPU abilities

Design a better carrier for the Nvidia GPU

Specifications[edit | edit source]

The requirements as outlined by our client are shown below:

Iridium 9523 Main Requirements[edit | edit source]

Design and test firmware and ground software for SAMD51-based 9523 board
Need to update the SAMD1 board developed by SCUBEE to a SAMD51
Send schematic to our client for an updated development board with focus on updating the boost converter
Receive board back from client for final Development and testing

Focus	Required Parameters
Computer Engineering	Hookup the Dev board to the SAMD51 Split firmware between the development board (Iridium 9523) and the SAMD51
Electrical Engineering	Hookup the Dev boar to the SAMD51 Design the RF Power Boost Converter - Client has a preference for it to be gallium nitrate MOSFET Help with the firmware development
Computer Science	Firmware development for the SAMD51 Software development for parsing and analyzing incoming and outgoing data Encryption and Decryption for communication between the ground server and the Iridium 9523 Ground Server software development to communicate the with the Iridium 9523 in Data Mode

ADCS Main Requirements[edit | edit source]

Research and select the ADCS components
Design a driver topology to enable control system growth

Focus	Required Parameters
Electrical Engineering	Cost Benefit Analysis for Coarse and Fine Sun Sensors Cost Benefit Analysis for Magnetometers Cost Benefit Analysis for inertial measurement unit (IMU)
Mechanical Engineering	Cost Benefit Analysis for Torque Rods Cost Benefit Analysis for PCB Magnetorquers Cost Benefit Analysis for Reaction Wheels Selection of components for Modeling and Physics for the ADCS
Computer Science	Research the best control options for the ADCS Develop controls and firmware to manage the selected hardware
Material Science Engineering	Research the best material for ware conditions Radiation shielding for the cube satellite

ADCS Minimum Viable Product[edit | edit source]

The goal of the product developed by the ADCS subteam is to be sent to NASA for vibration testing. This will inform future iterations of this assembly and ultimately the flight unit.

Mechanical Requirements:

Operable within a vacuum

Can withstand high levels of radiation

Will burn up in the atmosphere (this influenced the type of 3D printed material used, for instance)

Fits within 1U (10cm x 10cm x 10cm cube)

Weighs less than 3 lb

Can turn the whole satellite in a reasonable amount of time

Electrical Requirements:

Function from a 9V input voltage

Process sensor data and drive motors

Be able to work alongside mechanical design (same form factor)

AI in the Sky Main Requirements[edit | edit source]

Research and develop an experiment to demonstrate useful machine learning on an active spacecraft
Develop software to determine the radiation effects on a running GPU
Develop a low bandwidth slow-paced interactive program to demonstrate GPU abilities
Design a better carrier for the Nvidia GPU

Focus	Required Parameters
Computer Science	Develop a meaningful experiment to run on-orbit GPU Develop ADCS software interfacing Base firmware to swap active software
Material Science Engineering	Develop Radiation Shielding Research Heat Dissipation through alcohol heat pipes, water pipes, and solid copper in space

Design Considerations[edit | edit source]

9523 Considerations[edit | edit source]

Firmware[edit | edit source]

For the firmware development, there were two things to consider, the architecture and the operating system. For the architecture some of the concepts that were considered was the super-Loop with a finite state machine, the event driven or the task based.

Program Architecture

Super-Loop

A super loop program structure consists of an initialization routine and an infinite loop.

RTOS

Problems with Arduino: The Arduino base libraries such as Serial.h do not have a robust code design. For example, in a personal project, a buffer overflow from attempting to send data to fast causes a memory overwrite.

Multithreading: During discussions with Avery, it became obvious that we would need functionality to handle multiple concurrent processes. For example: While the satellite is spending 15min transmitting data, another device onboard requests to send data. In this case, it would be logical to have one process handle the transmission, and another process handle the notification of being busy. Arduino support for this is EXTREMELY limited.

Design Validation: Unlike Arduino, RTOS is used heavily in industry, including at Nasa. Because of this, robust software for validating the functionality of code exists.

Native libraries: Since Arduino is hobbiest focused, it does not have robust, tested libraries for basic memory functions involved with transmitting data. In contrast, a RTOS will feature tested and integrated communication and memory management features.

Watchdog timers:Most RTOS use a chips full functionality, such as watchdog timers, which allow recovery from a fatal error. This would be important since once the satellite launches, we have no way to update the code.

Zephyr RTOS

C-language-based Real time operating system that is extremely lightweight (sub 40kb) that is used widely in industry and had a heavy verified codebase and design validation and error checking functionality.

We would use it as the bootloader and program Architecture to build our program upon and support functionality for memory management, communication, testing, multithreading.

In order to switch we would need to accomplish the following:

Add support for Chip (SOC family support) :

Zephyr currently supports the Adafruit Feather M4 express which uses the SAMD51 J19A chip, the board we are using is the Adafruit Grand central M4 which uses the SAMD51 P20A chip. The difference between these two chips is the latter has twice the memory, and an additional crystal oscillator

In order to add support, a new SOC(system on a chip) configuration for the P20A variant will be made, this is a well documented, abet, complex, process. The difficulty will be lessened by the fact the J19A configuration is very close. This work can be accomplished over winter break by me.

Add support for Board (Board support):

The configuration files for the feather board will be adapted to the grand central. Adafruit has extensive documentation on the slight differences, so this should not be to difficult. (SPOILER ALERT! IT IS!)

Add support to dev environment:

A simple configuration file based on the Feather configuration will be added to platformIO to allow ease of development for other CS team members.

Ground Server[edit | edit source]

The Hardware

The ground server was first considered to be located on the University of Idaho Network. When our team communicated that we needed an outward facing server on the network, they brought up multiple complications and documents that we would take longer than our time on this project. Because of this drawback, we setup our ground server through digital ocean as it provides our team an internet facing server with a static IP address.

The Software

The ground server software was straight forward. Our team understood we needed a simple socket connection that could receive communication on a binded port, but we initially struggled with implementing encryption with pre created code used on the Satellite RTOS firmware. After communicating with the team, we decided on using the wolfcrypt library to implement AES256 encryption across the internet.

ADCS Considerations[edit | edit source]

In the first semester of development of our ADCS, we investigated the design of current commercial ADCS units, as well as the off-the shelf options for individual components. Commercial options included the Mai-400 by Maryland Aerospace, as well as the Integrated ADCS by Cubespace. Both options were high cost, with the Cubespace model running $24,700-37,000. The components we selected for our in-house ADCS included an inertial measurement unit (IMU), a sun sensor, a magnetometer for sensing attitude, as well as torque rods and a flywheel for attitude control. Each member of the team was assigned to research the working principles 1-2 components and find off-the-shelf options. A decision matrix was used to evaluate the best option for each.

Torque rods pass a current through wire coils to create a magnetic field, which then interacts with Earth’s magnetic field to generate a moment force. They can have air cores or ferrous cores; the ferrous cores are more powerful but require a demagnetization procedure after being used and are also heavier. Unlike flywheels, torque rods do not have any moving parts, which means fewer points of failure and generally higher reliability. They are, however, limited due to only being able to produce torque parallel to the magnetic field. SatBus MTQ M6P, CubeSpace Cube Torquer (Small), and MTQ200 torque rods were evaluated in the design matrix based on cost, moment generated, mass, flight history and efficiency. The CubeSpace torque rods, made with a ferrous core treated to have low residual dipole, scored highest. As of May 2nd, they cost $790 each or $2120 for three.

Sun sensors work by detecting the incident angle of sunlight, so the CubeSat can determine its relative angle to the sun. For this component, we considered Hamamatsu s5991/ s5990, and Mouser QP50-6-SM, as well as creating our own by buying photodiodes and attaching them to a pyramid-shape support structure. While photodiodes would have been a low-cost approach, the testing, programing, and validation process it would require couldn’t be justified, especially since Hamamatsu sun sensors retailed for $24. The design matric variables used were cost and accuracy. Efficiency was initially included, but the draw for all sun sensors was so small as to be negligible.

IMUs include multi-axis accelerometers and gyroscopes to measure minute changes in inertia. The models considered were Adafruit TDK InvenSense ICM-20948, VUPN6602, and SEN-15335 ICM-20948. The design matrix variables compared were cost, accuracy, and flight history, with the Adafruit IMU ranking highest. It has a 3-axis gyroscope with a range of +/- 2-16 g, and a 3-axis accelerometer with a range of +/- 250-2000 dps.

The magnetometer could determine attitude with respect to the earth's magnetic field, but also is important for torque rod operation. The magnetorquers PNI RM3100, DRV425-Q1, and NSS Magnetometer were evaluated based on cost, accuracy, efficiency, and flight history. DRV425-Q1, by Texas Instruments, scored highest.

The flywheel we decided to manufacture in-house to decrease costs, by up to an order of magnitude. The flywheel system is uniaxial instead of tri-axial because the CubeSat it will fly on already has 2-axis control from outside torque rods. This flywheel is also commonly referred to as a reaction wheel. It functions much like the classic physics class experiment where a person spins up a bicycle wheel and stands on a lazy susan. The person then rotates due to the conservation of angular momentum. Likewise, a reaction wheel functions by spinning up one direction, causing the satellite to rotate the opposite direction in order to counter the momentum. Since this design was the most flexible and commercial options were rare and expensive, the team opted to design and manufacture one.

Project Learning[edit | edit source]

ADCS[edit | edit source]

In the project we have learned how to effectively manage a project budget as well as how to properly research different components. We’re trying to understand how components work so that we can choose an adequate but low-cost option. Grace Rosenvall needed to do research and calculations to understand how reaction wheels worked with regards to angular momentum and to ensure the feasibility of my design. Andrew Pilchard completed research on the selection for RF converters. With all of the teams selections we had to simulate them in the circuits to see if they could work with our design specifications.

9523[edit | edit source]

Over the past 10 months, the 9523 subgroup has overcame multiple challenges in developing the firmware and communication back to the ground server.

Final Design[edit | edit source]

9523[edit | edit source]

With the concept selection being Arduino with FreeRTOS, the structure involves five tasks with equal priority levels to prevent deadlocking task that would require to read the serial buffers (Ex. TechEd command or Iridium dropping its call). These tasks can communicate with each other via queues that each task will check if a request was received (Ex. CubeSat wants to know TEMP sensor readings). Here are the five task that made up our firmware dev:

Cube Satellite RTOS tasks Firmware

Serial Communications Task

The Serial communication task (TESBUS Task) is the interaction between the main CubeSat computer and our Iridium 9523 carrier board. The TechEdSat bus will send commands to this task via UART which will then become parsed and be sent to its respective queue. If the command is on carrier board controls (Ex. Receiving TEMP/Power consumption readings or Turning ON/Off ), the TESBUS task will send the command to the Heartbeat queue. If the command is on Iridium signal quality or transmitting a message via SBD or RUDICS, the command will be sent to the Iridium queue. Lastly, this task receives the responses from the Heartbeat/Iridium Tasks back to the TechEdSat Bus to give acknowledgements to their commands.

Heartbeat Task

The Heartbeat task runs the carrier board’s non-Iridium functionalities. Every second, the task will read the TEMP sensors. Every 30 seconds or upon request from TESBUS command, a Heartbeat message will be sent to the TESBUS queue on the TEMP and power consumption readings from their respective Analog sensors. The power consumption readings are the voltage and current readings from where NASA Ames would like to observe (Ex. Readings from the Boost Convertor) via an ADC. If the TEMP sensors ever reach a reading over 70 Celsius, the board is too hot to transmit a message via the Iridium 9523 and needs to shut off to lower the temperature. A shutoff command from TESBUS could also shut the board off until restarted.

Iridium Task

The Iridium task is the interaction between the carrier board and Iridium 9523. Whenever this task receives a transmit command through the Iridium queue, the Iridium task would go through the Iridium 9523 AT command protocol. Which would involve waiting for the signal quality to be good enough for the message to be transmitted. Then dependent on which type of communication is being used, SBD or RUDICS, the task will be using a modified Iridium library to transmit the message via Iridium 9523.

Watchdog Task

The Watchdog task prevents the possibility of deadlock by restating the processor if the watchdog timer times out due to any fatal error that may occur .

RandomGen Task

The RandomGen task generates random data to send through the Iridium queue whenever a random data SBD/RUDICS transmit command is sent from the TESBUS.

Ground Server[edit | edit source]

The ground server code is running the python function below. The ground server initially binds a port to the static IP address of the ground server. It then creates a loop waiting for a connection from the client. After establishing a connection from a client. The communication is then written to a file and printed to the screen.

Ground Server RUDICS socket connection

If the communication is encrypted, then we decrypt the data using the function below. With the Wolf crypt library, encryption and decryption are made easy with a static IV and a static password that only the client and server know.

Decryption Function for received communication

ADCS[edit | edit source]

Mechanical[edit | edit source]

The Final Design of the Reaction Wheel

Stats:

- Moment of Inertia = 26122.27 g*mm^2
- Diameter = 58mm
- Thickness = 11mm

Improvement from old stats:

- Moment of Inertia: 11029.21 g*mm^2
- Diameter = 48mm
- Thickness = 9mm

The reaction wheel design was based off of the initial design from the first semester of work. Two designs were explored: a solid wheel and a spoked wheel. The spoked wheel design was chosen as placing more mass away from the center meant that the wheel could be lighter but still effective. The goal with this design is to reduce weight and size while still maintaining an effective system.

The wheel is designed for direct mount to the Maxon 351006 motor shaft, a 2mm shaft. Due to tolerancing, the hole on the wheel must also be 2mm in diameter. The wheel is secured to the shaft using a set screw. Three would be optimal but due to geometry, is not possible. This will be discussed further in the Future Work section.

The wheel is made out of aluminum alloy. This project used 7075, though 6061 should also be acceptable. The base plate is the standard TES104 form factor, made out of 1/8” aluminum plate. The motor and wheel are mounted to a motor mount that was 3D printed using the multi-jet fusion process available through GoProto. It’s a PA12 Nylon material and should have the rigidity and composition required for the application. The cover that contains all the moving pieces is made out of this same material using the same process. Small vents were added to the sides of the cover to align with NASA venting requirements.

This wheel can impart 0.8 revolutions in a minute to the satellite at maximum speed. If the speed is lowered to something more reasonable, the satellite will still be within the required range of time for rotation.

The Mechanical Design

Electrical[edit | edit source]

The Electrical Design

Our final conceptual design consisted of the schematics for the SAMD21, IMU motor driver, and power convertor. We previously had dev boards for the SAMD21 and IMU. We ended up designing dev boards for the motor driver and the power converter. Due to time constraints, we were unable to send the final design board to a manufacturer. Thankfully all the next group has to do is integrate the components together and send the board to a manufacturer.

Once the final PCB is completed, they can test the flywheel. Our conceptual design for the electrical control system was based around the SAMD21 working as the communication module between the IMU and the motor driver. The IMU measures the speed, direction, acceleration, and the angular rate of the CubeSat itself. The motor driver communicates to the motor and tells it to turn clockwise or counterclockwise, as well as how fast to rotate. Our last component is the power convertor, which is used to convert a 9-volt input from the CubeSat and deliver a 3.3-volt output to the other three components.

Validation[edit | edit source]

9523[edit | edit source]

Traceability Matrix[edit | edit source]

We will create a Requirement Traceability Matrix to validate that all requirements given to us by NASA are checked via test cases such that no functionality is unchecked during Software testing and system testing.

Example test: Simulating an overheating condition in software and verifying the device shuts off correctly.

The traceability matrix would cover the following standards:

Program Protection Standards

4.1.1 - Command Stack Protection
- Commands to and from the ground server must be encrypted.
- Must comply with the Federal Information Processing Standard (FIPS) 140
  - Refers to another document for encryption standards
4.1.2 Backup Command Link Protection
- A backup command process should be created that overrides command authority in an anomalous condition. This command authority should be encrypted form of authentication.
4.1.3 Command Link Critical Program/Project Information (CPI)
- encryption, authentication, and CPI protection of hardware commands, key-handling, and bit patterns of critical patterns.
4.2 Ensure Positioning, Navigation, and Timing (PNT) Resilience
- Position, Navigation, and Timing information should be protected as well as the communication path via secure protocols.
4.3.1 Interference Reporting
- We should report unexplained interference to SAPP or other notifying organizations
4.3.2 Interference Reporting Training
- Proficiency training to make sure we can detect interference

ADCS[edit | edit source]

Vibration Testing[edit | edit source]

There are two primary sections of testing our system. The first and primary way in which our system will be tested is through Vibration Testing upon our system being sent to NASA. The goal of this testing is to determine the modal properties of our system. It will quickly and easily work to determine the strength and rigidity of our system.

Visualization Testing[edit | edit source]

The second testing came in the form of a test stand that would allow visualization and display of the way that the fly wheel works. We created a test stand that will hold the reaction wheel assembly and sensors. This will allow us to troubleshoot, test and confirm that the motor driver is working correctly, and show to a broad audience the principles of a flywheel. The test stand was composed of two 3D Printed Parts, a ceramic bearing, plexiglass, and various fasteners.

Future Work[edit | edit source]

9523 Subgroup at Expo

9523[edit | edit source]

Ground Server[edit | edit source]

Our recommendation for future work for the ground server would be to analyze the received packed in order to determine whether the packet is SBD or RUDICS. Currently we are using 2 ports, one will receive SBD and one will receive RUDICS communication. We recommend cleaning up the collection of data and to rewrite the program to work on a single port and differentiate the difference of SBD and RUDICS within the code instead of relying on the use of 2 different ports. We also recommend for the future work to adapt team fires code for SBD communication into the ground server program.

Firmware[edit | edit source]

Our recommendation for future work on the firmware would be to custom write memory allocation in order to avoid fragmentation. For the HeartBeat task we recommend adding signal strength and the number of Iriduim_commands within in the queue. For the firmware we recommend adding an encryption task in order to send mission data.

ADCS[edit | edit source]

Mechanical[edit | edit source]

The future work on the mechanical system lies mainly in the wheel construction. This wheel design requires a CNC mill for manufacturing and has some complexity in terms of how the shaft is retained. Ideally this complexity is reduced while still maintaining a secure connection to the motor shaft.

The wheel was originally designed with three set screws retaining the shaft. Unfortunately, this doesn’t work with the very small shaft size and so alternate methods need to be considered. The method favored by the machinist we’re working with involves cutting a flat on the motor shaft and using a singular set screw to secure the connection.

The overall assembly should be shortened slightly and may need to adjust so that the controls can be mounted on the same plate, possibly on the other side, and so that the assembly takes up as little real estate as possible. There is also the possibility of other ADCS components being integrated into this system so leaving room for those as well is ideal.

Electrical[edit | edit source]

Future work on the electrical system primarily involves completing the schematic and associated board design, writing a program for the processor, and adding positioning sensors on the satellite.

The communication pins between the IMU, SAMD21 and Motor driver need to be properly connected. The IMU and SAMD21 should have SPI communications, the motor driver should have information about the speed, direction and acceleration sent to the SAMD21 as analog feedback, and the SAMD21 should send speed direction information to the motor driver. The board layout needs designed for the SAMD21 and IMU. These then need to be integrated with the board layouts of the motor driver and power converter. (Note: The headers on the motor driver are for testing purposes only and should be removed on the final design.) Once the schematic is finalized, a program needs to be writtenfor the SAMD21.

Positioning sensors should be added to the design. Due to the size and purpose of the satellite, photo diodes should be strongly considered over sun sensors. Additional sun sensors should be added if a single sun sensor per side does not produce a high enough resolution.

Team Members[edit | edit source]

	Grace Rosenvall Major: Mechanical Engineering Hometown: Boise, Idaho Responsibility: Team Manager, SubGroup Lead ADCS Email:gcrosenvall@gmail.com		Andrew James Pilchard Major: Electrical Engineering Hometown: Moscow, Idaho Responsibility: Budget Manager Email:ajpilchard@gmail.com
	Harrison Thomsen Major: Electrical Engineering Hometown: Nampa, Idaho Email:harrisonthomsen@icloud.com		Finan M. Bryan Major:Mechanical Engineering Hometown:Coeur D'Alene, Idaho Responsibility:Primary Client Contact Email:brya01542vandals.uidaho.edu
	Lillian Mortensen Major:Materials Science & Engineering Hometown: Richland Email:mort8668@vandals.uidaho.edu		Joseph Dennison Major:Computer Engineering Hometown:Bothell, WA Responsibility:SubGroup Lead 9523 Email:denn2258@vandals.uidaho.edu
	Robert R Goes Major:Mathematics and Computer Science Hometown:Boise Responsibility:SubGroup Lead AI in the Sky		Taegan Williams Major:Computer Science Hometown:Post Falls, ID Responsibility:Scribe Email:will8798@vandals.uidaho.edu
	Cosette King Major:Computer Science