Control surface preflight check #24391
Draft
Conversation
This file contains hidden or 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
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 1864 byte (0.09 %)]px4_fmu-v6x [Total VM Diff: 1864 byte (0.1 %)]Updated: 2025-07-16T09:17:00 |
This was referenced Feb 21, 2025
mbjd
force-pushed
the
cs_preflight_check_3
branch
6 times, most recently
from
a815643 to
d1e18c1
Compare
|
This is great. A CS preflight command QGC side is the logical next step that allows you to hit a button and have all CS move to min max move rather than a manual check. Awesome. |
mbjd
force-pushed
the
cs_preflight_check_3
branch
from
e9c709b to
b0de604
Compare
mbjd
force-pushed
the
cs_preflight_check_3
branch
from
b0de604 to
9e4b058
Compare
RomanBapst
reviewed
Jul 7, 2025
mbjd
force-pushed
the
cs_preflight_check_3
branch
from
b162d35 to
c75ea70
Compare
sfuhrer
reviewed
Jul 14, 2025
|
|
||
| if (vehicle_command.command == vehicle_command_s::VEHICLE_CMD_DO_PREFLIGHT_CS_CHECK) { | ||
| if (!_armed) { | ||
| // currently this does not check prearmed status. if not prearmed, it will just do nothing. |
There was a problem hiding this comment.
Would be good to notify the user, yes.
There was a problem hiding this comment.
checking for prearmed state now. I added a subscription to actuator_armed to get it, I presume there's not a neater way, or can you think of one?
...odules/control_allocator/VehicleActuatorEffectiveness/ActuatorEffectivenessTiltrotorVTOL.cpp
Outdated
Show resolved
Hide resolved
| uORB::Subscription _tiltrotor_extra_controls_sub{ORB_ID(tiltrotor_extra_controls)}; | ||
|
|
||
| bool _bypass_tiltrotor_controls{false}; | ||
| float _collective_tilt_normalized_setpoint{0.5f}; |
There was a problem hiding this comment.
Do we need both that and _last_collective_tilt_control? Can we remove some of these class members? They add memory and through that complexity.
There was a problem hiding this comment.
I'd keep them both as they serve different purposes:
_last_collective_tilt_controlis populated inprocessTiltrotorControls, thus acts as an output wrt. that function. It is used to construct the effectivenes matrix. note that is is not actually the last collective tilt control -- it is modified here to achieve desired transition behaviour with a "wrong" effectiveness matrix..._collective_tilt_normalized_setpointis an input toprocessTiltrotorControls, only in the case of overriding collective tilt introduced here.
I suppose it would be technically possible to unify them, especially if we guarantee that we will never be in a preflight check and a transition at the same time. But mixing input/output functionality would imo be confusing and hinder maintainability, and we'd have to remove / move / work around the hack of sometimes outputting the wrong collective tilt.
instead only leaving tilt. adjust function / variable names accordingly.
|
Please don't merge before before mavlink/mavlink#2224 |
mbjd
force-pushed
the
cs_preflight_check_3
branch
from
6ecc76d to
2d76534
Compare
I still need to get someone from ArduPilot to look at the mavlink PR. I've been trying and will continue to do so. Ping me next week if it has not merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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
The current preflight check sends servo commands (essentially) directly over mavlink. This requires the GS to know/guess which actuators are available and should be tested.
Solution
As an alternative solution, this check tests control surfaces in functional groups (roll/pitch/yaw/tilt). It works as follows:
VEHICLE_CMD_DO_PREFLIGHT_CS_CHECK, containing parameters: axis (roll/pitch/yaw/tilt) and control input.ControlAllocatorapplies the given control input to the given axis.param set COM_PREARM_MODE 2).ActuatorEffectivenessTiltrotorVTOLwith a setter function (declared for the base classActuatorEffectiveness, but empty implementation unless overridden).Here is a diagram depicting the information flow:
Alternatives / modifications
ControlAllocatorinto an own class