RC fail safe is too aggressive

murphym18 commented 2 years ago

In the arm test, the RC fail safe causes the program to exit almost immediately after arming.

After the drone arms, the fail safe detects that the drone is in a human-piloting mode. This causes the RC fail-safe to kick in immediately. The program exits and the test ends right at the beginning. This problem is guaranteed because the user never gets a chance to enter an automatic-mode (like offboard mode). The drone must be armed before it can enter offboard mode.

To address this problem we can prompt the user to put the drone in offboard mode after arming, but before starting the RC fail-safe.

Edit: at first, I thought this would be easiest but I forgot about one important detail: we have to stream set points to the flight controller before we can enter offboard mode.

Another approach is to have the companion computer enter offboard mode automatically after arming.

murphym18 commented 2 years ago

The arm test now prompts the user to enter offboard mode. a6551224c13687c13ee2d56ad5cf0da4bce40895

Still need to update the hover test and box test

murphym18 commented 2 years ago

I committed a fix to the hover test and box test. Unfortunately, I wasn't able to test them because my simulated drone doesn't have an RC transmitter.

murphym18 commented 2 years ago

After reviewing the code, I think it would be better if the companion computer entered offboard mode automatically. At first, I thought it would be easiest if the user manually switched to offboard mode. But that's actually harder because we have to stream set points to PX4 before we can enter offboard mode (whether we enter the mode manually or automatically). So it's actually more straightforward to do it automatically.

Right now, the tests are needlessly too complicated because we prompt the user to switch modes. The tests have to keep track of how long we've been armed so we don't oversleep (if we oversleep PX4 will auto disarm because we took too long to take off). For example, instead of doing this: https://github.com/DroneResponse/hardware-tests/blob/c85302721ad62db1596af213804cfb44f25c0523/nodes/arm.py#L47-L58

We could just do this:

    log("switching to offboard mode")
    drone.set_mode(FlightMode.OFFBOARD)

    log("starting RC failsafe trigger")
    start_RC_failsafe(sensors)

    sleep(9.5)

murphym18 commented 2 years ago

I changed the arm test so that it enters offboard mode automatically. But I couldn't simplify the code.

During testing, it took a non-negligible amount of time to enter offboard mode (about 1 second). This could be due to my test setup. But I ended up needing to keep track of how long we've been armed. So I wasn't able to simplify the code like I hoped.

For what it's worth, my test setup exposes a worst case scenario. The program connects to the flight controller over WiFi (which is slow) using TCP (which makes it even slower).

murphym18 commented 2 years ago

I tested a modified version of the arm test on the intel aero. It worked as expected.

Note: the modifications are related to the intel drone having a different RC configuration.

Here are the logs

root@intel-aero:~/hardware-tests# docker compose run --no-deps arm
[INFO] [1652463639.666471]: arming test: creating SetpointSender
[INFO] [1652463639.674388]: arming test: starting SetpointSender
[INFO] [1652463639.680683]: arming test: done starting SetpointSender
[INFO] [1652463641.445450]: arming test: waiting for user to start the test with the RC transmitter
[INFO] [1652463641.452059]: is_user_ready_to_start: channel 5 = 1901 is_chan5_ok = False   channel 8 = 1901 is_chan8_ok = True
[INFO] [1652463642.228294]: is_user_ready_to_start: channel 5 = 1901 is_chan5_ok = False   channel 8 = 1901 is_chan8_ok = True
[INFO] [1652463642.983563]: is_user_ready_to_start: channel 5 = 1901 is_chan5_ok = False   channel 8 = 1901 is_chan8_ok = True
[INFO] [1652463643.736252]: is_user_ready_to_start: channel 5 = 1901 is_chan5_ok = False   channel 8 = 1901 is_chan8_ok = True
[INFO] [1652463643.844594]: is_user_ready_to_start: channel 5 = 1500 is_chan5_ok = False   channel 8 = 1901 is_chan8_ok = True
[INFO] [1652463644.528908]: is_user_ready_to_start: channel 5 = 1901 is_chan5_ok = False   channel 8 = 1901 is_chan8_ok = True
[INFO] [1652463645.124316]: is_user_ready_to_start: channel 5 = 1500 is_chan5_ok = False   channel 8 = 1901 is_chan8_ok = True
[INFO] [1652463645.241501]: is_user_ready_to_start: channel 5 = 1099 is_chan5_ok = True   channel 8 = 1901 is_chan8_ok = True
[INFO] [1652463645.248160]: arming test: sending arm command
[INFO] [1652463645.283972]: arming test: waiting for sensors to indicate that we're armed
[INFO] [1652463645.726136]: switching to offboard mode
[INFO] [1652463645.739778]: waiting for PX4 to enter offboard mode
[INFO] [1652463646.725004]: detected offboard mode after 0.992 seconds
[INFO] [1652463646.730843]: arming test: starting RC failsafe trigger
[INFO] [1652463646.736902]: RC failsafe waiting for data
[INFO] [1652463646.747981]: RC failsafe now watching for RC override
[INFO] [1652463655.269686]: arming test: sending disarm command
[INFO] [1652463655.301909]: arming test: waiting for sensors to indicate that we're disarmed
[INFO] [1652463655.725331]: arming test: SUCCESS

Of note, it still took about 1 second to enter offboard mode;

[INFO] [1652463646.725004]: detected offboard mode after 0.992 seconds

murphym18 commented 2 years ago

The tests now enter offboard mode automatically after arming. And I tested them as much as I could with the Intel Aero. For each test, I was able to run the code until just before takeoff (though I couldn't takeoff as I'm in a populated area).

The arm test ran as expected with no modifications to arm.py.
The hover test ran as expected but I modified the test to stop before takeoff.
The box test ran as expected but I had to stop it before takeoff.

I had to modify the is_user_ready_to_start function for all tests because the Intel Aero has a different RC configuration.

DroneResponse / hardware-tests

RC fail safe is too aggressive #12