Two webcams with one VisionPortal each

Software Vision Processing
21

I think I found the issue.

I took the hint, and created a new opMode using the code you provided above. I then extended it slightly to use 3 cameras on 3 VisionPortals and discovered that…it works. 2 of the 3 viewports are blue screens but this should be expected given that the logitech 270’s are running at 640x480, through a single hub, with default image compression (from the doc: Under the legacy YUY2 format , one webcam or the other (on a shared hub) may stop streaming above roughly 640x360 resolution. This is below the default resolution of 640x480.)

I modified the code a bit further to stopStreaming() on each portal immediately after it starts streaming and wait for CAMERA_DEVICE_READY before building the next portal. I also added some gamepad controls to “switch” between portals by calling stopStreaming() on the “current” portal and "resumeStreaming() on the “new” portal. Again, everything works fine, one camera at a time.

This was tested both with a powered and unpowered USB hub confirming (I think) the suspicion that the issue in this case, was not about USB power.

So then I started adding in the additional embellishments that were present in the test bed described above. A single line reproduced the issue:

            .enableLiveView(true)

When this line was added to the VisionPortal builder, the portal would hang in the OPENING_CAMERA_DEVICE state. If the passed in parameter is false, everything works as expected.

So we’ll modify our code so enableLiveView() is only called when we want it set to false and I think the kids are back in business.

I would appreciate knowing if:
A) you can reproduce this (try adding .enableLiveView(true) to your VisionPortal builder)
B) If you can reproduce this, is it a bug or expected behavior?

Thanks!

22

I have not tried to reproduce this yet, but I can say it is probably expected behavior.

Note the implementation of enableLiveView (in particular the last line):

        /**
         * Configure the vision portal to use (or not to use) a live camera preview
         * @param enableLiveView whether or not to use a live preview
         * @return the {@link Builder} object, to allow for method chaining
         */
        public Builder enableLiveView(boolean enableLiveView)
        {
            int viewId;
            if (enableLiveView)
            {
                viewId = DEFAULT_VIEW_CONTAINER_ID;
            }
            else
            {
                viewId = 0;
            }
            return setLiveViewContainerId(viewId);
        }

Also note the javadoc comment for setLiveViewContainerId:

        /**
         * A more advanced version of {@link #enableLiveView(boolean)}; allows you
         * to specify a specific view ID to use as a container, rather than just using the default one
         * @param liveViewContainerId view ID of container for live view
         * @return the {@link Builder} object, to allow for method chaining
         */
        public Builder setLiveViewContainerId(int liveViewContainerId)
        {
            this.liveViewContainerId = liveViewContainerId;
            return this;
        }

When using multi portal, you should be setting the container ID, not using enable live view.

What’s happening when you use enable live view on both, is that you are asking both portals to insert a view in the same UI layout element and it evidently cries when you try to do that.

23

Ah. Thank you for that insight.

Then is there a mechanism for indicating (on a per VisionPortal basis) whether a “live view” (e.g. RC “screen” view) of that portal should be enabled or not?

I suppose one could let it be enabled by default and then use stopLiveView() and resumeLiveView() as needed?

24

If you don’t want a live view with multi portal, you can set the live view ID to 0.