MNT: Migrate connectivity logic from UI to Connector class

[vaughantnrc]

Connectivity buttons have been removed from the various panels, except for the Connector panel. The Connector panel now allows you to start either "Detectors Only" or "Detectors and Solvers". The state is now expected to persist across transitions between tabs.

[keiranbarr]

David (Windows) and I (Linux) have tested this on three configurations:

1. Running locally with USB webcam
2. Connected to pi detector, which is running the old code, while the local machine (pose solver and gui) runs the new code
3. Connected to pi detector, which is running the new code, along with the local machine (pose solver and gui)

Setup 1 works for David but the image and marker update is very slow. It does not work for me however, as the detector is unable to open the USB device.
Setup 2 works for both of us, but is very slow on David's setup. With my setup the image is not visible at first and poor when dialed in, same as #3 below.
Setup 3 has the preview frame not visible at first. Even after dialing in the capture settings to make the frame visible, the image quality and detection is poor--with markers only occasionally being detected.

In addition, the GUI is prone to crashing on my machine, which can be caused by:

• selecting "annotate rejected markers"
• starting image preview before capture parameters have been sent

On my machine I am also not able to load/view calibration images.

[vaughantnrc]

Thanks @keiranbarr and @Rampex1 , this is helpful. I'll try to figure out why you're getting these behaviours.

[vaughantnrc]

As per discussion, it appears as though there are two issues at play here:

1. we are currently using a parameter set that has been tuned for OpenCV, and it does not work well for the picamera implementation. See Use different parameter structures (including defaults and ranges) depending on the camera driver (OpenCV vs picamera2) #32
2. For Keiran, clicking on preview image immediately after selecting detector results in GUI hang

I will investigate the second issue, the first will be resolved separately

[keiranbarr]

Code looks good and works fine for me

[Rampex1]

I am getting an error when clicking on preview image in the detector panel.
[[gui at 2024-06-28T15:21:58.696535]]: ERROR - Received error: Internal error. Failed to process request series.
I'm not sure if this is related to my camera at home, but my camera is working fine on the main branch.
As for the code, i scanned through it and it looks good.

[vaughantnrc]

I am getting an error when clicking on preview image in the detector panel. [[gui at 2024-06-28T15:21:58.696535]]: ERROR - Received error: Internal error. Failed to process request series. I'm not sure if this is related to my camera at home, but my camera is working fine on the main branch. As for the code, i scanned through it and it looks good.

Do you have any other information or error text? It is probably worth checking the console/terminal outputs too

[Rampex1]

All the code is working properly. The only thing is that the detector with IP 192.168.0.101 seems to be having trouble detecting the aruco markers. This is probably more related to the camera itself rather than the code, so should be okay to merge.

[keiranbarr]

I investigated David's issue above and it doesn't seem to be related to the camera. The Pi at 192.168.0.101 is running the new code while the one at 192.168.0.102 is running the old code. If I power both down and switch SD cards then it switches: the Pi at 192.168.0.102 is unable to detect well, while the one at 192.168.0.101 works fine. I think this is related to getting and setting the default capture parameters of the Pi Cameras, because I had noticed issues before with the capture image being poor by default on the Pi's running the new code. However, I have been unable to visually verify that the image quality is indeed worse, because I cannot preview the image without hanging the GUI.

[vaughantnrc]

In that one capture it looks as though the markers in the middle of the image are generally being captured and the ones around the outside are generally not. I wonder if it's an effect of the lens distortion. We might try undistorting the image before processing it, though that will incur some processing overhead.

I'll take a look too to compare the two cameras.

I think this work can be merged. Though we may have found a few new issues to investigate.

However, I have been unable to visually verify that the image quality is indeed worse, because I cannot preview the image without hanging the GUI.

Though it does still work if you run through VSCode?

[keiranbarr]

Though it does still work if you run through VSCode?

When I run through VSCode, the detector running the old code works as expected, but strangely the detector running the new code causes the GUI to hang when trying to preview image. From bash, connecting to either detector and trying to update the preview causes GUI hang.

[vaughantnrc]

I think this is related to getting and setting the default capture parameters of the Pi Cameras, because I had noticed issues before with the capture image being poor by default on the Pi's running the new code.

#32

[vaughantnrc]

When I run through VSCode, the detector running the old code works as expected, but strangely the detector running the new code causes the GUI to hang when trying to preview image. From bash, connecting to either detector and trying to update the preview causes GUI hang.

#58

[vaughantnrc]

I am getting an error when clicking on preview image in the detector panel. [[gui at 2024-06-28T15:21:58.696535]]: ERROR - Received error: Internal error. Failed to process request series. I'm not sure if this is related to my camera at home, but my camera is working fine on the main branch. As for the code, i scanned through it and it looks good.

I believe we figured this was due to a numpy update and is fixed in #51

[vaughantnrc]

In that one capture it looks as though the markers in the middle of the image are generally being captured and the ones around the outside are generally not. I wonder if it's an effect of the lens distortion. We might try undistorting the image before processing it, though that will incur some processing overhead.

Before trying undistortion, it may be worth trying different values for polygonalApproxAccuracyRate as per documentation at https://docs.opencv.org/4.x/d5/dae/tutorial_aruco_detection.html