Skip to content

Add OV9782 support, optional support for libcamera 0.6+, and add arm64 sysroot JNI build helper#30

Open
SoZ0 wants to merge 5 commits intoPhotonVision:masterfrom
Prometheus-Dynamics:ov9782
Open

Add OV9782 support, optional support for libcamera 0.6+, and add arm64 sysroot JNI build helper#30
SoZ0 wants to merge 5 commits intoPhotonVision:masterfrom
Prometheus-Dynamics:ov9782

Conversation

@SoZ0
Copy link

@SoZ0 SoZ0 commented Feb 6, 2026

Summary

This PR adds OV9782 support (C++ + Java), makes control-setting behave better across mono sensors and cameras that don’t expose certain controls, and includes a helper script for building/publishing an arm64 JNI against a sysroot (Docker by default). It also makes the libcamera>=0.6 requirement optional so we don’t break existing build environments.

What changed

  • Add OV9782 camera model support in C++ and Java.
  • Update model parsing (stringToModel) and treat OV7251 as grayscale.
  • Make CameraGrabber::setControls check what controls the camera actually supports before setting them; handle mono sensors more cleanly.
  • CMake: add REQUIRE_LIBCAMERA_0_6 (default OFF) to optionally enforce libcamera>=0.6.
  • Build: make libcamera_meme optional (BUILD_CAMERA_MEME) and add tools/build_arm64_jni.sh for sysroot-based arm64 JNI builds.
  • Docs + ignores: README updates and a couple .gitignore additions for local build/sysroot artifacts.

How to use

Enforce libcamera 0.6+ (only if you want it):

cmake -B cmake_build -S . -DREQUIRE_LIBCAMERA_0_6=ON

Arm64 sysroot JNI build:

SYSROOT_DIR=/path/to/target/rootfs \
  MAVEN_LOCAL_REPO=/path/to/m2 \
  tools/build_arm64_jni.sh

# by default to avoid breaking existing environments.
option(REQUIRE_LIBCAMERA_0_6 "Require libcamera >= 0.6 (enforced via pkg-config)" OFF)
set(LIBCAMERA_MIN_VERSION "0.6" CACHE STRING "Minimum libcamera version when REQUIRE_LIBCAMERA_0_6 is ON")
if (REQUIRE_LIBCAMERA_0_6)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for 2027+, we should force everyone to use a new libcamera?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what the over arching goals are, so I did not want to force 0.6 if there was other issues with other platforms. I would recommend it as 0.6+ is stable now to my knowledge

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully this fixes (unofficial) Debian/RPiOS Trixie support again. I don't have the time to check this today, but maybe tomorrow.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like we currently install libcamera 0.5.2 -> https://github.com/PhotonVision/photon-image-modifier/actions/runs/22130709321/job/64030036864?pr=126#step:5:1477

I think @Gold856 was partially through compiling libcamera from source as part of this driver build, which would release us from our dependence on random rpi apt repos.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The RPiOS Trixie image has libcamera 0.6 preinstalled. While libcamera 0.5 is available, sufficiently removing 0.6 to install 0.5 is nontrivial.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I got libcamera 0.6 building completely independently. That's what I want to switch to for 2027. Still trying to work out how to ship the IPA files and stuff.

@@ -0,0 +1,134 @@
#!/bin/bash
Copy link

@mcm001 mcm001 Feb 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remind me why we should upstream this script, rather than the existing cross build setup? (Which granted only really works in CI or a real Pi)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes local dev much quicker and possible without access to direct hardware. I can swap it out with a full docker container so other environments can build easier or if its not wanted can be removed all together.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think that the current cross-compiling story kinda sucks/isn't there, so I do see value in having a blessed way to build outside of the pipeline. I'll think a bit harder on it but that broadly makes sense to me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants