[computer vision] Opticflow multiple cameras

[matteobarbera]

Proposal for #1772

The files currently compile, I plan to test the opticflow module on a Bebop with both cameras before finalizing the pull request.
The modified cv_opticflow module is able to run the computer vision functions on both front and bottom camera simultaneously. I tested it on a Bebop 1, I added the required defines to the bebop_opticflow_indoor.xml airframe to showcase the module usage, but perhaps making a whole new airframe might be better.

I have not found a clever solution on how to avoid writing a lot of duplicate code for the defines in cv_opticflow.xml (and as a consequence in the initialization of the multiple opticflow_t structs). Originally I intended for the module to be able to run on an arbitrary number of cameras, but due to how Paparazzi handles module defines I had to hardcode it to front and bottom cameras only in a lot of places.

There are a lot of changes that have been made already, the next step would be to change the opticflow ABI message, since (from my understanding) it's not currently possible to distinguish if the message contains results from the front or the bottom camera.

[dewagter]

Thank you for this important update.
I understand that functions might need extra parameters, but doesn't cv_add_to_device already know the camera id as the first parameter?

[matteobarbera]

Perhaps me calling it camera id is not the clearest name. In order to run the cv functions and know which opticflow struct to use, where to write the result etc. some form of identification needs to be passed to the video_listener cv_function. I chose to pass a uint8_t which is then used as an index in opticflow_module.c to know which struct in the opticflow_t array and opticflow_result_t array to use.

Originally I didn't want to hardcode an id for front/bottom camera (to support an arbitrary number of devices), so technically when cv_add_to_device is called there could be a hardcoded "id" or "index" that is then used by the cv_function by looking at the device name, without the need of an additional function parameter in cv_add_to_device. But I thought that having the "id" be set in the same file where it is then used was more transparent.

This index/id being so free to choose could cause some confusion on how it's supposed to be used, so if linking the camera name to it is a better option I can change it. It's not the cleanest solution at the moment, as there are no checks/safeguards on this extra function parameter, so I am very much open to suggestions.

[dewagter]

Thanks for the extra information.

[tomvand]

Hi Matteo, I'm currently going through your pull request. Why did you choose to set the id in cv_add_to_device instead of hardcoding it in the struct video_config_t *device (e.g. a sender_id for the front_camera and bottom_camera structs) and passing that value to the cv_function? To make it easier to allocate and find the correct optic flow struct? I'm fine with the solution, just wondering ;).

[tomvand]

See comments, but looks good to me

[matteobarbera]

Hi Matteo, I'm currently going through your pull request. Why did you choose to set the id in cv_add_to_device instead of hardcoding it in the struct video_config_t *device (e.g. a sender_id for the front_camera and bottom_camera structs) and passing that value to the cv_function?

I thought it would be better to avoid hardcoding id since an if statement would also then have to be used when you need to check the id every time you need to use it to access/write to one of the structs in the array. Similar to why I didn't want to use the camera name as the identification method.

Another option that I thought of was to create a static variable in cv.c that would start at 0 and increment every time a new device is added, so no extra arguments would need to be passed to cv_add_to_device. However, this is a lot less transparent and could cause problems since you then have to check if the id of the first opticflow camera is indeed 0 so it can be correctly used as an index for the struct arrays.

[tomvand]

Agreed, let's stick with your solution then :)

[tomvand]

Only two minor comments, pprzlink, and then it's ready to be merged :)

[tomvand]

Looks good to me! Could someone (@gautierhattenberger ?) take a short look at the pprzlink changes before merging? Cheers