ADCS

Mission and Systems Level Requirements Impact Assessment

Comparison of ArcticSat and Iris based on the descriptions provided:

Low power mode:

ArcticSat: The CubeSat is designed to enter a low power mode when the battery reaches a 40% state of charge
Iris: Iris also enters a low power mode when the battery state of charge drops to 40%. However, during this mode, power is not provided to Attitude Logging, Torque Rods, and the Payload module.

Sun-pointing mode:

• ArcticSat: The CubeSat can enter sun-pointing mode upon receiving a command from the ground station.

• Iris: Similar to ArcticSat, Iris can enter sun-pointing mode when commanded by the ground station. In this mode, most subsystems are powered except for attitude logging and the payload module.

Material use:

• ArcticSat: The CubeSat design restricts the use of any non-metallic materials with a Total Mass Loss (TML) greater than 1.0 percent.

• Iris: When commanded by the ground station, Iris enters idle operations. During this time, most units are powered except for Attitude Determination, Attitude Logging, Torque Rods, and the Payload module. This description doesn't provide information on the use of non-metallic materials.

Detumbling mode:

• ArcticSat: After a 30-minute hold, the CubeSat is designed to enter detumbling mode.

• Iris: Similar to ArcticSat, after a 30-minute hold, Iris enters detumbling mode. In this mode, power is provided to the Battery Charge Controller, Power Control Unit, Battery Heater, Attitude Determination, and Torque Rods.

Post-ejection hold:

• ArcticSat: The CubeSat is capable of autonomously acquiring a safe mission attitude following the expiry of the 30-minute post-ejection hold after deployment.

• Iris: Similar to ArcticSat, Iris is capable of autonomously acquiring a safe mission attitude after the expiry of the 30-minute post-ejection hold.

In summary, while both ArcticSat and Iris share similar operational modes and functions, the main difference lies in their power distribution during these modes. Iris seems to have more specific power allocations to different subsystems in various operational modes.

Here are some additional thoughts on other aspects:

Power and Thermal Management: If ArcticSat relies on solar panels for power, it may have a more consistent power availability. However, constant sun exposure might also cause thermal management issues if the components are sensitive to temperature changes. The provided descriptions do not mention this aspect.
Magnetic Field and Gravity Variations: The Earth's magnetic field varies with latitude, and this can affect the performance of magnetometers in a polar orbit. Additionally, there might be gravity differences, although the impact depends on the required level of fidelity.
Launch Conditions: Direct launches can be more chaotic, introducing variables related to the rocket launch itself. This could mean that the Attitude Determination and Control System (ADCS) of ArcticSat and Iris need to be capable of dealing with a wider range of initial conditions, including potentially high initial rates of rotation.
Altitude: A higher altitude orbit will have less drag, reducing the need for frequent adjustments. However, it may also make certain maneuvers more difficult for both ArcticSat and Iris.

By considering these additional aspects, the comparison between ArcticSat and Iris becomes more comprehensive and provides insights into their potential advantages and challenges.

ADCS_Comparison

Model Philosophy

The team is set to develop multiple ADCS models at various stages of the design process. This subsystem encompasses:

1. ADCS Control Board

This board's role is to transmit sensor data to CDH and interpret commands from CDH, translating them into actuator actions.

2. Sensors

These components provide spacecraft attitude information to CDH via the control board. Various equipment like magnetometers, sun sensors, gyroscopes, star trackers, and GPS (GNSS) aids in this data acquisition.

3. Actuators:

These mechanisms enable spacecraft orientation and propulsion and include equipment like reaction wheels, magnetorquers, and a thruster.

Simulation Model

The simulation model for the LI Bus will extensively build upon the Iris model, integrating reaction wheels and a thruster. As the design phases progress, this model will receive updates to better simulate the spacecraft's dynamics.

Breadboard Model

The breadboard model incorporates black boxes for expensive ADCS components such as reaction wheels and a thruster. It combines these with ADCS elements, mainly sensors, from the Iris pre-flight models for testing and integration purposes. The Iris ADCS board will be adapted to accommodate the new components, including reaction wheels, GPS, thruster, and potentially sun sensors and star trackers. As the design stages advance, the black box components will be replaced with their functional equivalents, evolving into the engineering model.

Engineering Model

As mentioned earlier, the engineering model evolves from the breadboard model as expensive items are procured. It acts as a testing platform to complete verification activities for the subsystem and includes magnetometers, gyroscopes, sun sensors, and magnetorquers. It continues to use black box components for reaction wheels, GPS, and the thruster.

Engineering Qualification Model (EQM)

The EQM is constructed once the reaction wheels, GPS, and thruster are delivered and serves as the primary testing platform moving forward. This phase is likely to occur in phase C.

Flight Model

The flight model predominantly reuses components from the EQM, retaining only the cost-effective elements for implementation.

Detailed model differences

Breadboard Model:

Purpose: The breadboard model is an early-stage prototype used primarily for design verification and functional testing of individual components or algorithms within the ADCS subsystem. It's a relatively simple and low-fidelity model.
Components: The breadboard model may not use flight-quality components or hardware. Instead, it often employs off-the-shelf or easily accessible components to represent the functionality of the ADCS subsystem.
Testing: The primary goal of the breadboard model is to validate the feasibility of the design concept and test the performance of algorithms and software. It may not accurately represent the actual conditions of space.
Cost: Breadboard models are generally cost-effective and serve as a proof of concept before committing to the full development of the engineering model.
Risk Reduction: By testing components and algorithms in a breadboard model, you can identify potential issues or shortcomings early in the design process, reducing risks in later stages.

Engineering Model:

Purpose: The engineering model is a more advanced and refined prototype that closely represents the final ADCS subsystem. It's used for extensive testing and verification to ensure the system's performance and reliability in a space environment.
Components: Engineering models typically use flight-quality components and hardware that meet the stringent requirements for space missions.
Testing: The engineering model is subjected to a comprehensive series of tests, including environmental tests (thermal, vacuum, radiation, vibration), system integration tests, and full-scale functional tests. It aims to validate the system's performance under conditions that mimic those of space.
Cost: Developing an engineering model is more expensive than a breadboard model due to the use of flight-ready components and the extensive testing involved.
Flight Qualification: Successful testing and verification of the engineering model are crucial for achieving flight qualification, which is necessary for the actual deployment of the ADCS subsystem in a satellite.

ADCS Block Diagrams

ADCS System Block Diagram

ADCS Power Interfaces

ADCS Data Interfaces

Attitude Simulator Model - Simulink:

Environment

Simulates the orbit of the spacecraft. Attitude simulations typically do not exceed one orbit, so a simple unperturbed Keplerian orbit is used.
Simulates the Earth's magnetic field using the IGRF model to enable magnetic control.
Calculates the position of the sun, and whether the spacecraft is in eclipse, to study sun pointing and battery consumption during its lifetime.
Simulates attitude perturbations on the spacecraft. Gravity gradient and magnetic residual dipole disturbances are used.

Sensors

Simulates the performance of sensors including things like data rate, resolution, and bias.

Attitude Estimator

Uses an Extended Kalman Filter (EKF) based on the method's of Lefferts to fuse sensor data, help account for biases, and output a single attitude solution. More info below.

Controller Software

Simulates mission modes and attitude maneuvers. Attitude controllers for all mission modes are modelled for analysis. These modes include detumbling, sun-pointing, as well as the pointing required for science mode.
Models magnetorquer controllers, including the detumble, reaction wheel momentum desaturation, and coarse sun-pointing controllers.
Models reaction wheel controllers, including the rate and fine pointing controllers.

Actuators

Models magnetorquer performance and signals.
Models reaction wheel performance and orientation within the spacecraft.

EKF for Attitude Estimation

The AODCS will run an Extended Kalman Filter (EKF) onboard the CDH to provide attitude estimation using updates from all of the attitude determination components. The purpose of this estimator is to combine telemetry from all attitude and position sensors, and output a single pointing quaternion as the spacecraft's current orientation. Using this, the spacecraft can regularly estimate its orientation even if some attitude sensors are not available. For example, if the spacecraft performs a maneuver that causes the star tracker to point at the sun for a time, the spacecraft can continue to update its orientation based on other sensors like the gyroscope, with the last viable star tracker measurement acting as a high accuracy reference point. This also provides some resilience to bias and drift among sensors like the gyroscope and magnetometer. More info below.

SGP4 for Orbital Position Estimation

LI Bus will run an SGP4 orbit propagator alongside the attitude estimator for orbital position estimation to aid in pointing. This allows for orbital information to be polled at any time internally if GNSS updates are unavailable. SGP4 remains a popular orbit propagator due to its purely analytical method. Research and code for the propagator is also widely available.[1] SGP4 has been found to be accurate to about a half-kilometer in the tangential direction during propagation.[2] This is likely not accurate enough for most imaging purposes, but is sufficient for helping align with ram and the sun while in science mode.

Another advantage of this method is that the propagator epoch can be updated using two different sources. A TLE can be uploaded from the ground, or the CDH can convert the last GNSS update into a TLE with an updated epoch. All satellites are tracked by the United States Space Force and regular updates can be found on Space-Track.org and CelesTrak.

Components & Requirements Compliance

System Requirements

ADC Requirements Compliance

ADC Control Board

UMS-0641 Requirements Compliance

GNSS Antenna - Antcom 1.2G-Mini

UMS-0651 Requirements Compliance

GNSS Receiver - NovaTel OEM719

ArcticSat will use a NovaTel OEM719H-WFN-LNN-TMN-H GNSS receiver. Its features include GPS+Galileo+QZSS, L1/L2/L5/L6/E1/E5a/E5b/AltBOC/E6, SBAS L1/L5 Single Point+DGPS PNT, 20 Hz Data Output Rate, High Speed Includes GLIDE & RAIM. The flight model is COCOM removed and considered Controlled Goods, the engineering model is a COCOM enabled OEM719-WFN-LNN-TMN.

Development resources for the receiver can be found below.

UMS-0361/0362 Requirements Compliance

Gyroscope - STMicroelectronics A3G4250D

UMS-0635 Requirements Compliance

Magnetometer - Memsic MMC5983

UMS-0636 Requirements Compliance

Magnetorquer - York University

UMS-0053 Requirements Compliance

Reaction Wheel - STAR Lab

For information regarding the design and manufacturing of the reaction wheel, see its wiki page.

Sun Sensor - York University

UMS-0381 Requirements Compliance

Page updated

Google Sites

Report abuse