Added ability to dynamically change thruster location via property#1073
Added ability to dynamically change thruster location via property#1073bcoconni merged 2 commits intoJSBSim-Team:masterfrom
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-radis exposed via property and prevents scripting a tilt-rotor adequately.