WIP: Fixed wing control API #24056
Open
WIP: Fixed wing control API #24056
+2,514
−2,119
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RomanBapst
force-pushed
the
pr-fw_ctrl_api
branch
from
a3b4779 to
d73b3a0
Compare
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 5844 byte (0.28 %)]px4_fmu-v6x [Total VM Diff: 5852 byte (0.3 %)]Updated: 2025-02-06T14:17:01 |
RomanBapst
force-pushed
the
pr-fw_ctrl_api
branch
2 times, most recently
from
f14b301 to
8405fa3
Compare
…responding limits Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
RomanBapst
force-pushed
the
pr-fw_ctrl_api
branch
from
4544dec to
daa6b1a
Compare
Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
KonradRudin
reviewed
Jan 17, 2025
There was a problem hiding this comment.
I like the restructuring, having the fixed wing position control more separated into the mode and the actual control. As well as having more intermediate options.
I went through all of it. but not in the complete detail yet, just when i saw something i mentioned it.
Biggest issue for me is that we don't yet have a clear way to tell, that the longitudinal and lateral controller should be enabled or not. Should be in the vehicle control mode flags propably like _vcontrol_mode.flag_control_rates_enabled
| float32 height_rate_setpoint # NAN if not controlled directly, used as feeforward if altitude_setpoint is finite [m/s] | ||
| float32 altitude_setpoint # NAN if not controlled, MSL [m] | ||
| float32 equivalent_airspeed_setpoint # [m/s] | ||
| float32 pitch_sp # NAN if not controlled, overrides total energy controller [rad] |
There was a problem hiding this comment.
I guess you can't use those as feedforwards, right? So shouldn't we keep that separate as an alternative to the attitudeSetpoint message?
| float32 lateral_acceleration_setpoint # NAN if not controlled directly, used as feedforward if either course setpoint or airspeed_reference_direction is finite, [m/s^2] | ||
| float32 roll_sp # TODO: remove, only for testing | ||
|
|
||
| float32 heading_sp_runway_takeoff # [-pi, pi] heading setpoint for runway takeoff |
There was a problem hiding this comment.
Do we want that here? If we have that the lateral control is not enabled anyways. Keep it separate?
| @@ -116,13 +116,13 @@ class __EXPORT RunwayTakeoff : public ModuleParams | |||
| * @param external_pitch_setpoint Externally commanded pitch angle setpoint (usually from TECS) [rad] | |||
| * @return Pitch angle setpoint (limited while plane is on runway) [rad] | |||
| */ | |||
| float getPitch(float external_pitch_setpoint); | |||
| float getPitch(); | |||
|
|
|||
| /** | |||
| * @param external_roll_setpoint Externally commanded roll angle setpoint (usually from path navigation) [rad] | |||
| longitudinal_control_limits.throttle_max = (_landed | ||
| || !_local_pos.v_z_valid) ? _param_fw_thr_min.get() : _param_fw_thr_max.get(); | ||
|
|
||
| _longitudinal_ctrl_limits_pub.publish(longitudinal_control_limits); |
There was a problem hiding this comment.
ATM you publish the limits on every loop, thats not needed for every mode. Alternatively, we could just reset the limits to default each time the mode changes and if required only the mode publishes the adjusted limits
| float tecs_fw_thr_max; | ||
| const float acc_rad = _directional_guidance.switchDistance(500.0f); | ||
| float throttle_min = _param_fw_thr_min.get(); | ||
| float throttle_max = _param_fw_thr_max.get(); | ||
|
|
||
| if (pos_sp_curr.gliding_enabled) { |
There was a problem hiding this comment.
I think this is currently not handled, right? Check comment about the uorb topic, would be nice to have in the long control a field where you can specify normal mode or like here thrust/speed mode
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Outdated
Show resolved
Hide resolved
Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
Signed-off-by: RomanBapst <[email protected]>
Jaeyoung-Lim
reviewed
Feb 8, 2025
There was a problem hiding this comment.
Sorry that I am late to comment on this PR. I think there would be a lot of value of creating a FW API.
The api proposed have separate messages for longitudinal and lateral gudiance. This seems to be built on the assumption that lateral and longitudinal control (TECS) would be controlled in a decoupled way.
However, it would have been nicer if the api would be designed for more "generic" fixed-wing tasks, rather than exposing configurations of the underlying interface. IMO, an api should fully define what the vehicle "should" do for a given task (e.g. path following), rather than expose the underlying implementation.
-
Lateral/longitudinal controller decoupling is a design choice for a specific implementation. This would make it hard for other controllers to share the API, if the controllers do not have such decoupling (e.g. 3D NDI acceleration-based control).
-
The decoupling is not only not necessary for the task of path following, but can even limit what kind of paths we can follow in 3D. For example, if you try to track an inclined loiter(or any complex 3D path of arbitrary shape) the height rate setpoint in the
FwLongitudinalSetpoint.msgis no longer usable, since the information on the 3D geometry is already lost (e.g. height rate depends on the speed and direction of the vehicle to stay on the path).
Is there a good reason that we want to enforce the separation of lateral/longitudinal control on the API side?
@tstastny
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Solved Problem
Implement fixed wing control API for lateral and longitudinal control.
Changelog Entry
For release notes:
Alternatives
We could also ...
Test coverage
Context
Related links, screenshot before/after, video