Auto mode handling UX improvements #6523

LorenzMeier · 2017-02-05T21:56:58Z

This adds a few useful changes:

If you move in LAND, AUTO or HOLD the sticks the system will give control back to the pilot
If you do not connect any RC the system will default to HOLD and will allow you tablet control
If you gain position lock for the first time the system will re-evaluate the mode switch (so if you dropped down to alt hold it will now go into position)
If the system breaches the Geofence it will now always drop back to POSCTRL if the sticks are moved

LorenzMeier · 2017-02-05T21:59:54Z

@Tumbili @dagar @MaEtUgR comments welcome. I think this is all common sense enough.

dagar · 2017-02-05T22:04:02Z

src/modules/events/mag_calibration/task.cpp

@@ -0,0 +1,324 @@
+/****************************************************************************


I think this slipped in unintentionally?

dagar · 2017-02-05T22:06:08Z

src/modules/commander/commander.cpp

+		}
+
+		// abort landing or auto or loiter if sticks are moved significantly
+		if (internal_state.main_state == commander_state_s::MAIN_STATE_AUTO_LAND ||


Any reason this wasn't combined with the same behaviour for RTL above?

Not really. We should do a function doing the comparisons.

dagar · 2017-02-05T22:06:47Z

src/modules/commander/commander.cpp

+			// transition to previous state if sticks are touched
+			if ((_last_sp_man.timestamp != sp_man.timestamp) &&
+				((fabsf(sp_man.x) - fabsf(_last_sp_man.x) > min_stick_change) ||
+				 (fabsf(sp_man.y) - fabsf(_last_sp_man.y) > min_stick_change) ||


Should min_stick_change factor in time between man sp changes?

I think it should. We should implement a change rate.

Actually - I think last_sp_man is implemented as the last setpoint in the last mode (implicitly the last manual mode). Its where you left the sticks when you handed over control. Locking that position and comparing it makes more sense than a change rate.

dagar · 2017-02-05T22:09:19Z

Thanks for taking care of this, I think it makes a lot of sense.

LorenzMeier · 2017-02-05T22:09:28Z

src/modules/commander/commander.cpp

@@ -194,6 +194,7 @@ static float max_ekf_dang_bias = 3.5e-4f;
 /* pre-flight IMU consistency checks */
 static float max_imu_acc_diff = 0.7f;
 static float max_imu_gyr_diff = 0.09f;
+static float min_stick_change = 0.25f;


This is not a good default.

I recant, that's actually an OK default.

dagar · 2017-02-05T22:13:36Z

We might need to play with it to see if it actually matters, but I'm wondering about the case where you're flying manually, violate the fence, and RTL is triggered. Letting the sticks settle back to neutral shouldn't be enough to change the state to POSCTL.

LorenzMeier · 2017-02-06T07:50:18Z

That has been a corner case before as well. I think any pilot would try to take over again. We need to test it. To me RTL on fence breach is sort of incompatible with manual input anyway. Its very scary and counter-intuitive. So maybe breaking out of it immediately is not so bad (if you are inside the radius again).

AndreasAntener · 2017-02-06T08:58:42Z

IMHO it comes down to the question if the operator is aware that RTL on fence breach is activated and that a fence is active in the first place. If we assume that is the case, then RTL on fence breach is fine even in manual mode. My suggestion to improve the awareness was to let RTL turn the vehicle around first before you let the user switch out (which would also make sure it's inside the fence again).

Stifael · 2017-02-14T09:40:53Z

I just quickly tested it in sitl:
moving stick during hold brings me back to position
moving stick during mission brings me back to position
moving stick during rtl nothing happens.

* If you move in LAND, AUTO or HOLD the sticks the system will give control back to the pilot * If you do not connect any RC the system will default to HOLD and will allow you tablet control * If you gain position lock for the first time the system will re-evaluate the mode switch (so if you dropped down to alt hold it will now go into position) * If the system breaches the Geofence it will now always drop back to POSCTRL if the sticks are moved

Stifael · 2017-02-15T10:59:20Z

tested on real vehicle.
It seems that the stick input is not correctly interpreted:
if in hold:

there is no switch when moving sticks slowly
there is also sometimes no switch when moving sticks quickly, but not to the maximum range

if in rtl:

nothing happens

What exactly is the main advantage of this feature? for instance, if I am in hold and move the sticks, then I would enter position control but the remote controller still has the stick at hold. If I now want to switch back again to hold, then I first have to switch back the stick to position and then back to hold. it seems more intuitive to just switch remote stick from hold to position

MaEtUgR · 2017-03-02T07:50:38Z

src/modules/commander/commander.cpp

@@ -2498,15 +2506,34 @@ int commander_thread_main(int argc, char *argv[])
 			main_state_before_rtl == commander_state_s::MAIN_STATE_RATTITUDE ||
 			main_state_before_rtl == commander_state_s::MAIN_STATE_STAB)) {

-			// transition to previous state if sticks are increased
-			const float min_stick_change = 0.2f;
+			// transition to previous state if sticks are touched
 			if ((_last_sp_man.timestamp != sp_man.timestamp) &&
 				((fabsf(sp_man.x) - fabsf(_last_sp_man.x) > min_stick_change) ||


If I read it correctly this is handled like a switch transition, meaning the value is compared to what it was when the fc last received an RC update. So the actual speed with which you have to move your stick depends on the RC update rate and if you happen to have a high update frequency you might never reach such a step.

MaEtUgR · 2017-03-02T08:01:06Z

I guess RTL is not bothered because you might accidentally overlook an automatic RTL on low battery. But the same would also apply to the land mode. An automatic emergency land because of critial battery could go unnoticed. I know it makes things more complicated but maybe we need a distinction of forced reactions or a way the user can not accidentally switch out of these modes.

LorenzMeier · 2017-04-10T06:58:53Z

We should do these UX changes one release later.

stale · 2019-01-20T17:59:02Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

dagar · 2019-02-06T00:56:57Z

Is this still wanted?

mhkabir · 2019-02-06T01:44:07Z

I like this as a feature. Seems very sensible.

mcsauder · 2019-08-19T16:42:12Z

Hi @LorenzMeier and @dagar , I've checked through this PR and the only changes proposed here that are not already incorporated into current PX4:master involve position_lock_gained. Everything else in this PR is already in place in the master branch.

If you would like, I could submit a PR with the position_lock_gained logic changes from this PR and this PR could be closed, or this PR could just be closed out.

Let me know if you'd like those remaining changes submitted or how else I can help.

Antiheavy · 2019-08-19T17:02:42Z

If the system breaches the Geofence it will now always drop back to POSCTRL if the sticks are moved

@mcsauder I recall a discussion within the past few months about how this specific behavior would be inappropriate for Fixed Wing as POSCTRL for fixed wings isn't "just hover" like it is for multicopter. In your review of this old PR, did you see that feature as MC only?

mcsauder · 2019-08-19T17:42:03Z

Hi @Antiheavy , I think your discussion is unrelated to this particular change. For convenience here is a compare of what I *believe is the appropriate application of the remaining intent in this PR: master...mcsauder:mode_switch_automodes

I did a quick flight test to see if anything was obviously broken by these changes and things appear to be functioning properly. (They will require some more scrutiny.)

julianoes · 2019-08-22T08:44:45Z

Remaining diff is here: #12769 thanks @mcsauder

LorenzMeier added this to the Release v2.0.0 milestone Feb 5, 2017

dagar reviewed Feb 5, 2017

View reviewed changes

LorenzMeier force-pushed the pr-mode_switch_automodes branch from 9e76f3c to ed5d39f Compare February 5, 2017 22:07

LorenzMeier commented Feb 5, 2017

View reviewed changes

dagar mentioned this pull request Feb 6, 2017

RTL allows user take over without mode switch #6444

Closed

LorenzMeier force-pushed the pr-mode_switch_automodes branch 2 times, most recently from 74bf35e to 2222002 Compare February 13, 2017 10:34

LorenzMeier force-pushed the pr-mode_switch_automodes branch from 2222002 to 48ba241 Compare February 14, 2017 21:37

LorenzMeier force-pushed the pr-mode_switch_automodes branch from 48ba241 to 266bb94 Compare February 14, 2017 21:46

MaEtUgR reviewed Mar 2, 2017

View reviewed changes

LorenzMeier modified the milestones: Release v2.1.0, Release v1.6.0 Apr 10, 2017

dagar modified the milestones: Release v1.7.0, Release v1.8.0 Oct 5, 2017

PX4BuildBot added the status/STALE label Jan 17, 2018

weekly-digest bot mentioned this pull request Jan 27, 2019

Weekly Digest (20 January, 2019 - 27 January, 2019) #11307

Closed

dagar removed the status/STALE label Feb 5, 2019

weekly-digest bot mentioned this pull request Feb 10, 2019

Weekly Digest (3 February, 2019 - 10 February, 2019) #11425

Closed

dagar modified the milestones: Release v1.8.0, Release v1.10.0 Jul 4, 2019

weekly-digest bot mentioned this pull request Jul 7, 2019

Weekly Digest (30 June, 2019 - 7 July, 2019) #12430

Closed

jkflying requested a review from julianoes August 21, 2019 16:00

mcsauder mentioned this pull request Aug 21, 2019

Add _position_lock_gained bool and associated logic remaining to close PR #6523. #12769

Closed

julianoes closed this Aug 22, 2019

julianoes deleted the pr-mode_switch_automodes branch August 22, 2019 08:44

mcsauder added a commit to mcsauder/PX4-Autopilot that referenced this pull request Sep 3, 2019

Add _position_lock_gained boolean and associated logic from PR PX4#6523.

1f1696b

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Auto mode handling UX improvements #6523

Auto mode handling UX improvements #6523

LorenzMeier commented Feb 5, 2017 •

edited by AuterionWrikeBot

Loading

LorenzMeier commented Feb 5, 2017

dagar Feb 5, 2017

dagar Feb 5, 2017

LorenzMeier Feb 5, 2017 •

edited

Loading

dagar Feb 5, 2017

LorenzMeier Feb 5, 2017

LorenzMeier Feb 5, 2017

dagar commented Feb 5, 2017

LorenzMeier Feb 5, 2017

LorenzMeier Feb 6, 2017

dagar commented Feb 5, 2017

LorenzMeier commented Feb 6, 2017

AndreasAntener commented Feb 6, 2017

Stifael commented Feb 14, 2017

Stifael commented Feb 15, 2017 •

edited

Loading

MaEtUgR Mar 2, 2017 •

edited

Loading

MaEtUgR commented Mar 2, 2017

LorenzMeier commented Apr 10, 2017 •

edited

Loading

stale bot commented Jan 20, 2019

dagar commented Feb 6, 2019

mhkabir commented Feb 6, 2019

mcsauder commented Aug 19, 2019

Antiheavy commented Aug 19, 2019

mcsauder commented Aug 19, 2019 •

edited

Loading

julianoes commented Aug 22, 2019

		@@ -0,0 +1,324 @@
		/****************************************************************************

Auto mode handling UX improvements #6523

Auto mode handling UX improvements #6523

Conversation

LorenzMeier commented Feb 5, 2017 • edited by AuterionWrikeBot Loading

LorenzMeier commented Feb 5, 2017

dagar Feb 5, 2017

Choose a reason for hiding this comment

dagar Feb 5, 2017

Choose a reason for hiding this comment

LorenzMeier Feb 5, 2017 • edited Loading

Choose a reason for hiding this comment

dagar Feb 5, 2017

Choose a reason for hiding this comment

LorenzMeier Feb 5, 2017

Choose a reason for hiding this comment

LorenzMeier Feb 5, 2017

Choose a reason for hiding this comment

dagar commented Feb 5, 2017

LorenzMeier Feb 5, 2017

Choose a reason for hiding this comment

LorenzMeier Feb 6, 2017

Choose a reason for hiding this comment

dagar commented Feb 5, 2017

LorenzMeier commented Feb 6, 2017

AndreasAntener commented Feb 6, 2017

Stifael commented Feb 14, 2017

Stifael commented Feb 15, 2017 • edited Loading

MaEtUgR Mar 2, 2017 • edited Loading

Choose a reason for hiding this comment

MaEtUgR commented Mar 2, 2017

LorenzMeier commented Apr 10, 2017 • edited Loading

stale bot commented Jan 20, 2019

dagar commented Feb 6, 2019

mhkabir commented Feb 6, 2019

mcsauder commented Aug 19, 2019

Antiheavy commented Aug 19, 2019

mcsauder commented Aug 19, 2019 • edited Loading

julianoes commented Aug 22, 2019

LorenzMeier commented Feb 5, 2017 •

edited by AuterionWrikeBot

Loading

LorenzMeier Feb 5, 2017 •

edited

Loading

Stifael commented Feb 15, 2017 •

edited

Loading

MaEtUgR Mar 2, 2017 •

edited

Loading

LorenzMeier commented Apr 10, 2017 •

edited

Loading

mcsauder commented Aug 19, 2019 •

edited

Loading