Skip to content
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

PR block auto-disarm when in Launch Detection for Hand-Launched FW #13775

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Kjkinney
Copy link
Contributor

@Kjkinney Kjkinney commented Dec 23, 2019

If the vehicle is in a launch detection state, it is possible to trip the auto disarm without ever launching the vehicle. This change allows the commander to determine if the vehicle is in a launch detection state and if so, it will not auto-disarm the vehicle.

This is a re-do of #12513 re-based on the current master

This PR has been further tested on our fixed-wing vehicles as well

@Antiheavy

@Antiheavy
Copy link
Contributor

This PR is basically required for any hand launched vehicle that also wants to use the very important auto-disarm safety feature. Thanks!

…if the vehicle is in a launch detection state, it is possible to trip the auto disarm without ever launching the vehicle. This change allows the commander to determine if the vehicle is in a launch detection state and if so, it will not auto-disarm the vehicle.
@Kjkinney
Copy link
Contributor Author

I found a pretty large bug in relation to this PR. If the vehicle is armed without launch detection, the launch detection message remains true, which means that auto-disarm is still blocked. I believe this is due to the new way that I decide whether or not the plane is in launch detection. I am going to restructure this to avoid the issue. FYI @Antiheavy

…his also makes it more robust to weird states.
@Kjkinney Kjkinney force-pushed the pr-fw-launchdetect-autodisarm branch from bd4185d to 5fbde21 Compare December 27, 2019 15:39
@Kjkinney
Copy link
Contributor Author

Kjkinney commented Dec 27, 2019

Fixed the bug and made it more robust, as well as rebased.

@Antiheavy Antiheavy requested a review from dagar December 27, 2019 16:51
@Kjkinney
Copy link
Contributor Author

@MaEtUgR @RomanBapst Could you guys take a look at this updated version?

@dagar
Copy link
Member

dagar commented Dec 28, 2019

Feedback in #13797 should have been left here, but basically I think this part is workable with a few minor changes.

@@ -14,3 +14,5 @@ float32 acceptance_radius # the optimal distance to a waypoint to switch to the
float32 yaw_acceptance # NaN if not set

float32 altitude_acceptance # the optimal vertical distance to a waypoint to switch to the next

bool launch_detection_running # true if the launch detection is running
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought for later, it might be worth adding all launch detection states here for logging. That would be better than dumping the text messages into the log.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good Idea

@@ -110,6 +110,7 @@ static struct actuator_armed_s armed = {};

static struct vehicle_status_flags_s status_flags = {};

static struct position_controller_status_s controller_status = {}; //Struct for holding controller status
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
static struct position_controller_status_s controller_status = {}; //Struct for holding controller status

@@ -1547,9 +1548,12 @@ Commander::run()
_was_falling = _land_detector.freefall;
}

if (_controller_status_sub.updated()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this within the armed.armed conditional and keep a local launch_detection_running bool. The idea is to minimize the work you do (only update when armed) and minimize memory usage (only store the minimum).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested changes added. I'm not completely sure I put the the launch_detection_running bool in the proper place.

@Antiheavy Antiheavy requested a review from julianoes January 8, 2020 17:33
Copy link
Contributor

@julianoes julianoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix.

Only 2 questions from my side.

position_controller_status_s controller_status = {};
_controller_status_sub.copy(&controller_status);
launch_detection_running = controller_status.launch_detection_running;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should also update this topic when not armed. That way we can reset the bool flag when disarmed, so it's not stale.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Kjkinney If you do it that way I think you could even write

if (armed && ! launch_detection_running) { ... } else { ... }

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Kjkinney Actually I noticed that @dagar suggested to do it this way.

@@ -165,7 +165,8 @@ class FixedwingPositionControl final : public ModuleBase<FixedwingPositionContro
uORB::Publication<vehicle_attitude_setpoint_s> _attitude_sp_pub;
uORB::Publication<position_controller_status_s> _pos_ctrl_status_pub{ORB_ID(position_controller_status)}; ///< navigation capabilities publication
uORB::Publication<position_controller_landing_status_s> _pos_ctrl_landing_status_pub{ORB_ID(position_controller_landing_status)}; ///< landing status publication
uORB::Publication<tecs_status_s> _tecs_status_pub{ORB_ID(tecs_status)}; ///< TECS status publication
uORB::Publication<tecs_status_s> _tecs_status_pub{ORB_ID(tecs_status)}; ///< TECS status publication
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this needed? I don't see it.

@RomanBapst
Copy link
Contributor

@Kjkinney I reviewed and generally the changes look good. There's different suggestions regarding whether to update the position control status topic at every iteration or only when the vehicle is armed.
I will let @dagar comment on that.

@stale
Copy link

stale bot commented Apr 14, 2020

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@LorenzMeier
Copy link
Member

Could you rebase? My apologies that this has been sitting in the PR queue for so long.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants