ÃÛÌÒ´«Ã½Æƽâ°æÏÂÔØ

This article illustrates our group's most recent progress in developing an optimal path planner for rigid-body spacecraft rotations using Control Moment Gyroscopes (CMG's). This work improves upon our previous project by incorporating fully-modelled spacecraft actuators and addressing all of the fascinating complexities they add to the optimization problem. Above is an example of a solution returned by our solver for a 180° spacecraft rotation about its z-axis using an array of CMG's. Additonally, the satellite executes this maneuver while avoiding pointing its sensitive optical equipment (indicated in green) at the sun (indicated in yellow) during the rotation.

Spacecraft Rotations using Control Moment Gyroscopes

We begin by addressing a fascinating and nontrivial question: how exactly do spacecraft rotate themselves?

When portraying spacecraft, popular media adore the exciting visuals of gas thrusters. In practice however, fuel is a finite and valuable resource once a spacecraft has launched. As such, it is rarely used for anything other than adjusting and maintaining the orbit established by the initial launch. 

Spacecraft rotations on the other hand are required regularly for normal operations (pointing the solar panels at the sun) and when executing specific missions (orienting the spacecrafts cameras/sensors, docking with other spacecraft, etc). Amazingly, this common operation can actually be performed using simple electric motors and renewable electric power.

The principle behind this achievement, called Momentum Exchange, is straightforward. When applying a torque between the connected elements of a spacecraft, the total angular momentum of the entire spacecraft is conserved. That is, a motor applying torque on its shaft produces an equal and opposite reaction torque on the motor's frame. By heavily weighting the motor shaft with a dense wheel and connecting the motor frame to the spacecraft, we can rotate the entire spacecraft (albeit slowly) using this reaction torque. This device is called a Reaction Wheel and is frequently used in the design of smaller spacecraft.

However, we can go a step further. When the motor wheel is spinning, it also acts a gyroscope and produces powerful torques proportional to the speed of the wheel (also produced by momentum conservation). Torques applied to this motor assembly (via a new second motor) produce far more powerful reaction torques on the spacecraft than those from conventional reaction wheels. These devices are called Control Moment Gyroscopes (CMG's) and are used to efficiently rotate larger spacecraft such as the ISS. The diagram below shows an outline of such a device, with the (reaction) wheel spin axis highlighted in red and the secondary (or gimbal) motor axis highlighted in blue. Note that the outermost black frame of the CMG is mounted to the spacecraft frame, while the internal assembly and wheel are free to rotate via their respective motors.

Note that, by design, CMG's and reaction wheels only provide torque around a single axis. Since spacecraft are regularly required to rotate around arbitrary axes, multiple CMG's are arranged in an array combining their outputs to produce any required torque. One popular array geometery, the Rooftop Array, is shown below.

While CMG's are vastly more efficient and powerful than reaction wheels, they present an interesting and nontrivial challenge for control engineers. Specifically, the CMG's torque axis (produced by gyropscopic forces and highlighted in purple above) rotates with the CMG's wheel assembly, meaning that the available torque from that CMG at any given time is dependent on its current orientation. As such, certain torque directions may be unavailable (even for a well designed array) if the CMG's are all poorly oriented. For example, consider the the rooftop array above. In its default configuration (shown), all of the purple torque axes for the CMG's are confined to the xz plane, meaning that no combination of them can produce a torque along the y-axis. As such, any maneuver requiring the spacecraft to rotate around its y-axis using this array will require extra time for the array to reconfigure. 

Thankfully, there is a way to regain the Control Authority lost in these poor configurations (rather then avoid them entirely as most approaches do). Conventionally, CMG design engineers have assumed that the (red) wheel motor is to be used only to maintain the CMG wheel's speed to allow it to function as a gyroscope. This assumption simplifies engineering design and equations of motion, but also creates the problem discussed above. In fact, using these motors as conventional reaction wheels (while also maintaining the wheel speeds during downtime) restores the lost control authority (note that the indicated red axes from the previous example point along the previously inaccessible y-axis).

By combining the torques from the (red) wheel motors and the (blue) CMG gimbal motors, we are able to ensure that our system can produce arbitrary commanded torques in any configuration. However, this doubles the number of control inputs to the system and vastly complicates the system's equations of motion. It is this problem that we aim to solve using our PRONTO optimization algorithm.

Trajectory Optimization using PRONTO

Now that we understand how spacecraft rotate, we now consider how to plan optimal spacecraft rotation maneuvers using only the CMG motor inputs. That is, we wish to determine a path in each of the system's primary states (orientation, angular rotation rate, etc.)  and control (motor) inputs which:

1. Moves the satellite from our initial orientation to our desired orientation
2. Satisfies the system's equations of motion (e.g. a path we can actually follow)
3. Avoids pointing the onboard camera(s) at the sun (safety)
4. Is optimal in the mission context (e.g. least fuel used, fastest time, etc.)

In order to determine this maneuver (or trajectory) numerically, we use a technique called PRONTO to smoothly reshape a guess solution (e.g. a path that approximately satisfies (1) above) into an optimal solution which satisfies all of the requirements. The process of the algorithm reshaping this path is shown in the animation below.

Focusing first on the large sphere in the center of the figure, the blue, magenta, and red curves represent potential paths for the primary axes of the satellite to follow as it rotates. The green path represents the orientation of the onboard camera which is adjusted to sweep its vision cone away from the sun (yellow) as the solver progresses. If we were to freeze this animation, the path shown would be a viable manuever for the satellite to execute. The animation at the top of this page shows a satellite executing the (optimal) maneuver at the end of the animation.

The remaining plots illustrate how the various states, control inputs, and performance metrics of the maneuver are adapted by the solver, including:

1. The orientation of the satellite given by the quaternion q
2. The angular rotation rate of the satellite given by omega
3. The gimbal angles of each of the CMG's in the array delta
4. The angular momentum in the CMG gimbals h_g
5. The angular momentum in the CMG wheels h_w
6. The motor inputs tau_g and tau_w for the gimbal and wheel motors respectively
7. The CMG array's singularity index (proximity to a 'bad' configuration)
8. The maneuver's angular error from the target orientation

With these metrics, we can make some fascinating observations about the planned maneuver:

1. Even when used to improve control authority, the wheel momentum (speed) h_g is regulated to its target value by our solver
2. Our planned manuever improves the solution guess to get within 0.2° of the target orientation
3. The control inputs tau_g for the gimbal motors change from gentle and consistent torques to shorter, more intense torques. Although this is not necessarily more energy efficient, the shorter pulses indicate a more effective use of the CMG's torque amplification.
4. The angular velocity along the z-axis appears to saturate between 0 and 50 seconds and, during the same time frame, it appears as though the CMG array nears a singularity (See the singularity index plot). In fact, both features originate from the finite available momentum in the array. Once the CMG's are all aligned in the same direction, no more angular momentum is available in the array to rotate the satellite more quickly, causing the velocity to saturate. In this case, the singularity we approach is the array's momentum envelope, indicating we are hitting a performance bottleneck of the CMG's themselves.

The paper detailing this project is currently undergoing final revisions and will be linked here once it becomes publicly available.