RC_OPTIONS to 1 make copter yaw spinning

ArduCopter Copter 4.7
, , , ,
1

I think I found a bug, but I would like somebody else to confirm beform posting it on Github.

I’m working on Gazebo/SITL with standard Iris gazebo multocopter with runway world.

If I set this parameters :

  • RC_OPTIONS 1
  • FS_THR_ENABLE 0 (only to be able to arm)

When I takeoff the copter starts a continuous yaw spinning CCW.

I tried on a full fresh installation of Gazebo and Ardupilot (master and 4.7), the issue is still here

I used this parameter since a long time, and I didn’t see that in previous versions of ArduCopter.

I think I don’t really need this parameter, but it can have other issues because I don’t see any relationship between this parameter and the yaw spinning. And I pretty sure this behavior should also happen in real drones.

If someone can check, just by adding the parameters to the standard Gazebo/SITL Ardupilot

2

Hi @Dronotique,

Txs very much for helping testing 4.7 and reporting back.

I’ve reproduced the issue in SITL by doing the following:

  • ../tools/autotest/sim_vehicle.py --map --console
  • param set RC_OPTIONS 1 (to ignore RC input)
  • param set FS_THR_ENABLE 0 (to disable failsafe to allow arming)
  • GUIDED
  • arm throttle
  • takeoff 10

The vehicle does indeed spin as it climbs because it is consuming the pilot’s yaw input.

The issue occurs in 4.6 though as well so I don’t think it’s a regression but it seems to me that it is probably an existing bug.

If the vehicle is flying in GUIDED (as it is during my test) you can get around the issue by setting GUID_OPTIONS = 4 (Ignore pilot yaw)

image
image686×197 7.58 KB

@peterbarker and I are discussing how we should tackle this. Thanks again!

3

Hi @rmackay9 ,

Thank you for your quick response.

I think it not happens only in GUIDED. After the takeoff, if I go to LOITER mode, the drone crash in spinning.

Do you want me to open an issue on Github ?

4

RC_OPTIONS 1 means to ignore RC so that expected you crash in Loiter since you have 0 throttle.

@rmackay9 would need to confirm on a real drone, but this could be just an issue with SITL way to deal rc input from mavproxy

5

Hi @Dronotique,

Thanks for the feedback. @peterbarker has already created a PR with a potential fix so no need for an issue at this point.

It’d odd that you mention Loiter though because Loiter is a manually controlled mode meaning that an RC is required. Perhaps you’re using a joystick? In AP, a joystick is treated just like other RCs.

If you’re just looking for the vehicle to stop, Guided should work but Brake mode is another option

Thanks again for the report, this does appear to be a real bug!

6

Hello @rmackay9 ,

I‘ve just tested on Gazebo/SITL with the 4.7 branch (commit 571e8c7) and it works fine.

Regards

7

I think i’m having the same problem , it would be possibile to have a log of this problem from your side… i’m expericing quite same problem on the 4.6.3 firmware

8

Hi @Davide_Lentini,

I’ve replied elsewhere to you but for others reading this discussion, the bug is also likely present in 4.6.3 as well. The work around is to set AUTO_OPTIONS = “Ignore pilot yaw” bit. GUID_OPTIONS also has a similar bit.

I’ve marked the fix for backporting to 4.6 as well but I’m not sure when/if we will release 4.6.4.

9

Hi @Davide_Lentini,

To answer your question posted over on the PR, we think 4.5.x is fine. The issue appeared from 4.6.x.

10

Thanks . Well if the problem is actually not present in the 4.5.7 that makes the things a lot stranger !

So I explained in other discussion I’m sending this RC mavlink override

chan1==0 && chan2==0 && chan3==0 && chan4==0 && chan5==10 && chan6==20 && chan7==2000 && chan8==2000

, that should not be received by the FC, by activating the ignore mavlink override . This ignore works on the 4.5.7 .

If a deactivate the ignore mavlink override and send this command the drone will start spins exactly as the 4.6.3 version ! Even if the command is not controlling the yaw channel …

That’s so strange.

Also I simulate a drone with sitl on 4.6.3 and yes I confirm that’s rotating on the yaw quite equal as my yaw problem …

So the questions are :

  • Why is happening in the 4.5.7 for me but only when I send the rc_mavlink_override without the ignore RC mavlink override and the same in 4.6.3
  • It should not always happen ? Even if I not send the RC mavlink override

Anyway i’ll try with activating the auto_options , but actually I’m flying a SkyBrush Drone firmware with SHOW mode , I don’t know it will change something

This is also how we actually fix it in the 4.6.3 , for make the ignore_mavlink_override WORKS

void Copter::rc_loop()
{
// Read radio and 3-position switch on radio
// -----------------------------------------
if(!rc().option_is_enabled(RC_Channels::Option::IGNORE_RECEIVER) &&
!rc().option_is_enabled(RC_Channels::Option::IGNORE_OVERRIDES))
read_radio();
rc().read_mode_switch();
}

11

@rmackay9

So here is my final report of this problem :
I tested this with versions 4.5.7 and 4.6.3 in the ArduPilot simulator (SITL).

To simulate sending the `rc_override_mavlink` command, I set up a MAVLink TCP mirror from Mission Planner and sent the `rc_override_mavlink` command via a Python script.

With version 4.5.7, the yaw spinning issue persists when:

- I disable “ignore rc override”

- I send any rc_override_mavlink command, for example, setting all channels to 0 and just one channel (I tried channel 16) to a value of 1

This demonstrates that version 4.5.7 has the yaw spinning issue under certain conditions

With version 4.6.3, the yaw spinning issue occurs when:

- IF I KEEP “IGNORE RC RECEIVER” AND “IGNORE MAVLINK OVERRIDE” ENABLED

- I send any rc_override_mavlink, for example, all channels set to 0 and only one channel (I tried channel 16) with a value of 1

OR

- I do not send an rc_override

This is the only difference between the real world and the simulation in version 4.6.3; in the real world, yaw spinning only occurs if I send the rc_override, whereas in the simulation it always happens

In 4.6.3, we resolved this by adding an additional check; I’ll post it in the discussion. We would still keep the AUTO_OPTIONS set to “ignore yaw mavlink,” but this still demonstrates that under certain conditions, the problem occurs in both 4.5.7 and 4.6.3

12

@Davide_Lentini,

Thanks for the extra detail. I wonder if you’ve tested 4.7? As you might image, it is much easier for us to fix 4.7 issues.

13

Hi , @rmackay9 , i just test with 4.7.0 beta sitl and the bug it still there!

Hi tried with “ignore rc” and “ignore rc override” ENABLED and it spins

With adding AUTO_OPTIONS→ignore pilot yaw , it will not spins

14

Hi @Davide_Lentini,

Txs for the report. Has a log been posted anywhere?

The difference between SITL and the real world is that in SITL, I think MAVProxy uses the rc-channel-override message to send RC to the vehicle so this will interfere with your own sending of this message. I think MAVProxy will stop sending rc-channel-override if SIM_RC_FAIL = 1.

I think another condition to reproduce this issue is that the RC failsafe must be disabled (e.g. FS_THR_ENABLE = 0).

I’m going to try to reproduce this in SITL but I strongly suspect it is another variant of the existing issue reported by Dronotique at the top of this thread and it will be resolved in 4.8 once @peterbarker implements the per-channel validity check. Still, I’d like to document the exact conditions the issue appears so that we can be sure that fix covers this variant as well.

15

Hi @Davide_Lentini,

I’ve reproduced the issue in SITL and created this new issue. As mentioned, I’m quite confident that this is the same underlying issue that causes issue 32862 so I expect we will fix this in 4.8.

I think for now the workarounds are:

Thanks again for the report!

16

Hello guys. Im experiencing a similar problem like this for the last few weeks but in AUTO mode, could this be something connected or did i just configure my quad wrong. Im building a autonomous mission quad and the end goal is to get rid of the radio controller and do simple missions only using a GCS with an ELRS backpack. The quad flies the missions perfectly fine with an RC controller, but as soon as i try to do the missions using only mission planner i get a weird yaw input in all stages of the flight (during takeoff, waypoints and on the rtl). I’ve tried disabling any pilot yaw input i could think of (auto_options, land_reposition, rtl_options etc etc.) and it did helped. The yawing dissapeared in every part of the mission (takeoff, waypoints, rtl) except for the landing portion of rtl. I’ve tried ending the mission with a LAND instead of RTL and it still yaws when it gets into LAND. I’ve played with landing speed and all sorts of parameters but couldnt get this problem to go away. I have the same problem in 4.6.3 and in 4.8. Im pretty new to ardupilot so if this problem isnt for here just tell me and ill delete it. Ill post some logs as well. :slight_smile:

17

Hi @Dode,

Thanks very much for the report. Indeed it looks like we have a bug here introduced many years ago by this PR.

I’ve created an issue and added this to our 4.7 issues list and I’m pretty confident we can fix this.

I guess you agree that if RTL_OPTIONS = “Ignore Pilot Yaw” we should always ignore the pilot’s input during all stages of the RTL?

Thanks again!

18

Thank you for your response Randy!

And yeah, i think that would make the most sense, since landing is already part of RTL as it is. I will test the fix as soon as it is available!

I got one more question. Since the same problem arises when i finish the mission in LAND instead of RTL as well, will that problem be fixed as well?

All the best!

19

Hi @Dode,

Yes, I’ve created a PR which I think resolves both issues.

Thanks again for the report!

20

Thank you for the work put in!