Sorry for the problems you are facing. Indeed, as @PeterR stated, we have been using Jetson Nano revision A02, which has support for only 1 camera, that’s why you are having issues with the second camera to show up in a Revision B01, which has 2 camera ports.
We already order a B01 revision and it’s on its way to our lab. Once it arrives we will test and update the patches to enable the second camera.
Additionally, we will work on instructions to update the kernel, DTB and modules using deb packages, so it is easy for you all to update it when needed.
As mentioned above, I got it working by editing the DTB file by hand (the status: okay / disabledissue). I haven’t yet had time to try the very latest version from RidgeRun - the latest commit I used was from July 27th. I have only tried out the first camera port on a revision B01 board, and that works fine. My image is flipped but its easy enough to adapt the GStreamer examples to flip it back (use nvvidconv flip-method=2, see the documentation here).
Thrank you for your effort on making the HQ Camera work on Jetson.
I’m using a Jetson Nano B01 Module on a Auvidea J30B Carrier board (JN30B carrier board for Jetson Nano – Auvidea) . Is there a way to combine the DTB of Auvidea with the Drivers for the Raspberry HQ Camera? The described installation procedure will certainly cause conflicts…
There is not easy way to do that. You need to create a whole new DTB for that case. Not sure but Auvidea board may have different I2C buses, GPIOs, and CSI connections that need to be changed in the DTB.
RidgeRun can provide engineering support to do it. If you are interested you can send us an email to support@ridgerun.com
I’ve tried this twice today, but my imx477 sensor is never detected at boot up. Has there been any change since you guys updated the repository in the nvidia sources or jetpack? I had it working for a short while using arducams dtb file, but now when I wanted to start from scratch and do a clean install, it’s a no go… I don’t even see any signs of the 477 in the logs. Has anyone gotten this to work successfully on a new install? I rather not go buy a new camera before I’m sure it’s not a driver issue.
Thanks @DavidSoto-RidgeRun, I got it working but I had to first disable the imx219 driver from the kernel. I will put my questions on github from now on, cheers.
Hi Peter, Glad to hear that you got it working. Actually it is better if you post your questions here. People opened some issues in GitHub as well but the forum is the official way to get help with the driver. We hope to see the community using the driver and if some of you have any improvement to the driver please feel free to share it and we will merge it in the repo.
Ok, then I will continue to bug you guys here then :) I’m actually already on that particular issue on github (ClonedPuppy), but I will need to do one more clean install tomorrow and write down what doesn’t work before I open up the issue again. Just want to rule out any mistake from my end.
I hope I can help to implement some more features in the driver, right now it’s pretty bare bones. I’m impressed that you all managed to get a 4k stream working though.
I have uploaded a couple of debian packages that replaces the kernel image, modules and dtb, facilitating the IMX477 driver installation on Jetson Nano.
Please check the updated instructions in the Jetson Nano subsection of this guide.
You will also find a link to download both of the .deb packages in the guide.
Thank you for the Drivers. I am happy to hear the driver also supports B01.
I’m using jetson nano B01 with raspberry pi HQ camera. I installed Jetpack with Balena etcher not with SDK manager since my host OS is window.
I installed Debian package with “option A” instructed here and execute the pipeline below.
SENSOR_ID=0 # 0 for CAM0 and 1 for CAM1 ports
FRAMERATE=20 # Framerate can go from 2 to 60 for 1920x1080 mode
gst-launch-1.0 nvarguscamerasrc sensor-id=$SENSOR_ID ! “video/x-raw(memory:NVMM),width=1920,height=1080,framerate=$FRAMERATE/1” ! nvvidconv ! nvoverlaysink
And I got an error.
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:557 No cameras available
Got EOS from element “pipeline0”.
I connected HQ cameras at CAM0 port. Is there any way I can solve this issue?
Also, Does Debian package also supports to edit exposures?
Are there any plans for a DKMS package so when the kernel updates, the driver is rebuilt? Google does this with the Coral module and it’s fantastic – even working on Nano and surviving updates.
Also. I cannot manage to download the debian packages from your google drive. The download does not start. Perhaps the limits have been exceeded?
Hi @mdegans, we are not working on a DKMS package at this point. But we are working with NVIDIA in a long term solution now that the driver has been useful for the community. Please stay tuned.
Having the same problem as @riul5627k. Installed the Debian package on a clean build, removed the R8 resistor, but getting no camera found on GStreamer. Any advice on how to debug?
imx477 doesn’t show up in lsmod,
dmesg reports imx477_board_setup: errorduring i2c read probe (-121)
Thanks
Did you consider the hardware changes suggested in our wiki to get the cameras available on the i2c buses?
Denali, you can check if the camera is being detected by using the i2cdetect command.
If the cameras are still disabled it might be due to a hardware issue.
I’ve managed to get a Raspberry Pi HQ Camera working with my Jetson Nano without making any hardware mods to the camera.
The camera won’t work “out of the box” because it is designed to work with the Raspberry Pi that uses 3.3V logic levels on the ENABLE signal, rather than the 1.8V levels the Jetson Nano produces. While the 1.8V logic high from the Jetson is enough to turn on the camera’s voltage regulators, it is too low for the reset circuit to detect and thus the camera is held reset. Removing R8, as suggested by the folks at RidgeRun, effectively diconnects this reset circuit and allows the camera to function properly.
My alternative solution is to create a cable that incorporates a level shifter in the ENABLE line so that, even when driven by a Jetson Nano, the camera still sees the 3.3V logic levels on that line that it expects. I used a Texas Instruments SN74LV1T34 to do the level shifting, but as this is a low-speed signal, I can’t see any reason why a simple level shifter built from a couple of transistors and a few resistors wouldn’t work too.
The advantages of this approach are that it doesn’t involve modifying the camera (or Jetson Nano), and only involves soldering inexpensive components that are easily replaced. However, it does make the cable directional - plug it in the wrong way round and you’ll reverse the power rails on the level shifter circuit, which probably won’t end well.
If people are interested, I’ll write up more details - and perhaps even share some photos of my terrible soldering!
I don’t usually do this since I don’t like to encourage distributing third party SD Card images, but for testing purposes, if anybody is interested, here are some SD Card images for NX and Nano with RidgeRun’s patches applied.
You will still need either a modified HQ camera or one from Arducam designed spefically for use with Nano. I haven’t had much time to test recently, so please report any issues you find that don’t exist JetPack 4.4 (for example, missing packages or added packages).