Editor: Relative Pointing Chain
Description
This guide showcases how to create a relative pointing chain on a spacecraft. This chain is designed to direct a payload’s normal direction in the direction of another spacecraft or object in inertial space. This is commonly used for communication simulations between spacecraft in a constellation, aligning the antenna directions with another spacecraft.
This example scenario can be found at the Data/Demo_SpacecraftToSpacecraftComms level. It uses a reaction wheel array to orient the spacecraft's attitude to align the antenna in the direction of another spacecraft, allowing for communication of data flow.
Creating the Spacecraft
Start by configuring a level with a spacecraft spawned in orbit. The spacecraft must have the following components for this chain to work:
- Reaction Wheels
- Computer
The spacecraft can have any other number of components and instead of using reaction wheels, an external force torque module could be implemented as the effector instead. Additionally, the data system is independent of the software and is not required to be configured at the software level. The spacecraft shown is used for this guide.
For this example, a secondary (empty) spacecraft is also spawned into the simulation and given the name ‘Target'. This spacecraft does not have any actuation or flight software, except a navigator, and is only used to produce the inertial coordinates of the body for the primary spacecraft to orient its payload towards.
Adding the Navigator
After spawning the spacecraft in the level blueprint, flight software can be added to the spacecraft. This is usually done in a blueprint function but can be done directly on the Event Graph. The first step is to add the Navigator component. This is required for all flight software chains, and the relative-pointing chain is no exception. The Navigator produces the estimated position and rotation of the spacecraft, with some noise values applied. It is a source of truth and does not simulate the data from a sensor. This component needs to be added to the Computer on the spacecraft, which can be done by first fetching the computer and constructing the Navigator.
The Navigator takes three input flags, which define how the errors are added to the module:
- Cross Translation: A flag that defines a position error depending on its velocity
- Cross Attitude: A flag that defines an attitude error depending on its attitude rate
- Use Eclipse: A flag that defines whether the sun pointing vector on the navigation attitude message depends on whether the spacecraft is in an eclipse. This flag is only useful for the sun-safe pointing chain.
Adding the Relative Pointing Software
The next software to add is the Relative Pointing Software, which will define the guidance error between the current spacecraft state (with the errors defined by the navigator) and the secondary spacecraft. This module takes in two input messages; the first is the primary spacecraft’s navigation message coming from the navigator, with the errors applied. The second message is a bit trickier to get and it depends on the scenario that it can be added. The second message needs to be a navigation message from the other spacecraft. With a real simulation, the other spacecraft should be sending its state via a data system, which is how it works in the demo provided, having the spacecraft send its state over the data network. The software module outputs a reference message, which is the body frame vector that represents the targeted reference frame that the spacecraft needs to orient towards. The example below shows the standard example of pulling the target navigation message from the other spacecraft.
The Alignment Vector is the body frame \(B\) vector that the spacecraft will align its targeted frame with. The vector is normalized in X, Y, and Z body frame coordinates. Although the above will work if the targeted spacecraft also has a computer with a navigator, in general, this will not be a proper example. Instead, an additional module can be added. This is the Spacecraft Navigation Converter Software, which converts a body state message (that can be grabbed from the other spacecraft) and converted to a navigational translation message.
Using the new software module, the relative pointing software can take in two navigation translation messages, with each message from each spacecraft.
Adding the Attitude Tracking Error Software
The next module to add to the chain is the Attitude Tracking Error Software, which takes in both the current reference frame that is targeted (in the body frame) and the current spacecraft attitude message (which can be found from the navigator on the first software module added) and determines the guidance frame that would rotate the spacecraft towards the reference. It computes the frame difference and produces the output that can be fed into a PID controller module. Without the tracking error, the reference frame is not enough to determine the correct torques for a spacecraft to reach its desired attitude.
An optional parameter is the Sigma RRc, which defines the corrected reference frame parameter. By manipulating these values, it can define a fixed frame rotation to the corrected reference frame \(R_c\) from the reference frame \(R\).
Adding the MRP Feedback Software
A standard software module that is used for all pointing chains is the MRP Feedback Software. This software module takes in a desired guidance direction and compares the direction with the current orientation. It then uses a PID controller to create a torque message that will define how much torque is given to the effectors (such as a reaction wheel or external force module) to start orienting the spacecraft in the desired vector. The guidance message is a requirement as the input for the module, however, the reaction wheel messages (speed, availability and config) are optional and can be used when a reaction wheel exists. These messages provide information to the controller on the configuration and speed of each reaction wheel and can optimize the controller for specific wheels.
The MRP controller is configurable and the PID constants can be adjusted. These parameters are dependent on the state of the system and the friction models on the reaction wheels. The default constants are suggestive and work in a majority of use cases.
- K: The proportionality-gain constant (P) to the MRP errors.
- P: The rate-error constant (D) for the feedback gain.
- Ki: The integration feedback error constant (I) on rate error.
- Integral Limit: The integration limiting torque to avoid wind-up issues.
- Known Torque Point B_B: The defined additional external torque, defined in body frame coordinates, that is applied to the controller.
Adding the Reaction Wheel Motor Torque Software
The MRP controller will return an expected torque for some effector to apply on the spacecraft in the body frame. If a reaction wheel module is used, then this torque needs to be converted to a reaction wheel command, that can be sent to the reaction wheel array on the spacecraft. This is the Reaction Wheel Motor Torque Software and it takes in the state of the reaction wheels (as a configuration message) and the required torque command and produces an array motor torque message, containing a list of torques that are to be applied to a reaction wheel. By default, if no availability message is defined, the module will assume all reaction wheels that are configured are available and operable in the system.
The reaction wheel motor torque software has one additional parameter, defined as the control axes. This parameter defaults to the identity matrix but can be configured to define a non-symmetrical axis of control, in the case that a reaction wheel or software produces the torques in a rotation that is not equivalent to the reaction wheel direction vectors.
Connecting the Reaction Wheel Message
The reaction wheel motor torque software produces an array message that the reaction wheel uses to control the torques of each wheel. The final task of the flight software chain is to connect the message to the reaction wheel. This can be done using the Set In Messages method, which is the standard syntax for updating the input messages of a component.
These are all the required software modules for the relative-pointing chain to be implemented on a spacecraft. Additional software modules can be added for specific use cases, such as a power voltage conversion. The flight target message can also be published via the data system for a full in-the-loop simulation.