I’ve tried several IMX 219 cameras from Amazon and none are recognized by my Orin Nano - I’ve done all the testing steps recommended in various placed. Does anyone have a link to one you’ve ordered and tested that works?
Hello @mhebel,
Hope everything is going great.
A while back I got a pair of waveshare IMX219-160IR Camera and they worked out of the box.
However, getting imx219 cameras to work with the Jetson platform should not be such a painful experience.
Would you be opposed to running a couple of tests to see if we could help?
best regards,
Andrew
Embedded Software Engineer at ProventusNova
Thanks, I’d be happy to run some tests as long as you’re not asking for consulting fees. It’s been a very painful experience.
Hey @mhebel,
Sure no worries, we usually only accept projects a certain size and up.
And helping you with this driver issue certainly would not meet our minimum project requirements.
Maybe down the road your project would grow into requiring serious engineering expertise, and then you could decide if reaching out for our assistance would be necessary, but for now lets you try to get you out of the imx219 camera issue.
Now. The first test I would like you to run is to verify that the driver is loading.
Please connect the camera your board, and power it up.
Then, on a console, run the following command and please provide the output:
dmesg | grep imx
This would let us know if the driver is at least loading.
best regards,
Andrew
Embedded Software Engineer at ProventusNova
[ 12.789743] imx219 9-0010: tegracam sensor driver:imx219_v2.0.6
[ 12.811037] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx219 9-0010 bound
Cool, thanks!
Means the driver is loading and it actually shows the camera sensor bound.
Now, lets try 2 tests:
- Lets see if the video device is registering successfully:
ls /dev/video*
- Lets try a simple capture pipeline:
gst-launch-1.0 nvarguscamerasrc ! fake sink
Now, for the second command, the expected behavior for a success case is actually the command runs, shows no image, but it prints a bunch of debug messages. Then it shows as “stuck” after printing the logs. Then you can Ctrl+C to stop it.
Please run those commands and share the output.
best regards,
Andrew
Embedded Software Engineer at ProventusNova
I assume you meant fakesink, not fake sink since it threw an error?
martin@nano:~/CSI-Camera$ ls /dev/video*
/dev/video0
martin@nano:~/CSI-Camera$ gst-launch-1.0 nvarguscamerasrc ! fakesink
libEGL warning: DRI2: failed to authenticate
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
GST_ARGUS: Creating output stream
(Argus) Error BadParameter: (propagating from src/eglstream/FrameConsumerImpl.cpp, function initialize(), line 93)
(Argus) Error BadParameter: (propagating from src/eglstream/FrameConsumerImpl.cpp, function create(), line 44)
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, threadInitialize:318 Failed to create FrameConsumer
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, threadFunction:239 (propagating)
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, waitRunning:201 Invalid thread state 3
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:849 (propagating)
Redistribute latency...
Got EOS from element "pipeline0".
Execution ended after 0:00:00.105828972
Setting pipeline to NULL ...
Freeing pipeline ...
Yes, that is correct.
Apologies, the auto-corrector likes to mess with me sometimes.
Thanks for running the tests.
Seems like the driver is in fact registering the video device successfully.
However, argus is failing to start camera capture.
Let’s try with v4l2-ctl to get argus out of the equation for now.
- Install v4l-utils
sudo apt install v4l-utils
- Run the following command for raw video capture:
v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap -d /dev/video0
best regards,
Andrew
Embedded Software Engineer at ProventusNova
This is the only output I get…
martin@nano:~/Desktop$ v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap -d /dev/video0
<<<<<<<<<<<<<<<<<<<<<<< 21.19 fps
<<<<<<<<<<<<<<<<<<<<< 21.19 fps
<<<<<<<<<<<<<<<<<<<<< 21.19 fps
<<<<<<<<<<<<<<<<<<<<< 21.19 fps
<<<<<<<<<<<<<<<<<<<<< 21.19 fps
Cool! That means that means you are successfully capturing from the camera.
So the issue seems to be Argus not wanting to let you capture for some reason.
Give me a couple of hours to free up from some meetings I have and I will do a bit of digging into that issue you are having with GStreamer.
In the meantime, you can validate image capture on your end by running this command:
v4l2-ctl --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --stream-mmap -d /dev/video0 --stream-count=5 --stream-to=test.raw
Just note that you will be capturing RAW video so you will have to use special software to review it. But if you have a linux machine, you can get away with using vooya to view the raw data.
best regards,
Andrew
Embedded Software Engineer at ProventusNova
Thanks much! Appreciate your time and efforts.
Andrew. I got video going - Because I was also having firefox issues (resolved) I was using remote desktop, which would not allow the stream to be generated by Argus. I don’t think we changed anything at all, but now running nvgstcapture-1.0 now streams the image which it didn’t before when I wasn’t using remote desktop. So, I’m not sure what changed.
That’s amazing!
Great Job !! That means you can stop throwing money at new camera modules.
Yeah sometimes that happens because some software requires EGL to access the display and for some reason that fails when using remote access to the board or similar setups.
In your case nvgstcapture might have worked because it could be using other libraries instead of EGL or it could already be fixing other configuration issues for it to work with remote access.
Just in case, we have this guide on how to remote access your board with no-machine. Lots of people find it helpful since is very popular in our website, so you might find it useful too. I recall one of our customers used it to remote-control an ROV they were working on.
Now that the cameras are working, you can go back at your regular project schedule.
And please do not hesitate to reach out if you require further assistance, we would love to help.
best regards,
Andrew
Embedded Software Engineer at ProventusNova
1 Like