Â鶹ӰԺ

This visualization illustrates our recent work in developing an optimal maneuver planner for rigid-body satellite rotations. Specifically, this animation shows how our solver reshapes a 180º rotation about the satellite's z-axis to be both optimal and feasible.

In general, finding a maneuver which is optimal (e.g. uses the minimum fuel, arrives in the least time, etc.) is extremely difficult as we must search over an infinite-dimensional space of potential maneuvers connecting the initial and target orientations. This point is easy to visualize with any household object, as you can turn it upside down an infinite number of ways (e.g. rotate the top towards you, away from you, to the right or left, and any combination of those four). This difficulty is further complicated by our inability to represent a continuous curve using the finite precision and memory available to a computer. Thus, we must accurately approximate these maneuvers as we search for the optimizer.

Additionally, real satellites have implicit safety constraints on their motion to prevent stressing or wearing out onboard hardware. As a result, we can only consider maneuvers which are feasible (i.e. satisfy these constraints along the entire maneuver). Some common operational and safety constraints for satellite rotations include:

1. Ensuring safe (bounded) commands for the attitude thrusters (to prevent saturating them),
2. Ensuring a safe (bounded) angular rotation rate along each axis during the maneuver (to avoid over-stressing the structure of the satellite and improve the accuracy of onboard sensors),
3. Avoiding blinding an onboard sensor by pointing it near bright objects, such as the sun, moon, or other planets.

This final constraint is particularly challenging, as it cuts a hole in the space of feasible orientations that the satellite can pass through during the maneuver.

To make this problem computationally tractable for modern CPU's, we apply a Trajectory Optimization technique called PRONTO, or the Projection-Operator-based Newton's method for Trajectory Optimization. This approach uses geometric insight of the system's Trajectory Manifold (the space of maneuvers which the satellite can execute from a fixed initial condition) to identify the exact (continuous) deformations necessary to approach the optimizer. Although we will not elaborate on this technique here, these deformations are illustrated in the above animation. Note that the final solution for the above problem can be computed rapidly (within 30s) on a modern CPU.

Examining this animation in more detail, note first that the top-left panel shows the time-varying orientation (or attitude) of the satellite using a 4-parameter representation called a quaternion. This representation is highly numerically efficient but often difficult to interpret. Alternatively, the red, magenta, and blue axes inscribed on the sphere in the top-right panel show how the x,y, and z-axes of the satellite rotate during the maneuver (shown as the satellite would appear to an external observe floating in space next to it, or in the space-fixed frame). Note that the z-axis remains almost stationary during the maneuver, as the majority of the desired rotation is around this axis. Also shown on this sphere is the current direction of an onboard camera (shown in green) and the current relative direction of the sun (shown in yellow). To adhere to the 3^rd constraint above, we must then ensure that the final maneuver does not move the green camera path through the yellow viewing angle for the sun.

In addition, the applied thrust u(t) and the angular rate ω(t) along each axis of the satellite (in its own body-fixed frame) are shown in the two panels in the bottom left. Note that, as the solver progresses in the animation, the z-axis thrust and rotation rate curves push up against the 1^st and 2^nd constraints. This indicates that the optimal, feasible behavior for this maneuver is to apply max thrust for a brief time and then coast at the maximum safe velocity until the majority of the rotation has been executed. The thrusts and rotations along the other axis are then applied to swerve the camera away from the sun to adhere to the 3^rd constraint.

Finally, the bottom right panel shows the remaining rotation angle necessary to complete the maneuver (called the MRP attitude error). While this error does not converge exactly to zero at the final time (indeed, exact convergence is actually sub-optimal), it converges well within the tolerance of the native attitude controllers on the satellite, allowing them to complete the maneuver exactly.

To better understand the progress of the algorithm, note the stage indicator in the top right of the animation. PRONTO first begins with a guess for a direct rotation between the initial and final attitudes. Because this guess incorrectly orients the sensor at the sun (and so is infeasible under the specified constraints), PRONTO quickly adjusts this maneuver to satisfy all the constraints by a safe margin (the first stage). Since this solution is sub-optimal to the overall optimization problem, PRONTO then iteratively pushes closer to the constraints by lowering the parameter Îµ_ko (following the so-called central path for an interior point method) to reach the optimal constrained rotation maneuver (the second stage).

A unique and useful property of the PRONTO result shown above is that each curve iterate returned by the solver is a valid trajectory under the satellite's natural dynamics. That is, in the absence of noise, the satellite can follow each of the intermediate curves exactly (as opposed to tracking along them using waypoints). Additionally, each curve iterate shown after initial feasibility is obtained (i.e. after the green curve exits the gold circle) is also feasible. That is, feasibility is maintained by PRONTO once it is achieved (also not presented by conventional approaches). Thus, each curve iterate displayed above is a sub-optimal, but safe and valid potential maneuver for the satellite when fast-decision making is required. Neither of these properties are provided by classic trajectory optimization solvers, which approximate the problem as a conventional nonlinear programming problem.

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