-
Notifications
You must be signed in to change notification settings - Fork 13.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
commander: collapse ArmStateMachine and simplify #21129
Conversation
69a6b14
to
edf4388
Compare
33ba4a0
to
dd21af4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my eyes this is a very valuable simplification. There is a lot of distributed, glanced-over, unnecessary complexity in this logic and after going through I'm reasonably sure you captured all important bits. The cases for which I'm not so sure I made a comment. We have to test these through if it didn't happen already but it's certainly worth it because things get much more deterministic.
Some small suggestions I'll add in a commit.
@@ -2368,7 +2324,7 @@ void Commander::control_status_leds(bool changed, const uint8_t battery_warning) | |||
BOARD_ARMED_LED_ON(); | |||
} | |||
|
|||
} else if (_arm_state_machine.isStandby()) { | |||
} else if (_vehicle_status.pre_flight_checks_pass) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pre_flight_checks_pass
should not pass if we are currently calibrating then.
|
||
// reject if armed or shutting down | ||
answer_command(cmd, vehicle_command_ack_s::VEHICLE_CMD_RESULT_TEMPORARILY_REJECTED); | ||
|
||
} else { | ||
|
||
/* try to go to INIT/PREFLIGHT arming state */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Temperature calibration is the only case that sets neither calibration_enabled
nor rc_calibration_in_progress
. Are we sure we can't arm in temperature calibration?
|| (!actuator_armed_prev.manual_lockdown && _actuator_armed.manual_lockdown) | ||
) { | ||
if (isArmed()) { | ||
send_parachute_command(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was previously a guard that did not allow triggering the parachute multiple times except for when resetting for test purposes with the undocumented unterminate command. I don't see why this should be an issue but wanted to note that it's a change in behaviour.
} else { | ||
_actuator_armed.force_failsafe = false; | ||
_actuator_armed.lockdown = false; | ||
if (!isArmed()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't there be a way to terminate before arming for testing? I'm asking because the DRS parachute mechanism to my knowledge can/should be tested before arming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Terminate before arming? Doesn't sound intuitive to me, to be honest.
|
||
_lockdown_triggered = false; | ||
_flight_termination_triggered = false; | ||
} else if (_user_mode_intention.change(vehicle_status_s::NAVIGATION_STATE_TERMINATION)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there additional conditions to enter termination then? Can we then unterminate by switching mode? Could that happen unintentionally? We could chop up the parachute in that case no?
return TRANSITION_NOT_CHANGED; | ||
} | ||
|
||
if (_vehicle_status.calibration_enabled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Best we move all of these additional
- calibration
- Throttle too high
- armed by RC
checks into the _health_and_arming_checks
next. Probably it needs to know calling reason if that's not the case already.
if (valid_transition | ||
&& (new_arming_state == vehicle_status_s::ARMING_STATE_ARMED) | ||
&& fRunPreArmChecks | ||
&& !(status.hil_state == vehicle_status_s::HIL_STATE_ON) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be that HIL now fails certain preflight checks that were skipped in an obfuscated way before. We need to test it and go through these if that didn't happen already.
} | ||
|
||
// system_status overrides | ||
if (actuator_armed.force_failsafe || actuator_armed.lockdown || actuator_armed.manual_lockdown | ||
|| vehicle_status.nav_state == vehicle_status_s::NAVIGATION_STATE_TERMINATION) { | ||
|
||
system_status = MAV_STATE_FLIGHT_TERMINATION; | ||
|
||
} else if (vehicle_status.calibration_enabled) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we can't calibrate while being armed this "override" doesn't make sense. The valid case is already handled above.
Make message format consistent with the arming denied error messages.
pre_flight_checks_pass can only be true or false the else case cannot be reached.
dd21af4
to
09f41da
Compare
I rebased the pr without conflict and added my suggestions in additional commits.
|
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: https://discuss.px4.io/t/px4-maintainers-call-may-16-2023/32137/1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I couldn't spot anything obviously wrong.
} else { | ||
_actuator_armed.force_failsafe = false; | ||
_actuator_armed.lockdown = false; | ||
if (!isArmed()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Terminate before arming? Doesn't sound intuitive to me, to be honest.
…e_machine_collapse
There's still some overlap and duplication between actuator_armed and vehicle_status that we can consolidate.
I don't particularly like all the scattered HIL_STATE_ON checks, these should really be nearly entirely eliminated.