ardupilot
ardupilot copied to clipboard
ArduPilot
Add 'soft' LOG_BACKEND_TYPE option
Issue details
As discussed here: https://github.com/ArduPilot/ardupilot/commit/268d6523e9c76e0e316bad0d2472c987a431d91d
If LOG_BACKEND_TYPE is set to 3, and a mavlink connection is not present for whatever reason, then PREARM fails. It would be very nice and user friendly to have another option to skip the PREARM fail if the mavlink connection fails, particularly as this setting requires a firmware reboot to activate. And in this case, it would also be user friendly to have this new setting by default, so logging to an attached device such as companion computer is automatic, if one is connected.
Version
All
Platform
[ x ] All [ ] AntennaTracker [ ] Copter [ ] Plane [ ] Rover [ ] Submarine
On Tue, 28 Nov 2017, Fnoop wrote:
If LOG_BACKEND_TYPE is set to 3, and a mavlink connection is not present for whatever reason, then PREARM fails. It would be very nice and user friendly to have another option to skip the PREARM fail if the mavlink connection fails, particularly as this setting requires a firmware reboot to activate. And in this case, it would also be user friendly to have this new setting by default, so logging to an attached device such as companion computer is automatic, if one is connected.
I can't see us changing the default behaviour; people not having logs when they were expecting them is a terrible thing.
Perhaps we could have a bitmask LOG_BACKEND_CHK (or LOG_BACKEND_IGNCHK) which allows a backend to not be working for arming to proceed?
Explaining a LOG_BACKEND_TYPE=4 being a mavlink backend which doesn't matter for arming purposes would be interesting in the parameter description!
I do agree that it's important for people to get logs when they're expecting it. But it should also important for ardupilot to be user friendly and provide a good out of the box experience. A mode like proposed 4 (mandatory SD card, optional mavlink) still fails prearm if you're not going to get any logging, it just would check to see if there is an attached mavlink logger and use it as well if available. If this was made the default, it wouldn't make any difference to the current default behaviour, except to be more user-friendly to mavlink loggers out of the box.
Or the bitmasks that you suggested are another good idea, although bitmasks tend to confuse regular users unless they're presented nicely in the GCS.
There have been quite a few people confused by all this (myself included, even though I've hit it several times now!), there's clearly room for improvement. A lot of people working with companion computers tend to change equipment a fair bit, hard failing prearm checks due to what could be an optional non-flight component is not ideal - as I pointed out on the commit discussion, it's the only non-flight check that does this.
In addition, the parameter needs a reboot to take effect, can this be fixed?
On Wed, 29 Nov 2017, Fnoop wrote:
There have been quite a few people confused by all this (myself included, even though I've hit it several times now!), there's clearly room for improvement. A lot of people working with companion computers tend to change equipment a fair bit, hard failing prearm checks due to what could be an optional non-flight component is not ideal - as I pointed out on the commit discussion, it's the only non-flight check that does this.
Yep, we seem to need to do something here.
It would be trivial to actually tell the user which backend is failing periodically - perhaps, if the user has multiple backends specified we just emit a statustext message indicating which are failing? That would tell you pretty much straight away what's going on.... and it keeps the configuration simple....
In addition, the parameter needs a reboot to take effect, can this be fixed?
I considered that, too, today, when you brought it up.
These are the largest allocations we make in the system, and chopping-and-changing them may lead to bad stuff happening. Particularly if you go from a large buffer size to a larger buffer size, you may simply not have the contiguous memory to do that allocation. I guess we could just force a reboot at that point.... Let's put it down as "something to experiment with".
As I've participated in the discussed in the linked commit, I'll write my opinions again:
- I disagree with @fnoop that letting a MAVLink backend fail by default is more user friendly, I would say that's the opposite, if a user turns it on he wants it to work
- this might be the only non-flight check, but it's one we want to have, it's as important as the flight checks
- I strongly oppose using the LOG_BACKEND_TYPE for checking the health, if we ever add a new backend type it will be a mess
- in the commit discussion I proposed a new LOG_BACK_HEALTHY parameter that would be a bitmask saying which backends to check for health; I still think this is the best solution
Could this be added to the existing LOG_BITMASK parameter instead of making a new one? Just have a bit for mavlink optional and file optional. If set for optional, it won't fail the arming check.
I disagree with @fnoop that letting a MAVLink backend fail by default is more user friendly, I would say that's the opposite, if a user turns it on he wants it to work
It depends on your point of view and use case. If you're flying a $10,000 camera ship and it goes down in flames and the logging wasn't working, you'd be a little annoyed, I grant you that. And there are plenty of Ardupilot users that fall into that category, and I completely understand that erring on the side of caution is a Good Thing. But there are also lots of hobbyists/newbies/fun flyers who either just want to plug something in and have it work, or struggle to follow all the setup necessary. Adding more checks that prevent it from taking off makes less experienced users more likely to just turn prearm checks off - a bit like forcing complex passwords that have to be changed every x days makes a lot of people just write it on a post it and stick it to the keyboard, or give up on using the features they want to use. One suggestion I was making was simply to add optional mavlink logging as the default, in addition to the current mandatory SD card logging. This doesn't detract from the default security of mandatory SD logging, but does offer additional mavlink logging if something is connected, without having to do any extra configuration - that is being user friendly. If this is too confusing, or compromising the security of the logging checks outweighs the usability of optional checks based on the greater experience than my point of view, that's absolutely fine. I'm simply raising an issue to put forward a problem that I've seen on numerous occasions.
I strongly oppose using the LOG_BACKEND_TYPE for checking the health, if we ever add a new backend type it will be a mess in the commit discussion I proposed a new LOG_BACK_HEALTHY parameter that would be a bitmask saying which backends to check for health; I still think this is the best solution
This makes sense, I agree with this!
Is there still interest in this? It seems to me that if you want logging you should not be allowed to arm. I'm not sure any of the hobbyists/newbies/fun flyers would even be using the MAVLink log backend?
