Today I configured Herelink and Solex based on the latest release.
As recommended in the current guide, I configured the vehicle’s mode switches in Solex (four different modes) using two buttons (short and long click actions) and set FLTMODE_CH: to 0 on ArduCopter (4.0.3).
My concern is that due to packet losses in communication the MAVLink command may get lost. Is there any kind of retry strategy?
The previous way of mapping click actions to PWM timings transmitted via SBus looks more stable to me as this signal gets transmitted repeatedly as long as there is no further click setting a different value.
So I tend to continue using the button -> SBus channel values configuration in the general settings app instead of the button -> MAVLink command configuration in Solex.
Is there any argue against my concerns coming from the developers?
To be honest, the classic two state / tri state switches / potis (with defined positions) on remote controllers like FrSky Taranis seemed more intuitive to me and gave better control especially in stress situations.
The issue is using Sbus should you have an RC crash or reboot your mode could be switched to the default position with no user input.
Because these are buttons and not physical switches upon boot their state has to be set to the default position.
This means you could have the default as stabilised and then be flying in loiter. If you had a RC crash or reboot the craft would be told to enter Stabilised with out our input.
This can not happen in Mavlink, as you have said it’s a single command and as such no update is sent and also no change state is sent and as such you would not have an uncommanded mode change.
The chances of a Mavlink mod change being missed is extremely low and even if you did it would be something you would see and could correct. It’s much more desirable behaviour than an uncommanded mode change with using Sbus though.
I really don’t see a missed Mavlink command being a common thing overall.
The only other thing I will say is if you were using Sbus then RTL should be the default position for the button resting for safety but again it’s not advised for main mode selection.
The overall advice is to have mode selection on Mavlink with a single button on Sbus set to RTL and that being the default boot config.
Thanks for your elaborately reply and clarification about the result on the SBus channel state in case of (some kind of) remote crash.
This also leads into the question, what kind of crashes we can have on Herelink and how they affect the control of such a substantial function like the vehicle mode. On one hand, we have crashes of the Solex app (and I already saw these on the first day of testing after an initial installation with latest firmware/software). On the other hand, we can have crashes of background services used by the app or the whole Android system at all (at least the latter is quite unlikely).
The chance of missing a MAVlink command simply depends on your link quality which drops down below 100% quite fast, if you do not only make bench tests (Mission Planner uses the relation of received to total expected packages as they are usually consecutively numbered). So at a link quality of 80%, the chance of a dropped command is 1:4 when there is now strategy implemented for repeated transmission in case there is no result-check after setting the command.
Defining “RTL” as initial state on restart is also not always a good idea e.g. in case parts of the mission are carried out in “Auto” or “Guided” mode. I am pretty sure, you would NOT want to get an interrupted mission only due to an app crash on your remote.
Sorry to say that, but in my opinion using push buttons which “forget” their state in case of “crash” is not a good idea for a mode switch with that substantial functionality (and I saw many others complaining about that). Both approaches (mapping to SBUS / PWM or sending MAVLink commands) have their flaws.
I don’t see how it’s an elaborate reply ? It’s the facts of the how the system works.
App crash would not trigger Sbus state to change, only a device crash would. As for likely hood wel this is down to safety and issue mitigation.
Yes the system is not perfect, no system is, it does not have physical switches therefor their is inherent differences in how it has to behaves on switches.
Yes it’s possible you could have a last state stored For Sbus however that could get lost in a device crash as or not be recorded correctly should the crash actually happen at the time of changing the state.
This why Philips advice is to use Mavlink as it’s overall safer for mode change as it’s predictable in a failed state.
As with all systems there are limitation and the advice that was given is based on that, while a craft exiting a mission on a device reboot into RTL may not be desirable it’s far better than a craft being lost due to mode change the user did not ask for.
Also with regards to lost Mavlink commands, a change is commanded that change and if it did not happen he would see that he can command it again. At worst that simply pressing a button again. An uncommanded mode change on Sbus could result in a loss or worse.
Are you seeing losses of Mavlink commands or is this simply a theoretical issue ?
The reality here is that as there is no physical switches the software buttons behaviour has to be accounted for.
It’s entirely up to you if you want to use Sbus or Mavlink for mode selection however the reason they are saying to use Mavlink is because of the above.
If you feel the risk of Mavlink being more unreliable than Sbus then you do what you feel is right.
Thanks once more. As I am not a native English speaker, we may have different interpretations about “elaborate”
Of course it is up to the users to decide which approach could match their use case better. At least, the explanations, pros, cons, risks and examples given in this discussion may help to find that decision.
It is in the nature of radio transmission that packet losses have to be taken into account.
Time will tell if the concept of more stateful switches/buttons/potis etc. should be rethought with Herlink2 / Herelink+ / Herelink Pro etc.
