Skip to content

Conversation

@aZira371
Copy link
Collaborator

@aZira371 aZira371 commented Dec 3, 2024

Pull request type

  • Code changes (bugfix, features)

Checklist

  • Tests for the changes have been added (if needed)
  • Docs have been reviewed and added / updated
  • Lint (black rocketpy/ tests/) has passed locally
  • All tests (pytest tests -m slow --runslow) have passed locally
  • CHANGELOG.md has been updated (if relevant)

Current behavior

for issue #655

New behavior

(DRAFT)
ENH: adds 3 DOF simulation capability to rocketpy.Flight.

*ENH: added "u_dot_3dof" for "solid_propulsion"
mode

*ENH: adding "u_dot_generalized_3dof" for "standard" mode (still incomplete)

*ENH: new parameter "simulation_mode" for swtiching between 3 dof and 6 dof

*ENH: updated conditions for "__init_equations_of_motion"

*ENH: 2 new example files have been created to test 3 dof model "test_bella_lui_flight_sim" and "test_camoes_flight_sim"

Breaking change

  • No

Additional information

This is a draft pull request!
Equations of motion have been modified in such a way that values related to various rotational dofs is set to zero.

ENH: adds 3 DOF simulation capability to rocketpy.Flight.

*ENH: added "u_dot_3dof" for "solid_propulsion"
mode

*ENH: adding "u_dot_generalized_3dof" for "standard"
mode (still incomplete)

*ENH: new parameter "simulation_mode" for swtiching
between 3 dof and 6 dof

*ENH: updated conditions for "__init_equations_of_motion"

*ENH: 2 new example files have been created to test 3 dof model
"test_bella_lui_flight_sim" and "test_camoes_flight_sim"
@Lucas-Prates Lucas-Prates added Enhancement New feature or request, including adjustments in current codes Flight Flight Class related features labels Dec 4, 2024
@Lucas-Prates Lucas-Prates linked an issue Dec 4, 2024 that may be closed by this pull request
@Lucas-Prates
Copy link
Contributor

Lucas-Prates commented Dec 4, 2024

Thank you for your interest in implementing 3-DOF in RocketPy, @aZira371 . I will try to take a better look into it, but I notice one thing already: use 6 DOF as the default input for simulation_mode for two reasons:

  1. most people will use 6 DOF;
  2. changing it to 3 DOF introduces breaking changes, and we really want to avoid that. You can see that a breaking change occurred because the tests failed.

@Lucas-Prates Lucas-Prates changed the title DRAFT: for ENH/3-dof-simulation (See #655) ENH: Implementing 3-dof-simulation Dec 4, 2024
ENH: adds 3 DOF simulation capability to rocketpy.Flight.

*ENH: added "u_dot_3dof" for "solid_propulsion"
mode

*ENH: added "u_dot_generalized_3dof" for "standard"
mode

*ENH: new parameter "simulation_mode" for swtiching
between 3 dof and 6 dof

*ENH: updated conditions for "__init_equations_of_motion"
ENH: fixed standard 3 dof

*MNT: Cleaned up the "u_dot_3dof" and "u_dot_generalized_3_dof"

*MNT: Corrected Typos in "simulation_mode"
description

*ENH: "u_dot_generalized_3_dof" fixed and tested
on examples.
@Gui-FernandesBR
Copy link
Member

Gui-FernandesBR commented Feb 8, 2025

  • Git rebase develop
  • Revert changes in the jupyter notebook
  • Create PointMassMotor
  • Create BaseRocket
  • Create PointMassRocket
  • Modify Rocket class where it's needed (here other people can help you, including Gui)
  • Modify the Flight class again, if needed (delete u_dot_3dof)
  • Include integration tests (here you can ask for help)
  • Format and lint the code (see the Makefile)

…otor

ENH: added "BaseRocket" and "PointMassRocket" to rocket class

ENH: added "PointMassMotor" to motor class with various input cases of thrust values
@codecov
Copy link

codecov bot commented Feb 25, 2025

Codecov Report

❌ Patch coverage is 82.23684% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.26%. Comparing base (9cf3dd4) to head (567b9e0).
⚠️ Report is 6 commits behind head on develop.

Files with missing lines Patch % Lines
rocketpy/simulation/flight.py 68.11% 22 Missing ⚠️
rocketpy/motors/point_mass_motor.py 90.38% 5 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #745      +/-   ##
===========================================
- Coverage    80.27%   80.26%   -0.02%     
===========================================
  Files          104      106       +2     
  Lines        12769    12979     +210     
===========================================
+ Hits         10250    10417     +167     
- Misses        2519     2562      +43     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

aZira371 and others added 6 commits April 11, 2025 20:31
…e tests

ENH: Added a new jupyter notebook for a simplified 3 DOF example

MNT: PointMassMotor intialization error fixed

MNT: PointMassRocket properties enhanced based on the example runs
MNT: Cleaned up the flight class u_dot_generalized_3dof

TODO: Add info for 3 dof cases and fix some new issues when parachute is added.
@aZira371 aZira371 marked this pull request as ready for review May 10, 2025 17:51
@aZira371 aZira371 requested a review from a team as a code owner May 10, 2025 17:51
aZira371 and others added 6 commits June 11, 2025 01:18
-MNT: removing the parameters not needed for point mass kind of motors

-MNT: removing extra parameter thrust_curve

-MNT: fixing problems with motor class inheritance
-ENH: removed 'BaseRocket' class now 'PointMassRocket' inherits directly from 'Rocket' class
-MNT: fixed calculations of mass flow rate and exhaust velocity
-MNT: adjusted propellant initial mass setter error by allocating the input initial mass to the property
MNT: renaming pointmassmotor.py

-MNT:snake case renaming
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 15 comments.

Copy link
Member

@Gui-FernandesBR Gui-FernandesBR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Collaborator

@phmbressan phmbressan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR looks good. Main points missing for me that could be easily appended to a following PR:

  1. There are still no "sanity-check" tests for the results. We could probably make an "acceptance" test for it, by picking up a known battle-tested Flight and hoping for the landing coordinates being close. The tolerances for it are a point worth discussing. Maybe even comparing to a parabolic trajectory might give some insight (for sanity-checking a ballistic Flight);
  2. Still on the validation side: results should be pretty close if one runs a bare-bones Rocket in 6-DOF, right?
  3. Some tests lack proper docstrings;
  4. Smaller comments I left throughout my review.

I'm fine proceeding with a merge here, but the first point for me is important before releasing the feature.

Comment on lines +75 to +82
@cached_property
def center_of_propellant_mass(self):
"""Center of propellant mass is always zero"""
return Function(0.0)

# Propellant inertias: always zero, but return as Function objects
def _zero_inertia_func(self):
return Function(0.0)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Annoying, but I would discretize both based on self.thrust to ensure consistency/speed for the outputs.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could elaborate what you mean by discretize here exactly?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check above lines from the same file, there should be a .set_discrete_based_on_model call somewhere. This is done to optimize the code for speed, keeping the data crunching based on arrays (instead of lambdas).

@aZira371
Copy link
Collaborator Author

The PR looks good. Main points missing for me that could be easily appended to a following PR:

  1. There are still no "sanity-check" tests for the results. We could probably make an "acceptance" test for it, by picking up a known battle-tested Flight and hoping for the landing coordinates being close. The tolerances for it are a point worth discussing. Maybe even comparing to a parabolic trajectory might give some insight (for sanity-checking a ballistic Flight);
  2. Still on the validation side: results should be pretty close if one runs a bare-bones Rocket in 6-DOF, right?
  3. Some tests lack proper docstrings;
  4. Smaller comments I left throughout my review.

I'm fine proceeding with a merge here, but the first point for me is important before releasing the feature.

Agreed on the first and second point. I can run a 3 DOF example of one of the already existing examples and see how it works. From there we will also be able to understand tolerances.

* docs: Update test docstrings to follow RocketPy style guidelines

Co-authored-by: aZira371 <[email protected]>

---------

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: aZira371 <[email protected]>
@aZira371 aZira371 self-assigned this Nov 27, 2025
@aZira371
Copy link
Collaborator Author

aZira371 commented Nov 27, 2025

Screenshot from 2025-11-27 16-31-49

@Gui-FernandesBR @phmbressan
Here is a comparison of results of 3 dof and 6 dof on bella lui rocket example. as expected the impact/landing point is drastically incorrect. This is expected as 3 dof only implements translation motion (meaning the quaternion rates are 0) , to model rotational kinematics I can introduce an evolving unit direction vector for the “effective body/flight‑path axis” with a simple kinematic or quasi‑static weathercocking model. What do you think? This can be an implementation after this PR is merged!

just a small note on how the Weathercocking Model Works:

  • Calculate the current body z-axis direction from quaternions (attitude vector)
  • Calculate the desired direction as the opposite of the freestream velocity (normalized)
  • Compute the rotation axis as the cross product of current and desired directions
  • Apply angular velocity proportional to sin(misalignment_angle) (for quasi-static alignment)
  • Compute quaternion derivatives from this angular velocity

@aZira371
Copy link
Collaborator Author

aZira371 commented Nov 27, 2025

Results with preliminary weathercocking implementation and creating quasistatic attitude variation for 3 dof :
termination at apogee :-
Screenshot from 2025-11-27 16-34-05
termination at apogee false : -
Screenshot from 2025-11-27 16-46-45
Screenshot from 2025-11-27 16-47-36

@Gui-FernandesBR
Copy link
Member

@phmbressan thank you for the quick response. I will merge this PR as this is becoming quite dated now.
@aZira371 will make smaller, separate PRs to solve your remaining comments.

@Gui-FernandesBR Gui-FernandesBR merged commit 704c796 into RocketPy-Team:develop Nov 27, 2025
9 of 10 checks passed
@github-project-automation github-project-automation bot moved this from Mid-Term to Closed in LibDev Roadmap Nov 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Enhancement New feature or request, including adjustments in current codes Flight Flight Class related features

Projects

Status: Closed

Development

Successfully merging this pull request may close these issues.

ENH: 3-DOF simulation

6 participants