Control surface preflight check #24391
Draft
+358
−58
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
- currently triggered via param COM_DO_CS_CHECK. ultimately this will be replaced by a mavlink cmd - new VehicleStatus.nav_state, NAVIGATION_STATE_CS_PREFLIGHT_CHECK. this is how commander tells ControlAllocator to conduct the check - (todo) within ControlAllocator we overwrite torque setpoints to do the check. additionally we can also control servos directly from there, in a different mode if that is needed.
not sure if all of these are needed, but with all of them the allocator runs, and with only flag_control_allocation_enabled it does not.
modifies torque setpoints directly via the matrix c.
we "intercept" the tiltrotor_extra_controls message, which is read again right after in ActuatorEffectivenessTiltrotorVTOL::updateSetpoint.
even if we are not currently testing the tilt axis. then we send zero tilt rather than nothing.
previously it would always change _user_mode_intention to _prev_nav_state forever. now we change it only if we are in preflight check mode to not interfere with anything else later.
this adds a new flag to ActuatorEffectivenessTiltrotorVTOL: _preflight_check_running. We set it from ControlAllocator, and if true we always add collective tilt to the actuator setpoint.
Previously, the approach to modify collective tilt control was to send the corresponding tiltrotor_extra_control uOrb message from ControlAllocator, which then influences ActuatorEffectivenessTiltrotorVTOL with minimal changes. This was a bit hacky and introduced potentially conflicting uOrb messages. So, with this new approach we pass the same information via argument. Specifically, the class ActuatorEffectiveness now declares updateSetpoint with an extra argument, preflight_check_running. It is only used in ActuatorEffectivenessTiltrotorVTOL, but has to be included as a "dummy" in all other classes inheriting from ActuatorEffectiveness. The argument can be used to bypass the collective tilt/thrust setpoints, instead replacing them with values from public class member variables which can be set from outside just before calling updateSetpoints. Also, slight refactor in ControlAllocator by splitting up the functions related to the preflight check into smaller parts
this allows us to have *only* the setter in the base class (ActuatorEffectiveness) with an empty implementation. Derived classes can implement another implementation, or stay completely unchanged w.r.t. previously. This may finally be the desired clean-ish OOP-ish solution to this.
put everything related to tiltrotor extra controls into own function to clean up updateSetpoint
The preflight check can be enabled by switching to nav_state vehicle_status_s::NAVIGATION_STATE_CS_PREFLIGHT_CHECK using VEHICLE_CMD_SET_NAV_STATE. Thus we can ditch this function and forgo adding an extra vehicle command.
and remove the parameter which ran it before. also, print info about rejection if trying to run it while armed
previously it would continue running after one round, because the two functions preflight_check_update_state and preflight_check_overwrite_torque_sp were called within the same preflight check running if clause, so updating _preflight_check_running in the first would not stop the second from running.
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 1160 byte (0.06 %)]px4_fmu-v6x [Total VM Diff: 1144 byte (0.06 %)]Updated: 2025-02-24T15:50:37 |
This was referenced Feb 21, 2025
- only publish ack if we got the right command initially - fix state machine (don't jump from 0 to 1 immediately) - comments, docstrings - move command next to previous one
mbjd
force-pushed
the
cs_preflight_check_3
branch
2 times, most recently
from
fb98635 to
f010c75
Compare
previously, one command without params started the entire check. here this is changed to including axis (roll, pitch, yaw, ...) and deflection in the vehicle command. idea being that ground control can implement a nice slider to actuate rpy. commander cs_check atm does only one hardcoded axis/deflection combo.
mbjd
force-pushed
the
cs_preflight_check_3
branch
3 times, most recently
from
2f13da3 to
a815643
Compare
- refactor last bit of logic from Run() into own method - update tiltrotor logic to new input (vehicle command rather than state machine) - remove unneeded member vars - format
mbjd
force-pushed
the
cs_preflight_check_3
branch
from
a815643 to
d1e18c1
Compare
# for free
to join this conversation on GitHub.
Already have an account?
# 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
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
(This describes the solution after bc86923, currently a slightly different version is WIP)
As an alternative solution, this control surface preflight check is triggered using a single command and decides on the PX4 side which specific actuators are used. It works as follows:
VEHICLE_CMD_DO_PREFLIGHT_CS_CHECK, no parameters as of now.ControlAllocatorcycles through roll, pitch, yaw, and collective tilt, and tests the min/max setpoints for each one.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