Posts made by mark

Hi @Alex-Kushleyev, thanks for the help. I have been trying a few configuration, different combinations with camera's cables, and coax boards. For my case it seems that the cable was not the issue but the camera. After changing this I have not seen it happen again.

@Alex-Kushleyev
This is the output i get from dmesg -w, the i put 2 enters at the place where the camera stream duplicates.
I do see the same error mesages as you sent, but only with id 6 instead of 3. I am quite certain i am using the 8-bit drives, since the files in /usr/lib/camera/ do not specify 10_bit, or 12_bit, and the output format of the sensor is RAW8

[  420.109884] qcom,camera ac50000.qcom,cci:qcom,cam-sensor2: Linked as a consumer to regulator.60
[  420.109907] qcom,camera ac50000.qcom,cci:qcom,cam-sensor2: Linked as a consumer to regulator.56
[  420.109942] qcom,camera ac50000.qcom,cci:qcom,cam-sensor2: Linked as a consumer to regulator.79
[  420.123279] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 997 CAM_ACQUIRE_DEV Success, sensor_id:0x577,sensor_slave_addr:0x34
[  420.180419] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor0: Linked as a consumer to regulator.58
[  420.182197] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor0: Linked as a consumer to regulator.56
[  420.184391] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor0: Linked as a consumer to regulator.60
[  420.184436] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor0: Linked as a consumer to regulator.79
[  420.194168] CAM_ERR: CAM-ISP: cam_ife_csid_cid_reserve: 1040 CSID:5 IPP resource not available
[  420.194171] CAM_ERR: CAM-ISP: cam_ife_csid_cid_reserve: 1040 CSID:4 IPP resource not available
[  420.194173] CAM_ERR: CAM-ISP: cam_ife_csid_cid_reserve: 1040 CSID:3 IPP resource not available
[  420.194175] CAM_ERR: CAM-ISP: cam_ife_csid_cid_reserve: 1040 CSID:2 IPP resource not available
[  420.194201] CAM_ERR: CAM-ISP: cam_ife_hw_mgr_print_acquire_info: 710 Successfully acquire single IFE[1 -1] with [11 pix] [0 pd] [0 rdi] ports for ctx:0
[  420.199051] CAM_INFO: CAM-CSIPHY: cam_csiphy_core_cfg: 1137 START_DEV: CSIPHY_IDX: 1, Device_slot: 0, Datarate: 1500000000, Settletime: 2200000000
[  420.204368] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 997 CAM_ACQUIRE_DEV Success, sensor_id:0x356,sensor_slave_addr:0x30
[  420.207707] CAM_INFO: CAM-ISP: cam_vfe_bus_ver3_init_hw: 3659 Overriding clock gating at bus input
[  420.207712] CAM_INFO: CAM-ISP: cam_vfe_top_ver3_init_hw: 246 Disable clock gating at IFE top
[  420.207731] CAM_ERR: CAM-ISP: cam_ife_mgr_start_hw: 4510 ->Config HW, 000000002005597e
[  420.208476] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 1089 CAM_START_DEV Success, sensor_id:0x577,sensor_slave_addr:0x34
[  420.217046] CAM_INFO: CAM-ISP: __cam_isp_ctx_sof_in_epoch: 1660 First SOF in EPCR ctx:3 frame_id:1 next substate EPOCH
[  420.291920] CAM_ERR: CAM-ISP: cam_ife_csid_cid_reserve: 1040 CSID:5 IPP resource not available
[  420.291923] CAM_ERR: CAM-ISP: cam_ife_csid_cid_reserve: 1040 CSID:4 IPP resource not available
[  420.291925] CAM_ERR: CAM-ISP: cam_ife_csid_cid_reserve: 1040 CSID:3 IPP resource not available
[  420.291926] CAM_ERR: CAM-ISP: cam_ife_csid_cid_reserve: 1040 CSID:2 IPP resource not available
[  420.291947] CAM_ERR: CAM-ISP: cam_ife_hw_mgr_print_acquire_info: 710 Successfully acquire single IFE[0 -1] with [11 pix] [0 pd] [0 rdi] ports for ctx:4
[  420.297184] CAM_INFO: CAM-CSIPHY: cam_csiphy_core_cfg: 1137 START_DEV: CSIPHY_IDX: 2, Device_slot: 0, Datarate: 1500000000, Settletime: 2200000000
[  420.305641] CAM_INFO: CAM-ISP: cam_vfe_bus_ver3_init_hw: 3659 Overriding clock gating at bus input
[  420.305645] CAM_INFO: CAM-ISP: cam_vfe_top_ver3_init_hw: 246 Disable clock gating at IFE top
[  420.305659] CAM_ERR: CAM-ISP: cam_ife_mgr_start_hw: 4510 ->Config HW, 000000002005597e
[  420.306460] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 1089 CAM_START_DEV Success, sensor_id:0x577,sensor_slave_addr:0x34
[  420.315030] CAM_INFO: CAM-ISP: __cam_isp_ctx_sof_in_epoch: 1660 First SOF in EPCR ctx:4 frame_id:1 next substate EPOCH
[  420.531299] CAM_ERR: CAM-ISP: cam_ife_hw_mgr_print_acquire_info: 710 Successfully acquire single IFE[5 -1] with [0 pix] [0 pd] [1 rdi] ports for ctx:5
[  420.532371] CAM_INFO: CAM-CSIPHY: cam_csiphy_core_cfg: 1137 START_DEV: CSIPHY_IDX: 0, Device_slot: 1, Datarate: 592000000, Settletime: 2800000000
[  420.533160] CAM_INFO: CAM-ISP: cam_vfe_bus_ver3_init_hw: 3659 Overriding clock gating at bus input
[  420.533164] CAM_INFO: CAM-ISP: cam_vfe_top_ver3_init_hw: 246 Disable clock gating at IFE top
[  420.533174] CAM_ERR: CAM-ISP: cam_ife_mgr_start_hw: 4510 ->Config HW, 000000002005597e
[  420.555764] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 1089 CAM_START_DEV Success, sensor_id:0x356,sensor_slave_addr:0x30
[  423.218172] cam_ife_csid_irq: 73 callbacks suppressed
[  423.218177] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  423.218949] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  423.222473] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC


[  424.215015] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  424.215712] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  424.218606] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  425.214507] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  425.215872] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  425.215911] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  425.216231] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.211853] cam_ife_csid_irq: 8 callbacks suppressed
[  429.211856] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.211948] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.212130] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.212208] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.212289] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.212672] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.212811] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.212943] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.213919] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  429.214209] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214444] cam_ife_csid_irq: 45 callbacks suppressed
[  434.214448] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214659] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214698] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214739] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214778] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214818] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214838] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214858] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214878] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.214898] CAM_ERR: CAM-ISP: cam_ife_csid_irq: 4903 CSID:6 ERROR_CRC
[  434.215584] CAM_INFO: CAM-ISP: cam_ife_csid_halt_csi2: 1931 CSID: 6 cnt: 1 Halt csi2 rx
[  434.215593] CAM_INFO: CAM-CSIPHY: cam_csiphy_subdev_handle_message: 22 subdev index : 0 CSIPHY index: 0
[  434.215597] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 103 PHY base addr=        pK-error offset=0x8b0 size=11
[  434.215602] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR0 = 0xc4
[  434.215607] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR1 = 0x1
[  434.215611] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR2 = 0x0
[  434.215616] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR3 = 0x0
[  434.215620] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR4 = 0x0
[  434.215625] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR5 = 0x0
[  434.215629] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR6 = 0x7
[  434.215633] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR7 = 0x0
[  434.215638] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR8 = 0x60
[  434.215642] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR9 = 0x50
[  434.215647] CAM_INFO: CAM-CSIPHY: cam_csiphy_status_dmp: 117 CSIPHY0_IRQ_STATUS_ADDR10 = 0xc4
[  434.215650] CAM_INFO: CAM-CSIPHY: cam_csiphy_subdev_handle_message: 22 subdev index : 1 CSIPHY index: 0
[  434.215653] CAM_INFO: CAM-CSIPHY: cam_csiphy_subdev_handle_message: 22 subdev index : 2 CSIPHY index: 0
[  434.215655] CAM_INFO: CAM-CSIPHY: cam_csiphy_subdev_handle_message: 22 subdev index : 3 CSIPHY index: 0
[  434.215658] CAM_INFO: CAM-CSIPHY: cam_csiphy_subdev_handle_message: 22 subdev index : 4 CSIPHY index: 0
[  434.215660] CAM_INFO: CAM-CSIPHY: cam_csiphy_subdev_handle_message: 22 subdev index : 5 CSIPHY index: 0
[  434.215673] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4616 idx 6 err 5 phy 0  lane type:0 ln num:1 ln cfg:0x2 cnt 1
[  434.215675] cam_csid_evt_bottom_half_handler: 1 callbacks suppressed
[  434.215677] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status RDI0: cc0
[  434.215678] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status RDI1: 0
[  434.215681] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status RDI2: 0
[  434.215683] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status RDI3: 0
[  434.215685] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status TOP: 0
[  434.215687] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status RX: 80011
[  434.215689] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status IPP: 0
[  434.215691] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status PPP: 0
[  434.215693] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status UDI0: 0
[  434.215694] CAM_ERR: CAM-ISP: cam_csid_evt_bottom_half_handler: 4621 status UDI1: 0

Hi @Alex-Kushleyev, Maybe is should have specified this, but I installed the resistor on another VOXl which had the same issue, but is unable to fly because of other reasons. I am still able to reproduce this issue with the original VOXL mentioned.

I did a test where i Covered up the tracking_front camera while both streams gave the sane outtput.

• The exposure and gain of the both camera's stay the same. Both when the tracking_front is covered, and when the tracking_down is covered.
• When only tracking_front is covered, the exposure and gain increases.
• when only traccking_down is covered, non of the camera's increase their exposure or gain.
  Let me know if you need me to run more tests, to try and figure thing out.

Hi @Alex-Kushleyev i ran the tests, and it seems that the issue only occurs when both the hires cameras are enabled. when one or the other is disabled, this problem does not occur. Also running the CPU in performance does make it run normally longer, but the stream still switches.
Looking again at the images of the VOXLs i notice that a resistor in the bottom left of the frame is not placed in the m0054 version that is placed in the m0154 version. I placed a 100k resistance there (same as on the other resistances.) and that seemed to work, at least for this VOXL. Could it be that this is related to the I2C address of the camera or the VOXL?

@Alex-Kushleyev, By the way, as i was comparing this VOXL2 to one which does not have this same issue, i noticed that the board seemed to be an older one, could this have anything to do with it?
VOXL with the issue:

VOXL which behaves as expected:

hi @Alex-Kushleyev, i am not using the 10 or 12 bit drivers, everything was set up using voxl-configure-cameras 28 this is what the /usr/lib/camera folder looks like (the .tuned files of the 412 camera were renamed in order to use the default .tuned files, which gave the best image for our application)

Hello I am encountering a weird issue using the M0173 with 2 IMX412 cameras and 2 AR0144 cameras.
The streams of the tracking cameras start out correct when (re)starting the voxl-camera-server, but after some point the tracking_down seems to copy the tracking_front images. Do you maybe know a solution for this problem? or have you seen this happen before? any help would be appreciated.


I am using sdk 1.4.5 on the drone.

Hi,
We are using the smaller IMX412 sensor (https://www.modalai.com/collections/accessories/products/msu-m0107?variant=45747768557872), and we noticed that this sensor was not able to be connected to while the older/larger version of this sensor connects to the same port without issue. Is this an known issue, or is there a way to solve this?
Some information about the setup:
We are running system image 1.6.2-M0054-14.1a-perf (SDK 1.0.0)
We also are running camera binaries from system image 1.7.1 for the IMX412 specifically.
We are connection 2 IMX412 cameras to hw sensor id's 2 and 3, and a tracking cam to hw sensor id 4.

Hi @Alex-Kushleyev
Thanks for the clarifications! A little bit of context for what purpose we use the camera's. We do analysis on the images taken, this analysis consists of detecting smaller features like plants on the image, usually the size of a couple pixels, i think in the neighborhood of 20x20 pixels most often. The amount of light available is dependent on the day, but usually there is enough light available that we can use short exposure times. (the tests above were indeed done inside the office and not in the practical sense we would otherwise use the drones.) For our applications the pixel noise is not that much of an issue as long as the features are visible. The video encoder we on not use.
As for the exposure times, these were set manually and not using the auto exposure as i thought this would be a fairer comparison. So in the images the gain was set to 400 and the exposure to 10ms, but the lighting conditions indoors are not that bight for the images, so the images were also somewhat darker than typically would be the case.
The idea of being able to tune the camera would be interesting for us, but i expect that would take some time to implement, but we are looking forward to it.

Hi @Alex-Kushleyev,

Thanks for the reaction, i tried the new camera binaries, and i think the images are better for it. Using the same features as before the image went from this:

to this:

There seems to be a bit more noise, but the quality of the image and especially the colors are better. I also tested on something closer by. old:

new:

Comparing these images it seems like before there was some kind of smoothing happening on the older version, that is now not happening anymore? also it seems that i need longer exposure times to reach the same brightness in the images. The resolution the camera server picks seems to be different from the config file. In the config file the resolution is set to 3000x4000.

Also when the camera is set to be 3840x2160 in the config file the resolution seems to be different, but in both cases the images coming through the pipe are in the expected format. so i don't know if this is an issue?

Is there by any change any news on this?

Hi @Alex-Kushleyev thanks for the reaction
To clarify, both images are take using the voxl-logger (from the hires_color stream), both the video streams are disabled on both the VOXL1 and VOXL2. (Both images are a crop from the full image, because the full image was to big to upload, and most of the rest of the image was a white background.)
The same camera is switched between the VOXL1 and the VOXL2, and the images are taken from the same distance to the object in the image.
VOXL 1 was set to 3840 x 2160 resolution, and the FPS was set to 30
VOXL2 was set to 4000 x 3000 resolution and the FPS was set to 15

We are currently working with both the VOXL (SDK1.1.2) and the VOXL2 (SDK1.1.0) and we noticed some quality differences between the two platforms. The colors in the image taken with the VOXL (first image) seem to be better than on the VOXL2 (second image). Also the image seems to be more blurry on the VOXL2 while taken with the same camera (IMX412).
Both platforms were set to hires only, with AE_MODE set to "isp".
On the VOXL2 the camera is connected to HW sensor ID 2
Is this a known isue? or is there a way to get the same quality on the VOXL2 as on the VOXL?


We also noticed the snapshot on the VOXL not having the wierd artefact the VOXL2 has (as mentioned in this post https://forum.modalai.com/topic/2546/some-issues-with-voxl-camera-server-1-6-2?_=1707751139845)

@Ariel-Young Thanks the new camera server works. The only thing is we still see the wierd repeating part in the image when using the snapshot function (top image), is this something you also see?

with the new SDK 1.0.0 we wanted to use the new snapshot functionality on the voxl2, but we notice that the images seem to have a part in the image where the image repeats itself.

Is there a solution for this, or is this a known issue?
This is something we see with both the IMX412 and the IMX214.

Another thing we noticed was that the hires_color pipe shows images which are misdecoded,

but this seemed to be fixed in the latest stable branch on git. But now we noticed that only 1 camera can be active at a time using this version (voxl-camera-server 1.7.0). The tracking camera also seemed to return a clitched image:

Is this version not ready for use yet? and if so is it known when this version is stable?

The same quality difference is also seen in the IMX412 camera. where on the Voxl1, The image has less noise/looks sharper than on the Voxl2

We have been working with the IMX214 image sensor on the Voxl and Voxl2, but we noticed there is a considerable difference in noise in the image between the 2 platforms, and also in the colour balancing.
for example these 2 images are taken using the same camera on a Voxl:

and the Voxl2:

more zoomed in for comparrison Voxl:

Voxl2:

Is there a way to get the same image quality from both Voxl and Voxl2?
We use the default settings ( voxl-configure-cameras 8 ) where we only change the resolution to 3840x2160.

Hello, We recently started working with the new IMX678 camera, but we have notices it has more noise when compared to the IMX412, and also the images seem to have a green tint over them. Is this something that is known, or are we maybe missing a setting in the camera server config for the IMX678. We have them both configures as IMX214 images sensors in the camera server config. (we use system image 1.5.5)
IMX412 image:

IMX678 image:

{
	"version":	0.1,
	"cameras":	[{
			"name":	"tracking",
			"enabled":	true,
			"frame_rate":	30,
			"type":	"ov7251",
			"camera_id":	2,
			"ae_mode":	"lme_hist",
			"ae_desired_msv":	60,
			"ae_k_p_ns":	1000,
			"ae_k_i_ns":	0,
			"ae_max_i":	250
		}, {
			"name":	"hires",
			"enabled":	true,
			"frame_rate":	3,
			"type":	"imx214",
			"camera_id":	1,
			"preview_width":	3840,
			"preview_height":	2160,
			"record_width":	1920,
			"record_height":	1080,
			"snapshot_width":	3840,
			"snapshot_height":	2160,
			"ae_mode":	"off"
		}, {
			"name":	"hires2",
			"enabled":	true,
			"frame_rate":	15,
			"type":	"imx214",
			"camera_id":	0,
			"preview_width":	3840,
			"preview_height":	2160,
			"record_width":	1920,
			"record_height":	1080,
			"snapshot_width":	3840,
			"snapshot_height":	2160,
			"ae_mode":	"off"
		}]
}

@Chad-Sweet said in Hires images are not showing correctly when using 3000 x 4000 resolution:

voxl-camera-server --list

I am using the voxl 2. The type is set as IMX214 in the camera server config because it does not accept type IMX412, but the camera works with setting the type as IMX214.

This is the output that voxl-camera-server --list gives, where camera 1 is the IMX412, and camera 2 is an IMX214.
I have tried other resolutions from this list, like 4056x3040, and 3040x3040, but then i get the error that the the config is not supported.

Also this list does not indicate 3840x2160 as a possible resolution, while is it able to run that.

This is also the list of configuration that the camera -server is searching through and here 4000x3000 and 3840x2160 are available combinations, and in this list 4056x3040 is an available resolution, but the format does not match the needed format, and 3040x3040 in not in this list at all.
I have tested this camera about a year ago on the VOXL1 and then is was able to give me images with the resolution 4000x3000.

I am trying to get 12MP images from the IMX412 sensor using the voxl 2, but the images recieved are looking like it is decoded wrongly like this.

Is there an setting for the camera that i may have missed? (these are the settings i used)