Gripper Released Payload Too Early – My Friend Lost His Lunch!

Today, I tested a gripper and successfully convinced my friend to eat a hamburger that I delivered. However, there was an issue—the gripper released the payload before reaching my friend’s position.
RCIN.C11 and RCOU.C11 during flight

According to my plan, the drone was supposed to fly in AUTO mode to waypoint 6, then switch to LOITER to release the hamburger. However, I didn’t see it drop as expected. After checking the log file, I found that the gripper had released the payload somewhere between waypoints 5 and 6.

Could anyone help me identify the cause of this issue so I can prevent it in the future? I’d really appreciate your support. logfile

P.S.: My friend ended up eating ramen for lunch.

Good to hear your friend was fed after all.

You have the gripper control on RC8, not RC11.

RC11_OPTION      0.000000 # Do Nothing
RC8_OPTION       19.000000 # Gripper Release

SERVO11_FUNCTION 28.000000 # Gripper

So it looks like it did what it was told (even if that wasn’t what you wanted.)

2 Likes

Thank you, Allister Schreiber, for helping me realize that I checked the RC values incorrectly. Do you know the cause of these two error messages?

‘2025-01-31 13:47:11.424 Error: Subsys RADIO ECode 2
2025-01-31 13:47:11.424 Error: Subsys FAILSAFE_RADIO ECode 1’

TLDR: You lost radio link and it went into failsafe.

2 = Radio
2 = Late Frame : no updates received from receiver for two seconds

5 = Radio Failsafe
1 = Failsafe Triggered

https://ardupilot.org/copter/docs/common-diagnosing-problems-using-logs.html#unexpected-errors-including-failsafes

https://ardupilot.org/copter/docs/logmessages.html#err

1 Like

Thank you @Allister , currently I have another post on the link: VTOL Unable to Land on Moving Truck – Stuck Following Truck - #2 by manavgandhi17.

‘2024-08-31 12:23:21.336, 01:00:03.289848, VTOL position1 d=130.5 r=300.0,
2024-08-31 12:23:21.336, 01:00:03.289983, VTOL Position1 d=130.5,
2024-08-31 12:23:21.446, 01:00:03.390259, VTOL position2 started v=2.1 d=3.6 h=40.1,
2024-08-31 12:23:22.385, 01:00:04.333233, VTOL position1 d=128.7 r=300.0,
2024-08-31 12:23:22.385, 01:00:04.333283, VTOL Position1 d=128.7,
2024-08-31 12:23:22.406, 01:00:04.352377, VTOL Overshoot d=4.0 cs=-0.1 yerr=-3.2,
2024-08-31 12:23:22.446, 01:00:04.390122, VTOL position2 started v=2.0 d=4.0 h=40.0,
2024-08-31 12:23:23.439, 01:00:05.383471, VTOL position1 d=126.9 r=300.0’

I am wondering where these messages come from?

Hello @Allister , I used a joystick for GCS, and both the RF controller and GCS control the gripper via RCIN.C8. How can I determine whether RCIN.C8 is coming from the RF controller or GCS? At that moment, I lost connection with both, but the gripper was still activated. I want to understand why it was triggered.

Just to make sure I understand correctly, you had a joystick connected to a laptop AND a traditional RC controller?

If they are both controlling the RC8 channel then if you switched from the joystick to the RC (or the other way) if there is a difference in their output to RC8 the flight controller will see that as a triggering RC8 and in this case releasing the lunch. Switching between the RC controller or the GCS Joystick doesn’t necessarily have to be something you did. The radio failsafe could have triggered it. I didn’t look for that in the logs, but check the time stamps for when RC8 was activated against when the radio failsafes occurred.

Yeah, I used joystick connected to a laptop & RC controller

image
I think so too. From my GCS recording, the connection was lost at 13:46:37.

Does anyone have any suggestions to prevent this problem in the future?

Do you think the different in RC range differ from game pad causes the issue?

So, during the incident happen, is the RC engaged or the joystick from the PC is engaged? My understanding, at one time, only one device can be engaged. If both can engaged at the same time and two pilots are controlling, how disaster will it be.

Running with two controllers is possible, but you need to be careful because of incidents like this. The easiest thing to do is simply commit to a single controller if that’s possible. Or, on the joystick disable the ability to run the gripper. You still have the option to use it on the laptop.

If you do want to keep the same hardware then you need to make sure you have a process in place to make sure that both the joystick and the RC controller have all the same settings, all the switches are in the same place or state before you launch the mission. It’s a procedural fix, not a hardware/firmware one. I’m not aware of a way to do this in the software because the system is only really handling one at a time.