Raspberry Pi HQ Camera in Jetson Nano

Hi Erich,

Since NVIDIA is integrating the driver by default in Jetpack for Jetson Nano 2G we expect it will happen again with the 4GB board and work out of the box. We are not aware of problems with the driver in jetpack 4.4.1, however, one of our engineers will give it a try and report you back if it is a problem in the driver or a configuration issue.

-David

2 Likes

Hi sagain,

I tried a fresh install of the JetPack 4.4.1 on B01 board with HQ camera (R8 removed).
After installing, I did an update & upgrade to be on the latest versions.

After installing the new driver with option A for nano, no boot is possible.
I have now an UART converter connected, here is the boot-log over UART in the attached txt file.

BR
Erich
nano_boot_log_error_477_441.txt (27.8 KB)
After the last line in the logging there is a big delay, then automatic reboot.

Hi erich,

I am having the same exact issueā€¦updated the software of the nano today, then the camera did not work any more, I reinstalled the kernels for the camera support and now it wonā€™t boot againā€¦

It seems like with the latest update the kernel wonā€™t run.

Hopefully someone sees this and brings a new version of the kernel to bring back the support.

Thanks for all helping!
David

Hello,

I have two Rasp Pi HQ cameras working on my Jetson Nano.
What Iā€™m having trouble with is setting an exposure time.
Has this been tested?

I got the module from:

and installed JetPack:
Jetpack R32, REVISION: 3.1 via the SDK Manager.

I have tried all variations of nvarguscamerasrc but the exposuretimerange does not change the exposure, even when aelock=true is set.

I tried gst-inspect-1.0 nvarguscamerasrc to view more options but didnā€™t find anything useful.

Any ideas?

Changing the gain works! 100%

Thank you
Valentin

Hi David,

are there any news from your side regarding HQ camera on 4.4.1 with latest updates?
My project here is complete standing without a working camera (a professional customer project!).

BR
Erich

Hi Erich,

Sorry for the delay. One of engineers is now working on this, the end of year break delayed the update but this week we are back on this. In the next couple of weeks it should be ready.

-David

2 Likes

Hi.
Thank you so much for your effort.

I have little questions about using the drivers.
Could you let me know the Pixel Readout Rate of the drivers?
Where can I find the information?
Can we decrease the rate(reading less pixels per time)?

Thank you.

Hello,

We have switched to the RidgeRun drivers and still canā€™t change the exposure time. Any advice?

Thank you

@siderskiy

Exposure time GStreamer pipeline can be locked to the frame rate, or at least not greater than it (360 degree shutter).

If you think about it, it makes sense. In a video pipeline the shutter canā€™t be open for longer than a frame. You can try setting exposure after the pipeline starts on the Argus source but in my tests this breaks things.

For reference Iā€™m working with the IMX 477 by Arducam and RidgeRunā€™s drivers using the patch method.

Thanks, Iā€™ll give it a try.
I tried setting the frame rate very low and modulate the exposure, and still no luck. Autoexposure works, it somehow modulates the exposure time. Also changing the exposure time on the camera on the Pi works (but not using gstreamer).

Wondered if autoexposure somehow works with exposure time longer than the frame rate with some kind of sliding window buffering algorithm.

Hi All,

Thanks for the patience, the driver is already ported to JP 4.4.1 and tomorrow we will just do a review and then make it available.

@siderskiy, can you provide more details on how you are testing? We would like to give it a try, the driver has a exposure and the ISP makes use of that control.

-David

@siderskiy

IIRC, it does auto-gain by default unless you set both values of the ranges to the same, so there are at least these in play:

 $ gst-inspect-1.0 nvarguscamerasrc
...
  exposuretimerange   : Property to adjust exposure time range in nanoseconds                   Use string with values of Exposure Time Range (low, high)                        in that order, to set the property.                     eg: exposuretimerange="34000 358733000"
                        flags: readable, writable
                        String. Default: null
  gainrange           : Property to adjust gain range                   Use string with values of Gain Time Range (low, high)   in that order, to set the property.                      eg: gainrange="1 16"
                        flags: readable, writable
                        String. Default: null
  ispdigitalgainrange : Property to adjust digital gain range                   Use string with values of ISP Digital Gain Range (low, high)                     in that order, to set the property.                     eg: ispdigitalgainrange="1 8"
                        flags: readable, writable
                        String. Default: null
...
  exposurecompensation: property to adjust exposure compensation
                        flags: readable, writable
                        Float. Range:              -2 -               2 Default:               0 

For details of what exactly those do, youā€™ll have to dive into the source, which is in the public sources tarball, IIRC. To me at least, itā€™s not at all clear what these properties do.

Thank you @mdegans and @DavidSoto-RidgeRun,

TLDR; Real exposure time range for sensor mode 1: [34000,33333333]

With @aaronlozhkin:

We did an exhaustive test and here is the story.

  1. When using gst-launch-1.0 nvarguscamerasrc ā€¦ it shows that both sensor modes have an exposure range of [13000,683709000]. However, both of those values output a warning ā€˜invalid time rangeā€™, and the camera defaults to some default exposure time.
    In:

gst-launch-1.0 nvarguscamerasrc exposuretimerange="13000 13000" wbmode=0 sensor_id=0 sensor-mode=1 ispdigitalgainrange="1 1" aelock=true gainrange="4 4" ! nvoverlaysink

Out:

GST_ARGUS: NvArgusCameraSrc: Setting Exposure Time Range : 13000 13000
GST_ARGUS: Invalid Exposure Time Range Input

  1. The values that donā€™t produce an error are [34000,358733008]. Suspiciously close to the gst-inspect-1.0 nvarguscamerasrc example.

  2. For sensor-mode=1: The exposure values from [34000,33333333] actually change the exposure time. However, the range [33333334,358733008] does not produce a warning message and defaults the exposure time to some arbitrary default value which seems to be relatively dim.

Here are some extra questions:
If sensor-mode=1 is 60 fps, how is it that we can set the exposure time to 33,333,333ns (i.e. 1/30s), instead of 16,666,666ns

How can I have an exposure time over 1/30s. My application is very low light.

Hello everybody,

we are using the RidgeRun drivers on Jetson Nano DK (JP4.4/L4T 32.4.3), but having a little issue (the video starts to blink yellow) when accidentally looking at the sun (which is very common in our use case).

This was recorded from our system using gstreamer:

We were able to reproduce it on lab tests using a flashlight:

I donā€™t know if itā€™s really a driver issue or just the expected behaviour when these conditions are met. Anyways, as we are not experts on the field of digital video, some advice would be nice.

As context, we are using nvarguscamerasrc with default parameters, maybe thereā€™s some tuning we can try there?

Thank you very much in advance.

Hi everyone,

Iā€™m happy to announce that the IMX477 driver porting for Jetpack 4.4.1 is ready for you all to give it a try. You can check it out in our Github repo:

https://github.com/RidgeRun/NVIDIA-Jetson-IMX477-RPIV3

The patches and the debian packages were updated. Donā€™t hesitate to let us know in case you find any issue.

Regards,
Carlos R

2 Likes

Hey @jbarria,

Could you please try disabling the Auto Exposure in nvarguscamerasrc? You can run the pipeline with:

nvarguscamerasrc aelock=true

I just want to see if the issue appears even if auto exposure is disabled.

You can also try with awblock=true and see how it behaves

@David:

Thanks for the new version, its working here on an full updated nano 4GB!
I marked the 2 files with apt-mark hold so that they are not update.
Just in time, we have an telco today with an potential customer - so wen can report that we can start with the demonstrator application programming.

BR
Erich

Thank you very much for your response @CarlosR92 . I just answered in the github issue to avoid spamming on this thread.

Regards.
Jorge

Hello again,

I want to start the jetson_io.py tool, but it is not starting correctly.
The window shortly is visible for a fraction of a second and then it dissapers.
No error message.

I tried the init.py hack and the dtb file is from your hack in the /boot/dtb directory.
Could there be a problem with your hack and the jetson_io tool?

BR
Erich

Hi @CarlosR92

Auto exposure still works even though I disabled auto exposure and set the exposure timerange.
When I see the laser beam, It flashes like @jbarria and stops.

My pipeline is shown below.

cv2.VideoCapture("nvarguscamerasrc ! video/x-raw(memory:NVMM), width=(int)4032, height=(int)3040,format=(string)NV12, framerate=(fraction)30/1, exposuretimerange = "34000 34000", aeLock=true, ispdigitalgainrange="1 1", gainrange="4 4" ! tee name=t t. ! queue ! nvv4l2h264enc bitrate=14000000 ! h264parse ! matroskamux ! filesink location=now.mkv t. ! queue ! nvvidconv ! video/x-raw, format=(string)I420, width=1000, height=700 ! appsink sync=0 ")