Navigation

    VEYE IMAGING Forum

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Recent
    • Popular
    • Users
    • WIKI
    • veye.cc

    SOLVED MV-MIPI-GMAX4002M compatibility with Jetson Xavier NX, Orin NX

    Machine Vision camera
    3
    13
    1778
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • veye_xumm
      veye_xumm @newstec last edited by

      @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.

      N 1 Reply Last reply Reply Quote 0
      • N
        newstec @veye_xumm last edited by

        @veye_xumm

        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:
        2.jpg

        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.

        veye_xumm 1 Reply Last reply Reply Quote 0
        • veye_xumm
          veye_xumm @newstec last edited by

          @newstec
          Please try veye_viewer.
          https://github.com/veyeimaging/veye_viewer/releases/tag/v0.1.1_jetson

          N 1 Reply Last reply Reply Quote 0
          • N
            newstec @veye_xumm last edited by

            @veye_xumm
            99.png

            Thanks for all the help!

            N 1 Reply Last reply Reply Quote 0
            • N
              newstec @newstec last edited by

              @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.

              44.jpg

              veye_xumm 1 Reply Last reply Reply Quote 0
              • veye_xumm
                veye_xumm @newstec last edited by

                @newstec Cheers!

                1 Reply Last reply Reply Quote 0
                • S
                  STiwana last edited by

                  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.

                  veye_xumm 1 Reply Last reply Reply Quote 0
                  • veye_xumm
                    veye_xumm @STiwana last edited by

                    @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.

                    S 1 Reply Last reply Reply Quote 0
                    • S
                      STiwana @veye_xumm last edited by

                      @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:

                      1. With the MV-MIPI-GMAX4002 camera on Jetson, can I also use the camera inside a gstreamer pipeline (and also maintain the low latency)?
                      2. 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?
                      3. 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)
                      4. How many years do you plan to keep these camera modules available for?

                      Best Regards

                      veye_xumm 1 Reply Last reply Reply Quote 0
                      • veye_xumm
                        veye_xumm @STiwana last edited by

                        @stiwana
                        https://wiki.veye.cc/index.php/Mv_series_camera_appnotes_4_jetson

                        For specific information, please refer to the link above. We provide a veye_viewer client for customers to initially get started and verify usage.

                        We haven't done extensive debugging on GStreamer yet. As for OpenCV, there are examples provided in the article above. Regarding the latency issue: although the camera itself has negligible delay, each image entering the Jetson system will experience some latency due to the V4L2 buffer, format conversion, and preview processes—all of which involve memory buffering queues.

                        The most fundamental solution is to develop your own program tailored to your product's specific needs, allowing flexible management of buffers. Additionally, note that the V4L2 buffer containing the camera images after they enter the Jetson system includes timestamps. It is recommended that you use these timestamps.

                        Regarding the supply of this product, we will maintain long-term availability unless the chip is discontinued. We will keep a regular inventory sufficient to meet retail demand. For bulk orders of several hundred units or more, the production cycle is typically within one month.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post