Fixed-wing high level control rework #24056
Conversation
RomanBapst
force-pushed
the
pr-fw_ctrl_api
branch
from
a3b4779 to
d73b3a0
Compare
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 4596 byte (0.23 %)]px4_fmu-v6x [Total VM Diff: 4524 byte (0.24 %)]Updated: 2025-05-26T12:04:00 |
RomanBapst
force-pushed
the
pr-fw_ctrl_api
branch
3 times, most recently
from
4544dec to
daa6b1a
Compare
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
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Outdated
Show resolved
Hide resolved
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
|
@Jaeyoung-Lim Thanks for your input on this!
Yes, and so far lateral and longitudinal control have almost completely been decoupled in PX4. The only coupling I am aware of is that NPFG used to be able to change the airspeed setpoint. But other than that, it was decoupled.
You are not limited to the exposed interfaces presented in this PR. If you want to have your fancy NDI controller running offboard and send attitude / rate or even actuator commands directly, you are free to do so, those interfaces I think are already there.
I think it's a design choice which solves 95% of the use case that people would want. I think that's pretty good.
Could you please specify the exact interface that you would need to solve whatever use case you are trying to solve? Generally, I have a feeling that your expectation is that ONE uorb topic defines exactly ONE control API. I don't think this needs to be true necessarily. I think you will use some kind of SDK, which will expose one interface to the developer, but the SDK itself can use multiple uorb topics. |
|
Hi. Thanks @RomanBapst and @KonradRudin for putting in work to finally start cleaning up the the fixed-wing high-level control infrastructure a bit! I haven't had time to fully go through the details, but I am a little confused what specifically is the "API" here. But there may just be some difference in everyone's semantics... The uorb topics in the figure look more like logging topics to me, as I find it odd an application would send e.g. pitch setpoint, throttle setpoint, altitude setpoint, and height rate setpoint all out into the ether at the same time? Maybe @RomanBapst you can de-confuse me on the strategy? :) Are there multiple uorbs being bundled and sent at once from e.g. the ROS2 mode? Are these messages just defining what each block (controller) needs as input? And the actual exposed API will be something more basic, with each control block parsing it to convert to the right inputs to each? Maybe it would help to include the module boundaries on the diagram, so it's clear where uorbs are subscribed to, vs whatever internal parsing a module does to input the right args to the control libraries. On the topic of alternate APIs (@Jaeyoung-Lim ), the block diagram itself looks as though it's not terribly far away from supporting a wide array of things. e.g. if there were a single 3d instantaneous path setpoint API, the height component of it could still be routed to Alt-Ctrl, the vertical incline of the path then converted to a height rate setpoint that could be used as feedforward, added to the feedback height rate from Alt-Ctrl, and then sent off to TECS (or Velocity NDI, or whatever). It looks as though that is actually already somewhat happening in the diagram? So long as the blocks on the diagram are decoupled as shown, and new urobs can be made with a parser to spit out the resp. input msgs each controller one is using needs, I would imagine it's possible to do, right? Or maybe I miss something on the routing details? (I am a bit foggy on things now after not looking for a long time) |
RomanBapst
changed the title
@tstastny I have changed the title of the PR to not contain the word API, as it seems to be confusing. Also note, that the current uorb messages contain certain fields I wish would not be there, but since it was a priority to not break existing functionality with this refactor, I added them regardless. I am all in favor to remove fields like I'm also adding a diagram here which I hope explains a bit better the architecture in terms of modularity. |
RomanBapst
force-pushed
the
pr-fw_ctrl_api
branch
from
60aa9d9 to
55be964
Compare
RomanBapst
force-pushed
the
pr-fw_ctrl_api
branch
from
5dff39d to
6a9a8c4
Compare
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Outdated
Show resolved
Hide resolved
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Outdated
Show resolved
Hide resolved
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.hpp
Outdated
Show resolved
Hide resolved
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Show resolved
Hide resolved
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Show resolved
Hide resolved
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Outdated
Show resolved
Hide resolved
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Outdated
Show resolved
Hide resolved
src/modules/fw_lateral_longitudinal_control/FwLateralLongitudinalControl.cpp
Outdated
Show resolved
Hide resolved
|
@RomanBapst @mahima-yoga @KonradRudin I've cleaned up the commits (incl. incorporating the changes in #24886) and force pushed. Edit: now also rebased on main to hopefully get rid of the MAVROS CI failures. |
sfuhrer
force-pushed
the
pr-fw_ctrl_api
branch
2 times, most recently
from
9db1ee4 to
395a3bd
Compare
- split up old module into two, one handling setpoint generation, one control - add lateral and longitudinal control setpoints topics that can also be injected from companion computer - add configuration topics that (optionally) configure the controller with limits and momentary settings Signed-off-by: RomanBapst <bapstroman@gmail.com>
Signed-off-by: Silvan <silvan@auterion.com>
…_wheel Signed-off-by: Silvan <silvan@auterion.com>
Signed-off-by: Silvan <silvan@auterion.com>
…o min tas Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Params that are used by FW Mode Manager - FW NPFG: NPFG params, should be renamed to FW Lateral Control once moved to the lat/lon controller - FW Auto Takeoff - FW Auto Landing Params used by Fw Lat/Long Controller: - FW Lateral Control - FW Longitudinal Control Params used by both: - FW General Params used by Performance model: - FW Performance (could be moerged with FW General?) Signed-off-by: Silvan <silvan@auterion.com>
add RunwayControl messge to pass wheel steering controls to wheel controller Signed-off-by: Silvan Fuhrer <silvan@auterion.com> Runway takeoff: specify that RWTO_TKOFF is directly applied during takeoff Signed-off-by: Silvan Fuhrer <silvan@auterion.com> msg/RateCtrlStatus: remove unused wheel_rate_integ field The wheel rate controller is not run in the moduels that are now running the MC/FW rate controllers, so thsi field canot be filled. Signed-off-by: Silvan Fuhrer <silvan@auterion.com> wheel rate controller: use speed scaler quadratically on integrator Signed-off-by: Silvan Fuhrer <silvan@auterion.com> wheel yaw controller: use a time constant of 0.1 Signed-off-by: Silvan Fuhrer <silvan@auterion.com> FW Attitude Controller: lock heading setpoint for wheels to initial heading Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
…ight rate change Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Signed-off-by: Silvan <silvan@auterion.com>
- Add versioning to interfacing messages - Add header description - Add units, frame and range wherever possible - Add [norm] and @range indentifiers
Signed-off-by: Silvan <silvan@auterion.com>
|
I'm going ahead and merge this, after giving this a lot of testing in the last months. Wrapping up the final documentation items in separate PRs. |
8 participants
Solved Problem
Because of the convoluted manner of the current high level fixed-wing controller architecture, it is not possible to cleanly implement an external flight mode that is interacting with PX4 over e.g. height rate, course and lateral acceleration setpoints.
In this PR we rework the FW position controller to expose clean APIs for lateral and longitudinal control.
Changelog Entry
For release notes:
TODO
Alternatives
Test coverage
Flight test: