OpenPnP on Raspberry Pi 4 #60
Comments
|
Seems like someone should write a integration for https://libcamera.org/ |
|
Initially this started out with a java.lang.UnsatisfiedLinkError error failing to load libopenpnp-capture.so. I was able to resolve this issue by downloading the current release and copying the library to the proper location (cp /home/pi/Downloads/libopenpnp-capture-ubuntu-latest-aarch64.so /usr/lib/libopenpnp-capture.so). I am now able to instantiate a OpenPnpCaptureCamera instance however the Device Settings tab all available devices either don't list a format (unicam) or list a format as: 0 x 0, 0 FPS (bcm3835-isp). Using libcamera-hello to list the available cameras reports the following: pi@raspberrypi:~/Downloads $ libcamera-hello --list-cameras Available cameras0 : imx219 [3280x2464] (/base/soc/i2c0mux/i2c@0/imx219@10) I can see the cameras output if I try: libcamera-hello --camera 0 --timeout 60000 |
|
Please try on v0.0.25 and reopen if you are still seeing this. |
|
Please re-open this ticket. Downloaded v0.0.25 from https://github.com/openpnp/openpnp-capture/releases/download/v0.0.25/libopenpnp-capture-ubuntu-latest-arm64.so and moved to /usr/lib as requested. pi@raspberrypi:/usr/lib $ md5sum libopenpnp-capture.so Downloaded latest OpenPNP build. |
|
https://www.raspberrypi.com/documentation/computers/camera_software.html#v4l2 pi@raspberrypi:/usr/lib $ lsmod | grep bcm2835 |
|
The reported camera modes from libcamera are all raw Bayer. You'll need to find an interface that gives YUV or MJPEG I believe. |
|
|
|
Can you provide any assistance here as it seems like you wrote the arm camera stack (#47). |
|
@darkomenz Can you please download the openpnp-capture test app and see what it reports? You'll need to have the v0.0.25 libopenpnp-capture.so in your path or in the same directory as this binary. Here's the output from my machine, for reference: |
|
I tried your suggestion but your test application seems to be linked against a older version of : pi@raspberrypi:~/Downloads $ wget https://github.com/openpnp/openpnp-capture/releases/download/v0.0.25/openpnp-capture-test-ubuntu-latest-arm64 openpnp-capture-test-ubuntu-latest-arm6 100%[=============================================================================>] 23.09K --.-KB/s in 0.003s 2023-03-28 13:31:48 (7.89 MB/s) - 'openpnp-capture-test-ubuntu-latest-arm64' saved [23648/23648] pi@raspberrypi: It should be looking for capture.so.0.0.25 correct? |
|
For testing I was able to also try this: pi@raspberrypi: ./openpnp-capture-test-ubuntu-latest-arm64: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./openpnp-capture-test-ubuntu-latest-arm64) |
|
pi@raspberrypi:~/Downloads $ strings /usr/lib/aarch64-linux-gnu/libc.so.6 | grep GLIBC |
|
Please remove all the existing copies of libopenpnp-capture.so, including versioned ones. At that point, running the test app should fail to find libopenpnp-capture.so. It should not be looking for a specific version. Then grab the 0.0.25 so file, rename it to libopenpnp-capture.so (no version) and try the test app. There should be no versioned filed, and the test app should not be looking for a specific version. Thanks, |
|
Test app does seem to have a NEEDED entry for the versioned .so: /opt/nvidia/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-objdump -x ~/Downloads/openpnp-capture-test-ubuntu-latest-arm64 | grep NEEDED GLIBC 31 implies @darkomenz is on Focal but the test app seems to have been compiled on Jammy. This is one of the reasons I really dislike Ubuntu. |
|
Thanks @ian-arkver, so are there two issues?
Is that correct? I am wide open to ideas about improving the Linux builds. Here is how it is done currently: https://github.com/openpnp/openpnp-capture/blob/master/.github/workflows/build.yml#L119 Could be this is a simple issue of just building with a different version of Ubuntu? Here are our options:
And of course we could always Dockerize it to use any version we want. So, if anyone who knows this stuff can suggest improvements, please do! |
|
In the past when shipping binaries to down-rev Ubuntu folks the easiest way was to compile on an older Ubuntu VM, yeah. I'd probably go with 18.04 until GH cans it, then move to the oldest available. There may well be Better Ways (tm). I grabbed the x86 versions of the lib & test app and ran it on my PC with my old webcam. Worked fine once I'd symlinked the .so as the versioned one it was looking for. But I'm on Manjaro with GLIBC version 2.37. |
|
This is probably a Better Way, but looks non-trivial. I've not tried it. |
|
fyi, master CMakeLists has this: set(OPENPNP_CAPTURE_LIB_VERSION "0.0.24" CACHE STRING "openpnp-capture library version") I'd guess it's something in the CMake stuff rather than the CI yaml that's causing this to be baked in. |
|
https://discourse.cmake.org/t/linking-against-non-versioned-or-major-library/3931/2 SONAME is set from the SOVERSION above and I guess that's what's linked against in the test app's target_link_libraries. |
|
Okay, that looks like the culprit - thank you! So I'll downgrade the runner, fix that version, and push a new release. Hopefully that will resolve it. |
|
Yeah, it'll still be looking for *.so.0.0.25 though. (or .26 or whatever it's set to) |
|
I think the thing here is the difference between VERSION and SOVERSION, which you've set the same. https://cmake.org/cmake/help/latest/prop_tgt/VERSION.html#prop_tgt:VERSION VERSION should be the fully dotted release version, but SOVERSION should be the "ABI Compatibility version". I tried setting it like this... now cmake builds these... and the test executable has this... |
|
Ok so I have decided to try to build from source and run the unit test just to see what happens. pi@raspberrypi: Quoted variables like "var" will no longer be dereferenced when the policy CMake Warning (dev) at linux/contrib/libjpeg-turbo-dev/cmakescripts/GNUInstallDirs.cmake:187 (if): Quoted variables like "var" will no longer be dereferenced when the policy -- CMAKE_INSTALL_BINDIR = bin (/opt/openpnp-capture/bin) For compatibility with older versions of CMake, option is clearing the CMake Warning (dev) at linux/contrib/libjpeg-turbo-dev/CMakeLists.txt:160 (option): For compatibility with older versions of CMake, option is clearing the -- Shared libraries enabled (ENABLE_SHARED = 1) |
|
I also checked what v4l2-ctl and libcamera-hello says about the attached cameras. pi@raspberrypi:~/Downloads/openpnp-capture/build/linux/tests $ v4l2-ctl --list-devices bcm2835-isp (platform:bcm2835-isp): unicam (platform:fe800000.csi): unicam (platform:fe801000.csi): rpivid (platform:rpivid): pi@raspberrypi:~/Downloads/openpnp-capture/build/linux/tests $ libcamera-hello --list-cameras
|
|
I'm not that familiar with RPi camera setup. It looks like they've split the CSI and ISP drivers into separate video nodes and these are now mediactl devices. Libcamera hides this behind a friendly layer. Does libcamera-hello actually display the capture ok? For OpenPnP-Capture, I don't know if this code makes use of libcamera. If not, it's quite probable it doesn't support the RPi mediactl pipeline setup. |
|
You might be able to script the mediactl pipeline setup to connect the CSI to the ISP and then use one of the ISP capture nodes with openpnp-capture, but mediactl pipelines are a bit "dark arts". Anyhow, I don't have an RPi to test with and help you. I suggest you ask around on the RPi forums to see if this can be done - the aim being to capture YUYV on a plain V4L2 device node. 6by9 is usually very helpful. |
|
Hello @ian-arkver, I am trying to develop a openpnp controller based on the Raspberry Pi Compute Module 4. libcamera is an open source camera stack for many platforms with a core userspace library, and support from the Linux kernel APIs and drivers already in place. It aims to control the complexity of embedded camera hardware by providing an intuitive API and method of separating untrusted vendor code from the open source core. libcamera aims to encourage the development of new embedded camera applications by limiting the complexity that developers have to deal with. The interface is designed around the way that modern embedded camera hardware works. |
|
Oh and as for your earlier question yes the libcamera-hello application works without issues and I can take pictures from both attached cameras. |
|
um... and? Libcamera FAQ #1 quoted? Not sure what your point is. When the Pi OS people moved away from what they called the "Legacy Stack" they completely changed the camera API. Yes, you can hide that behind libcamera, but that requires the app (here openpnp-capture) to support libcamera's API. If this repo doesn't support that particular platform and that particular library then that support would need to be added to enable it. Contributions welcome. Or it may be possible to configure the pipeline with a script, as I suggested, i.e. to basically do what libcamera is doing for you (unless libcamera is also physically passing buffers from one driver to the other). This is common practice for mediactl pipelines on many platforms, but it's tricky to get the syntax and parameters right. It's not really a "work around". But you'll get more support on an RPi specific forum than here I think, i.e. from people who actually have the hardware and have probably done it before. [ps: Since libcamera-hello works you could try dumping out the pipelines with media-ctl -p while a libcamera app is running. Then you might be able to recreate them.] |
|
Hello @ian-arkver, If I install 32bit Raspbian this library works without issues. As OpenPNP recommends 8gb of memory on the Build FAQ this implies that a 64bit os is recommended and so it was tested and found to be in a unusable state. Right now we know that its broken but the root cause is yet to be determined. Can we focus on finding the root cause instead of work arounds for the moment? Regards |
|
Folks, I think Ian has found the issue with the library versions. I just haven't had a moment to fix it. Please be patient. |
|
I'd guess the "root cause" is that 32 bit Raspbian uses the "Legacy Stack" and the new 64 bit os doesn't, and that doesn't work out-of-the-box, without some pipeline setup. Anyhow, I'm out of ideas. Good luck! |
|
Hello @ian-arkver, I am not so sure as raspi-config has the option to enable the legacy stack and it does not resolve the issue.
pi@raspberrypi:~/Downloads/openpnp-capture/build/linux/tests $ ./openpnp-capture-test Regards |
|
From my reading earlier the Legacy Stack doesn't have unicam drivers. Your log looks unchanged. I'd definitely recommend chatting to someone on the RPi forums. To be honest, I'm guessing here and as I said I've no hardware to test & repro on. |
|
One last comment - you are blazing a trail into the unknown here. I don't think anyone has used this on Raspi with CSI cameras before. Previous aarch64 support has been for UVC cameras or CSI Cameras on other platforms (eg. Apple, nvidia). This will require work done to make it work so don't be upset if it takes time and effort. |
|
Okay, I've merged the changes @ian-arkver suggested - thank you for that! As long as the build looks good I'll release this as v0.0.26 and update OpenPnP as well. |
|
Hello @vonnieda, Can we keep this ticket open until the fix that you have proposed is confirmed to resolve the issue that has been mentioned in this thread? Regards |
|
@darkomenz Yep, keeping it open. It was auto closed by the commit message so I reopened it. |
|
This is odd. The library only calls up GLIBC_2.17 and all the functions bar one in the test app are also pulled from 2.17. But the main entry point is still using 2.34... aarch64-none-linux-gnu-objdump -x Downloads/openpnp-capture-test-ubuntu-20.04-arm64 | grep GLIBC_2.34 Don't really know why this would be. Not a clean build perhaps? |
|
Hello @ian-arkver, The os is available from: https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-64-bit pi@cm4-pnp:~ $ objdump -x /lib/aarch64-linux-gnu/libc.so.6 | grep GLIB pi@cm4-pnp:~ $ strings /usr/lib/aarch64-linux-gnu/libc.so.6 | grep GLIBC Regards |
|
I can try to build from source again but likely will result in the same issues as last time. |
|
It seems libcamera includes a gstreamer plugin which could be used to capture video for GStreamerCamera, in theory. https://github.com/raspberrypi/libcamera#using-gstreamer-plugin |
Any update on the 64bit arm camera pipeline. Its broken on https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-64-bit
The text was updated successfully, but these errors were encountered: