I made a mistake when cherry-picking things into #1534. Fixing it also
prompted me to regenerate message things without thinking even though it
wasn't needed here but it helped me catch an issue with a bad shim. I
must not have saved it properly on my computer and missed it before
review.
I found these with a quick find-and-replace and checked against the inbuilt Python type checking. I am away from my robot and can't really
confirm there are no flow-on effects. There are no other active usages of the bad casing in the Python code, so we should be good. The generated serde messages already use this casing, so we don't need to update there.
List types should never be optional if sent to NT because an empty list conveys the same
thing.
The equivalent C++ struct takes the same approach with empty vectors rather than an optional vector.
Fixes GPL violation, the license has been missing since 2024.
This also puts licenses in as many JARs and native library archives as possible (for good measure.)
We've moved the install script to photon-image-modifier. This updates
the install script in photonvision to just download and run the
install.sh from photon-image-modifier.
This is quite an odd issue/fix.
So this is what happened... Photonvision booted with the camera
connected and the camera was working...
After a short time the camera stopped working (for some reason maybe
static, maybe temp, maybe wiring, idk).
During this time pv showed
Jul 04 06:25:18 BackLeft java[643]: [2024-07-04 06:25:18] [CSCore -
PvCSCoreLogger] [ERROR] CS: ERROR 40: ioctl VIDIOC_QBUF failed at
UsbCameraImpl.cpp:723: Invalid argument (UsbUtil.cpp:156)
Jul 04 06:25:18 BackLeft java[643]: [2024-07-04 06:25:18] [CSCore -
PvCSCoreLogger] [WARN] CS: WARNING 30: BackLeft: could not queue buffer
0 (UsbCameraImpl.cpp:724)
I went over and played with the wire. The camera fully disconnected but
it ended up "reconnecting"
When the camera was "reconnected" photonvision detected a "new camera"
except this time with no otherpaths (aka no usb path, or by id path).
That resulted in pv creating a new camera configuration for a camera
with no otherpaths
Cscore then started to report errors that look like it attempted to
connect to the same camera twice
This fixes it by filtering out USB cameras that have no otherpath on
linux.
# Overview
Previously if the coproc came up later, getProperty would return the
string literal "null", which made us print the BFW. Add tests to make
sure that we don't do that anymore by rebooting a sim coproc +
robot in a combination of different orders.
There is a weird edge case at least with arducam/broken arducams/used
arducams where cscore will see it when pv starts but not be able to
connect to it. If we always read out the "current" video mode instead of
null when it is disconnected things will work. If the camera is
disconnected while we try to change the video mode when we get the
current video mode it will tell us what we wanted to set it to. Then
when the camera reconnects it will be in that video mode.
This prevents spamming of the logs by the network interface device
monitor by:
- checking to make sure the device file exists before starting the
monitoring task
- only logging once if it throws an exception, but keep trying in case
the exception is transient
Also reworks OV9782 defaults. Probably doesn't work on windows. We should hide these sliders probably.
Co-authored-by: Cameron (3539) <theforgelover@gmail.com>
This bug would only appear when there are cameras with the same naming.
Old config matching would also match using the by-id this was
problematic. When one camera is disconnected it would assign the by-id
path to the other camera with the
same name. When the camera is replugged in it would not be reassigned
the by-id path and would fail the camerainfo equals check.
Sliders for exposure and brightness would spam messages on the backend.
This used to cause crashes and can cause it to get quite laggy /
delayed. This will add a 20ms debounce which won't send the value to the
backend until the value hasn't changed for 20ms.
---------
Co-authored-by: Matt <matthew.morley.ca@gmail.com>
This PR changes the way that photonvision interacts with nmcli to control networking on the coprocessor. Instead of modifying an existing connection, Photonvision adds new connections for DHCP and Static IP configurations. It then activiates the proper one at startup and any time that the network configuration is changed.
It also now uses the interface name and not the connection name and checks that the interface is available before making any changes. If the saved interface is not found, it updates the stored interface name and applies the network settings to the current interface. This should minimize the failure to control the network if the network interface wasn't available when PhotonVision first booted.
One other benefit of not altering the default configuration is that, if PhotonVision fails to run for any reason, the device can be accessed using the original networking configuration.
The code has been tested on an OrangePi5 and and a Raspberry Pi 4.
Addresses: #1261
Rotate camera calibration coefficients based on camera rotation. Probably. Seems to work. Maybe.
---------
Co-authored-by: Matt <matthew.morley.ca@gmail.com>
We accidentally copied more settings then we wanted. This adds an
annotation that we can mark variables with that will prevent them from
being copied when we switch pipeline types.
