SOLVED MV-MIPI-GMAX4002M compatibility with Jetson Xavier NX, Orin NX
-
- The MV-MIPI-GMAX4002M model was missing on this page and has now been added. Both Jetpack 5.1 and 6.2 are supported. However, we currently only provide the 4-lane mode DTB for Orin NX and Orin Nano under JP6.2 mode, as only these two boards have official baseboards that expose the 4-lane interface.
- You're right. Just place the order using that link. We will ship ADP-MV1-V2.
- For Jetson Xavier NX, since the official baseboard only exposes 2 lanes, the DTB in our provided driver remains configured for 2-lane mode, which limits the maximum frame rate.
As for Orin NX, there is no such restriction. You can refer to the 4 How to Use 4-Lane Modesection to enable 4-lane mode. - yes.
- The MV series products feature ISP (Image Signal Processor) capabilities, including typical functions such as auto-exposure, LUT (Look-Up Table), and more.
-
I purchased the MV-MIPI-GMAX4002M with the ADP-MV1-V2 adapter. I installed the Jetpack6.2,L4T r36.4.3 on the Jetson Orin NX 8gb. However, unfortunately I cannot install it using the GitHub repository "nvidia_jetson_veye_bsp". How can I proceed with the installation? Thank you very much!
-
@newstec
https://wiki.veye.cc/index.php/How_to_upgrade_the_Jetson_system_to_support_VEYE_cameras
Please refer to this article, mainly part 6.6, part 6.8, and part 8. -
Thank you very much for the reply, it really helped! I followed the recommendations faithfully and successfully completed the installation. However, I'm facing a problem:
The camera generates an image with errors and very low fps, as shown in the attached image:
Attached is the sudo dmesg: ubuntu@ubuntu~$ sudo dmesg.txt
ubuntu@ubuntu:~$ sudo dmesg | grep -i 'fail' [ 779.319935] mvcam 10-003b: camera_common_s_power: failed to enable mclk [ 2254.006074] NVRM rpcRmApiControl_dce: NVRM_RPC_DCE: Failed RM ctrl call cmd:0x731341 result 0xffff: [ 2334.553992] mvcam 10-003b: camera_common_s_power: failed to enable mclk [ 3210.855067] NVRM rpcRmApiControl_dce: NVRM_RPC_DCE: Failed RM ctrl call cmd:0x731341 result 0xffff: ubuntu@ubuntu:~$ sudo i2cdetect -y -r 9 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- ubuntu@ubuntu:~$ sudo i2cdetect -y -r 10 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- ubuntu@ubuntu:~$ ls /sys/firmware/devicetree/base/bus@0/cam_i2cmux/i2c@0/ '#address-cells' rbpcv2_imx219_a@10 reg status name rbpcv3_mvcam_a@3b '#size-cells' ubuntu@ubuntu:~$ ls /sys/bus/i2c/drivers/ at24 fusb301 nxp-pca9450 sec_pmic axp20x-i2c ina3221 pca953x simple-mfd-i2c bd9571mwv max732x pca954x smbus_alert bq27xxx-battery max77620 pf8x00 tpm_i2c_infineon cros-ec-i2c max8973 pfuze100-regulator ucsi_ccg cs2000-cp mp8859 rk808 usb3503 dummy mvcam rohm-bd718x7 vc5 fan53555-regulator nvvrs_pseq rtc-ds3232 ubuntu@ubuntu:~$ v4l2-ctl --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture [0]: 'GREY' (8-bit Greyscale) Size: Discrete 2048x1200 Interval: Discrete 0.037s (27.000 fps) [1]: 'XY10' (XAVIER 10-bit/16-bit Greyscale) Size: Discrete 2048x1200 Interval: Discrete 0.037s (27.000 fps) [2]: 'XY12' (XAVIER 12-bit/16-bit Greyscale) Size: Discrete 2048x1200 Interval: Discrete 0.037s (27.000 fps) ubuntu@ubuntu:~/Downloads/nvidia_jetson_veye_bsp/mv_tools_jetson/i2c_tools$ sudo ./mv_mipi_i2c.sh -r -f version -b 10 [sudo] password for ubuntu: Executing: ./mv_mipi_i2c_new.sh -r version -b 10 version is C 01.48 and L 03.20
TIMEOUT 30 DEFAULT primary MENU TITLE L4T boot options LABEL primary MENU LABEL primary kernel LINUX /boot/Image INITRD /boot/initrd APPEND ${cbootargs} root=PARTUUID=e7cecac7-8b18-4414-b9b9-41ae8eab84d9 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0 nv-auto-config FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0001-nv.dtb OVERLAYS /boot/veyecam/tegra234-p3767-camera-p3768-veye_mvcam-dual-4lane-cam1.dtbo # When testing a custom kernel, it is recommended that you create a backup of # the original kernel and add a new entry to this file so that the device can # fallback to the original kernel. To do this: # # 1, Make a backup of the original kernel # sudo cp /boot/Image /boot/Image.backup # # 2, Copy your custom kernel into /boot/Image # # 3, Uncomment below menu setting lines for the original kernel # # 4, Reboot # LABEL backup # MENU LABEL backup kernel # LINUX /boot/Image.backup # INITRD /boot/initrd # APPEND ${cbootargs}
I only have one camera.
I'd be very happy if it worked well! Thank you very much.
-
@newstec
Please try veye_viewer.
https://github.com/veyeimaging/veye_viewer/releases/tag/v0.1.1_jetson -
Thanks for all the help!
-
@veye_xumm Good news, it's working!
I changed the port to "CAM1" (i2c-9).
I believe the "v0.1.1_jetson" files were essential for proper operation.
Thank you for your efforts in helping.
-
@newstec Cheers!
-
Hi @veye_xumm
I have an application that needs a very low latency (<10ms at maximum. Even less if possible) from capture to being available to the Jetson for real-tim processing. I read in some posts on the forum that veye cameras have more than 100ms latency due to ISP. In that case, is there any VEYE camera that I can still use? My requirements are:- Bigger pixel size for low light capture (the GMAX4002 seemed decent)
- High frame rate (at least more than 60fps)
- Ability to use a physical trigger signal
- Very low latency (<10ms, even less if possible).
Please guide me if there are any VEYE cameras which will satisfy my requirements. Thank you.
-
@stiwana
I think the post on the forum might have misled you. In fact, the latency of the VEYE series (models starting with VEYE-) is relatively high.
The latency of the MV series, for instance MV-MIPI-GAMX4002M, is very low (below 1ms) because our ISP pipeline does not use frame buffering and only has a small amount of line buffering. -
@veye_xumm
Thanks so much for your answer. I am very glad I asked you this question. Of the latency is 1ms as you mention , then the rest looks suitable too. I will buy some to test.Some follow up question:
- With the MV-MIPI-GMAX4002 camera on Jetson, can I also use the camera inside a gstreamer pipeline (and also maintain the low latency)?
- For the lowest latency and deterministic performance (the application will need to know exactly when the frame was acquired), what would you suggest with these cameras...use from opencv or gstreamer, or does it not matter? Any other tips you can give me for very low latency, real time performance with the MV cameras?
- What's the usual lead time to buy these cameras in case the cameras are out of stock when purchasing (from a supply chain point of view when my device is in production)
- How many years do you plan to keep these camera modules available for?
Best Regards