I just wanted to let you know that RidgeRun added support to use the IMX219 and ov5647 cameras with tegra X1 including ISP support
We have tested multiple cameras (up to 6) at the same time using the J20 board from auvidea. Our first approach included the support to capture bayer using v4l2src. Once the V4L2 drivers were working RidgeRun added support to use the cameras with the ISP, this means that we can also capture using nvcamerasrc and therefore do the bayer to YUV conversion in the Tegra ISP. You can find more information including gstreamer pipelines in our wiki page:
it is great that Ridgerun is providing support for the Raspberry Pi cameras. Thank you David. We have just build a few prototypes of the J20 rev 1 boards. They are designed for the TX1 dev kit and are plugged into the 120 pin CSI-2 connector on the dev kit board. The J20 replaces the camera board, which comes with the dev kit. It may be used on other carrier boards which offer the same 120 pin connector. For more information please have a look at the reference manual for the J20. Below a picture of the J20 rev 1 board:
At this point we are using the same ISP settings supported by nvcamera by default, we do have an ISP overwrite config file with all the settings but we are not using it with IMX219. With the OV5647 we will be using it but we are not there yet. So we are basically using the same ISP config supported for the ov5693 and the image looks pretty nice as you can see in the video
Today we gave it a try to use the ISP to do the debayer process when using the ov5647 driver and it worked properly, we also tried it with 6 cameras + 6 nvvidconv to downscale them as well and it worked. We will be updating the wiki with the pipelines. Then we will be changing the parameters of the ISP config file.
We will upload a video showing the 6 cameras in action.
@chijen, which tool do you use to create the ISP config file, I have the feeling that it is generated by an automated tool, am I right?
good to know David. What is your resolution and fps for 6 cameras configuration? ISP configuration is the output of camera characterization flow. This step is to use equipment and software tool to compensate various camera parameters and create a configuration file. We enable camera partners for this support/development purpose.
We support several resolutions but the test was with 1080p15, we are changing the driver to run the same test with 30fps. However, this change has nothing to do with the ISP or the tegra itself. From our tests with imx219 we know it can handle higher framerates.
RidgeRun and nvidia are ecosystem partners but since we don’t create hardware we don’t have access to the tool to do the characterization of the camera. RidgeRun is a software only company and we get hired to make things work with Linux and gstreamer, that is why we added the support to off load the arm on doing the bayer to yuv conversion and use the isp instead with our camera drivers. Actually the images describe a really high quality, nvidia did a great job with tegra X1. Now we will start checking what is doing each of the parameters of the isp calibration file.
RidgeRun has tested Tegra X1 ISP using our own drivers with the nvcamerasrc element, in this case we tested with the imx219 sensor and several properties that nvcamerasrc provides, we create a Wiki with some pipelines:
I tried to disconnect all six Pi V1.3 cameras when powering up TX1 with J20, then I connected 3 Pi cameras to J4, J5 and J6, all 3 were detected, I connected 3 more Pi cameras to J1, J2 and J3, all 6 cameras were detected and working.
After power cycling TX1 without changing any connection, only J1, J2 and J3 were detect.
There may be design issues of J20s for driving the pi cameras and I2C address shifters in parallel. It’s unlikely all 3 I2C address shifters for J4, J6 and J6 are defective.
I believe Nvidia’s 6 camera reference design (e3333) and Leopard Imaging’s LI-JTX1-MIPI-ADAPT with I2C switches (TCA9546/TCA9548) are better than using I2C address shifters.
Nvidia and Leopard Imaging use only one I2C bus for all cameras and do not have I2C load issues.