Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disconnecting and reconnecting a webcam causes failures #57

Closed
NoahAndrews opened this issue Nov 22, 2022 · 11 comments
Closed

Disconnecting and reconnecting a webcam causes failures #57

NoahAndrews opened this issue Nov 22, 2022 · 11 comments

Comments

@NoahAndrews
Copy link
Member

NoahAndrews commented Nov 22, 2022

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.

@NoahAndrews
Copy link
Member Author

I can reproduce the issue 100% of the time.

@NoahAndrews
Copy link
Member Author

I can also reproduce this issue using a C615 webcam.

@jmaten
Copy link

jmaten commented Nov 23, 2022

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
Copy link
Member

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
Copy link

jmaten commented Nov 23, 2022

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
Copy link
Member

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
Copy link

jmaten commented Nov 23, 2022

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
Copy link
Member

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
Copy link
Member

Windwoes commented Dec 1, 2022

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
Copy link

jmaten commented Dec 2, 2022 via email

@Windwoes
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants