Extrinsic Matrices for 3+ cameras #660
Comments
|
I believe it doesn't relate to the overlaps, but instead is directly the cam0 -> cam1, and then cam1 -> cam2 sequential order. Camchain example: cam0:
cam_overlaps: [1, 2]
camera_model: pinhole
distortion_coeffs: [-0.3044477343700008, 0.06831190064580549, 0.0016385158708163779,
-0.0008662676729043089]
distortion_model: radtan
intrinsics: [542.4693569385074, 542.5943654005414, 524.0797458796575, 374.9032424633794]
resolution: [1024, 768]
rostopic: /bb2/left/image_mono
cam1:
T_cn_cnm1:
- [0.9996636322595407, -0.0023396338089671878, 0.025829217009016997, -0.11851975874888755]
- [0.0023291690482534857, 0.9999971927692536, 0.0004352300012703644, -9.924984662223608e-08]
- [-0.02583016277927054, -0.00037492299114023263, 0.9996662753757097, -0.0002488380896967549]
- [0.0, 0.0, 0.0, 1.0]
cam_overlaps: [0, 2]
camera_model: pinhole
distortion_coeffs: [-0.3172271683629877, 0.0796622417650886, 0.0016817111445300336,
0.0003884697800337926]
distortion_model: radtan
intrinsics: [542.1195972116055, 541.3994254954196, 512.4177276233356, 373.65549791432295]
resolution: [1024, 768]
rostopic: /bb2/right/image_mono
cam2:
T_cn_cnm1:
- [0.9992669676356307, 0.020129473755802423, -0.0325627345072751, 0.01773871315621785]
- [-0.01905646952339181, 0.9992758637360629, 0.032933252554748896, 0.05903083063685694]
- [0.0332020836933597, -0.03228858065702636, 0.9989269588901679, -0.024070661488148848]
- [0.0, 0.0, 0.0, 1.0]
cam_overlaps: [0, 1]
camera_model: pinhole
distortion_coeffs: [0.033130172812662916, -0.3296327708784002, 1.6123381603976683,
-2.924050525810986]
distortion_model: equidistant
intrinsics: [787.0594937497326, 785.6673160989883, 426.17865094797287, 351.9821746436108]
resolution: [808, 608]
rostopic: /bkfy/image_monoAnd the result.txt |
|
Hi, thank you for the response. I checked the multiplication and found that it was not very satisfactory: Meanwhile yours gives a very good result: I wanted to combine the pointclouds together but the results seemed really off, hence I thought that the camchain matrices were being parsed incorrectly, however it seems that the result is still quite wrong, should I take this as a bad calibration (a bad convergence)?
The two pointcloud groups are supposed to be overlapping together but there is a blank void in the middle, and the multiplication matrix is quite far from the identity matrix. |
|
Please pose your result txt and pdf report. How many connections do you have between each camera, and how do the reprojection errors look? How are you recovering this pointcloud? Stereo matching? Why would it be the middle here isn't clear to me. |
|
Hi, please find the files attached. I do not have the txt file any more but the contents should be in the PDF's first page. This is a 3-camera Realsense d435 setup where the cameras are pointed at each other in a roughly 60-degree angle, hence the actual capture scene is quite small. Based on the reprojection errors of around +- 2px I had assumed that this was small enough hence the calibration was good. I am projecting the pointcloud from the RGBD image using the intrinsic parameters from the yaml files, but using the pointcloud directly is also a viable option since we had saved the depth/registered_points directly. We just want to align these pointclouds so that they make sense. |
|
It looks like the camera1 to camera2 link has ~4k observations, while the camera2 to camera0 has 41k. Maybe this could be a problem, I am not sure. The 3d picture doesn't make much sense to me as the z-axis of all sensors should be pointing in a common direction correct? You can see that the cam0 has a weird spike with the majority of at very high azimuthal angle also, not sure what to think about this: Additionally, the reprojection errors don't look that gaussian so it might be worth trying to recollect and varying the board position in the image frame a bit more (use the |
|
Thanks for your suggestions! The observation differences is mainly because of the camera placement, because the placement itself (+ the resolution presumably) caused the algorithm to fail to detect the chessboard between two of the cameras (likely 1->2) unless I was standing in one very specific angle, or that the intrinsic step itself couldn't be completed with a lot of NaNs without sticking the board right in front of the camera. The 3D system does look really weird now that you mention it, though I could possibly think it would be ok if the Y and Z axis were swapped on that outlier camera. Are these results because of the kalibr algorithm itself, because I am quite sure we were using the same camera coordinate systems throughout all 3 cameras. |
|
why is the transformation called T_cn_cnm1 when it's the transformation from cam0 to cam1? |
This is the naming convention used. T_1_0 is the T_0_to_1 rotation. |
Hi, I am trying to calibrate a set of 3 cameras using Kalibr but I don't understand how the t_cn_cnm1 works.
Here is my output from the yaml:
From the wiki, T_cn_cnm1 is supposed to represent the transform with respect to the last camera in the chain. For a 2-camera setup this is intuitive to understand but I am a little confused in this particular scenario.
Cam 1 does not overlap cam 0 thus what is this T_cn_cnm1 for cam 1? If it is to the last camera in the cam_overlaps, then for cam 2, the cam_overlaps is [0, 1], thus does the T_cn_cnm1 for cam 2 represent the transformation matrix of cam 2 to cam 1 coordinates? In this case what is the transform of my cam 0, since the cam 1 <-> cam 2 matrices are circular with each other.
The text was updated successfully, but these errors were encountered: