Contributing Software + An approach to Fail Safe

Post Reply
fokat
Posts: 4
Joined: Tue Jul 15, 2014 12:38 am

Contributing Software + An approach to Fail Safe

Post by fokat »

Hi there,

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:

  1. 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.
  2. 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

User avatar
haydent
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: Contributing Software + An approach to Fail Safe

Post by haydent »

in a way this already exists with modern tx controllers and this likely why the existing code has not been developed much further. as you can set your rx failsafe so it reverts back to pre chosen state on signal loss. eg you can make an aux channel default to RTH on signal loss.

you will find other threads of users developing more advanced RTH features to better support safe return

there is a mix of members who have access to add new code to multiwii and there would be certain members focused on different areas, you will find details of them in the svn logs

also you can try to get discussion and interest going here for getting changes made though it can be hit and miss depending on the topic

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Contributing Software + An approach to Fail Safe

Post by scrat »

@fokat: This is how it is done in UAVx project I think. So this is working with original Turnigy Rx which doesn't support failsafe. But time is not 1 sec but is 10sec.

@haydent: Yes this is ok till Rx is working and is connected to FC. But what about if Rx stops working or maybe cable from Rx to Fc disconnects?

edit: I support that kind of patch. Not just MultiWii - Baseflight too.

User avatar
haydent
Posts: 583
Joined: Sun Jun 17, 2012 1:35 am
Location: NSW, AU

Re: Contributing Software + An approach to Fail Safe

Post by haydent »

sure that is possibility that i thought of too, and i guess it is a matter of how much time someone wants to put into it vs the need. good to have as comprehensive system as possible. but what if your lipo plug disconnect ? or a esc wire... there are many points of failure

scrat
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: Contributing Software + An approach to Fail Safe

Post by scrat »

haydent wrote:sure that is possibility that i thought of too, and i guess it is a matter of how much time someone wants to put into it vs the need. good to have as comprehensive system as possible. but what if your lipo plug disconnect ? or a esc wire... there are many points of failure


I agree.

Post Reply