I’ve got a new Pixhawk based quadcopter ready to fly with this bug hampering the readiness:
I’ve got throttle failsafe set up correctly so that if the SBUS cable becomes undone, then that’s covered. That works.
On top of that, I configured my FrSky L9R to use ‘receiver failsafe’ so that when a failsafe occurs, these additional things happen:
[ul]
[li]CH5 mode changes to RTL[/li]
[li]Lights and strobe go on[/li]
[li]LMA (lost model alarm) goes on[/li]
[li]Camera switch selects FPV camera (default)[/li][/ul]
The lights are connected to the Pixhawk’s AUX1 with RC mode set to passthru. So far so good, that works.
The LMA is connected directly to the receiver’s CH7 port (CH7 has no assigned function in my Mission Planner).
Now for the weird stuff when I switch my radio off:
The LMA (directly connected to receiver) beeps indicating that receiver failsafe is working.
The lights (connected via Pixhawk passthru) do not turn on, indicating that Arducopter isn’t reacting as expected to the failsafe.
With Mission Planner open so that I can monitor channels 1 thru 8, I can see CH5 go to the PWM value associated with RTL, yet the Mission Planner voice doesn’t announce RTL and in the Flight modes tab, it still shows the previous mode is active (stabilize) even though at the same time it’s highlighting the RTL mode in the select box.
What this tells us, is that the receiver failsafe is setting the right value for CH5, but Arducopter isn’t doing anything with it for some reason.
[attachment=0]Houston.png[/attachment]
Hopefully somebody can help me resolve this issue, so that I can go out and fly safely.
P.S. this forum doesn’t allow the extensions .txt and .param, so if anybody needs to see my params file, then I’ll post it inline.
I am not sure how to fix your issue as you are doing it an odd way. Normally RTL is on the throttle value and not channel 5. The problem with channel 5 is if your sbus cable unplugs it won’t set channel 5 above 1750 to trigger your RTL.
You should be protecting against radio loss not you sbus cable falling out anyway. although using the throttle method will protect against that too. With throttle fail safe you need to ensure the receiver failsafe is set to set throttle lower than normal zero throttle value. And check using the RC monitor page in mission planner.
Also you should not use RTL before you have flown and tested loiter. If your compass is wrong for any reason you are asking for a fly away.
When testing RTL on the bench I am pretty sure it will switch out of RTL if it is landed and within its RTL window…i.e. home and landed.
There’s nothing odd about how I’ve setup failsafe.
As I mentioned, throttle failsafe is setup, tested, and it works (when using no PPM signal failsafe or throttle very low failsafe).
Additionally, I’ve also got receiver failsafe set (for the reasons I already mentioned in the OP). Arducopter can’t know/see this of course. The receiver just sets the channels as I programmed it to do with most importantly, the mode (CH5) going to RTL.
Although this has got nothing to do with the bug I mentioned:
Yes, I already know that I should test loiter and calibrate the compass and all that stuff before performing RTL or any other sort of navigation for that matter, and yes I already know that throttle failsafe is not just for a disconnecting SBUS cable but also for receiver brownouts and failsafes too. Nothing new there.
If Mission Planner & Arducopter had a feature whereby users can script a series of events to take place in the event of a (throttle) failsafe (as seen from Arducopter), then I could simply use throttle (or no PPM) failsafe only and script the values that need to be sent to the output channels for my lights, LMA, and camera switch. The only thing missing in that list is lower landing gear since I don’t use LG. But since this useful feature doesn’t exist yet, I’ll have to use receiver failsafe (i.e. all channels set to predefined values in the event of RC loss).
OK wasn’t trying to teach you to suck eggs…seen too many people with RTL issues on untested setups. Better to mention it on the off chance, might save some more people from losing the copters if they read this and are new.
I think landing gear is coming in 3.3
I think the stab/rtl disparity is due to it being home and landed. I think it switches out of RTL when its complete, which is probably the safest thing to do…don’t want a copter RTLing (if there is such a verb) into you .
Do the log files show an RTL to stab transition? That would show RTL was engaged and then switch out of again by the brain.
Also are these tests while armed? maybe the brain interlocks the RTL out if not armed. I admit I am guessing a bit, just trying to prod at the problem to help solve it. I have in the past bench tested RTL and seen it didn’t say RTL as it switched out due to thinking it was home and landed.
A script methodology would be nice in such events or other events.
Good tip on the logs, I’ll dig into that.
In the mean time, I did some more testing and debugging:
Since Mission Planner doesn’t seem to offer a means to display all input channels above the first 8, I placed an SBUS decoder on the L9R’s SBUS output with a servos attached to the decoder’s ports programmed for CH9 and CH10. I tested failsafe, and the servo’s moved to their expected positions. These positions equate to lights on and switch to FPV camera on the Pixhawk (the first 2 AUX ports using PassThru). Strangely, the Pixhawk/Arducopter can’t know that the receiver is in failsafe mode, but somehow something is causing it to stop passing through the SBUS channels above 8 when receiver failsafe is triggered. I’m baffled on this one. Perhaps some disruption in the SBUS communication as the L9R goes into failsafe mode.
I changed the failsafe setting on CH5 from RTL to Alt-Hold: now when I turn my radio off while the quadcopter is armed, throttled up, and held by hand off the ground (simulating flight), Arducopter goes into Land mode which makes sense.
I can assume that the reason it didn’t go into RTL mode was because I was indoors (no GPS), although I did expect it to at least go into land mode instead of stay in Stabilize and perform an instant disarm. But I’ll test it more (perhaps my handheld flight simulation wasn’t convincing enough) and try to prove myself wrong. So it seems this last issue isn’t as bad as the subject of the OP seems to indicate.
If you have RCIN enabled in your logs can you see the additional channels above 8?
I can on mine, not sure if that is virtual robotix ubrain specific. But if it does would prove yours is measuring it, even if not responding as you want.
[quote=“MarkM”]I thought the sbus just stops sending signals when the tx/rx link is lost.
Pixhawk see’s the signals stop and automatically goes into failsafe.
I do know it always been said NOT to modify channel 5 in the event of failsafe and just use the throttle failsafe.[/quote]
SBUS is just a protocol. I think you’re confusing it with a Futaba receiver or something. In any case the L9R supports 2 failsafe types: one is no signal (which is what you were thinking of) and the other which I’m using and referred to as ‘receiver failsafe’ is with all channels set to a predefined position.
Normally, if you don’t need to do additional things during failsafe as I mentioned in the OP, just setting the throttle failsafe is indeed the easiest/best.
[quote=“turdsurfer”][quote=“MarkM”]I thought the sbus just stops sending signals when the tx/rx link is lost.
Pixhawk see’s the signals stop and automatically goes into failsafe.
I do know it always been said NOT to modify channel 5 in the event of failsafe and just use the throttle failsafe.[/quote]
SBUS is just a protocol. I think you’re confusing it with a Futaba receiver or something. In any case the L9R supports 2 failsafe types: one is no signal (which is what you were thinking of) and the other which I’m using and referred to as ‘receiver failsafe’ is with all channels set to a predefined position.
Normally, if you don’t need to do additional things during failsafe as I mentioned in the OP, just setting the throttle failsafe is indeed the easiest/best.[/quote]
Yeah frsky does have the option for presets failsafe on sbus, that’s what I use actually, so I will be setting it to stab at the same time as RTL. I had to do this rather than kill the signal so that my landing gear comes down, it needs a definitive signal so if loses signal the legs stay where they are…which I’d rather they dropped obviously. Although in my case the landing gear is wired to the pwm outs on my x8r direct.
[quote=“RabbitStu”]If you have RCIN enabled in your logs can you see the additional channels above 8?
I can on mine, not sure if that is virtual robotix ubrain specific. But if it does would prove yours is measuring it, even if not responding as you want.[/quote]
I finally got to analyse the logs. I can see all RCIN channels that the Pixhawk supports (from C1 thru C14), but I can only see 8 RCOU channels. I wonder where I can find the AUX channels or if the firmware simply doesn’t take these into account during failsafe.
In the log analysis image below, you can see that the radio failsafe occurs near line number 3000. A few things can be noted:
[ul]
[li]Input CH10 (lights) goes high, which is good.[/li]
[li]Input CH3 (throttle) drops to low, which is as expected.[/li]
[li]Input CH5 (mode) goes high to where I last set Alt-Hold for testing, which is good.[/li]
[li]For RCIN, 14 channels can be seen.[/li]
[li]For RCPU, 8 channels can be seen, but where are the AUX channels that also set to pass through RC info?[/li]
[li]One peculiar thing that stunned me for a couple of seconds was: how does the Pixhawk know there was a failsafe? I forgot that unlike PPM-SUM, the SBUS protocol contains, besides channel info, a failsafe indicator bit too. The Pixhawk is obviously using this and logging the failsafe event. But why it’s not passing through my AUX channels, I don’t know yet.[/li][/ul]
[attachment=0]failsafe_log.png[/attachment]
Update: I just changed the failsafe preset to make CH5 go to RTL again (as it originally was), and simulated flight without GPS indoors, turned the radio off, and now it went into Land mode. So that is good.
So the only lingering problem is: why aren’t the AUX channels (RC channels >= 9) being passed through during radio failsafe?
P.S. I wish I could edit the subject of the OP to make it more appropriate, but I can’t.
Have you got any solution for your problem? I have a very similar setup as yours and everything was working fine in rc 3.1.5 version… Last week I updated the firmware to the rc 3.2.1and got the same problems as you described…
Reflash to rc 3.1.5 and everything is working again… definitely a problem with this new copter release.
Please let me know if you find a solution for that.
No solution.
My workaround is to forget about having this fixed any time soon, and use a Y servo cable in the receiver’s SBUS output and a FrSky SBUS decoder. That way when a failsafe occurs, the failsafe channel presets will be sent to the connected devices correctly, bypassing the Pixhawk.
5 minutes of googling came up with this - pixhawk.org/modules/pixhawk
Which states channels 1-8 have a failsafe capability but doesn’t say anything about the 6 aux outs having it, so I’d say the work around is for the Pixhawk hardware to be redesigned. Nothing to do with the software.
[quote=“MarkM”]5 minutes of googling came up with this - pixhawk.org/modules/pixhawk
Which states channels 1-8 have a failsafe capability but doesn’t say anything about the 6 aux outs having it, so I’d say the work around is for the Pixhawk hardware to be redesigned. Nothing to do with the software.[/quote]
That is has “nothing to do with the software” seems impossible to me. The firmware has complete control over what it sends to the AUX channels. That’s why they can be used for landing gear, gimbal, etc. So that same firmware can (if so designed) read the incoming SBUS input and pass through channel values to the AUX outputs if the user configured them as passthrough channels. The only chance of your claim being true is if the SBUS decoding happens in a different chip using 3rd party closed-source firmware that is poorly designed in such a way that it only passes the failsafe status (and no channels) through when a failsafe is detected. But I really doubt something like that is the case.
[quote=“turdsurfer”][quote=“MarkM”]5 minutes of googling came up with this - pixhawk.org/modules/pixhawk
Which states channels 1-8 have a failsafe capability but doesn’t say anything about the 6 aux outs having it, so I’d say the work around is for the Pixhawk hardware to be redesigned. Nothing to do with the software.[/quote]
That is has “nothing to do with the software” seems impossible to me. The firmware has complete control over what it sends to the AUX channels. That’s why they can be used for landing gear, gimbal, etc. So that same firmware can (if so designed) read the incoming SBUS input and pass through channel values to the AUX outputs if the user configured them as passthrough channels. The only chance of your claim being true is if the SBUS decoding happens in a different chip using 3rd party closed-source firmware that is poorly designed in such a way that it only passes the failsafe status (and no channels) through when a failsafe is detected. But I really doubt something like that is the case.[/quote]
There are two groups of servo connectors, one main group of 8 outputs wired through the backup processor, and an auxiliary group of 6 outputs directly wired to the main processor.
I’m pretty convinced that this is a software issue and I wish we could have some attention from the developers and maybe a fast solution for it…
the reason why I say that is because my setup is similar to turdsurfer, quad with pixhawk and L9R receiver, and I also prefer to use the built in receiver failsafe for the reason already listed( and the main reason in my setup is because I want the fpv camera to be pointing to a specific position in case of failsafe, something that cannot be done using the throttle FS( or at least I don’t know how to do it)).
Until now I being using the firmware version 3.1.5 and I had everything working the way that I want with the built-in receiver failsafe.
Last week I decided to add a second gps unit to my setup, but rc3.1.5 doesn’t support 2 gps’s so I upgraded for rc3.2.1 and I started to have the failsafe problems described here, downgraded back to rc3.1.5 and everything is working again…
So, something has being changed recently in the software and it’s in my point of view a serious issue because it has not being described or notified to user that it would change.
Also, this afternoon I tried the firmware 3.3rc5 and it behaves same as 3.2.1
If anyone has any explanation or solution please let us know.
Also if any developer could have a quick look in the code and see what is going on I would really appreciate, and I’m sure more people would…
You have probably tried this but just in case you haven’t…
When your RC Failsafe is triggered do you have the Throttle CH set to drop to below the Throttle FS Value? If so, I think that the Pixhawk will see this as a Throttle FS event and go into FS mode. This would stop the passthrough and initiate ah RTL or LAND (Depending on situation such as GPS lock etc).
I am sure the reason that the code is written this way is so that only the throttle channel will trigger FS and then it will ignore ALL RC inputs until the FS is cleared.
I think for what you want you can set you RC failsafe to set the throttle to be 50% as you are also setting CH5 to RTL. That should keep the throttle FS from activating and initiate an RTL. You will get the correct RTL behaviour and also keep the Pixhawk out of Failsafe mode, keeping passthough active.
The throttle FS will still work if you physically lose the connection as CH3 will drop below your Throttle FS value.
I think the confusion is that if you wish to send and RTL to CH5 when your RX goes into its Failsafe mode you can not also send a low Throttle value (that is below you APM Failsafe value).
So, try setting you Rx FS with throttle at 50% and see what happens. The mode should change but you will not get a Failsafe warning in MP. That way you know that the passthroughs should still be working.
I’ve got a similar issue… My futaba rx is set to fail safe at 50% throttle and to put ch 5 into fail safe. When I turn my tx off all the sliders go where they should but the mode won’t change, no matter what mode I set for the fails safe position. My rx either holds the throttle or moves it to a preset position. But I can’t get it set lower than the stick allows it to be, so throttle fail safe won’t work for me. I need pixhawk to listen to the mode switch command it’s clearly getting but with the rx off of out of range of the rx pixhawk stops listening to the rx. When I gist set this quad up it did work fine but at that time I had to put my rx into mode sbus mode everytime I connected a battery to fly, the rx remembered its mode cuz I tested it with a sbus decoder and servo, but pixhawk would only listen if I reset the mode to a sbus mode. But if I disconnected power to just the rx I could plug it back in and everything worked fine so it’s not the rx. But when pixhawk was disconnected from power and plunged back in it wouldn’t listen to the rx commands anymore unless I changed the rx mode to sbus mode again even though it was already in sbus mode… Pixhawk needed to see the mode change of it didn’t listen to the futaba rx. I finally got it working right by connecting the sbus2 port on the rx to pixhawk’s sbus out port… Now everything works fine when I change batteries and I don’t have to keep setting the rx mode to sbus on power up anymore, but now pixhawk won’t listen to the preset fail safe settings… I can’t fly like this, I’m afraid if I go to far and the rx and to loose contact with each other that my copter will keep flying away on me…
My rx is the futaba R7008sb. It wasn’t a cheap rx… Anyone that can help please do
.