Joystick Control Locks Out RC Transmitter Control

I attempted to fly using a Joystick today.  While flying, i changed to Joystick Flight Control using APM Mission Planner. When i switched out, the RC controller was locked out from Throttle, Pitch, and Yaw/Roll (all defaulted to neutral position and throttle to idle). The mode change channel (6->8) was still working and was able to bring the plane back with RTL and it made a forced uncontrolled glide in for landing in manual mode(i did not have auto land set up). I performed several ground checks on the bench top and found the following. Every several times (about 1 in 10) when disabling the Joystick through APM, it will lock out both the joystick and the RC controller, though in APM it reads that the Joystick is not enabled. If the joystick is re-enabled it regains control. If the joystick is then disabled, the RC controller typically regains control. It appears as if there is a hand off error either in the APM Mission Planner or the APM2.5 code that is causing the RC receiver commands to be ignored and preventing the joystick controls from being sent. My current configuration:

APM: 2.5 with Arduplane 2.68
APM Mission Planner: 1.2.31
Datalink: 3DR radios, tried at both 128 and 250 airspeeds with ECC on and off
Aircraft: Slowstick
Transmitter: Futaba 9C with Spektrum Module
Receiver: Spektrum 6 channel park flyer.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Hi,

    Looking in the code, I think I found the cause of your control loss:

    Override is turned off for each channel by sending a channel value of 0 in the override messages (normal range of values is about 1000 for full deflection to one side to 2000 for full deflection to the other side. This is traditional RC pulse lengths in microseconds).

    When flying with a centered joystick, override values will be something near {1500,1500, ...}.

    To disable override, the APM has to receive one override message with all zeroes. Suppose one is sent from MP but never received... joystick is disabled in MP, override messages are no longer sent but APM is still blocking out RC...

    This is confirmed when looking at line 151 of JoystickSetup.cs in MP:

                {
                    MAVLink.mavlink_rc_channels_override_t rc = new MAVLink.mavlink_rc_channels_override_t();

                    rc.target_component = MainV2.comPort.compid;
                    rc.target_system = MainV2.comPort.sysid;

                    rc.chan1_raw = 0;
                    rc.chan2_raw = 0;
                    rc.chan3_raw = 0;
                    rc.chan4_raw = 0;
                    rc.chan5_raw = 0;
                    rc.chan6_raw = 0;
                    rc.chan7_raw = 0;
                    rc.chan8_raw = 0;

                    MainV2.comPort.sendPacket(rc);
                    System.Threading.Thread.Sleep(20);
                    MainV2.comPort.sendPacket(rc);
                    System.Threading.Thread.Sleep(20);
                    MainV2.comPort.sendPacket(rc);

                    //timer1.Stop();
                    MainV2.joystick.enabled = false;
                    MainV2.joystick = null;
                    BUT_enable.Text = "Enable";
                }

    An override of zeroes is sent but only 3 times. If there is a radio link loss of a few milliseconds, the message never gets to the APM.

    A solution would be to keep the thread running that sends joystick overrides even after disabling joystick. It should however send only zeroes and maybe at a reduced frequency.

    In the ArduPlane code there also seems to be something strange, as there is a global array of overrides declared in ArduPlane.c which is never written to:

    static int16_t rc_override[8] = {0,0,0,0,0,0,0,0};
    // A flag if GCS joystick control is in use
    static bool rc_override_active = false;

    However in system.pde there is a read of it:

    rc_override_active = APM_RC.setHIL(rc_override);                    // Set initial values for no override

    which maybe (?) causes rc_override_active to be set to false while override is really still active. If that is so, then failsafe does not work when overriding..

    Regards

    Soren

This reply was deleted.

Activity