ENH: Flight Class Overhaul

[giovaniceotto]

While the Environment class, the Motor class and the Rocket class have been refactored significantly since the first implementation, the Flight class has mainly stayed the same. Now, it is clear that it is outdated when compared with the rest of the code.

This issue proposes the implementation of the following new features to the flight class:

• Integration with sensors and controllers (Sensors #273 and ENH: Continuous and Discrete Control #274)
• Support for different flight models (simpler models may be faster)
• Support for flight enabling, disabling and adding flight events
  • Events include parachute triggers, staging, flight termination, etc
  • Disabling certain events changes how the flight is simulated
  • Adding termination events can help when only a portion of the flight is of interest
• Clear statement of all assumptions used, considering the active flight model
  • Active mass variation terms
  • Active aerodynamic models
  • Active earth/gravity models
  • Active atmospheric models
• Return a FlightTrajectorySolution object, rather than keeping the solution in the Flight class.
  • Allows for the reuse of the flight instance, changing the model or events and running the simulation multiple times.

Proposed Usage Example

from rocketpy import Flight

test_flight = Flight(...)

# Run first standard simulation
flight_trajectory_solution_1 = test_flight.simulate()

# Change models and events
test_flight.enable_models(...)

test_flight.list_events()

test_flight.disable_event(...)

test_flight.add_event(...)

# Run a second simulation
flight_trajectory_solution_2 = test_flight.simulate()

Requirements

• To be defined.

Proposed Architecture

• To be defined.

Proposed Milestone

Considering the roadmap to v1.0.0 and the work on sensors and controllers only for v2.0.0, it seems like this feature will be necessary only on v2.0.0.

[Gui-FernandesBR]

As discussed before, we need urgently remove the simulation from init method and create a Flight.simulate(self, eom="6-dof",...) method. Let the user to set which set of equations of motion he/she wants to use.

Additionaly... I'd like to proppose something: Instead of simulate the flight trajectory, allow the user to set flight attributes from a raw data, which could be provided by avionics logs or even other simulators. For instance, user could input a .csv file containing:

Time (s), x (m), y (m), z (m), e0 (m), e1 (m), e2 (m), e3 (m), latitude (º), longitude (º), dragCoefficient, AngleOfAttack (º)

The code could, then, calculate the missing attributes when possible. In this case, calculate the vx, vy and vz based on the provided data.

This would be really helpful to create flight comparisons of different sources.

[giovaniceotto]

I like the idea of having a processor of raw flight data, be it measured or simulated. However, I belive the Flight class should focus on simulation only. We could create another class to process raw data. As it stands, the Flight class already contains more then 4000 lines of code, which is quite hard to manage. Adding more functionality to it could make it even harder.

…

On Wed, Nov 16, 2022, 12:55 AM Guilherme Fernandes Alves < ***@***.***> wrote: As discussed before, we need urgently remove the simulation from *init* method and create a Flight.simulate(self, eom="6-dof",...) method. Let the user to set which set of equations of motion he/she wants to use. Additionaly... I'd like to proppose something: Instead of simulate the flight trajectory, allow the user to set flight attributes from a raw data, which could be provided by avionics logs or even other simulators. For instance, user could input a .csv file containing: Time (s), x (m), y (m), z (m), e0 (m), e1 (m), e2 (m), e3 (m), latitude (º), longitude (º), dragCoefficient, AngleOfAttack (º) The code could, then, calculate the missing attributes when possible. In this case, calculate the vx, vy and vz based on the provided data. This would be really helpful to create flight comparisons of different sources. — Reply to this email directly, view it on GitHub <#276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELYQ2QRXTPUFFQS6FTCZ3WIRLMBANCNFSM6AAAAAARXXEY5Y> . You are receiving this because you were assigned.Message ID: ***@***.***>

[Gui-FernandesBR]

This kind of "appends" section is a real sign of bad architecture. This is terrible and was only done to speed up the simulation loop. The simulation loop is always run twice! the first time is faster, the second (using post_process = True) is way slower but is important to get some flight attributes.

We should be fixing it soon!

Here are some ideas (needs to be tested):

• Before running the simulation, initialize vectors with a certain length, so by each time step we can simply modify the value of a indexed position of the array instead of using append (which is usually really slow). The problem is how can we anticipate the vector length before starting the simulation.
• Use numpy arrays instead of python lists for these objects.

[Gui-FernandesBR]

PR #581 contributes quite a lot to this issue.
No breaking changes so far!