Disconnecting and reconnecting a webcam causes failures

[ItsHarper]

Steps to reproduce

1. Configure a Logitech C270 webcam on a Control Hub
2. Run the WebcamExample OpMode
3. Disconnect the webcam
   1. The video display on the RC freezes
   2. If you stop the OpMode at this point, it will stop cleanly
4. Reconnect the webcam
   1. The video display stays frozen
5. The app may hang at this point all by itself, in which case the Control Hub OS watchdog present in OS 1.1.2 and later will restart it. Otherwise, the app will hang when you try to stop the Op Mode, with the same result.

Disconnecting and reconnecting a webcam works correctly when running an OpMode that uses the webcam from Vuforia.

[ItsHarper]

I can reproduce the issue 100% of the time.

[ItsHarper]

I can also reproduce this issue using a C615 webcam.

[jmaten]

Not sure if is related, but we are having a problem with the controller crashing in teleop. The robot runs fine for 15-30 seconds or so and then if we touch a wall, the controller crashes. We tried disconnecting the webcam and ran teleop which resulted in no disconnection. Plugged webcam back into control hub USB port, ran again and crashes started reoccurring. It was better yesterday after updated to RC and DS versions 8.1 because at least the controller recovered after 15 seconds or so. With version 8.0, would not recover without a power cycle. We use the webcam for autonomous so leaving it disconnected is not an option. We currently do not have a grounding strap on the robot. Waiting delivery of one from REV. One theory is that static buildup with mecanum wheels running on the foam tiles and then touching metal portion of wall with robot causes a spike and program error. Has been occurring more frequently since colder weather (heat on in the buildings resulting in lower humidity)

I attached a copy of our controller log from yesterday.

1. Started robot with webcam hooked up (16:14)
2. Started autonomous (16:17)
3. Op mode crash at 16:18:14, restarts at 16:18:40
4. Op mode crashes at 16:20:12
5. Disconnected webcam from control hub (16:23)
6. Continued to run with no crashes
   7: Reattached webcam at 16:42, program crashed some time after that.
   robotControllerLog11_22 webcam connect disconnect.txt

[Windwoes]

3. Op mode crash at 16:18:14, restarts at 16:18:40

I'm confused.... at 16:18:14 the RC receives a command from the DS to stop the OpMode; the OpMode does not crash.

11-22 16:18:14.485   984  1172 V Robocol : received command: CMD_INIT_OP_MODE(18514) $Stop$Robot$

It looks like the RC then sits idle until you start the program again from the DS at 16:18:40

11-22 16:18:40.809   984  1172 V Robocol : received command: CMD_INIT_OP_MODE(19257) 2022_Power Play Teleop League

---

As far as the "crash" at 16:20:12, what is not going on is not a crash but rather that your radio dropped off the USB bus. The tell tale sign is:

11-22 16:19:43.071   984   984 V FtDeviceManager: addOrUpdateUsbDevice(vid=0x0bda pid=0xc820)
11-22 16:19:43.539   984  1200 V UpdateUI: Network: active, disconnected

This is the radio re-appearing on the USB bus (check the VID & PID in an online database).

[jmaten]

I probably used the wrong terminology for when we had issues. During the events you mentioned, we never physically touched the driver station until restarting the op mode. Prior to DS and RC update 8.1, the communication wouldn't reestablish so that we could restart the op mode. So, if the communication is dropping off the USB bus, does that explain why it occurs when we have the camera in the USB port versus when we physically disconnected the camera in which we didn't have the disconnect problem? It did appear to happen when the metal side of the mecanum wheel touched the lower piece of the field perimeter.

[Windwoes]

So, if the communication is dropping off the USB bus, does that explain why it occurs when we have the camera in the USB port versus when we physically disconnected the camera in which we didn't have the disconnect problem? It did appear to happen when the metal side of the mecanum wheel touched the lower piece of the field perimeter.

Yes. The radio in the Control Hub is connected internally through USB. An ESD event is causing the radio to drop off the bus, which of course has the effect of breaking the wireless connection to the Driver Station. I have seen many many logs like this. What does seem to help is connecting the webcam to the USB 3.0 port instead of to the USB 2.0 port. The radio is on the USB 2.0 bus, and it seems like having the webcam on a different bus helps. I'm not entirely sure why. It could be that the webcam cable picks up enough induced current/voltage during an ESD event to temporarily cause mayhem on the bus it is connected to.

[jmaten]

We have been running it with the camera in the USB 3.0 port and yesterday ran with it in the USB2.0 port. It didn't seem to make a difference. We do have the camera plugged into a pigtail with a 90 degree connector on it for packaging reasons.

[Windwoes]

Okay. It does not seem like this is related to what Noah is reporting here, though. One thing to test would be to leave the camera connected, but don't actually initialize it with EOCV. If you still have the problem with the camera just sitting idle, then that confirms it is not an EOCV issue.

[Windwoes]

Investigation seems to indicate this is an SDK bug; namely a deadlock inside UvcDevice.

This means a fix will need to be made on the SDK side rather than the EOCV side.

[jmaten]

Thank you for the follow up. We added a grounding strap and put some anti-static spray on the wheels. Found that there was actually a white paper about static electricity issues with FTC robots, especially with mecanum wheels. Trying to isolate what we can from possibly touching the field frame. Try as much as we can to reduce the chances of it happening. The SDK update to 8.1 helped with reconnection after a connection issue.

…

On Thu, Dec 1, 2022 at 6:29 PM Windwoes ***@***.***> wrote: Investigation seems to indicate this is an SDK bug; namely a deadlock inside UvcDevice. This means a fix will need to be made on the SDK side rather than the EOCV side. — Reply to this email directly, view it on GitHub <#57 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJPQBATPRZL3S26ZZLTV63WLEYFHANCNFSM6AAAAAASIF3XX4> . You are receiving this because you commented.Message ID: ***@***.***>

[Windwoes]

This will be fixed by a patch in the upcoming FTC SDK v8.2