Submitted as a bug. I searched and don’t find that this had been submitted before. Hopefully this will cause it to be fixed.
github.com/diydrones/ardupilot/issues/1053
Sorry took a while to look at this again.
So, looks like we think this was a quasi-commanded movement of the RTL point?
Question is why would that happen? Can you guys do a test for me. “Safe” your copter (remove props, etc.) and then go to the radio tuning screen. When you turn off your radio, what do the roll and pitch do? Do they go to 900?
I’m using an FrSky system, and mine is programmed to output 1500 on roll and pitch during a radio-off. I’ve tested the radio-off RTL and it works fine on my system.
I wonder if the problem is as you are thinking. Your roll and pitch are outputting 900 during radio-off. (can you change this?) and then for some reason, the logic is getting messed up and it starts to use the roll and pitch inputs during the final stage even though we’re in failsafe RTL.
So looking at kf6bbl and troystrum’s logs, yeah, your roll and pitch are at 900-ish during the RTL. That’s probably not good.
I believe that blob of code you looked at is from 3.2, not 3.2. This part changed a lot in 3.2, so what you’re reading there isn’t accurate. I’ll have a quick look at 3.1…
Ok, I’d say that is a smoking gun:
You have to look in the 3.1.3 branch of trunk to get the code you’re flying. In the function do_land():
[code]}else{
// set landing state
land_state = LAND_STATE_DESCENDING;
// if we have gps lock, attempt to hold horizontal position
if (GPS_ok()) {
// switch to loiter which restores horizontal control to pilot
// To-Do: check that we are not in failsafe to ensure we don't process bad roll-pitch commands
set_roll_pitch_mode(ROLL_PITCH_LOITER);
// switch into loiter nav mode
set_nav_mode(NAV_LOITER);
}else{[/code]
Notice:
// To-Do: check that we are not in failsafe to ensure we don’t process bad roll-pitch commands
So, for now, the fix would be to make sure that your radio outputs center-stick during a failsafe event. I guess we’ll have to decide if this is important enough to do a bug fix release while waiting for 3.2 to come out.
Nice work you guys. We’re just working this out now. This will likely result in a bug fix release. (3.1.5)
Open Source at it’s finest. Solid data from the users leads to a fix.
1 Like
Yes, this is it exactly. I’ll have to reset my failsafe on the FrSky RX to fail to dead center. Mine was set to “down spiral” on radio failsafe - so it would bring a fixed wing back to the ground.
Thanks for seeing to getting this fixed. During a failsafe due to loss of radio is the last time you’d want something to misbehave this badly.
I’m just glad I tried it before I needed it.
Brilliant, thanks guys. Troy, how did you go about fixing the rx?
Hi, I can confirm that this is fixed in 3.2-rc1. Although there’s a problem with RTL in 3.2-rc1 in that it seems it has problems transitioning from loiter above home to land, so only sometimes lands itself - but that’s a different conversation!
Just finally following up on this. So I checked the behavior of the Frsky Taranis and more specifically the X8R receiver that comes with it, and what they do in radio link loss. I o-scoped the outputs of the X8R receiver to make sure what I’m telling you is accurate, so here goes.
NORMAL: During normal link on the PWM outputs, I see 18mS frames, and the positive pulse width in microseconds, matches the values that Mission Planner is showing on the radio calibration page, about 1000uS to 2000uS. No surprise here.
From the Sbus port (which I am using), I see 16 channels of data, which by the looks of it is about 115K baud, 16 bytes, LSB first. Not sure of the exact format, but I can clearly see stick input translated to serial bytes.
TX OFF: The PWM outputs on the receiver go dead. No 18mS frames, no positive pulses.
The Sbus port however continues to send a data stream of 16 bytes, but the values are empty. It’s high for the byte period, which I think is data 00. On Mission planner, this is showing up as value 874 for all inputs.
This is the default out of the box configuration. I have not set any failsafes on the X8R.
I’d have to go check again, but I think I have radio failure triggered by values below 900, so I understand how it ‘sees’ the radio failure now. However if I program failsafes as being mid-stick for all, I’m not sure it will ever know there is a radio failure. I think there was some trick of seeing below 900 for one channel like throttle. Have to go ready that some more.
[quote=“Rob_Lefebvre”]
Open Source at it’s finest. Solid data from the users leads to a fix.[/quote]
Thank You Rob!
And this is exactly why I switched to the Pixhawk. Glad the system works.
So just out of curiosity, is 3.1.5 a fork that just gets bug fixes, while 3.2 is where new dev goes on? Or is 3.2 based off of 3.1.5?
And when is it appropriate for me to close the bug in github, or does someone else do that?
I’d leave it open until 3.1.5 comes out. Jonathan was working on it. Hopefully it comes out soon.
The Rx behaviour you describe is pretty interesting. What you should do is set a failsafe value for the channels with center stick, but throttle under 975. Apparently there is an issue where the mode for failsafe should be set to something like Loiter, but I’m not totally sure about why that would be. Apparently if it is set to Stabilize, then it will just disarm instead of RTL.
I’m not sure that info is still valid.
3.1.5-rc2 fixes this RTL problem on my taranis, I switch the tx off and it RTLs and lands itself without flying off in a random direction and sending me diving for cover.
Great work guys!