Crash in easyopencv when attempting to stop streaming on a VisionPortal

Software Vision Processing
1

For an orderly shutdown of Autonomous we are attempting to disable a processor, stop streaming on the VisionPortal instance, and then call close() on the VisionPortal. The call to disable the processor completes but then on the next call to stopStreaming(0 we get this in our matchlog
--------- beginning of crash
11-21 09:37:52.323 1723 1964 E AndroidRuntime: FATAL EXCEPTION: Thread-48
11-21 09:37:52.323 1723 1964 E AndroidRuntime: Process: com.qualcomm.ftcrobotcontroller, PID: 1723
11-21 09:37:52.323 1723 1964 E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke interface method ‘void org.openftc.easyopencv.OpenCvCamera.stopStreaming()’ on a null object reference

Nowhere do we access easyopencv directly - we only use the VisionPortal.

Thanks,
Phil Young
FTC Team 4348

2

The VisionPortal uses EasyOpenCV on the backend. EasyOpenCV is used for all VisionPortal displays on the Driver Station and Robot Controller, and is also used to perform all AprilTag detection.

I’m sure you probably realize this, but I am going to say it for those who may not be aware, in order to safely clean up you generally have to work in reverse order of how you started it up - this goes for virtually all resource allocation use, not just the VisionPortal.

From your description, it’s difficult to tell that you’re following the proper steps. Can you post the appropriate snippet of your cleanup code so we can ensure the resources are being torn down in the appropriate sequence?

-Danny

3

Note that VisionPortal automagically performs an orderly shutdown when the OpMode is stopped regardless of whether the user tries to manually teardown anything or not.

Could you post a minimal, complete, and verifiable example OpMode that demonstrates the issue? From looking at the implementations, I think what is happening is there is a race condition between the automatic cleanup and your manual cleanup.

4

OK, I have a reliable test case based on the sample ConceptAprilTag. This week we’re desperately getting ready for our Meet 2 next weekend but I should be able to find some time to create a Gist.

5

Here is the link to a public gist that contains my modified version of ConceptAprilTag and the matchlog of the crash.

6

I was wondering if there has been any progress on this crash. Yes, there is a work-around, which is to do nothing and let the built-in cleanup run its course. but the test case clearly reproduces the problem. Thanks.

7

I haven’t had an opportunity to really take a look yet with finals and projects, but now that the semester is over I plan to take a look soon.

8

Based on what I read before, you can disable the processor, you can stop the stream, but when you want to close the visionportal, you really need to think twice before doing that, as this may cause crash.

9

Okay, I can reproduce this with a very simple test case:

@TeleOp
public class PortalCrash extends LinearOpMode
{
    @Override
    public void runOpMode() throws InterruptedException
    {
        VisionPortal portal = VisionPortal.easyCreateWithDefaults(BuiltinCameraDirection.BACK);

        waitForStart();

        while (opModeIsActive())
        {
            sleep(1);
        }

        portal.stopStreaming();
        portal.close();
    }
}

It is a race condition, but it’s a little different than what I thought at first.