AGX Orin R35.4: No cameras avaliable when using GStreamer with nvarguscamerasrc

[hemz]

Hi, Experts.

I have ported the driver for the AR0234 camera(which does not have an integrated ISP in the camera) onto my carrier board of the AGX Orin. And i can get RAW10 data through the V4L2 interface:
for the camera: (/dev/video4)
v4l2-ctl --set-fmt-video=width=1920,height=1200,pixelformat=BA10 --set-ctrl bypass_mode=0 --stream-mmap -d /dev/video4

And the camera: (/dev/video5)
v4l2-ctl --set-fmt-video=width=1920,height=1200,pixelformat=BA10 --set-ctrl bypass_mode=0 --stream-mmap -d /dev/video5

However, I encountered an error when using GStreamer with nvarguscamerasrc:

”Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:751 No cameras available”

gst-launch-1.0 nvarguscamerasrc sensor-id=4 sensor-mode=0 ! ‘video/x-raw(memory:NVMM), width=1920, height=1200, format=(string)NV12, framerate=(fraction)30/1’ ! queue ! nveglglessink -e

The dmesg logs are shown below:

uart_dmesg_log.txt (72.3 KB)

Could you give some advice? Thanks a lot.

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

Based on the provided information, it seems that you have successfully ported the driver for the AR0234 camera, which does not have an integrated ISP, onto your carrier board of the AGX Orin. You are able to get RAW10 data through the V4L2 interface for the camera.

However, you are encountering an error when using GStreamer with nvarguscamerasrc. The error logs are shown in the dmesg logs.

To provide advice, let’s break down the information:

1. The AR0234 camera does not have an integrated ISP, which means it does not use the Jetson ISP (CSI Interface). According to the Camera API Matrix, in this case, the V4L2 API should be used.
2. You are able to get RAW10 data through the V4L2 interface for the camera, which suggests that the V4L2 API is working correctly.
3. However, when using GStreamer with nvarguscamerasrc, you are encountering an error. The nvarguscamerasrc plugin is typically used with cameras that have an integrated ISP, which is not the case for the AR0234 camera.

Based on this information, it’s likely that the error is due to the fact that nvarguscamerasrc is not compatible with cameras that do not have an integrated ISP.

To resolve this issue, you may need to use a different GStreamer plugin that is compatible with V4L2, such as the v4l2src plugin. This plugin allows you to capture video from a V4L2 device, which in this case is the AR0234 camera.

Here’s an example pipeline that you can use:

gst-launch-1.0 v4l2src device=/dev/video4 ! video/x-raw, format=GRAY8 ! videoconvert ! ximagesink

This pipeline captures video from the /dev/video4 device (which is the AR0234 camera) and displays it using the ximagesink plugin.

Alternatively, you can also use the v4l2h264enc plugin to encode the video stream and then display it using the ximagesink plugin.

gst-launch-1.0 v4l2src device=/dev/video4 ! video/x-raw, format=GRAY8 ! v4l2h264enc ! h264parse ! video/x-h264 ! ximagesink

Note that you may need to adjust the pipeline to match your specific requirements.

In summary, the error you are encountering is likely due to the fact that nvarguscamerasrc is not compatible with cameras that do not have an integrated ISP. To resolve this issue, you can use a different GStreamer plugin that is compatible with V4L2, such as the v4l2src plugin.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[hemz]

@carolyuu

The AR0234 camera does not have an integrated ISP, which means it does not use the Jetson ISP (CSI Interface). According to the Camera API Matrix, in this case, the V4L2 API should be used.

Hi, I want to use the ISP module on the Jetson Orin.
By the way, There are 6 cameras in my application scenario, four of which have an integrated ISP module. the ISP module integrated on the AGX Orin is not required for these four cameras, whereas it is a necessity for the remaining 2 AR0234 cameras.

tegra-capture-vi {
num-channels = <6>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
ov2775_vi_in0: endpoint {
vc-id = <0>;
port-index = <0>;
bus-width = <4>;
remote-endpoint = <&ov2775_csi_out0>;
};
};
port@1 {
reg = <1>;
ov2775_vi_in1: endpoint {
vc-id = <1>;
port-index = <0>;
bus-width = <4>;
remote-endpoint = <&ov2775_csi_out1>;
};
};
port@2 {
reg = <2>;
ov2775_vi_in2: endpoint {
vc-id = <2>;
port-index = <0>;
bus-width = <4>;
remote-endpoint = <&ov2775_csi_out2>;
};
};
port@3 {
reg = <3>;
ov2775_vi_in3: endpoint {
vc-id = <3>;
port-index = <0>;
bus-width = <4>;
remote-endpoint = <&ov2775_csi_out3>;
};
};
port@4 {
reg = <4>;
ar0234_vi_in0: endpoint {
vc-id = <0>;
port-index = <2>;
bus-width = <4>;
remote-endpoint = <&ar0234_csi_out0>;
};
};
port@5 {
reg = <5>;
ar0234_vi_in1: endpoint {
vc-id = <1>;
port-index = <2>;
bus-width = <4>;
remote-endpoint = <&ar0234_csi_out1>;
};
};
};
};

[JerryChang]

hello hemz,

just an FYI, it’s not always sensor-id=4 maps to /dev/video4.

libargus checks position property for launching cameras.
for instance, in a three-camera system, it’s sensor-id=0 to enable camera with bottom position, sensor-id=1 to enable camera with top position, and sensor-id=2 to enable camera with center position.

since you’ve 6-cam in the system, please try refer to developer guide to have six-camera position property settings, such as.. bottomleft, bottomright, centerleft, centerright, topleft, and topright.

[hemz]

@JerryChang

top

Hello JerryChang,
I have a question: “ /dev/video0, /dev/video1, /dev/video2, /dev/video3 ” these 4 cameras don’t need to use the AGX Orin’s ISP. Therefore, dose the position attribute applicable only to the other 2 cameras ( “/dev/video4, /dev/video5“ )?

I modify the dts file like this, but I am still getting “No cameras avaliable.“

/**
* The general guideline for naming badge_info contains 3 parts, and is as follows,
* The first part is the camera_board_id for the module; if the module is in a FFD
* platform, then use the platform name for this part.
* The second part contains the position of the module, ex. “rear” or “front”.
* The third part contains the last 6 characters of a part number which is found
* in the module’s specsheet from the vender.
*/
modules {
module0 {
badge = “ov2775_bottomleft”;
position = “bottomleft”;
orientation = “1”;
drivernode0 {
/* Declare PCL support driver (classically known as guid) */*
pcl_id = “v4l2_sensor”;
/* Driver v4l2 device name */
devname = “ov2775 0-001b”;
/* Declare the device-tree hierarchy to driver instance */
proc-device-tree = “/proc/device-tree/i2c@3160000/ov2775_a@1b”;
};
};
module1 {
badge = “ov2775_bottomright”;
position = “bottomright”;
orientation = “1”;
drivernode0 {
/* Declare PCL support driver (classically known as guid) */
pcl_id = “v4l2_sensor”;
/* Driver v4l2 device name */
devname = “ov2775 0-001c”;
/* Declare the device-tree hierarchy to driver instance */
proc-device-tree = “/proc/device-tree/i2c@3160000/ov2775_b@1c”;
};
};
module2 {
badge = “ov2775_centerleft”;
position = “centerleft”;
orientation = “1”;
drivernode0 {
/* Declare PCL support driver (classically known as guid) */
pcl_id = “v4l2_sensor”;
/* Driver v4l2 device name */
devname = “ov2775 0-001d”;
/* Declare the device-tree hierarchy to driver instance */
proc-device-tree = “/proc/device-tree/i2c@3160000/ov2775_c@1d”;
};
};
module3 {
badge = “ov2775_centerright”;
position = “centerright”;
orientation = “1”;
drivernode0 {
/* Declare PCL support driver (classically known as guid) */
pcl_id = “v4l2_sensor”;
/* Driver v4l2 device name */
devname = “ov2775 0-001e”;
/* Declare the device-tree hierarchy to driver instance */
proc-device-tree = “/proc/device-tree/i2c@3160000/ov2775_d@1e”;
};
};
module4 {
badge = “ar0234_topleft”;
position = “topleft”;
orientation = “1”;
drivernode0 {
/* Declare PCL support driver (classically known as guid) */
pcl_id = “v4l2_sensor”;
/* Driver v4l2 device name */
devname = “ar0234 0-0011”;
/* Declare the device-tree hierarchy to driver instance */
proc-device-tree = “/proc/device-tree/i2c@3160000/ar0234_a@11”;
};
};
module5 {
badge = “ar0234_topright”;
position = “topright”;
orientation = “1”;
drivernode0 {
/* Declare PCL support driver (classically known as guid) */
pcl_id = “v4l2_sensor”;
/* Driver v4l2 device name */
devname = “ar0234 0-0019”;
/** Declare the device-tree hierarchy to driver instance */
proc-device-tree = “/proc/device-tree/i2c@3160000/ar0234_b@19”;
};
};
};

How can I determine the corresponding relationship between /dev/videox and the sensor-id ?

Thank you.

[JerryChang]

hello hemz,

it’s during kernel initialization stage, it’s step for camera device registration to setup a video device node to linux kernel. sensor probing only run once during kernel initialization stage of system boot-up. you’ll need to check the kernel logs for details.

you may dig into kernel driver, i.e. $public_sources/kernel_src/kernel/nvidia-oot/drivers/media/platform/tegra/camera/tegracam_core.c
video_register_device() is called in tegracam_device_register(), and this is public kernel code.
it’ll find a available number to register the video node automatically.
please customize the code to identify which camera sensor is registered, and set fixed number in calling video_degister_device() (in vi/graph.c).

[hemz]

Hello JerryChang,

I have now confirmed the corresponding /dev device numbers for the 6 cameras:
/dev/video0 ~ /dev/video3 are these 4 ov2775 cameras (equipped with an ISP module inside), and I can capture video from them.
/dev/video4 ~ /dev/video5 are these 2 AR0234 cameras (They do not have an integrated ISP module inside), and I can get RAW10 data from them.

Via an alternative approach: v4l2-ctl --list-devices

     v4l2-ctl -d /dev/video4 --list-formats-ext    

    v4l2-ctl -d /dev/video5 --list-formats-ext

It seems that I can map the six cameras to their corresponding video device numbers (/dev/videoX).
However, I cannot map the sensor-id values to the corresponding cameras. And I tried this command:
nvargus_nvraw --lps

It indicates that the number of available cameras is 0.
How should I further troubleshoot the problem next?
Thank you very much.

[hemz]

@hemz

Hello JerryChang,

I think my situation is somewhat similar to this link:

No cameras available(gstnvarguscamerasrc.cpp, execute:751)

Your sensor driver have CID implement problem. Have reference to below topic to fix it.

Now I can match the sensor-id with the AR034 cameras.

But, When I run the following command, An error occurred.
gst-launch-1.0 nvarguscamerasrc sensor-id=0 sensor-mode=0 ! ‘video/x-raw(memory:NVMM), width=1920, height=1200, format=(string)NV12, framerate=(fraction)30/1’ ! queue ! nveglglessink -e

err.txt (1.8 KB)

Could you give me some advices ?

[hemz]

@hemz

Hello JerryChang,

I can now capture data from the AR0234 cameras (after passing through the ISP on the Orin), referenced the commands in the following link.

Nvarguscamerasrc does not work

Hello I am having problems getting the “gst-launch-1.0 nvarguscamerasrc” to work. Jetson Linux 35.3.1 With v4l2-ctl I can save raw images that also look good v4l2-ctl -d /dev/video0 --set-fmt-video=width=3856,height=2201,pixelformat=RG12 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw [RawImage] but when I run gst-launch-1.0 nvarguscamerasrc, gstreamer opens for a short time but only shows a black image gst-launch-1.0 nvarguscamerasrc ! ‘video/x-raw(memory…

gst-launch-1.0 nvarguscamerasrc sensor-id=0 sensor-mode=0 ! ‘video/x-raw(memory:NVMM), width=1920, height=1200, format=(string)NV12, framerate=(fraction)30/1’ ! queue ! nv3dsink

gst-launch-1.0 nvarguscamerasrc sensor-id=1 sensor-mode=0 ! ‘video/x-raw(memory:NVMM), width=1920, height=1200, format=(string)NV12, framerate=(fraction)30/1’ ! queue ! nv3dsink

But it won’t run for long before reporting an error and exiting.

err-sensor-id_0.txt (2.4 KB)

err-sensor-id_1.txt (2.4 KB)

[JerryChang]

hello hemz,

according to the logs, it seems it’s streaming for couple of minutes before error reported.

CONSUMER: ERROR OCCURRED
ERROR: from element /GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0: TIMEOUT
Additional debug info:
Argus Error Status
Execution ended after 0:03:51.082883744

let’s give it another try to disable preview and shows frame-rate only
for instance,
$ gst-launch-1.0 nvarguscamerasrc sensor-id=0 sensor-mode=0 ! 'video/x-raw(memory:NVMM),width=1920, height=1200, framerate=60/1, format=NV12' ! nvvidconv ! fpsdisplaysink text-overlay=0 name=sink_0 video-sink=fakesink sync=0 -v

besides..
there’re some camera stability issues with JP-5.1.2.
please see-also Topic 268833, Topic 276217, Topic 305949.
is it a must to stay-on JP-5.1.2/r35.4.1? is it possible for moving forward to the latest JP-5 release version for verifciation?

[hemz]

Hello, JerryChang, thank you very much.

[hemz]

Hello, JerryChang,
After some testing, I still found a few issues. I’ll provide you with specific details about them. Meanwhile, I am also upgrading to version R36.4.

———————————————————————————————-
First, I updated the following patch packages as mentioned by Topic 268833:

(with debug flag enabled)

But, It hasn’t been completely solved (It can last for several minutes or a few hours).
Is it because the camera bandwidth hasn’t reached 1.5G? and how to view debug information for camera firmware?
Thanks a lot.