My first point is a question: Who is managing the software side of the MultiWii project? Is this forum the place to discuss and coordinate the development effort of the project?
My second point has to do with the implementation of Fail Safe in the current MultiWii software version. I've read the previous discussions about this topic and believe that all points are valid but don't apply for all possible scenarios, which is the reason for the apparent disent.
My understanding is that the current failsafe is all controlled by the following section of the code, which of course triggers behavior elsewhere to perform the actual control actions on the aircraft:
Code: Select all
#define FAILSAFE
#define FAILSAFE_DELAY 10
#define FAILSAFE_OFF_DELAY 200
#define FAILSAFE_THROTTLE (MINTHROTTLE + 200)
I see the following opportunities to improve the existing code and strategy so far:
- Separate detection of the failsafe condition into a configurable, well encapsulated component. I'm toying with the idea of implementing what I call a virtual aux channel (vAUX from now on) that is triggered HIGH or LOW based on the current detection algorithm. So, if no activity in CH1 to CH4 is detected in 1 second, vAUX goes high. Upon detection of the signal returns, vAUX goes low.
- Proper encapsulation of the failsafe behavior. IMO, the failsafe behavior should be treated in the same way "GPS HOME" or "GPS HOLD" are.
Thinking about the GUI, there would be a new action "FAIL SAFE" besides "GPS HOME", "GPS HOLD", etc. There would also be a new channel available (vAUX or whatever label is chosen for this). The user then would be able to choose what action to take in the event of activating the failsafe condition. Moreover, the failsafe condition could also be attached to a regular AUX channel to allow for testing in the cases that this makes sense.
In the MultiWii codebase, the failsafe action could become much more aggressive (ie, the current action -- albeit I also intend to try and program a safer controlled descent using onboard baro and GPS data). The failsafe code could wait until the aircraft is within the home waypoint before activation (or directly activate in case there's no waypoint). This gives the pilot the option to activate both "GPS HOME" and "FAIL SAFE" when vAUX goes HIGH to effect what I believe is a reasonably safe return to home, while at the same time allowing for a controlled descent or shutdown when this is considered the preferred approach.
In my opinion this change makes a lot of sense because it allows the pilot to configure the intended behavior while preparing to fly, possibly at or near the effective home position where he can be more aware of any conditions in its surroundings. It would also allow for selection of a failsafe strategy that makes sense for the specific situation (ie, turn off all motors vs return to home and land vs slow descent vs ...). With these changes we would be moving the task of configuring the fail safe operation from something you do at compile time to something done on the field.
I will be writing the code for this, but would like some coordination with whomever is working with the code at the moment so that changes can be properly tested and merged into the code base. I'll appreciate comments about the above points.
Best regards