Maneuver: New ideas - poliastro/poliastro GitHub Wiki

Continuous thrust

Notice that if one just provides a starting time, a magnitude and a duration there is an underlying control law. For instance, orekit only implements constant thrust maneuvers.

We could state that limitation and make the impulse tangent to the velocity, but then documenting an alternative approach would be nice.

Current limitations

In poliastro, State objects are responsible of applying a Maneuver: a Δv is computed and then added to the original orbit:

r, v = ss.rv()
vnew += delta_v
ss_new = ss.from_vectors(ss.attractor, r, vnew, ss.epoch)

The problem with this approach is that it is not possible to apply continuous thrust maneuvers (such as low-thrust ones).

In fact, as Maneuvers are in fact lists of Δv velocity increments, it is currently not possible to represent continuous thrust (see above).

Pending issues

These are some things that need to be fixed, wheter there is a big refactor or not:

• Fix class docstring
• Prepare for continuous thrust to introduce duration of impulse
• Rethink indexing
• Prevent units from messing up as shown in http://poliastro.github.io/user_guide.html#changing-the-orbit-maneuver-objects
• Enhance instantiation

Some ideas

In orbital, maneuvers are lists of abstract operations which do not depend on a certain orbit or state. Later on these are applied and the resulting orbit is obtained (with the possibility to get the intermediate ones too). The actions to be performed to apply the maneuver are defined in the maneuver itself, which is probably a nice thing to have in poliastro.

The fundamental problem with this approach is that it is not possible to compute the cost in Δv of the maneuver, which for me is a crucial operation.

(Notice that, for continuous thrust maneuvers, the specific impulse is needed to compute the Δv cost)

If I separate the operations to be abstract objects, then obtaining the total cost and applying the maneuver are overlapping operations. For me, this indicates that I need some sort of intermediate object.

`Maneuver`  `State`  `Mission`
(abstract)    -->    (specific)   -->  Final (and intermediate?) `State`

In the middle lies a specific program of impulses and corrections, done at precise moments in time, which can be sampled to obtain any intermediate State. These objects would be subject to plotting too.

This idea is similar to what I wrote in API-Refactor: Summary and recap.

Factory

Another idea would be to have a high level class that represents the operations to be performed in the maneuver, then combine it with the initial trajectory to yield an impulse program and with that compute the Δv.

Future

These ideas call for the creation of a Spacecraft object with some properties like mass, propeller systems, specific impulses and so on, which is a common approach, but that will be for a future version.