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

Flight mode changes to Loiter on disarm #1108

Closed
PaulHam211 opened this issue Oct 1, 2014 · 13 comments
Closed

Flight mode changes to Loiter on disarm #1108

PaulHam211 opened this issue Oct 1, 2014 · 13 comments

Comments

@PaulHam211
Copy link

How to replicate -
-Arm in Stabilize (droidplanner tells me its armed)
-Disarm (still in stabilize)

Copter disarms then flight mode on DroidPlanner changes to loiter. I have to flick the flight mode switch on the transmitter out of stabilize to get loiter off the screen.
I'm not sure if it is actually changing the flight mode on the pixhawk or is it just telling me its in loiter.

http://youtu.be/ZOG0y319LSQ

@arthurbenemann
Copy link
Member

This behavior was in fact added to the code here arthurbenemann@bb09263

It's needed for tablet only flights. Can you explain how it messes up the RC flight workflow?

@PaulHam211
Copy link
Author

Oh right. So thats what its supposed to do.

If I armed from my transmitter and not the tablet would the mode be loiter or stabalise?

I use the tablet to keep an eye on everything while flying. That includes listening to flight modes.

@m4gr3d
Copy link
Member

m4gr3d commented Oct 1, 2014

@PaulHam211 the mode would still be loiter. This is done so that if the take off button is used, the drone will be able to successful take off by being in the right flight mode.

@m4gr3d
Copy link
Member

m4gr3d commented Oct 1, 2014

@jason4short I have been talking with @arthurbenemann, and I feel like the mode switch should happen when the user clicks the take off button.
The reasons for that are as follow:

  • when the user clicks the take off button, it intends for the drone to do so, and so it's okay for the app to cause a mode change to achieve the intended behavior.
  • on the other hand, for the app to perform a mode change without the user's input or confirmation can be interpreted as bad UX.
  • switching to loiter on disarm doesn't guarantee that it will remain as such when the drone is next armed (i.e: user using RC to switch mode). Hence if the take off button is pressed, we would have to handle things ourselves by switching to the correct mode, or add additional logic to inform the user why the drone can't be made to take off.
  • at least for the initial release of the feature, a majority of the users will still be making use of their RC controllers. For the drone to switch flight mode on disarm might make them think there's an issue with the hardwares, autopilot, and/or DroidPlanner, as highlighted by this opened issue.

@m4gr3d
Copy link
Member

m4gr3d commented Oct 1, 2014

@arthurbenemann @jason4short another post highlighting the same issue: https://plus.google.com/113748210751020520760/posts/LhSfbdsPtNJ

@jason4short
Copy link
Contributor

The behavior on land confirmation should be fall back to Loiter, not disarm. Not sure how it was implemented but it doesn't seem right.
When the user is in Stabilize and disarms, nothing should happen.

@lperry3
Copy link

lperry3 commented Oct 1, 2014

The new disarm to loiter is not a good idea. In the winter our group fly's in a indoor soccer arena where we cannot get GPS LOCK, so this new setup is a problem because loiter does not work without GPS. The arena we fly in is 300x300+ with a 80 foot ceiling. I know we don't need DP to fly there but I like the battery audible updates. Larry

@arthurbenemann
Copy link
Member

That is a good point Jason. I implement the switch to loiter on disarm with
disregard to the mode. So let's just switch to loiter if the user disarms
in RTL or land.

@fredia the problem is not the takeoff, the problem is when arming.
On Oct 1, 2014 3:56 PM, "jason4short" notifications@github.com wrote:

The behavior on land confirmation should be fall back to Loiter, not
disarm. Not sure how it was implemented but it doesn't seem right.
When the user is in Stabilize and disarms, nothing should happen.


Reply to this email directly or view it on GitHub
#1108 (comment)
.

@m4gr3d
Copy link
Member

m4gr3d commented Oct 2, 2014

@arthurbenemann let's switch it to loiter then when arming from the tablet. If you update the logic to kick in when the user disarms in RTL or land, the same issue will kick in if the user triggers RTL or land from the RC controller.
Again the principle of least astonishment applies here.

@jason4short
Copy link
Contributor

The previous implementation was incorrect leading to undesired behavior.

I suggest we do:
RTL > Land > Loiter
Auto > Land > Loiter
Land > Loiter

In no other case we switch modes after disarming. The user can switch out of Land to whatever mode they want after disarming. They need to switch out of Land to fly again anyway, so I don't see any harm in this.

I'd prefer we don't switch modes directly before arming. If a user selects a mode via the tablet, say Position, then arms and tries to fly it they will be in a different mode than they just selected. We'll be basically ignoring their input and switching modes immediately after they input a mode. I think this will lead to frustration.

Jason

@m4gr3d
Copy link
Member

m4gr3d commented Oct 2, 2014

@jason4short since the user can switch to whatever mode they want after disarming, and before arming, what's the point of automatically switching to loiter then.
In either case, the app has to identify if it's in the right mode for arming, and act accordingly. In that situation it might be best no to do anything at all but notifying the user of the incorrect mode.

@jason4short
Copy link
Contributor

We did user testing and found this was a usability issue for people. You hit land, it lands, disarms, then you go to fly again, hit arm and it refuses. You cannot arm from Land mode. And there is really no reason to stay in Land mode after landing. It's pretty pointless. In most cases the user didn't choose land mode anyway, it's an artifact of the implementation in the flight code creeping into user experience.

@m4gr3d
Copy link
Member

m4gr3d commented Oct 2, 2014

I can't argue with user testing data :) .
And as you mentioned @jason4short this alternative is better than overriding the flight mode if the user sets it before arming.

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

No branches or pull requests

5 participants