UVC Webcam functional on Control Hub USB 2.0 port but fails to initialize on 3.0 port #1428
Comments
|
Of possible interest: If we put a powered USB Hub (like the Rev UltraUSB Hub) in between the Control Hub 3.0 port and the webcam, the failure mode shifts to this: |
I believe the smoking gun is here. Some webcams are not tolerant of USB device resets, and it looks like this is one of them. Skipping the USB device reset was one of the workarounds needed to support the Arducam OV9281 in SDK v8.2. If you're feeling adventurous, you could try adding your camera's VID and PID to the |
|
Thank you! We are definitely adventurous! However, modifying the SDK at the C++ level and rebuilding the libraries and getting those rebuilt libraries incorporated in our Android Studio build would be a new journey for us. Are there some documents around describing how to do this in general with the SDK? We think we understand the change to the code you are proposing, but not so clear on how to edit/rebuild that library? |
|
The link I sent points to Extracted-RC, which is already set up to allow you build the SDK entirely from library sources. You should just be able to clone the repo and build in AS like any other project. |
|
Do you happen to know what versions of Gradle and the Gradle JVM should be used to build this project in AS LadyBug? We have tried various combinations of gradle 8.5/8.9 and Gradle JVM 21/17 and no luck so far. Haven't gotten past gradle sync. Here is the gradle sync error with 8.5 and 17: |
|
I haven't tried to build it from Ladybug, you might need to do a side by side install of an earlier version of AS. |
|
Backed up to last release of AS Koala and it built no problem with our tweak to libuvc_internal.h. That was with jbr-17 and gradle 7.2 Thanks! To incorporate this into our build, is it as simple as copying the generated "~/FTCRobotController/build/outputs/aar/FtcRobotController-debug.aar" over to the corresponding directory in our team AS project? Or perhaps the entire contents of the ~/FTCRobotController/build" directory? Or even the entire ~/FTCRobotController/" directory? |
|
Let's start with just trying to run a sample vision OpMode from Extracted-RC and see if it fixes the issue. |
|
Good point. Tried a controlled experiment:
Sadly it died during initialization. Seems like something is amiss in the Extracted-RC build we did (fork/clone/build in AS). |
|
Ooops, looks like I forgot to bump some dependency versions in the gradle script for Extracted-RC when it was updated to 10.0. Can you edit this dependency block to have the following versions? |
You're truly a team saver Windwoes! Much appreciation for your help. We could use a couple more hints: (1) We were not quite able to decipher the way the VID and PID are being used in libuvc. We see the 16 bit shifts, but we are a bit confused because the existing Arducam you had support for only had a 3 byte VID (0xC45) while most of the others have 4 bytes. We can report that the log reports this for our Arducam: (2) We think the way to integrate this change into our robot build is to add a "libs" folder to our project and move the generated "~\Extracted-RC\RobotCore\build\outputs\aar\RobotCore-debug.aar" file from Extracted-RC to that new libs folder. Then we need to add this to the repositories block in build.dependencies.gradle: And then replace this line in the implementation block Thank you SO much! |
The VID is still 4 bytes, but the leading 0 is just implied. For structuring the case you'd just want to add your VID and PID to case makeVidPid(VENDOR_ID_ARDUCAM2, PRODUCT_ID_ARDUCAM_B0454):
Yeah that's roughly the right idea, but you might have issues with the other libraries that have a transitive dependency on RobotCore. You might have to add a gradle exclude block to those to block them from still trying to pull RobotCore from maven. However it may just be easier to copy-paste your TeamCode source files into Extracted-RC and use that as your primary repo. The other question though is one of legality. In the past, the game manual expressly prohibited modifying the portions of the SDK which are packaged as binary |
|
Thanks for the heads up. We are so close. We modified the uvc code as you suggested and tested and its all good. Now just a matter of incorporating that tweak into our build. We tried adding the updated robotcore aar to our build but couldn't even get gradle to find it on a sync. We'll keep working on that. We also tried incorporating our code (and a couple of additional library dependencies like Acme Dashboard) into our fork of Extracted-RC but that build failed with a cascade of duplicate java symbols like this:
Thoughts on that? |
This smells very strongly of one or more library authors incorrectly using |
|
Note the following on the FTC Dash readme:
|
|
Ahh! That was probably the issue with our attempt to build inside of Extracted-RC. Thank you! In the meantime, we thought we would try something really clever. So we set up a local maven repository on our build computer, used maven to "install" the updated version of the RobotCore aar file there with the same maven coordinates as the original version, then added a line to the repositories section above all the others that pointed to our local repository. To our delight it built, with one small issue where, for some reason, the transitive dependency from RobotCore to threetenabp didn't register. Adding that dependency to our build.dependencies.gradle resulted in what we thought was a successful build. However, when we installed it on the ControlHub, things went south quickly. The RobotController app couldn't successfully initialize and we had to do a factory reset to get it back...as you said up front, quite the adventure! We'll try it the way you suggested (from inside Extracted-RC) again with the exclusion you pointed out above. THX! |
|
Some more good news! Those exclusions did the trick. Here is our modified build.gradle (TeamCode module) that pulls in the two external libraries we use (both built on the FTC SDK): The only other tweak needed was a bump in the minSdkVersion from 23 to 24 since our NeoDriver library declared a minSDKVersion of 24. We made that change in build.common.gradle. We've built the RobotController with our code and robot config files on several machines, successfully installed it on the Control Hub, ran our test code for calibrating our computer vision (with the arduCam plugged into the USB 3.0 port), and all seems well. If there are other issues with the build, perhaps they will manifest as we run through the rest of our testing. We think this completes our adventure for now. Thank you again for helping us out with this, it was very educational and will put our minds at ease regarding wifi disconnects. If support for the ArduCam B0454 were to make it into the next minor release of the SDK, or even a team configuration of some sort to disable the USB reset on the webcam (since that seems to be a common issue), that would be really great. We think the B0454 could be an interesting solution for many teams. It's relatively inexpensive ($32 on Amazon), has a much wider field of view than anything comparable, and has a very small form factor that can be incorporated into many builds. It led us to learn quite a bit about lens and perspective distortion and how those can be fixed in OpenCV as well. THANK YOU! |
|
Happy to help |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a UVC webcam (ArduCam B0454) we have been using successfully this season on our Control Hub 2.0 port. We would like to move it over to the USB 3.0 port. When we do, the webcam is recognized on the USB bus and can be configured, but the FTC libraries fail to bring it online. Given that USB 3.0 is theoretically backward compatible with USB 2.0 devices, this is surprising. Below is what we see in the log when we try this. Emphasis added on a few lines.
We are keen to make this change to avoid the documented issues with the wifi chip and USB 2.0 port sharing a power supply, leading to disconnects. We had understood that it was also possible to connect a UVC webcam to the control hub USB C port, but cams connected that way are not recognized on the bus during configuration.
We would greatly appreciate any insights on how we might make this work.
Thank you,
The text was updated successfully, but these errors were encountered: