Posts made by mkriesel

Hello,
I'm having a strange issue with trying to flash a voxl 2 mini. I can flash it on my laptop but I'm trying to flash the sdk through a raspberry pi but once it finishes it initial flash it gets to
[INFO] Waiting for ADB, if this takes more than 1 minute power cycle VOXL

But when the voxl power cycles it doesn't boot back into adb. The DS2 dark green light stays on and the D2 usb power light stays off. Also it is no longer shows up in "
fastboot devices"

When I lsusb I get

Bus 001 Device 050: ID 05c6:900e Qualcomm, Inc. QUSB_BULK_SN:1D35C79F

I can hold down the SW1 button and power cycle that puts it back into fastboot mode so its not fully bricked to the point I have to use the switch but then I run into the same issue where I cannot flash it because I get back to the same error, If I run the sdk on my laptop on the same voxl instead of the pi it does work. Nothing in the script looks like it failing and this has happened both with 1.1.2 and 1.4.0 and 1.6.3.

Any ideas on what may be causing this? It seems like to me the flash is failing silently in some way and preventing the voxl to fully boot but I can't figure out why.

Thanks,

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)?

@Alex-Kushleyev
I am able to see and detect the ESC with one voxl but on another it seems to not work at all, they are both flashed with the same version and settings (voxl2 SDK 1.4.1) and the only difference is the voxl2, all esc and cables are the same.

voxl2:/usr/share/modalai/voxl-esc-tools$ ./voxl-esc-scan.py
Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00)
[GCC 8.4.0]
Found voxl-esc tools bin version: 1.9
VOXL Platform: M0054
Detected RB5 Flight, VOXL2 M0054 or M0104!
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000
Sending library name request: libslpi_qrb5165_io.so
Sending initialization request
INFO: Scanning for ESC bootloader: /dev/slpi-uart-2, baud: 230400
Updated baud rate to 230400
WARNING: No ESC(s) detected
VOXL Platform: M0054
Detected RB5 Flight, VOXL2 M0054 or M0104!
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 250000
INFO: Scanning for ESC bootloader: /dev/slpi-uart-2, baud: 230400
Updated baud rate to 230400
WARNING: No ESC(s) detected
VOXL Platform: M0054
Detected RB5 Flight, VOXL2 M0054 or M0104!
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 921600
INFO: Scanning for ESC bootloader: /dev/slpi-uart-2, baud: 230400
ERROR: voxl_uart_read_bytes: Bus '12' is not initialized
Updated baud rate to 230400
WARNING: No ESC(s) detected
VOXL Platform: M0054
Detected RB5 Flight, VOXL2 M0054 or M0104!
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 57600
INFO: Scanning for ESC bootloader: /dev/slpi-uart-2, baud: 230400
Updated baud rate to 230400
WARNING: No ESC(s) detected

ERROR: not all ESCs found
voxl2:/usr/share/modalai/voxl-esc-tools$ voxl-esc

What do you want to do?

1. scan 3) spin 5) upload_params
2. detect 4) upgrade_firmware
   #? 2
   enabling bridge
   bridge enabled
   ERROR: voxl_uart_read_bytes: Bus '12' is not initialized
   [ERROR] No ESCs detected
   disabling bridge
   Sending kill slpi command!
   bridge disabled
   EXITING VOXL-ESC WITH ERROR
   voxl2:/usr/share/modalai/voxl-esc-tools$

@Vinny Part of the issue is it doesn't see to be detected/work on boot but when I use the commands it does work, sometimes it doesn't work at all even with the commands but at the moment it doesn't work on boot at all. Is this an issue with the cable do you think? I ask because there will be no difference between the scenarios and trying the same setup (cables and voxl) with a different ESC seems to work so to me it seems like I somehow broke the esc, but I'm not sure how.

Hello,
I have a drone using a 5v VOXL ESC Mini 4-in-1 with Built-in Power Module with the voxl2 and I have run into an issue where after some use the ESC are not detected anymore by the voxl2. Sometimes, the I can run the commands described in https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md to manually spin but I can no longer fly through QGC and the blue status light does not blink anymore. After some time though I could not even run the commands on the voxl either and I get a notice that no ESC is detected. The blue light still comes on and the voxl is powered through it so power is for sure going through. Anything to try or test to diagnose or get these working? Nothing should have changed in between them working and not working

@tom Gotcha, I did not realize that and in the version of QGC I was using the motor spin tool was not working. I updated QGC and was able to get them working correctly, thanks for the help.

@constantines

1. I'm pretty sure motor order is correct, what is the best way to check/change this my method so far has been running the spin test command you provide and then switching the wires for where they are plugged in, is there a way in software to change this?
2. Rotation direction is correct
3. The voxl orientation matches the voxl 2 flight deck, with the picture below the front is the voxl side going to the top of the image
   

I have another drone that matched this setup as well that at one point was able to fly and now has a similar issue so I'm trying to figure out why it no longer can fly.

Hello, I have a voxl flight deck 2 with the 4 in 1 esc using the SunnySky V2806 v 650 motors. I've gone through the ESC calibration with props on defined on the git and motors seem to be able to spin up to correct rpm, however when I go to actually fly giving any throttle the drone pitches hard up and attempts to flip.

https://review.px4.io/plot_app?log=20ac3c83-485a-41ce-94a0-cca4886b4724

It seems like 2 of the motors are not reaching the same rpm as the others and I think this may be my issue, but when I run ./voxl-esc-spin.py --id 3 --rpm 4000 --ramp-time 2.0 all motors seem to ramp up and able to hold 4000 rpm fairly constantly so I don't think the esc calibration is the issue. I've also turned the px4 PID down pretty low just to try to get the drone in the air.

There seems to be something I am missing in this setup so I'm trying to get any answers, thanks.

Hello, I am testing the ar0144 camera with the ae_mode set to "lme_msv" and I don't see the "ae_exposure_period" making any signifigant change. I set it to "1.0" then "1.5" and the images look exactly the same, and it seems like there is no different between the "recovery" time when going from dark to light. I'm wondering what this setting does because I believe it works different then what I am assuming.

Hello,

I have been doing alot of test recently with a voxl2 mini and I have come across an issue that I'm hoping I can get some help with. After extreme shock the app proc imu, the one from the voxl-imu-server, the imu becomes extremely saturated and seems to lock at this saturated state. shown in the graph below is the accels and the y reaches 156 m/s2 and never comes back down. This seems to be resolved with a reset of the entire system, so power off power on of the voxl, however that isn't really an option during operation so I'm wondering if there is a way to reset or power cycle only the imu in hopes to correct this without having to shut down the entire system? Any leads on this are helpful.

@tom Thanks for replying, I have actually resolved this already, There was an issue with the power supply and I guess whenever it would get to 12 % it would drop enough power to shut off and I didn't have access to any of the lights so I just didn't realize. After fixing the power supply I was able to complete the flashing process and everything is working properly now.