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

[DO NOT MERGE] Fixed wing land-detector block #13797

Closed
wants to merge 3 commits into from

Conversation

Kjkinney
Copy link
Contributor

Describe problem solved by this pull request
If an airplane is in a "Launch-Detection" state, the land-detector can still be triggered. This is due to the Catapult-Launch parameters are set to be way less sensitive than the land-detector parameters.

This can cause false positives to occur due to the plane not being in air when the land-detector flips from landed to non-landed.

Describe your solution
This solution requires PR#13775

This uses the new launch detection uORB messages to change the Fixedwing land-detector values to those of the Catapult Launch detection. This keeps the vehicle in a landed state while in launch detection. Also includes a check for vehicle pitch, which may or may not be necessary.

Describe possible alternatives
The launch-detector could be flipped to being entirely based off of the land-detector. This would require a pretty significant restructure of both launch-detection and fixed-wing land detection

Test data / coverage
This has been in use on our Fixedwing vehicles for the past 6 months with no issues.

Additional context
This PR includes and requires #13775 and should not be merged until that PR is reviewed merged.

@Antiheavy

…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.
…his also makes it more robust to weird states.
…is in a Hand Launch/Catapault Launch situation. If so it will raise the values to those of the launchdetector in order to not allow false positives.
@@ -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.

You can move this within the auto disarm block below and only store a boolean (in the class) for launch_detection_running.

Copy link
Contributor Author

@Kjkinney Kjkinney Dec 30, 2019

Choose a reason for hiding this comment

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

Done in the other PR. I'll wait for that to get all sorted out and re-base this branch properly. In the meantime is there anything within the Fixed Wing Land Detection that should be changed?

@julianoes
Copy link
Contributor

I don't understand why this one is still needed once #13775 is merged.

@Antiheavy
Copy link
Contributor

I don't understand why this one is still needed once #13775 is merged.

because #13775 only deals with blocking auto-disarm. This PR blocks (or rather, "syncs") LandDetector with LaunchDetection threshold values. LandDetector causes other problems when it switches in and out of flying and landed states quickly on the ground (e.g. during ground handling) causing other parts of the controller to get confused (we've observed weird impacts to Mag resets, airspeed failsafe resets, TECS wind up and other things that seem related to LandDetector quickly switching in and out just prior to real takeoff).

@julianoes
Copy link
Contributor

@Antiheavy yes that makes sense! I'll review it again once the other PR is in.

@stale
Copy link

stale bot commented Apr 16, 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

@Kjkinney Do you want to rebase this or it is stale?

@Antiheavy
Copy link
Contributor

Looks like the basic idea here was implemented in a more up-to-date PR here: #20557

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.

5 participants