@SKA ,

In your case, the issue should be solved by commenting out one line in https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/eis/src/misp.cpp :

//TODO: FIXME //in roll following mode, the roll is not stabilized to the horizon, so it does not need to be flipped //need to resolve this in a better way because Rout is meant for another purpose if (!follow_roll) rc_matrix_right_multiply_inplace(&eis_ctx.H.m, eis_ctx.Rout.m); //rotate the image according to desired output rotation (nominally identity)

Specifically, comment out the if statement : if (!follow_roll) , so that the Rout matrix is always applied to the full transform H.

The issue is that I tried to solve another use case by using this parameter (when the voxl2 / IMU is flipped upside down while camera is right side up). I just tested and it appears to be working.

I will figure out a better way of handling the upside down IMU in this case so that the output transform can be used correctly, but for now you can just comment out that if statement.

Can you please let me know if that fix worked for you?

Alex

Hi @snowt33nshi
All of our ucoax based image sensors use the same cables.
Be careful mating adapters to sensors as they are not all compatible as noted here:
https://docs.modalai.com/micro-coax-user-guide/
Hope this helps.

@dvz ,

The lens in the MSU-M0149 camera module should come with IR filter installed, which means that you will not be able to detect IR light.

You can test with an IR LED or a phone that has an IR scanner (many phones do) or explicitly check for the filter by unscrewing the lens.

The IR filters installed in the lenses inside MSU-M0149 are not designed to be easily removable. Attempting to do so will void the warranty and may cause damage to the camera / lens or personal injury. Small pieces of the glass filter could come loose. Do not do it.

I just tried to remove the IR filter and i was able to remove it, the filter was broken in process. I unscrewed the lens from the lens holder. The adhesive holding the lens in lens holder, if present, is not permanent and can be scraped off if needed. Then I used a sharp point of an x-acto knife to pry the IR lens off. See images below.

We do not have an option to purchase M0149 camera without an IR filter.

However, a newer version of this camera (https://www.modalai.com/products/msu-m0166) has an option to select a lens without IR filter. Please note that M0166 camera uses different (ucoax) cables and adapters for connecting to VOXL2, so this is something to consider if you do decide to switch.

If you would like to purchase a lens without IR filter (it is very similar to the one in MSU-M0149, but without IR filter, similar overall specs), please send us a request, the part number is JSD5501-C0 (mention no IR filter, just in case). This is the lens shipped with M0166 with no IR filter option. https://www.modalai.com/pages/contact-us

Warning : Attempting to remove the IR filter will void the warranty and may cause damage to the camera / lens or personal injury
m0149_ir_filter_removal1.jpg

m0149_ir_filter_removal2.jpg

save image on voxl:

voxl-record-raw-image boson640_bayer -n 1 -d ./

display image using python3:

import cv2 import numpy as np WIDTH = 640 HEIGHT = 512 FILENAME = "boson640_bayer_640x512.gray" # read 16-bit file img = np.fromfile(FILENAME, dtype=np.uint16).reshape(HEIGHT, WIDTH) # simple normalize vmin = np.min(img) vmax = np.max(img) img_8bit = cv2.convertScaleAbs(img-vmin, alpha=255.0/(vmax-vmin)) # show image cv2.imshow("Normalized Image", img_8bit) cv2.waitKey(3000) cv2.destroyAllWindows()

b0c7843e-dbec-41e6-918b-b0f25085ee82-image.png

@Jetson-Nano Regarding question #1, Yes, you can attach an external FC over the UART.

Hello @LV-Office-Holder,

The M0138 racing ESC only has two I/O pins and they are used for aux PWM output. PWM input is disabled for this ESC due to lack of PWM input for each ESC channel.

The ESC protocol example can be found here : https://gitlab.com/voxl-public/support/esc-driver as well as part of PX4 implementation : https://github.com/modalai/px4-firmware/tree/voxl-dev/src/drivers/actuators/voxl_esc . I would suggest referencing the PX4 implementation since it has the latest updates.

Additionally, we have voxl-esc test tools (python) : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc . The test tools allow you to spin motors, plot data, perform firmware and parameter updates.

Please let me know if you have any other questions.

Alex

@jeremyrbrown5 Ah, yes, that'll do it.

Hey @dvz, thanks for your query

We’re currently in the process of updating the voxl-tag-detector to support additional AprilTag families beyond just the 36h11.

If you’d like to try this yourself in the meantime, the following line in main.cpp creates the detector for the 36h11 family: here

To add support for the tagCustom48h12 family, you can:

Add the include:

#include <tagCustom48h12.h>

Replace the detector creation line with:

tf = tagCustom48h12_create();

Please note that this change may affect the current functionality, you’ll likely need to make additional modifications in main.cpp to ensure it builds and runs correctly.
As mentioned, we’re actively working on making this a much smoother process in the future. But if you’d like to get started now, the above steps should point you in the right direction.

@jameskuesel , it looks like EIS was merged to the main branch shortly after SDK 1.5.0 was released.

If you have not updated you camera server, please do so : https://docs.modalai.com/camera-video/electronic-image-stabilization/#latest-source-code . You may also need to update libmodal-pipe library.

Alex

@Vinny , I have the schematics ready for review. I will wait for your email to share them with you.

Regards and thanks in advance,
Fernando

@Cliff-Wong Hi there. Thank you for answering my questions. We’re still using the same voxl-open-vins-server.conf settings with "en_vio_always_on": false and "en_auto_reset": true. I also updated the system to SDK 1.5.0 as suggested, but unfortunately, it didn’t seem to resolve the issue.

To further investigate, I tested VIO performance by holding the drone in my hand and moving it manually while observing the trajectories in the VIO visualization. I noticed two distinct trajectories being displayed: QVIO and OV. Sometimes the OV trajectory appears more accurate when I move the drone in a “plus” pattern, and sometimes the QVIO trajectory is more accurate, but most of the time it tends to drift significantly, and sometimes QVIO doesn't move at all.

I have two questions:

1-) What is the difference between QVIO and OV, and which one is actually used during flight for position estimation?

2-) What could be causing QVIO to fail to track properly, while OV performs well? (or the other way around)

Also, I'm not getting any 'manual control lost' errors in QGC, and I'm able to control the drone perfectly fine. However, it doesn't respond to any control inputs on rare occasions, where the drone can't hold its position and continues to ascend when I use VIO in 'Position Hold' mode.

Hi @Jetson-Nano
Here is our info for Doodle Labs support:
https://docs.modalai.com/cable-datasheets/#mcbl-00085
Sorry it's buried in a cable page, but it makes the case clear (we think) how to support Doodle 🙂
b1fa4a9a-f883-4566-b3e2-ae9ab14b7264-image.png

regarding probing USB signals, unless you had a USB decoder on the scope, I do not think that will prove anything useful. You may be better off running usbview:
Windows:
USBTreeView by Uwe Sieber — uwe-sieber.de/usbtreeview_e.html
It shows enumeration hierarchy, configuration descriptors, endpoints, VID/PID, power requirements, etc.
Linux equivalent:
Use usbview — it’s essentially the same utility (GTK front-end to lsusb).

Hope that helps!

@Alex-Kushleyev
Thank you for the information and support!
the calibration worked well after stopping other services.

Akira

@emarcphera Huh, interesting. Okay, thanks for posting the update!

Ok thanks, I can parse the raw data. I guess I was expecting the csv to contain the data as well

Hi @will-huang-oksi
Are you willing to share some pics? Might be a cabling issue (GND loop or lack of a common GND), or some other intermittent connection causing your problems.
It really is hard to debug without seeing the setup.

Thanks!
Vinny

@tom Thank you for your quick response. Do you have a model with these dimensions and technical specifications that is also waterproof, or is it possible for you to develop one? Thank you again in advance for your response.

@nickrobbins I would take at stinger as a place to start: https://www.modalai.com/products/stinger-vision-fpv?variant=48373207695664

It is on the Blue UAS list: https://www.diu.mil/blue-uas-cleared-list (Stinger Vision FPV)

Hi @Riccardo-Benedetti and @paul-foley ,

This issue is not common. There is a potential condition (which we are going to look into) when a MPA client crashes and does not close the pipes properly, the MPA server side will keep the allocated resources open. If the client crashes repeatedly, eventually there will be no more memory for the Kernel to allocate for the new pipes.

Please check to make sure that you have no client processes that are subscribing to image streams and are crashing and restarting (perhaps restarting automatically by systemd). It is possible that a process that is not your test app is misbehaving for some reason and is causing this memory leak by continuous crashing and re-starting.

Also, what if you just use voxl-inspect-cam to inspect the single camera stream and no other camera clients running, does the same issue happen?

Alex