The NvMedia Image Camera Capture sample application nvmimg_cap demonstrates how to use the NvMedia Image Sensor Control API to capture frames from the sensors and display them to a screen or save them to a file.

The nvmimg_cap sample application captures frames from sensors using the NvMedia Image Sensor Control API to display them to a screen and/or save them to a file. It can also be used to test the error detection functionality of the ISC.

The application requires users to provide command line input as well as a group of settings as defined in the configuration file.

The configuration file contains two sets of information.

The CSI packets from the aggregator reach the Video Input (VI) module and saved to memory. The frames can be displayed using the Display Controller (DC) and/or saved to a file. Any random errors, such as camera power failure, or broken video links, during the ongoing capture process are detected by the aggregator device. The aggregator forwards this error condition using GPIO interrupt to this application to inform the user.

The Image Sensor Control feature allows the usage of the ISC framework to program the camera module. Image Sensor Control consists of three parts:

The ISC kernel driver, running on Linux OS, controls the power of the camera sensors through GPIOs, to:

The Image Capture tool can be used to verify the error detection capability of ISC. The tool detects errors from the aggregator device for various scenarios such as camera power failure, video link failure, serializer failure etc.

In any of these cases, the aggregator device catches the error scenario since there is no data activity present on the lines there by detecting link error. The error is propagated to the application in the form of a GPIO interrupt and the application can take any necessary action. The action may include, but not limited to, reading the status register of the aggregator to figure out whether camera, serializer or GMSL link caused the failure. When an error is detected, the user receives a message similar to the following:

The Camera Capture pipeline consists of three components:

The following figure outlines the Camera Capture pipeline.

The following is the flow of the code for the camera capture components:

To run the Image Camera Capture sample application, run the following command:

To quit the application, enter q at the command line.

The configuration file format and the configuration file set format are defined as follows:

The configuration file contains groups of settings that configure capture settings. The application parses and selects a group of settings using the provided configuration set name as specified in the command line.

Each configuration set begins with a capture-params-set number, followed by the configuration parameters.

Valid configuration parameters are as follows:

Each configuration set requires mandatory parameters to determine the capture environment. The required parameters are as follows:

Where:

The optional parameters are as follows:

Where:

The following provides an example configuration set for a Conti camera on the DRIVE PX platform:

Comments begin with a pound sign (#). The text that appears after the pound sign to the end of the line is considered to be a comment and is not parsed by the script file parser.

The Image Sensor Control kernel driver consists of ISC manager isc-mgr and ISC devices isc-dev.

To debug ISC, you must control the power of the camera and the register settings programmed into the camera sensor using isc-mgr and isc-dev in debugfs of the Linux directory. Camera power is controlled dynamically by all the NvMedia camera sample applications. This is an additional control that can be used for debugging.

Echo the value to the isc-mgr from debugfs on the target.

The <val> is determined from the Device Tree; which is platform specific. For example, on Drive PX, val=1 enables power on Links 0 and 1 while val=2 enables power on Link 2 and 3.

You can read and write any register of the camera module (sensor, serializer) and aggregator through the isc-devices associated with each one.

The following provides an example of writing 0x43 to the I2C offset address 0x04 on the serializer (with device address 0x40).

The following issues are errors users of this application have encountered.

The error message is as follows:

This capture error indicates that the start of CSI frame not available. The aggregator was unable to lock/synchronize the frames from the camera modules. This issue does not occur when reference cameras are being used. Check the aggregator settings for more information.

The error message is as follows:

A generic CSI packet error occurred during the capture. Possible causes include:

The error message is as follows:

Possible causes include:

The error message is as follows:

Possible causes include:

The error message is as follows:

Possible causes include:

The error message is as follows:

This error occurs when an incorrect configuration is used to set up the camera sensor. For example, programming OV10640 sensor when OV10635 is actually connected to the platform.

This error occurs when an incorrect I2C device is used in the DTS file or the script file. Verify that the configuration present in the device tree, at the following location, matches that of the script:

There is a specific I2C device associated with the given CSI port. This error occurs because an incorrect initialization has been made.

The error message is as follows:

The display device creation failed. A possible cause may be that an incorrect display ID is provided on the command line. The nvmimg_cap application automatically detects display ID. Run the application with -h option to identify the correct display ID.

Available command line options:

If multiple display devices are detected, -d option selects the first device, if ID is not specified. An error results if the display ID is unusable.

The error message is as follows:

Each display ID and window ID combination yields a unique NvMedia output surface. This error occurs if this combination is being used by any other application. Verify the target to check if any other application is using the current output surface combination.

The following examples represent commonly used commands.

To capture RAW12 frames from the sensor (AR0231) and display them on to the screen on the CSI port AB:

To capture YUV422 frames from 4 sensors (OV10635), store them to a file with the prefix "frame" (files are named frame_0.raw, frame_1.raw, etc.), and display onto the screen on the CSI port AB:

For the DRIVE PX platform, the above command is executed either on Tegra A or Tegra B. However, Drive PX platform routes the images to both Tegras at the same time. To exercise this feature, use the slave option on one of the Tegras so that only one of the Tegras controls the camera sensor programming.

The slave option on the command line allows Tegra to capture the images from the sensors that are already programmed by the master Tegra. Thereby the slave Tegra programs only the aggregator.

To capture RAW12 frames from the sensor (OV10640) and display on to the screen on the CSI port AB:

For camera remapping, the csi_outmap of the enabled camera link(s) must start with 0, then 1, 2, and 3. The disabled camera cannot be assigned a smaller out number than the enabled camera.

To capture YUV422 frames from 3 cameras (OV10635):

In this case, the csi_outmap cannot be set to 1203. For example: