ModalAI Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. Alex Kushleyev
    3. Posts
    • Profile
    • Following 0
    • Followers 11
    • Topics 1
    • Posts 2085
    • Best 125
    • Controversial 2
    • Groups 1

    Posts made by Alex Kushleyev

    • RE: Hadron ov64b snapshots have a vertical image artifact

      Once you confirm this working, we can discuss the options for snapshots without going through the ISP, but you can either saw the raw bayer or any of the misp outputs using voxl-record-raw-image and convert to jpg / png offline if that works for you, but we can also help add a compression option to voxl-record-raw-image.

      Please note that the current debayering algorithm in MISP does add some smoothing / interpolation, so the YUV image is not going to be as crisp as possible. You could compare it to the jpg output of the ISP (even thought it has artifacts). If you are looking for highest possible fidelity, it may be best to perform offline processing on the raw bayer, then you have more options.

      Alex

      posted in Video and Image Sensors
      Alex KushleyevA
      Alex Kushleyev
    • RE: Hadron ov64b snapshots have a vertical image artifact

      @cguzikowski ,

      Good news. I got it working, but there were a few things needed to update. I packaged everything into a zip : https://storage.googleapis.com/modalai_public/temp/ov64b/20260401/ov64b_20260401.zip . It contains

      • latest sensormodules for Boson and ov64b
      • voxl-camera-server conf
      • updated default tuning file (to fix the gain scale so that gain 1.0 is 100, not 54)
      • updated com.qti.chi.override.so file which contains some pipeline information, now it will allow the large raw resolutions

      (I thought the above changes were already in the latest SDK but somehow they did not make it, I will need to double check).

      I also made some changes to the ov64b driver:

      • updated frame length for the 9248x6944 mode so that it is 10fps (not 9.2) -- this is close to max
      • added modes 9216x6944@10fps and 4608x3472@30fps (slightly cropped on the right), so that these buffers can be used by MISP / gpu without doing a copy.

      I am able to capture the raw bayer at 9216x6944, 9248x6944 ,4624x3472, 4608x3472 resolutions

      voxl-inspect-cam hires_bayer
      ...
      |   Pipe Name |  bytes  | wide |  hgt |exp(ms)| gain | frame id |latency(ms)|  fps |  mbps  | format
      | hires_bayer |79994880 | 9216 | 6944 | 33.00 | 1594 |      130 |    157.9  | 10.0 | 6415.5 | RAW10
      
      

      In order to enable the misp support for the 4624x3472 and 4608x3472 resolutions in camera server, need a small update:
      https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/commit/389b1f4628a9b9cc0e53c43a5cf0e457717e1270

      You can save the raw bayer using the voxl-record-raw-image tool, for example:

      voxl-record-raw-image hires_bayer -d .
      

      You should be able to dump some raw bayer images and de-bayer them offline.

      Also, here is the contents of the README that is inside the zip:


      Supported Hardware

      • voxl2
      • Hadron plugged into VOXL2 J8 via M0181 adapter

      Instructions

      • copy Boson sensormodule to /usr/lib/camera/
      • copy ov64b sensormodule with correct id to /usr/lib/camera/
      • copy com.qti.tuned.default.bin to /usr/lib/camera to fix the gain scale (1.0x = 100)
      • back up /usr/lib/hw/com.qti.chi.override.so and replace it with com.qti.chi.override.so.20260401 (rename to com.qti.chi.override.so)
        • this updated file allows the pipeline to use the highest resolution of the ov64b camera
      • copy voxl-camera-server.conf to /etc/modalai

      Suported Resolutions

      • mode 0 : 9248x6944 10 bit 10 fps
      • mode 1 : 9216x6944 10 bit 10 fps (MISP no copy) -- crop 32 pixels on the right
      • mode 2 : 4624x3472 10 bit 30 fps
      • mode 3 : 4608x3472 10 bit 30 fps (MISP no copy) -- crop 16 pixels on the right
      • mode 4 : 3840x2160 10 bit 60 fps (MISP no copy)
      • mode 5 : 1920x1080 10 bit 240 fps
      • mode 6 : 1920x1080 10 bit 30 fps

      Notes

      • even thought the 9248x6944 and 9216x6944 modes are 10 fps, you need to specify 30fps in the camera config file. This will be investigated further.
      posted in Video and Image Sensors
      Alex KushleyevA
      Alex Kushleyev
    • RE: PX4 -> QGC connection through USB for VOXL2

      @bendraper , I just tried this on a Windows 11 VM and even though i was able to see a network device appear in the VM and i configured the IPv4 properties, I cannot ping or ssh. It seems consistent with what you are seeing.

      posted in Ask your questions right here!
      Alex KushleyevA
      Alex Kushleyev
    • RE: Hadron ov64b snapshots have a vertical image artifact

      @cguzikowski , OK, yes i know what that issue is (unexpected frame size). I will that and test both resolutions.

      posted in Video and Image Sensors
      Alex KushleyevA
      Alex Kushleyev
    • RE: Hadron ov64b snapshots have a vertical image artifact

      OK, I will test it and get back to you shortly 🙂

      posted in Video and Image Sensors
      Alex KushleyevA
      Alex Kushleyev
    • RE: PX4 -> QGC connection through USB for VOXL2

      @bendraper , If you see an ethernet connection to VOXL2 show up on your Windows host, then the usb gadget is properly configured on VOXL2. Perhaps something else is going on. Are you assigning a static ip on your host that is on the same subnet as VOXL2?

      You should try to repeat the same test on a linux machine (or virtual machine) to see if you can get a working connection.

      Alex

      posted in Ask your questions right here!
      Alex KushleyevA
      Alex Kushleyev
    • RE: Station Mode Issue with Voxl Suite 1.6.3

      @fhaltmayer ,

      SDK 1.6.3 added support for usb-eth0 (ethernet over usb). That interface should be using subnet 192.168.7.x. If your wifi subnet is the same, that could cause issues. Can you please check to make sure your wifi subnet is different?

      Alex

      posted in Ask your questions right here!
      Alex KushleyevA
      Alex Kushleyev
    • RE: Starling 2 Max Motor Catches

      @RyanH , from the spin log above, i can only tell that the motor attempts to spin up but re-starts after the open-loop sinusoidal spinup is done and the ESC detects that the motor is not spinning.

      You should try to clear the debris by spinning the motor by hand first (or use compressed air) and then use the test script to spin for longer periods of time without propeller (changing speeds, etc).

      You could use a spin step command to automate increasing and decreasing spin speed (without rpm control, since it's not needed):

      ./voxl-esc-spin-step.py --id 0 --step-delay 2.5 --step-frequency 1 --power 20 --step-amplitude 30
      

      Alex

      posted in Starling & Starling 2
      Alex KushleyevA
      Alex Kushleyev
    • RE: Controller Heating

      @Myles-Levine , the VOXL2 SoC is not designed to run at full power for a long time without cooling.

      The maximum operating temperature is around 95 deg C, at which point, the CPU will being automatically throttling (reducing) operating frequency.

      It is common to rely on air flow from propellers when the drone is flying, however some implementations may have a small fan as well.

      Since you mentioned bench testing, installing a small fan next to VOXL2 to get airflow over the board should help. No specific recommendations, you can start with a standard 12V fan used in PC power supplies.

      It can be relatively easy to overheat VOXL2 without cooling, because it has quite a powerful processor and the heat is concentrated in such a small package. You can spend more time optimizing the code (if possible) or add passive and / or active cooling.

      Alex

      posted in Ask your questions right here!
      Alex KushleyevA
      Alex Kushleyev
    • RE: GNSS EMI Mitigation Guidelines

      For those who are tracking this issue.. We have some interesting updates with respect to the interference from IMX412 camera. As it has been previously documented, the IMX412 camera(s) on Starling 2 and Starling 2 Max are causing interference as soon as the streaming is enabled (there are clients to the streams that camera server offers for those cameras).

      IMX412 camera has several internal clocks, which are generated from the 24 Mhz base frequency that is fed from Voxl2 to all cameras. These clocks are configured during the camera initialization phase - the settings are contained within the imx412 sensormodule files.

      We were able to perform some parameter sweeps - specifically varying only the output MIPI bitrate, while keeping all other settings the same (gain, exposure, fps).

      The test was set up as follows:

      • generate imx412 sensormodule drivers for desired frequency range (1200-2100)
      • all tests use the same camera resolution 3840x2160 at 45FPS
        • higher fps = more interference
        • tried to have a relatively large frequency range while keeping the fps high (low mipi rates cannot support high fps), so 45fps was a good compromise
      • repeat for each frequency
        • copy appropriate sensormodules (for specific frequency) into /usr/lib/camera/
        • log baseline satellite signal strengths for all satellites 10 seconds -- this allows the experiment to not depend on any initial SNR captures at the beginning of the test, since SNR can change relatively quickly due to the environmental factors
        • start voxl-camera-server and voxl-inspect-cam hires_front_misp_color hires_down_misp_color and wait for 3 seconds
        • collect satellite SNRs for 10 seconds while the cameras are streaming
        • stop voxl-camera-server
        • wait for 3 seconds and repeat the loop for the next frequency

      After data has been collected, analyze the logs and generate plots.

      The tests were done outdoors using Starling 2 Max with original GPS receiver + V3 GPS mast and 75mm FR4 (with copper) circular plate under the receiver. Full Sun light and exposure was set to 0.1ms, gain to 100 (1.0x). During testing it was discovered that the most interference was present when the image was darker than normal (under-exposed) -- probably related to specifics of the MIPI packets that are causing the interference.

      Note that the default IMX412 MIPI bitrate was set to the maximum that the camera officially supports, which is 2100Mbps.

      As the plots show, there are several peaks where the satellite SNRs drop by 10-15dB, as initially noted in the overall system testing. Additionally, 2100Mbps is one of the worst frequencies to use, based on this data.

      As a result of testing, the following frequencies were identified as causing significant interference with GPS L1 band:

      • 1212Mhz
      • 1260Mhz
      • 1572-1578 Mhz (L1 band!!)
      • 1800Mhz
      • 2100Mhz

      We will be releasing updated IMX412 drivers very shortly to avoid using 2100Mhz frequency.

      There results below show 3 tests:

      • 1200-2100 Mhz sweep with steps of 30Mhz
      • 1200-2100 Mhz sweep with steps of 6Mhz
      • 1760-2200 Mhz sweep with steps of 8Mhz (focusing on the upper range, slightly different PLL configuration)

      1200-2100 Mhz sweep with steps of 30Mhz

      imx412_pll_sweep_1200_2100_30_3840x2160_45fps_heatmap.png

      1200-2100 Mhz sweep with steps of 6Mhz

      imx412_pll_sweep_1200_2100_6_3840x2160_45fps_heatmap.png
      imx412_pll_sweep_1200_2100_6_3840x2160_45fps_median.png

      1760-2200 Mhz sweep with steps of 8Mhz

      imx412_pll_sweep_1760_2200_8_3840x2160_45fps_heatmap.png
      imx412_pll_sweep_1760_2200_8_3840x2160_45fps_median.png

      posted in Starling & Starling 2
      Alex KushleyevA
      Alex Kushleyev
    • RE: Starling 2 loses all cameras; voxl-camera-server -l reports 0 cameras even after voxl-configure-cameras 27, voxl-configure-mpa, and reflash

      Hi @irw ,

      This seems like a hardware issue, potentially related to PMIC. Are you able to share full dmesg output from boot, when this issue is happening?

      One thing to try would be to disconnect M0173 board from VOXL2 and see if you can reproduce the same messages related to cam_sensor*power_up -- these are definitely not normal. Perhaps there is a short on one of the camera power rails, which is preventing PMIC from working properly.

      Alex

      posted in Ask your questions right here!
      Alex KushleyevA
      Alex Kushleyev
    • RE: Image Stabilization calibration and pipe size clarification

      Hi @jameskuesel ,

      Yes there is an issue when both MISP and snapshot are enabled. I will look into it again.

      By the way, what snapshot are you looking to grab? There are a few options;

      • a frame from high-res recording (with eis?)
      • a frame from low-res streaming (with eis?)
      • full frame, full resolution (no stabilization)
        • what format? jpg or raw bayer (for offline processing)

      We can implement a snapshot feature in MISP (and not going through ISP).

      Alex

      posted in Ask your questions right here!
      Alex KushleyevA
      Alex Kushleyev
    • RE: VOXL 2 Mini / MCCA-M0178-1 Adapter Compatibility

      @Noah-Heinen , unfortunately it is not possible to add a TOF sensor to your current Voxl2 Mini configuration. M0188 adapter does not support TOF.

      The only way this would be possible is:

      • remove M0188
      • add M0172 and connect TOF and either M0186 or M0166 camera
      • add another M0172 or M0194 and plug in a single camera. Unfortunately right now we don't have a small adapter like M0172 or M0194 that supports two standard cameras like M0166 or M0186.

      So you would probably be losing one of the tracking cameras if you want to add a TOF sensor.

      Alex

      posted in Support Request Format for Best Results
      Alex KushleyevA
      Alex Kushleyev
    • RE: How to fix the UVC camera DEVICE ID

      @Jskim , maybe it's ok that the Device ID is increasing, however it could mean the USB device is not de-initializing properly (according to the Kernel). Perhaps the device is still open / in use by voxl-uvc-server when you power the camera off (switch to the SD card mode).

      Please see some more information below that may be helpful.

      Fix 1: Configure voxl-uvc-server to identify the camera by Vendor/Product ID

      Instead of relying on the device index, tell voxl-uvc-server to always find your camera by its USB VID:PID. This is the most robust approach.

      Step 1: Find your camera's Vendor ID and Product ID

      lsusb
      

      Look for your UVC webcam in the output. The ID is in VENDOR:PRODUCT hex format, e.g.:

      Bus 001 Device 003: ID 090c:337b  <-- vendor=090c, product=337b
      

      You can also use the ModalAI helper script:

      show-video-device-info.sh
      

      Step 2: Update the voxl-uvc-server service to pass VID/PID

      Edit the systemd service override so the server always targets your specific camera:

      mkdir -p /etc/systemd/system/voxl-uvc-server.service.d/
      cat > /etc/systemd/system/voxl-uvc-server.service.d/override.conf << EOF
      [Service]
      ExecStart=
      ExecStart=/usr/bin/voxl-uvc-server -v <your-vendor-id> -p <your-product-id>
      EOF
      systemctl daemon-reload
      systemctl restart voxl-uvc-server
      

      Replace <your-vendor-id> and <your-product-id> with the hex values from lsusb. With this in place, voxl-uvc-server will find the camera by identity rather than by device node index, so it will survive power cycles without needing a manual restart.


      Fix 2: Create a udev rule for a persistent /dev symlink

      This assigns a stable name (e.g., /dev/uvc_cam) to your camera regardless of enumeration order:

      cat > /etc/udev/rules.d/99-uvc-camera.rules << EOF
      SUBSYSTEM=="video4linux", ATTRS{idVendor}=="<your-vendor-id>", ATTRS{idProduct}=="<your-product-id>", SYMLINK+="uvc_cam", MODE="0660"
      EOF
      udevadm control --reload-rules
      udevadm trigger
      

      After this, /dev/uvc_cam will always point to your camera. You can reference this stable symlink in any configuration.


      Fix 3: Check dmesg for resource leak warnings

      If the device ID keeps incrementing (e.g., /dev/video0 → /dev/video1 → /dev/video2...) rather than re-using the same node, there may be an underlying resource leak from improper de-initialization:

      dmesg | grep -i "uvc\|video\|usb" | tail -50
      

      Look for warnings about disconnection or failed cleanup. If the ID increments indefinitely, this points to a kernel-side resource not being released properly on power-off — that may require a deeper fix or a systemctl stop voxl-uvc-server before powering down the camera.


      Summary

      Step Action
      1 Run lsusb to get your camera's Vendor ID and Product ID
      2 Pass -v <vid> -p <pid> to voxl-uvc-server via a systemd override
      3 Optionally create a udev rule for a stable /dev/uvc_cam symlink
      4 Check dmesg for warnings if the device ID keeps incrementing

      The vendor/product ID approach (Fix 1) should eliminate the need for the manual systemctl restart workaround entirely.

      posted in Video and Image Sensors
      Alex KushleyevA
      Alex Kushleyev
    • RE: Starling 2 / VOXL2 M0129 ESC not detected during voxl-esc scan or firmware upgrade

      @syamala-kotireddy ,

      If the ESC is not showing any signs of life (no blue led blink), it probably means the ESC power regulator is not working properly. However, you mentioned that VOXL2 is actually booting fine? Can you measure the voltage on the connector / pads that provide 5V power from M0129 ESC to VOXL2?

      Please see the following post, where a capacitor on the ESC next to the main voltage regulator was knocked off, resulting in ESC not starting up. https://forum.modalai.com/topic/4151/voxl-mini-4-in-1-esc-missing-capacitor/ . However, in that post, i think VOXL2 was not booting either. In your case the issue may be something different.

      It is worth carefully inspecting the ESC.

      Also, if you have a power supply that can measure current, you can set it to 8V and measure the current draw of the ESC alone, it should be very small (maybe 20-30mA) but not zero.

      Alex

      posted in ESCs
      Alex KushleyevA
      Alex Kushleyev
    • RE: Hadron ov64b snapshots have a vertical image artifact

      @restore , the change to enable the maximum resolution raw output for OV64B was made at the end of October 2025, so you would need at least SDK 1.6.0, I believe. There was a change in the camera pipeline (not the camera driver) to allow such a large image size. Are you able to test on a newer SDK (just test the latest if you can)?

      Additionally, the resolution 9248x6944 cannot be directly used in MISP debayering (which uses OpenCL). There are some special requirements on the image stride, which width of 9248 does not match. So what will happen is the cpu will realign the image before feeding it to the gpu, but it is a lot of data to copy for a 64Mpix sensor. So I made a small change in width from 9248 to 9216 (just cut off 32 pixels) and it can be fed into the gpu directly. That change is not published yet, but i can share it.

      Lets first confirm that you can use the 1.6.x SDK to start the camera server at 9248x6944 and you should be able to save raw bayer and view the misp output.

      you can always double check the list of available raw resolutions using voxl-camera-server -l

      by "start the misp output stream", i mean that you need to have a client that subscribes to the misp output stream, so that the frames start going and AE can work, sending exposure and gain updates to the camera, so that the image is properly exposed. For example, viewing the stream in voxl-portal or just using voxl-inspect-cam hires_misp_color to get the data flowing, then you can save the raw bayer, which will have the proper exposure and gain applied.

      Alex

      posted in Video and Image Sensors
      Alex KushleyevA
      Alex Kushleyev
    • RE: Export Controls

      @Michael-Soul , it is EAR99

      posted in Support Request Format for Best Results
      Alex KushleyevA
      Alex Kushleyev
    • RE: Hadron ov64b snapshots have a vertical image artifact

      @restore , a few more things:

      • you should set the auto exposure to lme_msv, which is the non-isp option, since we would not be using isp in this case
      • before saving the raw bayer, start the misp output stream, so that AE can actually process, otherwise the exposure will be stuck in default value -- the bayer stream does not trigger AE to process.

      Alex

      posted in Video and Image Sensors
      Alex KushleyevA
      Alex Kushleyev
    • RE: Hadron ov64b snapshots have a vertical image artifact

      @restore, that is strange. Does this effect appear in the jpeg snapshot only? (as opposed to the preview stream).

      Yes, we do support saving raw bayer10 for this camera. For 9248 x 6944, each image would be something like 80MB (10-bit bayer)

      In order to test it,

      • set your preview width and height to 9248 x 6944
      • en_raw_preview : true
      • en_snapshot : false (for now)
      • en_misp : true
      • set misp width and height to something reasonable (1920x1080)

      When you run it, assuming there are no errors, you should see hires_bayer pipe and you can dump individual images using voxl-record-raw-image tool.

      I have not tested this in a while, but it should work. Let me know if you run into any issues.

      Also, please use an SDK that is not older than few months, as we recently enabled the full raw resolution support for this camera.

      Regarding the jpeg smoothing, the parameters are baked into the chromatix tuning file and we have not tuned that for any particular application. However, you should first check whether the jpeg encode quality is sufficiently high. snapshot_jpeg_quality param in your voxl-camera-server.conf is set to 75.

      Alex

      posted in Video and Image Sensors
      Alex KushleyevA
      Alex Kushleyev
    • RE: Moving functions from J19 legacy or high speed B2B

      @austin-c , The GPS driver is built for SLPI as well as APPS PROC, so you could connect it to a apps-proc UART and start the driver on the apps proc side of PX4.

      This was done on RB5 : https://docs.modalai.com/Qualcomm-Flight-RB5-linux-user-guide/

      https://docs.modalai.com/voxl2-linux-user-guide/

      Regarding magnetometer, just like with the GPS driver, you should be able to enable the mag driver to build for apps proc. Since the apps proc i2c uses standard posix interface, it should just work. However, i don't think we have ever tried it.

      Alex

      posted in VOXL 2
      Alex KushleyevA
      Alex Kushleyev