@griffin @tom it looks like discovery of multiple streams is improperly implemented in voxl-mavcam-manger.

the first issue I see is that each camera is being advertised as the same component ID

 init_arr[i].context.compid = MAV_COMP_ID_CAMERA; // todo make this command line arg

according to the mavlink spec each cam should have a unique id. https://mavlink.io/en/services/camera.html#camera_identification I would image this should look some thing like this.

int cam_comp_ids[MAX_MAVCAM_INPUTS] = {MAV_COMP_ID_CAMERA, MAV_COMP_ID_CAMERA2, MAV_COMP_ID_CAMERA3, MAV_COMP_ID_CAMERA4, MAV_COMP_ID_CAMERA5, MAV_COMP_ID_CAMERA6};

    for(int i=0; i<n_mavcam_inputs; i++){
...
    init_arr[i].context.compid = cam_comp_ids[i];

however when testing this change I think I have run into a bigger problem which is that I think only the last context's threads are running. I am not sure why this is, but it seems like the maybe the different threads can't read from the same modal pipe that is providing the mavlink? I suspect that somehow the reading and writing to the modal pipe is not sufficiently isolated causing either overwriting the first's context's callbacks or preventing the first context's callbacks from running.

let me know what ya'll think

@brahim after looking at this some more I think it is valid to have multiple streams per camera. I guess the use case would be to have a high res stream and a low res stream that's separate or something like that.

However I think people would still like to setup multiple cameras. I haven't tried this yet, but I think it could also be valid to spawn a manager per camera, and then stagger the component ids for each app. I think this might also fix the threading issue since each application would initialize separate pipe reads and wouldn't be blocked by each other?

@Eric-Katzfey I'm using a different mavlink GCS that's not QGC, so I need to make voxl-mavcam-manager conform to the standard.

@brahim after looking at this some more I think it is valid to have multiple streams per camera. I guess the use case would be to have a high res stream and a low res stream that's separate or something like that.

However I think people would still like to setup multiple cameras. I haven't tried this yet, but I think it could also be valid to spawn a manager per camera, and then stagger the component ids for each app. I think this might also fix the threading issue since each application would initialize separate pipe reads and wouldn't be blocked by each other?

@Eric-Katzfey I'm using a different mavlink GCS that's not QGC, so I need to make voxl-mavcam-manager conform to the standard.

@griffin @tom it looks like discovery of multiple streams is improperly implemented in voxl-mavcam-manger.

the first issue I see is that each camera is being advertised as the same component ID

 init_arr[i].context.compid = MAV_COMP_ID_CAMERA; // todo make this command line arg

according to the mavlink spec each cam should have a unique id. https://mavlink.io/en/services/camera.html#camera_identification I would image this should look some thing like this.

int cam_comp_ids[MAX_MAVCAM_INPUTS] = {MAV_COMP_ID_CAMERA, MAV_COMP_ID_CAMERA2, MAV_COMP_ID_CAMERA3, MAV_COMP_ID_CAMERA4, MAV_COMP_ID_CAMERA5, MAV_COMP_ID_CAMERA6};

    for(int i=0; i<n_mavcam_inputs; i++){
...
    init_arr[i].context.compid = cam_comp_ids[i];

however when testing this change I think I have run into a bigger problem which is that I think only the last context's threads are running. I am not sure why this is, but it seems like the maybe the different threads can't read from the same modal pipe that is providing the mavlink? I suspect that somehow the reading and writing to the modal pipe is not sufficiently isolated causing either overwriting the first's context's callbacks or preventing the first context's callbacks from running.

let me know what ya'll think

I would like to conduct SITL testing on the same PX4 commit I am deploying to my voxl. I have noticed that the SITL targets for both JMAVSim and JSBSim are failing to build.

I have been able to get my SITL platforms to build, but I have not been able to do it with out breaking the Voxl target. Here is a PR with change I made to get the SITL targets building.
https://github.com/modalai/px4-firmware/pull/61

I think the main issue are pound defines like the following

#if PX4_SOC_ARCH_ID == PX4_SOC_ARCH_ID_VOXL2
#include "fc_sensor.h"
#endif

PX4_SOC_ARCH_ID_VOXL2 is defined in the following enum

typedef enum PX4_SOC_ARCH_ID_t {

	PX4_SOC_ARCH_ID_UNUSED         =  0x0000,

	PX4_SOC_ARCH_ID_STM32F4        =  0x0001,
	PX4_SOC_ARCH_ID_STM32F7        =  0x0002,
	PX4_SOC_ARCH_ID_KINETISK66     =  0x0003,
	PX4_SOC_ARCH_ID_SAMV7          =  0x0004,
	PX4_SOC_ARCH_ID_NXPIMXRT1062   =  0x0005,

	PX4_SOC_ARCH_ID_STM32H7        =  0x0006,

	PX4_SOC_ARCH_ID_NXPS32K146     =  0x0007,
	PX4_SOC_ARCH_ID_NXPS32K344     =  0x0008,

	PX4_SOC_ARCH_ID_EAGLE          =  0x1001,
	PX4_SOC_ARCH_ID_QURT           =  0x1002,

	PX4_SOC_ARCH_ID_RPI            =  0x1004,
	PX4_SOC_ARCH_ID_SIM            =  0x1005,
	PX4_SOC_ARCH_ID_SITL           =  0x1006,

	PX4_SOC_ARCH_ID_BBBLUE         =  0x1008,

	PX4_SOC_ARCH_ID_VOXL2          =  0x100A,

} PX4_SOC_ARCH_ID_t;

The problem is that enums are not evaluated by the preprocessor. Therefore, when the preprocessor encounters the macro evaluation, PX4_SOC_ARCH_ID and PX4_SOC_ARCH_ID_VOXL2 are not recognized as they are part of an enum. As a result, #include "fc_sensor.h" is always included, regardless of the board type.

Would someone from the dev team be able to suggest a better way to create the macro?

Thanks in advance!