RFC: move default pin for FAILSAFE from throttle to roll?
RFC: move default pin for FAILSAFE from throttle to roll?
Hi,
for failsafe detection, MWii monitors the signal it gets from RX on one arduino pin that receives the RX throttle signal.
With Spektrum gear, the failsafe detection on the throttle pin does not work, because all/most Spektrum receivers continue to emit last known signal on the throttle pin upon rx failsafe. So if one wants MWii to detect a Speltrum RX failsafe condition the failsafe code has to monitor other than the throttle signal. It then works as expected.
Status:
We have a define for the failafe pin, the default is set to throttle pin (for historical reasons). With this configuration MWii cannot detect Spektrum RX failsafe conditions. Spektrum users have to change the definition for the failsafe pin.
Question:
does it break failsafe for other configurations/RX/Setups, if we move the default away from throttle to the roll pin?
As I have no experience with other rx brands, ppm/sbus/spektrum-sattelite, I ask for your comments.
Cheers.
for failsafe detection, MWii monitors the signal it gets from RX on one arduino pin that receives the RX throttle signal.
With Spektrum gear, the failsafe detection on the throttle pin does not work, because all/most Spektrum receivers continue to emit last known signal on the throttle pin upon rx failsafe. So if one wants MWii to detect a Speltrum RX failsafe condition the failsafe code has to monitor other than the throttle signal. It then works as expected.
Status:
We have a define for the failafe pin, the default is set to throttle pin (for historical reasons). With this configuration MWii cannot detect Spektrum RX failsafe conditions. Spektrum users have to change the definition for the failsafe pin.
Question:
does it break failsafe for other configurations/RX/Setups, if we move the default away from throttle to the roll pin?
As I have no experience with other rx brands, ppm/sbus/spektrum-sattelite, I ask for your comments.
Cheers.
AW: RFC: move default pin for FAILSAFE from throttle to roll
Wouldn't the easiest solution be a checkbox for failsafe? That way any user with spektrum or other failsafe receivers can define this condition in their receiver (as failsafe settings). E.g failsafe is checked on aux 4 high and the user has set the failsafe conditions for the receiver to aux4 high. When failsafe of the receiver kicks in, aux4 is set high and multiwii failsafe starts it's work
Re: RFC: move default pin for FAILSAFE from throttle to roll
what you describe is a workaround.
It requires
+ new code to be written
+ all Spektrum users enable this chechbox item for every MWii controller.
With current code they could change the failsafe pin define.
What I propose is a change of the existing default and be done with it for everyone for ever.
It requires
+ new code to be written
+ all Spektrum users enable this chechbox item for every MWii controller.
With current code they could change the failsafe pin define.
What I propose is a change of the existing default and be done with it for everyone for ever.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: RFC: move default pin for FAILSAFE from throttle to roll
I suggest to move to roll and remove the option in define. (no need to over complicate options)
Re: RFC: move default pin for FAILSAFE from throttle to roll
Is this OK for PPM users using PPM in on throttle. I suspect there are a fair number out there
Re: RFC: move default pin for FAILSAFE from throttle to roll
so can we do this:
1. we move the default define for failsafe pin to roll
and
2. if we see a define for ppm then in def.h change the failsafe pin define from roll to throttle?
1. we move the default define for failsafe pin to roll
and
2. if we see a define for ppm then in def.h change the failsafe pin define from roll to throttle?
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: RFC: move default pin for FAILSAFE from throttle to roll
Hamburger wrote:so can we do this:
1. we move the default define for failsafe pin to roll
and
2. if we see a define for ppm then in def.h change the failsafe pin define from roll to throttle?
The best way is first to check if it's ok for PPM sum.
I think it's ok.
no need to overcomplicate the code just to avoid a check
Re: RFC: move default pin for FAILSAFE from throttle to roll
ok, so we got two open cases that need investigation:
- spektrum sattelite
- ppm
As I have neither, anyone care to test and report?
I'd be willing to apply the code change on that basis.
- spektrum sattelite
- ppm
As I have neither, anyone care to test and report?
I'd be willing to apply the code change on that basis.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: RFC: move default pin for FAILSAFE from throttle to roll
i will check ppm tonight.
btw failsafe is handled sifferwntly for each system. so why the eorries for ppm?
btw failsafe is handled sifferwntly for each system. so why the eorries for ppm?
-
- Posts: 506
- Joined: Thu May 05, 2011 8:13 am
- Location: Slovenia
Re: RFC: move default pin for FAILSAFE from throttle to roll
Just my 2cents:
1. Does the code looks for decoded PPM signal (example: Throttle) or just for interrupts on Throttle pin?! If is second it doesn't work for Spectrum SUM since it will always detect signal from Throttle.
2. Spectrum RX (normally) outputs TH value that is set (sampled) at bind time, so it can be arbitrary value (normally it is minimum TH).
2.1. If you bind your receiver before setting endpoint from 1000 to 2000 in TX than RX in failsafe will output around 1100.
Regards Andrej
1. Does the code looks for decoded PPM signal (example: Throttle) or just for interrupts on Throttle pin?! If is second it doesn't work for Spectrum SUM since it will always detect signal from Throttle.
2. Spectrum RX (normally) outputs TH value that is set (sampled) at bind time, so it can be arbitrary value (normally it is minimum TH).
2.1. If you bind your receiver before setting endpoint from 1000 to 2000 in TX than RX in failsafe will output around 1100.
Regards Andrej
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: RFC: move default pin for FAILSAFE from throttle to roll
Hi,
you can turn off failsafe of spektrum receivers. So it would behave like a normal receiver on tx loss.
nils
you can turn off failsafe of spektrum receivers. So it would behave like a normal receiver on tx loss.
nils
-
- Posts: 506
- Joined: Thu May 05, 2011 8:13 am
- Location: Slovenia
Re: RFC: move default pin for FAILSAFE from throttle to roll
jevermeister wrote:Hi,
you can turn off failsafe of spektrum receivers. So it would behave like a normal receiver on tx loss.
nils
How do you do that?
Re: RFC: move default pin for FAILSAFE from throttle to roll
Hamburger wrote:ok, so we got two open cases that need investigation:
- spektrum sattelite
- ppm
As I have neither, anyone care to test and report?
I'd be willing to apply the code change on that basis.
Spektrum satellite and Futaba SBUS code do not care about specific channel. If FS is enabled it only checks that full frames are received. See Danal's answer here.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: RFC: move default pin for FAILSAFE from throttle to roll
Back from the workbench:
I tested the new failsafe parameters with my Turnigy TR6A 6 Channel RX with sum ppm.
I first set it to throttlepin and tested it: Failsafe was activated as expected after turning off TX plus guard time and was deactivates as soon as I turned o TX
I switched to Rollpin and it did the same.
So for my configuration everything seems OK.
GO GO GO!
Nils
I tested the new failsafe parameters with my Turnigy TR6A 6 Channel RX with sum ppm.
I first set it to throttlepin and tested it: Failsafe was activated as expected after turning off TX plus guard time and was deactivates as soon as I turned o TX
I switched to Rollpin and it did the same.
So for my configuration everything seems OK.
GO GO GO!
Nils
Re: RFC: move default pin for FAILSAFE from throttle to roll
thanks for checking.
So I understand it is safe to move failsafe detection from throttle to roll pin. Will implement (and remove config define) because it is no longer needed.
Kudos go to ThOrsten for finding out about the roll pin for throttle and his initial implementation.
So I understand it is safe to move failsafe detection from throttle to roll pin. Will implement (and remove config define) because it is no longer needed.
Kudos go to ThOrsten for finding out about the roll pin for throttle and his initial implementation.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: RFC: move default pin for FAILSAFE from throttle to roll
hi
be advised that I can only spwak for my configuration.
can you please add a description in code where i can change it?
btw.: it is very sad to see that a lot of people tly their gear without reading anything about it. very few people lnow what failaafe does or how the find me alarm works.
nils
be advised that I can only spwak for my configuration.
can you please add a description in code where i can change it?
btw.: it is very sad to see that a lot of people tly their gear without reading anything about it. very few people lnow what failaafe does or how the find me alarm works.
nils
Re: RFC: move default pin for FAILSAFE from throttle to roll
Hallo,
As I am currently involved in implementing the Spektrum-Expander solution (make 12 channel out of a DX7/8) known from mikrokopter I am also dealing with the decoding of the spektrum satellites serial signal.
If you use the direct three wire connection the decoder software already recognizes a missing rc link and by setting the failsafeCnt on the completion of each rx frame.
Otherwise the current implementation of the 3 wite Satellite solution just repeats the last value in rdData[], which you can easily verify in the gui.
So @hamburger if you use the 3 wire solution it IMHO makes no sense to change the pin because the pin is only monitored for standard rx. Spektrum, promicro, SBus and Serial sum PPM don't use the pin supervision.
As I am currently involved in implementing the Spektrum-Expander solution (make 12 channel out of a DX7/8) known from mikrokopter I am also dealing with the decoding of the spektrum satellites serial signal.
If you use the direct three wire connection the decoder software already recognizes a missing rc link and by setting the failsafeCnt on the completion of each rx frame.
Otherwise the current implementation of the 3 wite Satellite solution just repeats the last value in rdData[], which you can easily verify in the gui.
So @hamburger if you use the 3 wire solution it IMHO makes no sense to change the pin because the pin is only monitored for standard rx. Spektrum, promicro, SBus and Serial sum PPM don't use the pin supervision.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: RFC: move default pin for FAILSAFE from throttle to roll
I have not verified that Failsafe is working on a Mega with PPM enable, anyone aware if Failsafe works on the Mega Serial port?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: RFC: move default pin for FAILSAFE from throttle to roll
copterrichie wrote:I have not verified that Failsafe is working on a Mega with PPM enable, anyone aware if Failsafe works on the Mega Serial port?
didn't you read my post`?
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: RFC: move default pin for FAILSAFE from throttle to roll
jevermeister wrote:
didn't you read my post`?
I read a number of them, care to be more specific?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: RFC: move default pin for FAILSAFE from throttle to roll
Back from the workbench:
I tested the new failsafe parameters with my Turnigy TR6A 6 Channel RX with sum ppm.
I first set it to throttlepin and tested it: Failsafe was activated as expected after turning off TX plus guard time and was deactivates as soon as I turned o TX
I switched to Rollpin and it did the same.
So for my configuration everything seems OK.
GO GO GO!
Nils
I tested the new failsafe parameters with my Turnigy TR6A 6 Channel RX with sum ppm.
I first set it to throttlepin and tested it: Failsafe was activated as expected after turning off TX plus guard time and was deactivates as soon as I turned o TX
I switched to Rollpin and it did the same.
So for my configuration everything seems OK.
GO GO GO!
Nils
Re: RFC: move default pin for FAILSAFE from throttle to roll
I just crashed a copter because one of the 6 channel wires between RX and MWC broke during flight.
Unfortunately it was not the roll channel, so failsafe had no chance to know about this loss of control.
So how about we extend the current failsafe test to test at least the first 4 channels (roll, pitch, yaw, throttle) for failsafe condition?
NB: please do not tell me to use PPM in the first place, as most Spektrum rx do not provide it.
Unfortunately it was not the roll channel, so failsafe had no chance to know about this loss of control.
So how about we extend the current failsafe test
Code: Select all
if (mask & 1<<FAILSAFE_PIN && dTime>985) {
NB: please do not tell me to use PPM in the first place, as most Spektrum rx do not provide it.
Re: RFC: move default pin for FAILSAFE from throttle to roll
Why not. In this case really no failsafe pin configuration is needed. But it's not easy to implement in current way.
Re: RFC: move default pin for FAILSAFE from throttle to roll
I am not proficient in interrupt handling code, so maybe I am way off here.
My approach would be
- whenever valid rcValue is found for a channel, increment sum counter and increment pincounter[channel]
- at end of isr handling do failsafe test like
The constants would need some tuning, of course. What do you think?
My approach would be
- whenever valid rcValue is found for a channel, increment sum counter and increment pincounter[channel]
- at end of isr handling do failsafe test like
Code: Select all
if (sum counter > 40) { // received number of valid rcValues spread over channels
loop over pincounter[] {
if (pincounter == 0) failsafeCnt += 200; // add large enough number so other sane channels cannot clear failsafeCnt
else {
if(failsafeCnt > 20) failsafeCnt -= 20; else failsafeCnt = 0;
}
pincounter = 0;
}
sum counter = 0;
}
The constants would need some tuning, of course. What do you think?
-
- Posts: 2
- Joined: Thu Sep 06, 2012 1:08 pm
Re: RFC: move default pin for FAILSAFE from throttle to roll
Just jumping in here. It seems to me that Spectrum RX's (including OrangeRX) return all channels to the bind state on link failure. In my case (with MultiWii failsafe enabled) a link failure causes the motors simply to go back to idle and stay there indefinitely.
Wouldn't a simpler option be to temporarily set the down travel on TX throttle channel to 125% and re-bind, then set the travel limit back to normal again. It'll then theoretically flick to that extra low signal when the link is lost. Then on the board, set a failsafe threshold (somehow) so that if the throttle signal drops below it, the failsafe sequence initiates (cancelling it if it goes back into normal range again).
I take it failsafe only kicks in if the motors are armed?
Don't know how to go about doing this in the code though... I'm a bit new to this...
Wouldn't a simpler option be to temporarily set the down travel on TX throttle channel to 125% and re-bind, then set the travel limit back to normal again. It'll then theoretically flick to that extra low signal when the link is lost. Then on the board, set a failsafe threshold (somehow) so that if the throttle signal drops below it, the failsafe sequence initiates (cancelling it if it goes back into normal range again).
I take it failsafe only kicks in if the motors are armed?
Don't know how to go about doing this in the code though... I'm a bit new to this...
Re: RFC: move default pin for FAILSAFE from throttle to roll
stinkyweezl,
the current mwii failsafe implementation will only observe a signal loss on one pin - the rollchannel. This will detect the failsafe state a rx goes into when the rx looses connection to the tx.
This is trying to address another failure condition:
If for whatever reason the connection between rx and mwc breaks for one of throttle, yaw, nick then none of your rx failsafe nor the mwii failsafe will identify this, so no mwii failsafe will get activated. Of course, if you loose one of throttle,yaw,nich authority, then your flight is doomed.
the current mwii failsafe implementation will only observe a signal loss on one pin - the rollchannel. This will detect the failsafe state a rx goes into when the rx looses connection to the tx.
This is trying to address another failure condition:
If for whatever reason the connection between rx and mwc breaks for one of throttle, yaw, nick then none of your rx failsafe nor the mwii failsafe will identify this, so no mwii failsafe will get activated. Of course, if you loose one of throttle,yaw,nich authority, then your flight is doomed.
-
- Posts: 2
- Joined: Thu Sep 06, 2012 1:08 pm
Re: RFC: move default pin for FAILSAFE from throttle to roll
Probably not quite the right thread, got here via google. Just looking for a way to trigger the failsafe appropriately on a Spectrum compatible RX. For my current level of expertise, I have to make the reasonable assumption that my signal wire connections are bulletproof (resorting to the low tech solution of hot glue and cable ties).
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: RFC: move default pin for FAILSAFE from throttle to roll
Hey Hamburger, just use ppm
trolololol....
I will try to look into it tonight.
imho: everybody should get a nifty ppm converter.
Nils
trolololol....
I will try to look into it tonight.
imho: everybody should get a nifty ppm converter.
Nils
Re: RFC: move default pin for FAILSAFE from throttle to roll
Hamburger:
I have better idea. Try this code. Shoud work, but not tested.
In "RX_PIN_CHECK" macro:
At first channel the "GoodPulses" variable is cleared, then if pulse is valid - is incremented.
With three next channels is incremented too if pulse is valid.
Now at the end of interrupt GoodPulses variable is tested and if value is 4 (all first 4 channels are good) the failsafe counter is resetted.
Edit:
Tested and working , but tested only on Mega Boards.
Need testing on promini.
On promicro should work in old way.
I have better idea. Try this code. Shoud work, but not tested.
In "RX_PIN_CHECK" macro:
At first channel the "GoodPulses" variable is cleared, then if pulse is valid - is incremented.
With three next channels is incremented too if pulse is valid.
Now at the end of interrupt GoodPulses variable is tested and if value is 4 (all first 4 channels are good) the failsafe counter is resetted.
Code: Select all
#if defined(STANDARD_RX)
// predefined PC pin block (thanks to lianj)
#define RX_PIN_CHECK(pin_pos, rc_value_pos) \
if (mask & PCInt_RX_Pins[pin_pos]) { \
if (!(pin & PCInt_RX_Pins[pin_pos])) { \
dTime = cTime-edgeTime[pin_pos]; \
if (rc_value_pos==0) GoodPulses=0; \
if (900<dTime && dTime<2200) { \
rcValue[rc_value_pos] = dTime; \
if(dTime>985 && rc_value_pos<4) GoodPulses++; \
} \
} else edgeTime[pin_pos] = cTime; \
}
// port change Interrupt
ISR(RX_PC_INTERRUPT) { //this ISR is common to every receiver channel, it is call everytime a change state occurs on a RX input pin
uint8_t mask;
uint8_t pin;
uint16_t cTime,dTime;
static uint16_t edgeTime[8];
static uint8_t PCintLast;
static uint8_t GoodPulses;
pin = RX_PCINT_PIN_PORT; // RX_PCINT_PIN_PORT indicates the state of each PIN for the arduino port dealing with Ports digital pins
mask = pin ^ PCintLast; // doing a ^ between the current interruption and the last one indicates wich pin changed
sei(); // re enable other interrupts at this point, the rest of this interrupt is not so time critical and can be interrupted safely
PCintLast = pin; // we memorize the current state of all PINs [D0-D7]
cTime = micros(); // micros() return a uint32_t, but it is not usefull to keep the whole bits => we keep only 16 bits
#if (PCINT_PIN_COUNT > 0)
RX_PIN_CHECK(0,2);
#endif
#if (PCINT_PIN_COUNT > 1)
RX_PIN_CHECK(1,4);
#endif
#if (PCINT_PIN_COUNT > 2)
RX_PIN_CHECK(2,5);
#endif
#if (PCINT_PIN_COUNT > 3)
RX_PIN_CHECK(3,6);
#endif
#if (PCINT_PIN_COUNT > 4)
RX_PIN_CHECK(4,7);
#endif
#if (PCINT_PIN_COUNT > 5)
RX_PIN_CHECK(5,0);
#endif
#if (PCINT_PIN_COUNT > 6)
RX_PIN_CHECK(6,1);
#endif
#if (PCINT_PIN_COUNT > 7)
RX_PIN_CHECK(7,3);
#endif
#if defined(FAILSAFE) && !defined(PROMICRO)
if(GoodPulses == 4) { if(failsafeCnt > 20) failsafeCnt -= 20; else failsafeCnt = 0; }
#endif
.......
Edit:
Tested and working , but tested only on Mega Boards.
Need testing on promini.
On promicro should work in old way.
Last edited by Mis on Thu Sep 06, 2012 11:55 pm, edited 1 time in total.
Re: RFC: move default pin for FAILSAFE from throttle to roll
There are 2 ways to bind spektrum Rxs and it results in a different failsafe being used.
Bind plug in power Rx power Tx holding bind
And
Bind plug in power Rx bind plug out power Tx holding bind
I'm not completely sure of the effect of each method, its not clearly documented. But I believe the second method (pulling the bind plug before powering the tx) records the Tx stick positions at binding to use in failsafe conditions.
Bind plug in power Rx power Tx holding bind
And
Bind plug in power Rx bind plug out power Tx holding bind
I'm not completely sure of the effect of each method, its not clearly documented. But I believe the second method (pulling the bind plug before powering the tx) records the Tx stick positions at binding to use in failsafe conditions.
Re: RFC: move default pin for FAILSAFE from throttle to roll
@katch
I think you described it correctly. However neither does help the mwii to detect a partially broken connection.
@mis
Thank you. Looks much cleaner than mine. I can only test in 2 weeks from now. I will report back then.
So it is safe to assume that under normal conditions we never miss an interrupt per channel?
I think you described it correctly. However neither does help the mwii to detect a partially broken connection.
@mis
Thank you. Looks much cleaner than mine. I can only test in 2 weeks from now. I will report back then.
So it is safe to assume that under normal conditions we never miss an interrupt per channel?
Re: RFC: move default pin for FAILSAFE from throttle to roll
@hamburger
Just mentioning it in case it has some relevance to the code change proposed.
Need to see if we can get mwc failsafe to kick in regardless of how the spektrum failsafe is setup.
Just checked and the first method sends last known signal.
Second sends stick position when bound.
Just mentioning it in case it has some relevance to the code change proposed.
Need to see if we can get mwc failsafe to kick in regardless of how the spektrum failsafe is setup.
Just checked and the first method sends last known signal.
Second sends stick position when bound.
Re: RFC: move default pin for FAILSAFE from throttle to roll
OK, for compatibility with promini and mega boards my code need some little changes.
Now is tested with promini (on Mega328p) and with Mega2560.
Code is commited to shared repository.
With standard receivers, pulse absence or pulses below 985us on one of THROTTLE, YAW, PITCH or ROLL channel will trigger failsafe.
With PPM receivers - PPM absence or pulses below 985us on one of first 4 PPM channels will trigger failsafe.
On promicro (Mega32u4) boards and standard receiver only THROTTLE channel is checked.
Now is tested with promini (on Mega328p) and with Mega2560.
Code is commited to shared repository.
With standard receivers, pulse absence or pulses below 985us on one of THROTTLE, YAW, PITCH or ROLL channel will trigger failsafe.
With PPM receivers - PPM absence or pulses below 985us on one of first 4 PPM channels will trigger failsafe.
On promicro (Mega32u4) boards and standard receiver only THROTTLE channel is checked.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: RFC: move default pin for FAILSAFE from throttle to roll
Mis, you recently commited something to use more than 8 channels for PPM sum receivers.
Have you some example of RC systems ?
A standard rate is 20ms for the whole pulse.
each servo can vary between 1 and 2ms => 16ms + some margin to detect the last down state to start with a new pulse (in the current code 3ms) => 19ms
It's not really possible to handle more than 8 chans with a 20ms rate.
Have you some example of RC systems ?
A standard rate is 20ms for the whole pulse.
each servo can vary between 1 and 2ms => 16ms + some margin to detect the last down state to start with a new pulse (in the current code 3ms) => 19ms
It's not really possible to handle more than 8 chans with a 20ms rate.
Re: RFC: move default pin for FAILSAFE from throttle to roll
LRS systems like Thomas / RangeLink / DragonLink and others long range systems can generate 10 or even 12CH PPM. In this case the frame rate time is extended by about 2.2ms for any additional channel above 8. The 12CH PPM have about 28-30ms frame rate. I have RC system with 12CH PPM, and test MultiWii with it. Working perfectly.
Re: RFC: move default pin for FAILSAFE from throttle to roll
Mis wrote:OK, for compatibility with promini and mega boards my code need some little changes.
Now is tested with promini (on Mega328p) and with Mega2560.
Code is commited to shared repository.
With standard receivers, pulse absence or pulses below 985us on one of THROTTLE, YAW, PITCH or ROLL channel will trigger failsafe.
With PPM receivers - PPM absence or pulses below 985us on one of first 4 PPM channels will trigger failsafe.
On promicro (Mega32u4) boards and standard receiver only THROTTLE channel is checked.
Thumbs up!
It works for promini in all combinations of tx-rx bind strategy and signal losses I could test.
Re: RFC: move default pin for FAILSAFE from throttle to roll
report:
after 12min flight I saw 28 failsafeEvents via lcd.config menu! It had felt normal during entire flight, especially never felt throttle going to the low failsafe.throttle; so I guess system always recovered rx input quick enough? Or could it have happened during the initialization phase? The code does not look suspicious in that respect though.
It was with an orange rx spektrum compatible 6ch receiver (??610??), all channels wired separately; distance&height never was > 100m.
I am rather sure I had not seen this with earlier versions of failsafe. FAILSAVE_DELAY is at default 10; my cycle time is fixed to 5000us, flying in level mode (angle mode now).
I could start swapping receivers, but that seems so random an reaction.
Ideas, please?
edit: forgot to mention I run the TRI's single servo with the 300Hz update rate option on a 328p system, if that should matter.
after 12min flight I saw 28 failsafeEvents via lcd.config menu! It had felt normal during entire flight, especially never felt throttle going to the low failsafe.throttle; so I guess system always recovered rx input quick enough? Or could it have happened during the initialization phase? The code does not look suspicious in that respect though.
It was with an orange rx spektrum compatible 6ch receiver (??610??), all channels wired separately; distance&height never was > 100m.
I am rather sure I had not seen this with earlier versions of failsafe. FAILSAVE_DELAY is at default 10; my cycle time is fixed to 5000us, flying in level mode (angle mode now).
I could start swapping receivers, but that seems so random an reaction.
Ideas, please?
edit: forgot to mention I run the TRI's single servo with the 300Hz update rate option on a 328p system, if that should matter.
Re: RFC: move default pin for FAILSAFE from throttle to roll
from the code actual value of failsfeevents is not relevant. gets incremented during failsfa state for each cycle
Re: RFC: move default pin for FAILSAFE from throttle to roll
I find one bug in failsafe detection on pulses<985us.
On pulse time goes bellow 985us (before guard time initiate failsafe routine) the throttle value (or any other trigger channel) is updated and used as control value. In this situation (based on throttle example) 980us is first interpretted as minimum thtottle value, then FC wait "FAILSAFE_DELAY" with using MIN_THROTTLE as throttle level, then failsafe start, and set throttle value to propper landing level.
Tommorow I commit tested patch for this situation.
On pulse time goes bellow 985us (before guard time initiate failsafe routine) the throttle value (or any other trigger channel) is updated and used as control value. In this situation (based on throttle example) 980us is first interpretted as minimum thtottle value, then FC wait "FAILSAFE_DELAY" with using MIN_THROTTLE as throttle level, then failsafe start, and set throttle value to propper landing level.
Tommorow I commit tested patch for this situation.
Re: RFC: move default pin for FAILSAFE from throttle to roll
thanks for that indepth analysis.
In the meantime I went flying 5 packs on a large airfield, went >100m distance and height with zero failsafeEvents. So I have no explanation for my erlier experience.
Anyway, seems we are getting a rock solid failsafe implementation!
In the meantime I went flying 5 packs on a large airfield, went >100m distance and height with zero failsafeEvents. So I have no explanation for my erlier experience.
Anyway, seems we are getting a rock solid failsafe implementation!
Re: RFC: move default pin for FAILSAFE from throttle to roll
My private version of multiwii code have better failsafe - return to home at designed altitude then land automatically
But this option is very unfavorably accepted by someone, and I don't include this in the official version.
But this option is very unfavorably accepted by someone, and I don't include this in the official version.
Re: RFC: move default pin for FAILSAFE from throttle to roll
update (problem):
on two copters I have a 25% chance to trigger failsafe whenever I enter the arm/disarm stick combo. copter on the wet ground, tx less than 10m away.
- one is a heli with 1 motor & 4 servos@160Hz on a 328p board,
- the other a tri with heavy serial traffic, again on a 328p board.
Just a guess, but maybe the interrupts from the servos/serial do confuse the rx input handling and its failsafe logic too much?
The same heli with old r9xx software (older failsafe implementation) did not express that behaviour, same for the tri.
on two copters I have a 25% chance to trigger failsafe whenever I enter the arm/disarm stick combo. copter on the wet ground, tx less than 10m away.
- one is a heli with 1 motor & 4 servos@160Hz on a 328p board,
- the other a tri with heavy serial traffic, again on a 328p board.
Just a guess, but maybe the interrupts from the servos/serial do confuse the rx input handling and its failsafe logic too much?
The same heli with old r9xx software (older failsafe implementation) did not express that behaviour, same for the tri.
Re: RFC: move default pin for FAILSAFE from throttle to roll
Hamburger, check your endpoints for first 4 channels. Noone should be lower than 1000us (best keep it above 1030us).
Re: RFC: move default pin for FAILSAFE from throttle to roll
Mis, right on. Endpoints were as low as 990 and up to 2030. Reduced travel range and will test fly to verify.
Thank you.
Thank you.
Re: RFC: move default pin for FAILSAFE from throttle to roll
Verified. Wrong failsafes are gone with corrected endpoints.
Re: RFC: move default pin for FAILSAFE from throttle to roll
Mis wrote:Hamburger, check your endpoints for first 4 channels. Noone should be lower than 1000us (best keep it above 1030us).
I have throttle range from 990 to 2000. Is this ok or will be better if it is around 1000 to 2000? Other three channels are from around 1000 to 2000?
Thx!
Re: RFC: move default pin for FAILSAFE from throttle to roll
see my recent experience in posts above.
better make it 1000 (or slightly above) to 2000 for roll, nick, yaw and throttle.
better make it 1000 (or slightly above) to 2000 for roll, nick, yaw and throttle.
Re: RFC: move default pin for FAILSAFE from throttle to roll
Thx. I'll do that. For other 3 ch I've set ok.