Fixes#1564. Also copies vendordep JSONs to the examples as advised by
Thad. Removes unused shared/javacpp/setupBuild.gradle. Also removes
unnecessary `chmod +x gradlew` from CI workflows.
Instead of writing the kernel logs to the photonvision logs, this will
download them in the same zip file as the photonvision logs. Only includes dmesg logs from the current boot, which is fine since we should capture most of them in our logs now.
ARM-based machines populate the device model into Device Tree. We can
use this information to automatically detect and report the hardware
model for most Single Board Computers (SBCs). Vendors who want to
override this can still do so via the value in the configuration
database.
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.)
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.
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.
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.
The target list in networktables is limited to 127 items. When you
capture more than 127 calibration images it breaks this limit and errors
out and dies. Do not publish calibration targets to nt. And also move cal images into their own folder
This PR is for part 1 of #1354. It focuses on adding a model selection
interface for models that exist in `photonvision_config/models/`. Upon
completion we can ship more than 1 model and users could upload their
own through `ssh` without deleting the shipped model. This PR also adds
the abstractions need to support more DNN backends (say OpenCV, or RPI
AI Kit)
Up next is adding a CRUD interface for managing models through the UI.
Uses logic in
https://github.com/PhotonVision/photon-libcamera-gl-driver/pull/16 to
push the ov9281 down to its true minimum exposure.
Updates UI to list the exposure settings in ~~microseconds.~~ Native
units - not everyone works in microseconds.
Does its darndest to actually try to set the exposure in
~~microseconds.~~ Native Units. To do this...
Lifecam is funky when doing this - [cscore limits the exposure settings
to certain quantized
values](https://github.com/wpilibsuite/allwpilib/blob/main/cscore/src/main/native/linux/UsbCameraImpl.cpp#L129).
Add a new camera quirk to allow that.
~~Updated camera quirks to re-evaluate every camera load (rather than
recalling from settings - this shouldn't be necessary)~~ This should be
rolled back, needed for arducam type selection.
Updated camera quirk matching logic to make PID/VID optional, and
basename optional (and only match trailing characters). This enables
mirroring CSCore's logic for identifying lifecams by name.
Updated the USBCamera to primarily use cscore's exposed property names.
Since camera manufacturers use a potpourri of names for the same
thing....
For nice-to-have settings: new soft-set logic to try all possible names,
but gracefully pass if the property isn't there.
For required settings: Search a list for the first setting that's
supported, fail if none are supported.
More logging of camera properties to help debug.
Note: most of this work is because cscore doesn't directly expose a
massaged exposure-setting-absolute API (and, given what we've seen,
probably _shouldn't_, this struggle is not for the faint of heart).
---------
Co-authored-by: Matt <matthew.morley.ca@gmail.com>
