[Main] Ideal use case.

[lscarton]

KinovaVision kv;
kv.start();
cv::Mat img, depth_img;
kv.get_color_image(img);
kv.get_depth_image(depth_img);
kv.get_color_and_depth_image(img, depth_img);

@sthoduka

• are img and deepth_img passed by reference or by pointer?
• what do you prefear to set the parameters of kv (by constructor of by set_parameter function?)

Maybe the json parser should be outside KinovaVision so they are loosely cuppled, and play together in the main

[sthoduka]

• by reference for now I think
• either is fine; maybe constructor would be simpler
• yes, separating the json parser is fine, we can always change it later. I think it will mean the responsibility of loading the parameters is on the user of the library than the library itself, which may not be ideal.

I think the main thing is to get it working, and improvements can be made later

[lscarton]

@sthoduka I am thinking of two setting config methods:

• kv->config_rgb_camera();
• kv->config_depth_camera();

and 3 getting methods:

• `kv->get_color_and_depth_image(img, depth_img);
• kv->get_depth_image(depth_img);
• kv->get_color_image(img);

please try the main in the working branch and let me know if it is similar to what you had in mind.

[lscarton]

I do not see any use in the code of the information about the camera calibration beside width,height and camera_type. It also seems to me that they operate either color or depth but not both simultaneuosly. is it there a possible limitation in the hw/sw?

[sthoduka]

I am thinking of two setting config methods:

What would these methods do? I'll add some more comments in the PR

I do not see any use in the code of the information about the camera calibration beside width,height and camera_type.

Camera calibration will be useful later for pointcloud generation. And in general, people might need it for other tasks.

It also seems to me that they operate either color or depth but not both simultaneuosly. is it there a possible limitation in the hw/sw?

I don't think it's a hardware limitation; maybe separate ROS nodes were used for RGB and depth to simplify usage (e.g. launch only the RGB node, and use a separate gstreamer pipeline for each).

If we're getting both RGB and depth streams simultaneously, the gstreamer pipeline should have two sources and two sinks (from what I understand based on this)