-
-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: motor coordinates #423
Conversation
MAINT: Update develop branch from v1.0.0 master
Update develop regarding README contributors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall a simple and effective solution. I really liked it.
As this is a bug solving, I believe we should merge it directly to the master branch so we don't spend much time until actually getting these changes to the default branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are still some things wrong thorought the code. Here is what I found:
rocket_prints.py
: Line 97,rocket.py
: Line 102, documentation is wrongflight.py
:effective_1rl
andeffective_2rl
seem wrongflight.py
:b
andc
parameters inu_dot
flight.py
:r_NOZ
inu_dot_generalized
flight.py
: inb
parameter ofrotational_energy
Btw. The effective rail cached properties were duplicated, I just deleted them here because they are still related to this bug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved again, good work here!
Pull request type
Checklist
black rocketpy/ tests/
) has passed locallypytest --runslow
) have passed locallyCurrent behavior
A bug was identified by @Gui-FernandesBR regarding
add_motor
coordinate conversion. A legacy assumption ofnozzle_position=0
was being considered in code.New behavior
The coordinate conversion was fixed and now is consistent with the documentation: positions are defined with respect to the coordinate system's origin of the objects involved.
A parametrized test was added to check this behavior.
Breaking change