Auto Pause: Total disaster.

[tubeme]

Today I had a total crash with a novice while I was teaching him how to fly the PX4!

Why?? Just because he could not understand nor he could learn that in order to PAUSE his flight he has to

FIRST: switch to MISSION and then SECOND: to switch Auto Pause

it is just overwhelming for the pilot to think of this combination, especially in dare situation when you most likely need Auto Pause. It is against all the rules in a real airplane cockpit as well.

It is crazzzzyyyy!

It is like having your phone ringing in a meeting and then in order to MUTE it you have to first hit home button and then hold volume down for 2 seconds.

Or it is like if you are in the car listening to music CD and have your phone ringing first hit on the Radio Button and then hit CD pause in order to Pause your CD.

Now I have to make an input mixer setting in the Horus in order to do it with just one button, given all the processing power I have in the Pixhawk. Is it hard to make it function like RTL?

This becomes the N1 reason for crashes of novice for the last 6 months I experience. Nobody wants to fly PX4 at the club already. And it is hard for me to persuade them to start using it again with such public crashes and disaster in front of all people and humiliation for me!

It is non sense, period.

Or maybe I'm stupid and I'm missing some hidden parameter that should allow this. If this is the case excuse me for the rant.

[LorenzMeier]

That interpretation is wrong. Putting it into HOLD should be all it takes to make it either loiter at the default loiter radius or hover in spot when in multi rotor mode.

I suggest you try in the simulator first.

[tubeme]

Exactly what I had in mind @Lorenz and exactly my point. Because I'm talking about Airplanes now (I had to clarify) Auto Pause should do Loiter in our situation, in order for my student to have a brake from his plane uncontrollable dive (not because plane falure) and has his hands stop shaking from the overwhelming situation. So Auto Pause means Pause the flight (and FC take control of it) until I have time to explain to him the situation, why it happened, and most importantly to have my student pass the Adrenalin rush.

That is how I understand Auto Pause (ex. Loiter).

Experienced users dont use Auto Pause except if we are in mission and we have to Loiter for some time to change the mission or do some other stuff.

[julianoes]

@tubeme This comes from the fact that the modes are set-up in a hierarchical way and pause is nested in mission. I agree that it might be confusing if you don't know this fact, and if it's not already captured in your RC switch setup.

[tubeme]

Hi @julianoes @LorenzMeier

As far as I understand this is the current hierarchy of the flight modes taken from the source:

uint8 NAVIGATION_STATE_MANUAL = 0 # Manual mode uint8 NAVIGATION_STATE_ALTCTL = 1 # Altitude control mode uint8 NAVIGATION_STATE_POSCTL = 2 # Position control mode uint8 NAVIGATION_STATE_AUTO_MISSION = 3 # Auto mission mode uint8 NAVIGATION_STATE_AUTO_LOITER = 4 # Auto loiter mode uint8 NAVIGATION_STATE_AUTO_RTL = 5 # Auto return to launch mode uint8 NAVIGATION_STATE_AUTO_RCRECOVER = 6 # RC recover mode uint8 NAVIGATION_STATE_AUTO_RTGS = 7 # Auto return to groundstation on data link loss uint8 NAVIGATION_STATE_AUTO_LANDENGFAIL = 8 # Auto land on engine failure uint8 NAVIGATION_STATE_AUTO_LANDGPSFAIL = 9 # Auto land on gps failure (e.g. open loop loiter down) uint8 NAVIGATION_STATE_ACRO = 10 # Acro mode uint8 NAVIGATION_STATE_UNUSED = 11 # Free slot uint8 NAVIGATION_STATE_DESCEND = 12 # Descend mode (no position control) uint8 NAVIGATION_STATE_TERMINATION = 13 # Termination mode uint8 NAVIGATION_STATE_OFFBOARD = 14 uint8 NAVIGATION_STATE_STAB = 15 # Stabilized mode uint8 NAVIGATION_STATE_RATTITUDE = 16 # Rattitude (aka "flip") mode uint8 NAVIGATION_STATE_AUTO_TAKEOFF = 17 # Takeoff uint8 NAVIGATION_STATE_AUTO_LAND = 18 # Land uint8 NAVIGATION_STATE_AUTO_FOLLOW_TARGET = 19 # Auto Follow uint8 NAVIGATION_STATE_MAX = 20

This in its term means to me that from hierarchy stand point the RTL is lower in the hierarchy than the Mission and again is part of the autonomous modes as Loiter is, in other words RTL is also a sub mode of Mission if use Mission to denote autonomous modes, and can be activated from ALL modes (Manual, Acro etc) even without a GPS lock, which is very very good in design perspective. Without a GPS lock the RTL could do open loiter or land as far as I understand.

2-3 years ago RTL did not function this way and could not be activated from the Manual modes and without a GPS lock and I'm glad that after zillion of discussions on this topic things changed for good and PX4 became more reliable and robust as a flight controller. As I always like to think, the devil is in the details. And sometimes small details can make a difference between successful product or unsuccessful one.

There is something I noticed in the Flight Mode setup page in QGC. With the RTL switch enabled I see the Return monitor slider go to enable state the Return go yellow (ie activates) and I get the message "Reject Auto Return to Land" because I'm using bench test mock up I have for work and the mock up is in landed state. A minor detail here is that it is not correct English sentence! "Reject RTL" means that I have to reject the RTL but in reality it is that the RTL is rejected by the FC although I want to enable it. So the correct sentence should read "RTL rejected" and a good detail should be to have a second sentence to clarify why it is rejected. So it might read "RTL rejected, no GPS lock" or "RTL rejected, Aircraft is landed" etc.

When I flip the Pause/Hold switch I notice there are two sliders go to enable state: 1. Hold monitor slider and 2. Mission monitor slider at the same time. Which is logical if we want to anble the Loiter with just one (Hold) switch (this is exactly what I do in my Horus input mixer to make it work). Despite the Mission monitor slider and Hold monitor slider go to on state with the flip of Pause(Hold) switch neither Mission lights up in yellow nor Hold lights up in yellow nor i get any message from QGC that something is rejected.

Compared to this Hold switch behavior when I'm on the bench and I activate Mission with the main switch I see the Mission monitor slider go to on state, the Mission lights up in yellow and I get "Reject Auto Mission" message in QGC, of course consistent behaviour because I have no mission in the controller and I'm on the ground (If don't have mission in the PX4 and I'm in the air, the PX4 goes in Loiter state). Again minor detail is that "Reject Auto Mission" is not correct sentence. It should read Auto Mission Rejected" (by the FC) and again clarification why it is rejected could be added as a second sentence.

This to me is a totally inconsistent behavior for the Pause/Hold switch however i look at it.

And finally it is not a good idea to have a 2 different labels for the same thing because it might be hard to explain and setup by the user.

In the setup we refer to Loiter as Hold and we setup a Hold switch, but during flight we put a status and we receive a message as "Auto Pause Activated" in QGC. Either we use Hold or we use Auto Pause or just Pause to denote the Loiter in the setup and in the message the QGC gives. Probably HOLD is the better term.

[tubeme]

@julianoes Thanks for correcting the spelling mistake!

[tubeme]

I want to make my last pointer here.

I liked the Pixhawk and PX4 fundamental idea with the ROS almost since the beggining because it could easily scale up in terms of HW and SW development. Also I percieve it as a PROFESSIONAL controller given the extensive features.

I can point you to at least 3 cases of real airplane crashes with huge loss of life and damages on the ground due to bad signaling and confusing messaging in the cockpit.

And also there is famous emblematic A380 emergency situation with 50+ major system failures due to engine blow up. The messaging in the cockpit was so consistent, the procedures were so consistent with the messaging that the flight finished on the runway, the pilots managed to land it in this dare situation without a single life lost and without single people injury.

2 years ago we started scaling up, and we had flown a 2.5m - 3.4m IC engine airplanes at 10-20 kilos weight, with 1-3 kilos payload and about 5-10 kilos of gasoline.

Now we are moving towards 3.6m - 4.6m wingspan airplanes IC engine, 20-45 kilos weight and about 10-30 kilos gasoline with huge lipo batteries. So my point is that PX4 is not a toy/hobby controller anymore and with this scale we can really do damage and even kill people on the ground if we don't pay attention to the details!

I noticed today that @LorenzMeier added a PR https://github.com/PX4/Firmware/pull/6731 which a very very good thing and we have to be aware what could happen if we are not cautious.

[dagar]

It sounds like the confusion here is the "old/advanced" flight mode switch configuration which is a hierarchy. That nav state numbering isn't a hierarchy and has more to do with when things were added.

Have you tried the new "simple" flight mode config in QGC? Single channel for mode selection, separate dedicated switch for RTL, kill, etc.

[julianoes]

@tubeme I agree with your concerns. And thanks for pointing out multiple places where the feedback to the ground station is confusing or wrong. We should fix that.

For the mode switching, we probably need to go over these RC configurations again and check for cases like this. And maybe it's time to deprecate some "old/advanced" flight mode switch configuration if that's the issue. What do you think @dagar.

[tubeme]

Hey @dagar and @julianoes I don't like the new single switch setup because it is even more overwhelming for the novice than the multiple switch. Also I don't have the flexibility to setup the thing i want it my way with the single switch. Both ways are good on their own. I use the PX4 since version 0.5 which was about the summer 2014. I spent almost everyday with the controller and I still sometimes find myself in a maze. Imagine what is happening with a new user.

My interest and your interest in this open source project is to make as many people as we can use it. And there are certain qualities that PX4 should have in order to catch the fish. The simple example is the iPhone. I use smart phones since HTC P3300 windows phone which was avail way before Apple stepped in. The revolution for smart phones started with the iPhone because it was the easiest to use and with the best user experience created at that time. Despite Google stepped in with a lot of muscle they still are following in terms of sales. And now the iPhone is lacking a lot of features that Android has, and they are kind of dumb phones for me, but they still are holding their position as #1 smart phone in net worth.

Since the beginning of 2015 I want a single feature that will tremendously simplify the emergency response of the PX4. And that is setup a single emergency 3 pos switch. low position -regular flight, mid position - Hold or Auto Pause, high position - RTL. I cannot do this even today and finally I had a real crash with a real novice person in front of huge audience.I saw a lot of eye rolling and smiles. Of course If I had it in my hands I would most likely have the reflex to turn on the Loiter in time. But usually I leave my Loiter switch on during take off, and then in an emergency I flip the main mode switch to mission and voala I have Loiter with a single switch. This is a work around and not a good practice. I have this practice with time and got accustomed to it. I tell you something interesting. The guy that fly the most PX4 in our tests (he flies almost every day!) did not use loiter in many months. He has a 2-3 thousand hours on PX4 but three weeks ago he called me with a shocking question. "Hey Man, how do I go in Loiter? I could not turn it on at the field and I needed it to test some batteries."

Now I understand that nesting is different than indexing the modes in my example. But @julianoes has a great Idea that there should be some revision to what is going on in the nesting.

It is a simple idea, make the RTL and Hold in one emergency separate group on their own. Make both work from all modes + use the Hold with a higher priority than Mission in order to be able to Hold / Auto Pause the mission execution as well. This will nail it totally.

In this emergency mode group in the future we can include a certain other emergency modes regarding the collision avoidance like in the #6731. Like if we approach / sense a commercial plane dive down to safe alt and activate loiter or rtl. This group should have the highest priority above all modes.

[tubeme]

Sorry I don't want to sound like a wining dude but I want to make my final pointer and will never get in this topic.

The hardest thing to sell is the free thing!!!

I spent most of my career in TV and Advertising Production so in the TV business you sell FREE content.

From the user / viewer stand point the decision making on what to buy is a matter of 2-3 second. Then they hit the next channel on the remote and you loose money in the TV business, here in the FC soft we loose dedicated time.

We have to fight other open source free flight control software with the PX4. And even in our case it is a matter of 20 minutes until they install Mission Planner and flash APM. APM to me is a competition! despite we are kind in one group. Also there are at least 2 other very nice and decent open source fc software options.

We are so advanced in many many areas, but at the same time so un-punctual on some details.

[dagar]

@tubeme your idea is to have a dedicated switch that's OFF - RTL - LOITER for use in emergencies right? In an emergency why would you need RTL and Loiter/Hold on the same switch. Wouldn't either do?

How is the simple switch config more overwhelming? You have a single channel for selecting modes. Then you have a set of switches that override. What's missing? If you want more slots in your mode config you can mix switches together. I simply use the GCS to select modes and try to keep the transmitter simple. Most users only use a small set of modes.

Let's try to break this down into something specific, concise, and actionable. As far as the firmware is concerned, my interest is improving the new config, as I don't like the old style, either in configuration, usage, or how it's implemented in software.

[julianoes]

... finally I had a real crash with a real novice person in front of huge audience.

Sorry to hear that, and I do understand your pain.

And that is setup a single emergency 3 pos switch. low position -regular flight, mid position - Hold or Auto Pause, high position - RTL

This should be doable with the "new single switch setup" I believe. The setup should be in a way that whatever you envision / or think is really simple and powerful, should be possible.

I'll do some thinking and reading what could be done.

[LorenzMeier]

@tubeme We're changing the nested switch setup, however, adding to Julian's point: A setup with more than 3 modes is already way too confusing.

The way that normal products are built is to have 3 modes on hardware switches, an RTL switch and the rest of the modes on the screen / tablet.

Typical setup would be:

• POSCTL
• MISSION
• RTL

or with two switches:

• POSCTL
• MISSION
• HOLD

And RTL on/off

In theory you don't even need the mission switch. Just set it to mission using the tablet after uploading it and use the main mode switch to re-take manual control when needed.

We have stopped using the complex mode switching a long time ago and only use the single mode switch exclusively within the core dev team. Everything else is just too consuming and all the other flight modes can be enabled using the tablet.

That is also how most products, e.g. the ones from DJI handle the more advanced modes. You enable them on the screen and you can bail out any time using a HW switch.

[tubeme]

@LorenzMeier Good points!

I really haven't tried the single mode switch extensively. And that is due to the fact that until very recently a month ago it was not possible to take off and land in Pos or Alt ctl. I will definetely dig immediately in your proposed setup. There are also still some problems with landing in PosCtl, actually the land detection for the MC and VTOL, so it is pretty dangerous for me at this point to not have the option of Manual.

This way Lorenz is a very good way of setting up things and is something that I wanted long time ago giving exactly examples in previous discussions with DJI. Also don't forget that I might not want to use tablet and just fly, or as in my case use Professional ground station with a second person dedicated to it. So it is not a good idea for the pilot to rely solely on the presumption that he has to use tablet or phone for flying. So in my opinion there should be some rethinking. Or at least I have to wait for the final idea to fully develop. As a professional controller we have to be aware that there are a lot of scenarios and vehicles for use.

Your examples of setup are exactly how DJI is doing it. and it holds true for VTOL's as well. But I have another problem with this setup and it is with the airplanes.

If we are in Pos or Alt control how do we take of from hand or from airstrip? I did not tried this with FW and I don't have idea what will happen when by default I'm in Pos Ctl? Is it going to allow me to arm? And once I arm is it going to spin the prop trying to achieve min airspeed while in my hand. I have three very nasty cuts to my hands and fingers (one involved going to a hospital) with somehow inconsistent behavior of PX4 in FW (given I use master untested versions). Of course I had cuts from DJI as well and other controllers.

Can I assign switch for take off and landing in FW?

@LorenzMeier when the master speaks, everybody obeys :) but please I have points in what I wrote so we have to be right on the details. And if the single mode switch is the way to go we have to remove the old fashioned setup from QGC and not give the option for it.

[tubeme]

@dagar I will dig deeper in the single mode switch. I really have not tried it extensively and I will do it in the coming days.

While I'm teaching a student I perceive the Hold as a some king of a brake switch. A break that I can explain to them something, or a brake for them to rest for a minute or two until we can continue with what we are doing.

Also RTL involves climbing altitude sometimes 30-60 meters (I setup my return alt to 100m in the city) and maneuvering towards us which I don't like if I want to just have a brake for a minute.

Thanks @dagar @LorenzMeier

[tubeme]

@dagar @LorenzMeier

I don't have a 6 pos switch (i have a rotary 6pos knob which is not good for flight modes), and I could not setup take off and landing for FW with the simple switch. The rest is OK. I will fly it tomorrow this way. May be we could have two simple switches what do you think?

Also there should be some more options for Kill switch for the IC engines.

In two weeks we are flying a 4m IC engine airplane, and I have to make the kill switch setup in Horus, otherwise we could not stop the engine. The problem with IC engines is that the throttle is servo, and each engine - servo combination has its own sweet spot for the engine shut down. This concern the IC Helicopters as well.

There is no way to setup Flaps with the single setup page. For professional use it is a good idea to have the option to control the flap extension with a rotary knob as well or at least as a parameter. But this is optional. For the flaps it is a must to have the time it takes for full extension as parameter as well! The flap extension and timing is very important for airstrip landing.

[LorenzMeier]

We use the 6-pos option with just 3 active / loaded positions. The others remain unassigned.

Your feedback is really good and appreciated. We want to put a particular focus on usability issues in the next weeks so please keep it coming. I am completely aware how important it is.

[AndreasAntener]

Although I'm always arguing for the old style switching, I have to admit that my use case is really tuning an airframe where I'm going through all the modes and also switch directly between different modes. The options Lorenz explained really make a lot of sense for the typical usage. At least with the changed priority in #6764 it should be one step more flexible, also in combination with the single channel switching.

[tubeme]

@AndreasAntener I have the same use case as you. When building and testing new frames etc. I prefer to have all modes and options at my disposal. But I think we have to rethink a little bit more the whole system setup options. I'm rendering some thoughts for the last two days and have some ideas.

@LorenzMeier Your proposed setup is actually a corner case because it is the best one, but for MC. Just tree modes + some additional switches for certain things as transition kill and RTL. A lot like DJI.

Actually for MC I even don't need the Hold mode! it is just not necessary because it equals PosCtl with centered sticks.

Here is another thought i have. DJI already got the niche of one button control for novice users. I use this metaphor taken from the iPhone. The revolution of iPhone was the single button. But in their case they rely on the software developers to implement a back button functionality. It was horrible in the beginning, now they got it right with time (I still hate it so I use HTC). They introduced 2 other functions with time to this one button. Double click bringing a task management, and now they made it as a fingerprint reader. DJI got this lane on the highway, given they sell their drones in Apple stores. Of course because you cannot do more with less they moved most of their control to the iPhone or iPad. Where is the problem? Energy. iPhones and Tablets have limited amount of energy, so cleverly DJI hooked the iPhone or Tablet to their RC with cable for two reasons - 1. energy 2. feed the digital pipeline to the phone or tablet ie Control, Telemetry, Video. This is a very nice and well engineered concept but for now it is limited to MC and pretty short range flights given the pipeline is at 2.4ghz. We cannot compete with them on this. So what are our options? Give more power and functionality for a little bit more advance users. If we create a smarter system with more powerful feature set we can always mimic some simple setup options for the novice i.e. the new setup interface and only 3 modes.

I think the PX4 should have a two flavors in it. One is the powerful professional set and one is the simple use case set.

The thing that boggles my mind is the planes and VTOL. The planes definitely need more modes and options to fly than the MC. This holds true for VTOLs. VTOL is actually a plane! which has the option to take off and land in MC and it does not need all the things related to take off and landing like flaps and landing gear etc. If you make the VTOL with characteristics of a MC then you loose performance.

So our worst case scenario in terms of complexity is the plane. We have to keep the complexity for the plane but at the same time give the options for simplifications if you don't need complexity or if you fly MC. We cannot just remove the old style of setup. We could make it look and feel like the new style but with more buttons.

I don't feel comfortable having to rely on Tablet or Phone for flight! The 500mw telemetry drains my tablet for 30 minutes. We already have 1:30min flight times with the electric VTOL and about 2 hours with electric small planes. For the IC engines we can reach 5-6 hours and we rely on PC ground station.

We cannot create one size fits all solution and we have to concentrate on the main group of people using our product or the prospect buyers we want to get.

So the main questions that we have to ask ourselves are: Who is buying Pixhawk? What for? How do they control it?

In my opinion the real standard set is Taranis or Futaba with Pixhawk because the sbus standard. Or some of the OpenTX alternatives and flavors. And of course some Spectrums. And majority of this users fly APM. Only the more adventurous one go to PX4 and try the QGC and that is pretty logical. This pattern is the same for US and Bulgaria the places where we have information. At both places PX4 does not have a good reputation because - It is too hard to setup and tune!!! This implies that our users are a little bit more advanced users. So we have to bear in mind this fact. Taranis created X7 which will give a good budget option and we definitely can fight this tendency with pure marketing strategies. I have some ideas under my sleeves so when time comes I will bring to your attention a pretty decent marketing strategy that could kick ass.

If we agree that Taranis is the standard and the Airplane is the worst case scenario in terms of complexity and we cannot rely on tablet for now for pure FPV flying we have the following switches for control:

6 - 3 Pos switches 2 - 2 Pos switches 2 - rotary knobs 2 - levers

And from experience I grouped 4 main groups of functionality in different combinations. Not necessary all at once. Depends on the setup.

Flight group - Flight modes, Transition switch. Take Off and Landing group - Take off, Flaps, Landing gear, Parachute, Landing Emergency group - RTL, Hold - for FW and VTOL (Loiter), Engine Kill - IC or electric Video Cam or Instrument control - Pitch, Roll, Yaw, Rec, Cam Switch.

That is for the modes and switches.

So I chose Android as an option because of the back button.

So the real question is 1 button vs. 3 Buttons, iPhone vs. Android.

How do we give as much power to the user with least amount of buttons, but definitely not one. If they want one then fine use the simple switch setup. But most likely they will want more than one, because the main user group is the advanced one. I have no answer to this question yet. I just give you some thoughts out loud.

This is off topic but we have to see all the use cases in order to sort out all the options and the best trends for development.

I think that there is still a lot of business for the OSD! I know a lot of people that want to just fly without PCs, GSs or tablets - advanced hobbyists. They fly one of the most popular OSD FCs. The Vector. Because it has the best OSD. This is if we start to make a specialized small hobby versions of the Pixhawk PX4 products.

I started playing with one very unsupported and neglected OSDs because I hate the ugly look of MinimOSD. It is called PlayUAVOSD. It is an abandoned Open Source project (because the creator just had other things to do and abandoned it) with a VERY VERY powerful hardware base (ARM ST32F405). Then another guy Tobias made a fork of it but he again is not dedicating time to it. It looks perfect and is not bound to the ugly Fonts of MinimOSD. It visualizes the mission, has a 2 Cam input and you can switch 3 views that are totally configurable. In the future if there are some volunteers we can make our own fork and polish the thing. Still lacking some visuals like icons etc. Somebody made corrections for PX4 mode names so it is in sync with PX4. I'm not a dev so I could not do it.

The original project:

https://github.com/PlayUAV/PlayuavOSD

the Tobias Fork:

https://github.com/TobiasBales/PlayuavOSDConfigurator

[tubeme]

If we create a tailored version toward TV and Film production which includes modes that combine flying patterns + cam control patterns we will kill the competition ! I can help a lot in this direction.

[tubeme]

Here is an idea:

We don't have a simple or complex setup switch page. We have just one that looks like the current simple switch setup page. We have 4 types of switches 6 pos, 4 pos, 3 pos, 2 pos and a slider. We make this 5 templates for switches. 4 of these templates look like the current 6 pos switch but with 6, 4, 3 and 2 positions (drop downs). And the slider template is just 1 drop down.

So in reality when we have all the switches OFF we are in the default mode and default switch setup.

The minimum setup could be for MC

1 - 3pos template with three 3 drop downs (this will have label MODE SWITCH) by default the 3 modes could be Position, Stabilized, Mission) 1 - 3pos template with 1 empty (OFF) position + 2 drop down. The last drop down will have RTL by default (label could read EMERGENCY SWITCH)

Then a + button. Once you hit a + you will be given the choice to add a 6, 4, 3, 2Pos switch or Slider. Then it will add the template for a switch and you will choose a channel for it as well with position 1 empty (OFF state) and some drop downs to choose modes. (in the additional switches you will have always position 1 as empty (OFF))

This way I can add as many switches as I want and dedicate whatever modes or functionality as I want. So we go from simple to complex depending on my needs.

For VTOL the default should be the same as MC but with the exception of one additional mandatory default switch.

1 - 3pos template with three drop downs (this will have label MODE SWITCH) by default the 3 modes could be Position, Stabilized, Mission) 1 - 3pos template with 1 empty (OFF) position + 2 drop down. The last drop down will have RTL by default, here by default we could add the Hold (Loiter) as a mid position drop down (label could read EMERGENCY SWITCH) 1 - 2 pos template with 1. MC; 2. FW here you have no choice with drop downs (label could read TRANSITION SWITCH)

then again a + button so I could add mode switches and program them as I like.

For the FW we have the same as VTOL but with a little different modes order and without the transition switch:

1 - 3pos template with three drop downs (this will have label MODE SWITCH) by default the 3 modes could be Stabilized, Position, Mission) 1 - 3pos template with 1 empty position (OFF) + 2 drop down. The last drop down will have RTL by default, and Hold (Loiter) as a mid position drop down (label could read EMERGENCY SWITCH)

That is it. Simple, elegant and scalable . Going from simple to complex.

The only problem I see is the priorities... if we have two of the secondary switches turned on.

But if we use the grouping I made from the previous post we can sort out the priorities.

IE emergency should always have priority over modes. Kill switch RTL Hold

Landing and take off also should have priority over modes.

flaps and gear can be turned on all the time without priority.

If we added 3 flight mode switches then the second switch can have priority over the first one and the third one over the first two.

For example 1 mode switch - Stabilized, Position, Mission 2 switch OFF, Manual

So once in a wile I might want to check how is my CG and flip the second switch for a moment and then flip back to return to Stabilized.

5 templates in 3 categories - Mode switches, Emergency switches, Functional switches.

In each category the switches priority is determined by their order. 1,2,3 and so on. The larger the number the higher priority, if we don't see index numbering then the priority goes from left to right. Emergency switches will have higher priority than Mode switches. The functional switches will work in parallel to the other two categories. They will not have a priority. We should be able to move around the switches to reorder the priorities. The moving could be done in a WYSIWYG manner.

[tubeme]

If you like my idea i have another suggestion.

It is very impractical and I never used it (even when I was novice to PX4) to calibrate and assign switches in the calibration page. I proffered to do it in the Parameters, when there was no switch setup page.

Just remove the calibration of buttons and sliders from the calibration page. Usually at this stage you don't know yet what are the options and assignments etc. so omit this step there. This will make the calibration page more simple and straight forward.

And then add a simple button on the switch template which reads "Calibrate switch". If you see there are some inconsistencies or miss alignment then hit "Calibrate Switch" Click, Click, OK - boom you are done. simple on the spot. There might be only one or two switches that have problems... No need to calibrate all the switches.

[julianoes]

@tubeme Wow that a lot of reading for one to do :).

Trying to step back a bit. I'm going to ignore Android vs. iPhone and focus on the current RC gear that is out there right now and we need to live with. While autonomy is generally increasing, RC use and switch complexity will go down.

What problem are we facing?

• Users with different RC hardware, software, and configuration (1 switch to 1 channel, n switches mixed to 1 channel, etc.)
• Different flight modes, emergency modes, special features like kill switches, flaps, etc.
• Users with vastly different wishes (fixedwing tuning requiring all the modes, multicopter flying in POCTL plus RTL, POSCTL and all the mission functionality, ...)

There is no way we can come up with a switch model or hierarchical representation ever which captures all of these options! So what can we do?

What can we do?

Well, we have to offer the possible settings and let the user combine his wishes with his RC setup. That's also what the "new setup" tried to accomplish. The setup in QGroundControl needs to be very simple so that a user is aware of what the settings are and can verify it works (and will work when he/she needs it). If there any inconsistencies or conflicts, they need to be detected right then!

What do we have now?

Looking at the current two implementation, I see the following problems:

(Old) switch setup:

• The hierarchy is not appearant which can lead to the case that we're discussing here. However, some hierarchy is needed because otherwise the precedence is not given and you don't know if the mode switch or the "loiter/hold/pause" switch is more important (or intuitive, or safe?).

(New) single switch setup:

• The flight modes are set in 6 discrete steps. Why 6? It's tedious to get this matching.
• What is the precedence of the "Switch Settings" in relation to the flight mode? It is not appearant from the UI in QGroundControl. Why is it a single switch setup if there are additional (mode) switches like "Offboard" and "Return"? It boils down to be the same as the multi switch setup just with 6 instead of 3 options for the mode switch.

The exact problem that we're discussing in this thread is that there are different views and implementations of what the hierarchy should be right now:

• My was always that the hierarchy should be by levels of autonomy, meaning that loiter and RTL should only be available in AUTO. Back in the days I was reluctant to have RTL to have precedence over everything! Why? Because it is actually inconsistent with e.g. loiter (which is what you ran into). This being said, I do understand that this is confusing to a user and therefore not something to continue having the future!

• Your view is (as I understand it), that emergency switches should always have precedence. Sounds good, so what should happen if you engage both RTL and Pause? Should it pause the RTL or RTL the pause? What about LAND? What if you issue RTL in QGC and have a switch in Pause? With QGC in the loop it gets even more confusing. Also note that emergency switches conflict with the manual override which always has precedence anyway, at least for fixedwing.

How could we resolve this?

• Have Pause and Land to have precedence over the reset, except RTL which is suggested by @tubeme, @AndreasAntener and check and test that for edge cases.
• Or I have one crazy idea: Remove all hierarchy and just listen to the last switch that has been changed or the last command issued by QGC?

[tubeme]

@julianoes :) Sorry I just got carried away a little...

I understand your point about nesting in the current implementation. And yes it is logical that the RTL and Hold should be part of auto modes from development stand point.

But from user stand point everybody is thinking in a different way. And everybody has its preferences and different needs about mode and functionality priority from pilot / user stand point. So it is a good idea to have e dynamic setup and prioritize the setup to their liking.

I thought about your idea to listen to the last command. It is not crazy and I like it. My worry is that it will be very complicated to develop and there might be some other problems but I like it a lot.

Also while I agree that with the increase of autonomy we will reduce the flight mode options in terms of basic modes. But we will increase the scenario flying options. So pretty much the complexity of RC switches will be the same. Just the switching will move from basic mode flying to scenario flying. Like we added Take Off and Landing and Follow. We will add in the feature things like go here do this and that and we will still need the rc switches to cover this scenarios. We are still far away from the point where we will not need RC. This holds true especially for professional use. Some special professional users are very conservative in their procedures and they are very slow in adapting the new ways of doing things. So the RC is here to stay for a while.

[tubeme]

BTW rethinking the modes now, it is a good point you have about what has the priority QGC or the RC?? And then if I have connected Joystick in the QGC what has the priority?? QGC RC or the Joystick??

Given this your idea about what is last has the priority sounds pretty good to me. You touch the Joystick it has the priority. You touch the screen QGC has the priority. You move the RC it takes control.

[tubeme]

Something about the Emergency. Now we are thinking about only two options for emergency. Hold and RTL. But in the future we can add other emergency scenarios. Like go to Reserve Airport. Go to data link loss Loiter spot 1 etc. We have a collision emergency do this and that. So we have to prepare the system to accommodate all this emergency scenarios and give the user the flexibility to prioritize this options as well.

[tubeme]

My basic idea in two words is go from flight modes priority and nesting to control and switch priority.

Some people might like RTL to have the ultimate priority, while others might like Hold to have the ultimate priority.

Empower the advanced user if he know what he is doing, but at the same time make a predetermined safe simple set for the novice with priorities you think are the safest one, so he could not make a damage to himself or others.

Sometimes users can use your product in a totally unexpected ways that you never thought of and get their job done with your product.

In terms of safety for example I don't like that for a new PX4 board there is no RC fail-safe option preset by default. It is Disabled by default. Which means that the novice could see that there is RTL switch preset in the flight modes page and omit the fail-safe options page, thinking he has RTL as fail-safe enabled. He will fly with this presumption and will find out the truth once he looses the RC link (I've done this mistake despite I'm advanced user). Imagine what will happen if he is in Altitude or Position at that moment and does not have tablet or QGC connected... At least one fail-safe option should be enabled by default.

I don't want my product to be in the news with a bad rap. So safety should be the mantra for the next couple of years. My partner and friend told me the other day "The time is close, that a carbon machine will get in to the airplane jet engine, I pray I will not be in this particular airplane at that time".

[tops4u]

Hi People,

this quiet a lot to read and understand. My current concern with this matter is the following. I'm one of the specialists having a 3 & 2 Pos Switch mixed together to one RC Channel in order to get 6 Positions. This allows to skip some of the discrete steps. As they are currently all freely assignable in the single Channel Mode Assignment, I assumed this should not cause any Problem. With my setup it is i.e. possible to switch directly from PosCTRL to Pause/Loiter. I was working with this setup since FW 1.2 and have never had any trouble with it - but I did not use Loiter much.