AA236A (Old) Team Interfaces - spacecraft-design-lab-2019/documentation GitHub Wiki

Interfaces

This wiki page is for documenting and listing interfaces between different sub-teams. Each team will be listed, with subsections for their interfaces between the other teams:

Team 1: Flight Software

Mechanical/Mechanisms

Mechanical/Mechanisms to Flight Software

  • How deployment mechanisms interface with software
  • Spacecraft mass properties (e.g., mass, moments of inertia, products of inertia, dimensions, etc.)
  • Battery properties, like capacity, maximum power output, maximum charge rate, etc.
  • How to read battery (if applicable)

Flight Software to Mechanical/Mechanisms

  • TBD

GNC

GNC to Flight Software

  • GNC code (integrate into state machine)
  • Test their C++ software vs. our Python sim
  • Attitude determination/Kalman filter
  • Command output format
  • Interface for validation simulation
  • Time format State format

Flight Software to GNC

  • Wrap GNC code in Python
  • State machine framework
  • Feedback on deviation from ground-truth sim
  • Sensor information input format
  • Spacecraft parameter input format
  • Simulation for validation
  • State machine/mode information
  • Time format
  • State format

Actuators/Solar Panels

Actuators/Solar Panels to Flight Software

  • Actuator properties
  • Conditions for antenna deployment (time, what needs to be actuated and how)
  • How do we read the solar panel? What sensors are we using, and how are they connected?
  • Comms models (How does the radio work? How do we uplink? How do we downlink?)
  • Power budget
  • Python function for radio testing

Flight Software to Actuators/Solar Panels

  • Frequency (Hz) of the microcontroller loops, so they know what sort of frequencies to work with WRT comms
  • CircuitPython comms functions (and possibly full state machine/framework) for radio testing
  • Interface to the actuator.
  • Power budget
  • Communication models(i.e., uplink, downlink)

Flight Computer/Sensors

Flight Computer/Sensors to Flight Software

  • Magnetorquer models (specifically, we need to know what sort of signals to send the actuators to control them)
  • Sensor specifications
  • PyCubed set up with sensor models for hardware-in-the-loop testing
  • Low-level hardware-interface code (how to read each sensor using CircuitPython)

Flight Software to Flight COmputer/Sensors

  • Camera software integration
  • Full state machine to help determine power allocation

Team 2: Mechanical/Mechanisms

Flight Software

Flight Software to Mechanical/Mechanisms

  • TBD

Mechanical/Mechanisms to Flight Software

  • How deployment mechanisms interface with software
  • Spacecraft mass properties (e.g., mass, moments of inertia, products of inertia, dimensions, etc.)
  • Battery properties, like capacity, maximum power output, maximum charge rate, etc.
  • How to read battery (if applicable)

GNC

Receive:

  1. Ideal sensors placements
  2. Ideal magnetorquer placements/orientations (iterative)
  3. Expected solar performance (re. pointing requirements & eclipse period) (maybe solar team?)

Deliver:

  1. Mass and inertia properties
  2. Actual magnetorquer placements/orientations (iterative)

Actuators/Solar Panels

Receive:

  1. Solar cell area & position (re. pointing requirements; do we need deployable panels?)
  2. Solar panel actuation requirements (if deployable panels required)
  3. Expected solar performance (maybe GNC team, re. pointing requirements & eclipse period)
  4. Ideal antenna design, for us to convert to deployable form (maybe avionics team?)

Deliver:

  1. Solar cell layout restrictions (sensor/camera placement forcing gaps in the solar array)
  2. Power requirements
  3. Structural composition (for use in analyzing antenna placement needs)

Flight Computer/Sensors

Receive:

  1. Power requirements
  2. Sensor size, mass, ideal locations
  3. Mainboard and camera final configuration for integration into PocketQube
  4. Mainboard and camera datasheets and component specifications for vacuum testing and materials lists

Deliver:

  1. Power budget based on battery capacity and charge/discharge capability

Team 3: Actuators/Solar Panels

Mechanical/Mechanisms

Receive:

  1. Solar cell layout restrictions (sensor/camera placement forcing gaps in the solar array)
  2. Power requirements
  3. Structural composition (for use in analyzing antenna placement needs)

Deliver:

  1. Solar cell area & position, need to decide:
    • Pointing requirements
  2. Expected solar performance including eclipse period (after interacted with GNC team)
  3. Antenna design, need to decide:
    • Size of the antenna - Need to establish link budgets.
    • How to deploy?

Flight Software

Actuators/Solar Panels to Flight Software

  • Actuator properties
  • Conditions for antenna deployment (time, what needs to be actuated and how)
  • How do we read the solar panel? What sensors are we using, and how are they connected?
  • Comms models (How does the radio work? How do we uplink? How do we downlink?)
  • Power budget
  • Python function for radio testing

Flight Software to Actuators/Solar Panels

  • Frequency (Hz) of the microcontroller loops, so they know what sort of frequencies to work with WRT comms
  • CircuitPython comms functions (and possibly full state machine/framework) for radio testing
  • Interface to the actuator.
  • Power budget
  • Communication models(i.e., uplink, downlink)

GNC

Receive:

  1. Orbit and orientation design and planning
  2. Power requirements

Deliver:

  1. Expected solar performance (i.e., pointing requirements & eclipse period)
  2. Force generated from magnetic torques.

Flight Computer/Sensors

Receive:

  1. Power budget based on battery capacity and charge/discharge capability
  2. Pointing requirements for sensors (if needed.) need to interact with solar panel pointing requirements
  3. Battery power circuitry

Deliver:

  1. Solar panel pointing requirements
  2. Solar panel circuit integration plan (MPPT, etc.)
  3. Interface to actuator control

Team 4: Flight Computer/Sensors

Mechanical/Mechanisms

Deliver:

  1. Mainboard and camera final configuration for integration into PocketQube
  2. Mainboard and camera datasheets and component specifications for vacuum testing and materials lists

GNC

Receive:

  1. Power requirements for magnetorquer to ensure power limits are observed for combined magnetorquer, mainboard, and camera loading
  2. Sun sensor location (Maybe Mechanical and/or Solar?)

Actuators/Solar Panels

Receive:

  1. Power budget from actuators/solar panels
  2. Battery power circuitry to determine interface with mainboard.

Deliver:

  1. Power requirements

Flight Software

  • The CPU shall be a SAME51J20, which is an Arm Cortex M4 with FPU. Max speed 120MHz.
  • Max has the most experience with circuitPython drivers. Ask him if additional support is needed.
  • FC shall provide a pinout description for all final hardware

Team 5: GNC

Mechanical/Mechanisms

Receive:

  1. Mass and inertia properties
  2. Actual magnetorquer placements/orientations (iterative)

Deliver:

  1. Ideal sensors placements
  2. Ideal magnetorquer placements/orientations (iterative)

Flight Computer/Sensors

Receive

  1. Sensor model information/accuracy
  2. Maximum allowed command rate (also actuator team)

Deliver

Actuators/Solar Panels

  1. Expected solar performance (i.e., pointing requirements & eclipse period)
  2. Maximum allowed command rate (also flight computer team)

Deliver:

  1. Orbit and orientation design and planning
  2. Power requirements

Flight Software

Flight Software to GNC

  • Wrap GNC code in Python
  • State machine framework
  • Feedback on deviation from ground-truth sim
  • Sensor information input format
  • Spacecraft parameter input format
  • Simulation for validation
  • State machine/mode information
  • Time format
  • State format

GNC to Flight Software

  • GNC code (integrate into state machine)
  • Test their C++ software vs. our Python sim
  • Attitude determination/Kalman filter
  • Command output format
  • Interface for validation simulation
  • Time format State format