I have a 2 imx678 hires cameras attached to a voxl 2 mini the stream video using the voxl-camera-server without any problems, however there is a weird color tint on the cameras. Is there any way to adjust to color calibration for the voxl-camera-server? If not is there a way to access the raw8 or raw10 grey video without any image processing done to them?

@tom I thought I did but it wasn't in properly I tested it again and I got sucess.
so this confirms that uart is working correct? and then for using it in my own program I could use the same things I see in the test program with #include <voxl_io.h> and then all the same voxl_uart functions used in the program yeah?
Thanks.

@Moderator Any update on accessing the RAW8 for the hires image sensors?
Also, is there a way to change the exposure and gain manually. In the voxl-camera-server config I have been able to change the setting of ae_mode to off and I've tried using the "voxl-send-command hires0_small_color set_exp_gain 100 200" for example but nothing changes. I also tried setting the ae_mode to lme_msv but changing the settings in the config had no effect of the exposure or gain either, it was acting the same as the off mode. Are these settings available to the hires imx678? If not, is there any way for me to adjust the exposure and gain settings?

Hello,

I have 3 drones setup with what is essentially the flight deck setup with a front stereo and tracking camera and a voxl2. The voxl 2's have been replaced from their original and the ones we received are on SDK 1.5.0, in this version there is no option 11 for the voxl-configure-cameras

Available camera config IDs are as follows:

22 - M0173 Seeker V5+ dual AR0144
26 - M0173 Starling 2 IMX412 + dual AR0144
27 - M0173 Starling 2 PMD IMX412 triple AR0144
28 - M0173 Starling 2 Max dual IMX412 + dual AR0144
29 - M0173 Starling 2 Max PMD + dual IMX412 + dual AR0144
30 - M0173 Starling 2 Prototype dual PMD + dual IMX412 + dual AR0144
36 - M0173 Seeker V5+ IMX412 + dual AR0144
37 - M0173 Seeker V5+ IMX412 + dual AR0144 + Boson
46 - M0173 Seeker V5+ IMX664 + dual AR0144
47 - M0173 Seeker V5+ IMX664 + dual AR0144 + Boson
C - use user-defined custom camera config in
(/data/modalai/custom_camera_config.txt)
q - Quit The Wizard

selection:

One of the drones is on sdk 1.4.5 and has had no issues and I can configure option 11. I have copied all the same bins in /usr/lib/camera/ and am using the same voxl-camera-server.conf.

voxl-camera-server -l only shows 1 camera and it is only 1 of the stereo cameras and the voxl-camera-server does not start any of the cameras

Starting Camera: stereo_front (id #0)
gbm_create_device(156): Info: backend name is: msm_drm
setting ov7251 BLC register for cam id 0
ERROR: Failed to request camera info for camID 1, cam likely disconnected
ERROR: Camera 1 failed to find supported preview config: 640x480
WARNING: Failed to start cam stereo_front due to invalid resolution
WARNING: assuming cam is missing and trying to compensate
Starting Camera: tracking (originally id #2) with id offset: 1
WARNING: cam tracking (id 1) does not seem to be alive
Starting Camera: hires (originally id #3) with id offset: 1
WARNING: cam hires (id 2) does not seem to be alive
Starting Camera: stereo_rear (originally id #5) with id offset: 1
WARNING: cam stereo_rear (id 4) does not seem to be alive
ERROR: failed to initialize any cameras

------ voxl-camera-server: Started 0 of 4 cameras

------ voxl-camera-server: Camera server is now running

------ voxl-camera-server: Camera server is now stopping

------ voxl-camera-server: Camera server exited gracefully, returning -1

Hello,

I am working with a FETtec 45A 3-6S 4-in-1 ESC with the Voxl2 using the IO expansion board. I have gotten things setup where I can use QGC to control the motors using the actuator mode and it seems like I'm getting communication, however I am not sure if I am able to calibrate the ESCs. Whenever I run the px4-qshell command to calibrate esc I get an error that it times out, I hear beeps from the ESCs that seem to indicate its being calibrated but I'm not sure if it is actually working or not.

The issue it is causing at the moment that makes me unsure if they are calibrated or not is when I try to fly the drone either cannot get off the ground at all or one motor seems to be much lower power than the rest and it spins or flips. Makes it seem like something isn't

@Alex-Kushleyev

I'm trying to pull the images off and they seem to be corrupted somewhat. It almost seems like I'm getting the 16 bit image but in an 8 bit format. I'm subscribing to the boson_bayer and the image I'm getting seems to be the correct size and length but when I save its not correct. The RAW 8 stream I get on the voxl-portal looks the same, which I would expect for testing.

Heres what I'm getting for reference
https://drive.google.com/file/d/1fG5XEPM-b1NbC6H9R4jWSvZTDxm-a6Y_/view?usp=sharing

And then code I'm using to save it

static void _frame_cb(__attribute__((unused)) int ch, camera_image_metadata_t meta, char* frame, void* context)
{

    CameraInterface* interface = (CameraInterface*)context;

    if (interface->GetState() != ST_RUNNING) {
        return;
    }

    if (interface->ShouldSkip()) {
        return;
    }

    if (meta.format == IMAGE_FORMAT_NV12) {

    }
    else if (meta.format == IMAGE_FORMAT_RAW8) {
     
    }
    else if (meta.format == IMAGE_FORMAT_RAW10) {

    }
    else if (meta.format == IMAGE_FORMAT_RAW16) {
        std::cout << "16 bit image " << meta.size_bytes << " stride " << meta.stride << std::endl;
        int input_height = meta.height;
        int input_width  = meta.width;

        size_t frame_size = input_width * input_height * 2;

        char outname[100];

        std::string image_folder_name = "/data/pgm_frames";

        // uint16_t* frame_data = reinterpret_cast<uint16_t*>(frame);

        sprintf(outname, "%s/frame_%06lu.pgm", image_folder_name.c_str(), meta.timestamp_ns);
        printf("Output filename: %s\n", outname);

        // out_image.write(reinterpret_cast<char*>(pixels), IMAGE_PIXELS * sizeof(uint16_t));
        std::ofstream out_image(outname, std::ios::binary | std::ios::out);

        out_image << "P5\n640 512 65535\n";
        out_image.write(frame, frame_size);

    }
    else {
        // Not implemented
        std::cout << "other" << std::endl;
    }
}

Any thoughts?

@Alex-Kushleyev It seems to be working now, I'll do more testing but this looks correct

| Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format
| boson | 327680 | 640 | 512 | 0.00 | 799 | 163 | 21.6 | 60.0 | 157.3 | RAW8
| boson_bayer | 655360 | 640 | 512 | 0.00 | 0 | 163 | 20.0 | 60.0 | 314.6 | RAW16
| boson_color | 983040 | 640 | 512 | 0.00 | 799 | 163 | 22.7 | 60.0 | 471.9 | RGB
| boson_misp_encoded | 8826 | 640 | 512 | 0.00 | 799 | 163 | 25.5 | 60.0 | 4.1 | H265 (P)

Thanks for the help! Also, what version of the bosonSDK are you using for your python scripts? My version (3.0) doesn't have the dvoSetMipiStartState and a few other functions and I can't find a higher version on their website?

@Alex-Kushleyev
Alright, I've tried a few things and I can't see to get things to work.

voxl2-mini:~$ voxl-camera-server
Setting MISP AWB to Auto
MISP channels enabled in defaults : 0
MISP channels enabled in config file: 0

configuration for 1 cameras:

cam #0
name: boson
type: boson-fpv
bayer_type: 0
enabled: 1
camera_id: 0
camera_id_second: -1
fps: 30
en_rotate: 0
en_rotate2: 0

en_preview:          1
en_raw_preview:      1
preview_width:       640
preview_height:      512

en_misp:             1
misp_width:          640
misp_height:         512

en_small_video:      0
small_video_width:   640
small_video_height:  512

en_large_video:      0
large_video_width:   -1
large_video_height:  -1

en_snapshot:         0
snap_width:          -1
snap_height:         -1
exif_focal_length:   0.000000
exif_focal_len_35mm_format:0
exif_fnumber:        0.000000

ae_mode:             lme_msv
msv_exposure_min_us: 20
msv_exposure_max_us: 33000
gain_min           : 54
gain_max           : 8000
standby_enabled:     0
decimator:           1
independent_exposure:0

fsync_en: 0
fsync_gpio: 109

thread is locked to cores: 4 5 6 7
connected to mavlink pipe
Starting Camera: boson (id #0)
Opened GBM fd
gbm_create_device(156): Info: backend name is: msm_drm
Created GBM device
MISP Initializing for camera boson
Detected 1 platform(s)
Detected 1 GPU device(s)
Estimated imu dt = 0.000977s
Got unsupported format in getUVStartFromFmt, returning nullptr
WARNING: OMX SetTargetBitrate: H265 CBR requires bps >= 3.0Mbit (2000000 bps provided). Using FPS hack. scale = 1.500000

------ voxl-camera-server: Started 1 of 1 cameras

------ voxl-camera-server: Camera server is now running
ERROR: Received "Result" error from camera: boson
ERROR: Received "Buffer" error from camera: boson
ERROR: Received "Result" error from camera: boson
ERROR: Received "Buffer" error from camera: boson
ERROR: Received "Result" error from camera: boson
ERROR: Received "Buffer" error from camera: boson
ERROR: Received "Result" error from camera: boson
ERROR: Received "Buffer" error from camera: boson
ERROR: Received "Result" error from camera: boson
ERROR: Received "Buffer" error from camera: boson
ERROR: Received "Request" error from camera: boson

| Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format
| boson |
| boson_bayer |
| boson_color |
| boson_misp_encoded |

I copied the drivers into /usr/lib/camera/ and both the 8 bit and 14 bit drivers you provided gave the same error running various combinations of the set and read python scripts you sent.

(base) ➜ boson python3 boson_set_14bit.py
C serial FSLP load
Serial port open
Software Version: 4 0 27141
camera SN: 322022
dvoSetOutputFormat:
0
dvoSetType:
0
dvoSetOutputIr16Format:
0
roicSetFrameSkip:
0
Apply Custom Settings:
0
Save Settings To Flash:
0
Reboot
0
Closing com port and freeing serial port instance.
Serial port close
(base) ➜ boson python3 boson_read.py
C serial FSLP load
Serial port open
Software Version: 4 0 27141
camera SN: 322022
dvoGetType:
0
5
dvoGetOutputFormat:
0
3
dvoGetOutputIr16Format:
0
0
dvoGetLCDConfig:
0
0
ClockInfo:
0
60.0
27.0
16

Let me know if it seemed like I did something wrong, I tried both the J6 and J7 ports on the voxl 2 mini with the corresponding numbered driver.

@Alex-Kushleyev

Thanks for looking into this. At the moment there aren't any plans using the sync pin but we are trying to see if this is something worth looking into.

Back to testing, I recently got the boson board in and am trying to test it but have run into an issue with trying to get the camera-server installed.

I'm getting
voxl-camera-server depends on libmodal-pipe (>= 2.14.0); however:
Version of libmodal-pipe on system is 2.13.2.

Then for libmodal-pipe 2.14.0
dpkg: regarding libmodal-pipe_2.14.0_arm64.deb containing libmodal-pipe:
libmodal-pipe conflicts with voxl-cpu-monitor (<< 0.7.0)
voxl-cpu-monitor (version 0.6.0) is present and installed.

Bu voxl-cpu-monitor 0.7.0
dpkg: regarding voxl-cpu-monitor_0.7.0_arm64.deb containing voxl-cpu-monitor:
voxl-cpu-monitor conflicts with libmodal-pipe (<< 2.14.0)
libmodal-pipe (version 2.13.2) is present and installed.

So I'm stuck in a bit of a circle with the libmodal-pipe if you could help out

@Alex-Kushleyev Got around to testing this and J18 uart (qrb5165io-slpi-uart-test -d 2) and J19((qrb5165io-slpi-uart-test -d 7/6) all did not work with the error

Using device 2Sending library name request: libslpi_qrb5165_io.so
Sending initialization request
Received standard error event SNS_STD_ERROR_NOT_SUPPORTED
Couldn't configure flight_controller sensor
ERROR: fc_sensor_initialize failed
ERROR: Failed to initialize slpi
ERROR: Encountered error while initializing bus 12
[ERROR] Failed to open device

@Alex-Kushleyev Cool, follow up then the Boson has an external sync pin, does the mipi board support this still?

@Alex-Kushleyev I only need the RAW output I plan to do all the post processing myself so this is exactly what I need, Thanks!

Re: Boson 640 MIPI M0153: 16-bit Pre-AGC

Hello, I saw this post and I'm in a similar boat where I'm looking at using a boson over mipi. Is there any update that has been done or is planned with supporting 16 bit mipi and possibly 60 hz update (less important but would still be nice)?