-
Notifications
You must be signed in to change notification settings - Fork 460
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
Added ability to dynamically change thruster location via property #1073
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1073 +/- ##
==========================================
- Coverage 24.97% 24.95% -0.03%
==========================================
Files 168 168
Lines 18057 18072 +15
==========================================
Hits 4510 4510
- Misses 13547 13562 +15 ☔ View full report in Codecov by Sentry. |
I kicked off the build and test checks. No need to worry about the MacOSX-14 error about not finding Julia. |
0e7e110
to
803c3f3
Compare
Thanks! Anything else I have to do to get this through? Coverage? I intend to contribute documentation and code in the future to this project so I would like to become familiar with your processes. Thanks! |
Hi @hitchcock9307, I'd suggest you also add properties for jsbsim/src/models/propulsion/FGPropeller.cpp Lines 269 to 271 in 3c7582e
The idea is that you would have a reference point (that is named base_x in your original post) that never changes and that it would be the acting point that would be modified. This would give something like:
property_name = base_property_name + "/x-reference-position";
PropertyManager->Tie(property_name.c_str(), (FGForce*)this, &FGForce::GetLocationX);
property_name = base_property_name + "/y-reference-position";
PropertyManager->Tie(property_name.c_str(), (FGForce*)this, &FGForce::GetLocationY);
property_name = base_property_name + "/z-reference-position";
PropertyManager->Tie(property_name.c_str(), (FGForce*)this, &FGForce::GetLocationZ);
property_name = base_property_name + "/x-position";
PropertyManager->Tie(property_name.c_str(), (FGForce*)this, &FGForce::GetActingLocationX, &FGForce::SetActingLocationX);
property_name = base_property_name + "/y-position";
PropertyManager->Tie(property_name.c_str(), (FGForce*)this, &FGForce::GetActingLocationY, &FGForce::SetActingLocationY);
property_name = base_property_name + "/z-position";
PropertyManager->Tie(property_name.c_str(), (FGForce*)this, &FGForce::GetActingLocationZ, &FGForce::SetActingLocationZ); This would allow to use your formula <function name="rotor1/tilt-command-x">
<sum>
<property>propulsion/engine[0]/x-reference-position</property>
<product>
<property>propulsion/engine[0]/rotor-height-in</property>
<cos>
<property>propulsion/engine[0]/pitch-angle-rad</property>
</cos>
</product>
</sum>
<output>propulsion/engine[0]/x-position</output>
</function> Note that for this code to compile, you'd need to change the signature of the methods - inline double SetActingLocationX(double x) {vActingXYZn(eX) = x; return x;}
+ inline void SetActingLocationX(double x) {vActingXYZn(eX) = x; }
- inline double SetActingLocationY(double y) {vActingXYZn(eY) = y; return y;}
+ inline void SetActingLocationY(double y) {vActingXYZn(eY) = y; }
- inline double SetActingLocationZ(double z) {vActingXYZn(eZ) = z; return z;}
+ inline void SetActingLocationZ(double z) {vActingXYZn(eZ) = z; } |
Excellent recommendation, that will help clean up the XML implementation; changed. |
Looks good to me. |
In vehicle's such as tiltrotors the rotor must be both translated (i.e.
x_position = cos(theta)*rotor_height + base_x
) and rotated, only thepitch-angle-rad
is exposed via property and prevents scripting a tilt-rotor adequately.