Topics created by Jeremy Frederick

@Jeremy-Frederick , just to clarify, there are two IMUs on VOXL2 - one is connected to the DSP, used by PX4 and the second IMU is connected to the Application Processor (CPU). The data flow from the two IMUs normally does not cross, that is to say, that PX4 IMU is used by PX4 and the "apps proc" IMU is used for things like VIO, etc.

PX4 does not use the extrinsics.conf file, since PX4 has its own configuration for IMU rotation, I believe you know that.

Now, regarding the second IMU, if you flip your voxl2 board upside down (lets say roll it 180 degrees around its X axis), then your body->imu0 transform should reflect that [180, 0, 0].

When you specify the transforms between the imu and the cameras, you need to do that in the IMU frame. Perhaps that would be easier if you flip the drone upside down so that the voxl2 is oriented in its nominal orientation and then compute the transforms to the cameras by following the rotations described in our docs (see link below)

The Transform Tree typically looks like this;

Body | IMU | ------------------ | | | cam0 cam1 cam2

If your tracking camera is initially in forward facing orientation while voxl2 is "right side up", then you have the [0, 90, 90] rotation wrt the imu. if you roll the voxl2 board 180 degrees around its x axis (x axis still points forward), but the camera remains in the same orientation, then your imu->camera transform becomes [180, 90, 90]. You could verify this by using the red-green-blue marker helper tool as shown in the video 🙂

One way to understand this a bit better, and to do a sanity check.. When rotations are composed, they can be multiplied together as Rotation Matrices. When you compute the rotation between the drone's "body" to the tracking camera, this will look like body_R_cam = body_R_imu * imu_R_cam. which would be in the default case equal to something like this body_R_cam = [Ry(90) * Rz(90)] because body_R_imu is Identity Matrix (no rotation).

For the use case where VOXL2 is rotated upside down around the x axis, both the body_R_imu and imu_R_cam transforms have changed but they changed in the same (opposite) way and it just so happens that 180 degree rotation is the same as -180 rotation. So now we have body_R_cam = [Rx(180)] * [Rx(-180) * Ry(90) * Rz(90)] where the first Rx(180) is the body_R_imu and Rx(-180) is the part of the new imu_R_cam transform. As a result the 180 and -180 degree rotations cancel out and you end up with the original body_R_cam because you have not actually rotated the camera w.r.t to body.. Long explanation but worth the sanity checking.

Also more details here : https://docs.modalai.com/configure-extrinsics/

Now, regarding Open Vins actually using the upside down IMU to body rotation correctly, I will need to double check with my colleages. @Cliff-Wong , can you confirm?

@Jeremy-Frederick , please check the following:

try explicitly stopping PX4 before scanning for the ESC using voxl-esc python tools : systemctl stop voxl-px4 try another 4-pin uart cable, if available test another ESC the same way, if available

Was this ESC + board combination working before at stopped working?

Alex

@Jeremy-Frederick Okay, well then you will need to add support for such an external Mavlink enabled peripheral into voxl-mavlink-server. We don't currently support that.

@Jeremy-Frederick , the FPV ESC currently supports two pwm outputs, it can be tested using the following test script:

https://docs.modalai.com/voxl-fpv-esc-datasheet/#pwm-inputs--outputs (docs) https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/voxl-esc-pwm.py (test script) make sure ESC firmware is 39.18 or later, as specified in documentation

The python script tells you which ESC boards support pwm output:

# PWM support on ModalAi ESCs: # M0049, M0117, M0134, M0129 : IDs 0, 1, 2, 3 # M0138: IDs 0, 3 only # All boards use pin A2 for PWM output

by changing the --id argument between 0 and 3 you should be able to use this test script to control PWM outputs of the two test points of M0138 ESC . Please be careful soldering to the test points as they are small and avoid pulling on the wires (use strain relief).

We are also working on enabling a 3rd pwm output on the output that is currently used for the Neopixel LED (this output is also pwm capable).

In terms of integration, standalone testing can be done using this python script, but sending pwm commands have to go through PX4, and we are working on integration.

You can use the following tool which will send a message to PX4, which will get forwarded to the ESC:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/sdk-1.3.4/tools/voxl-send-esc-pwm-cmd.c . Note that this tool has been moved to another repo after sdk 1.3.4 , but you should be able to use this tool to control pwm from voxl2 command line while the px4 is running and talking to the ESC.

The new repo for the tools is here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-io-server/-/tree/dev/tools and I believe it should be doing the same thing, although i have not personally confirmed it yet.

Try it out!

Long term, we do plan to provide the support for this (this is not a temporary feature), so we are working on cleaning up the tools for that.

Alex

@Jeremy-Frederick Those aux channels are implemented differently when getting manual control messages from QGC. The only one that is mapped is aux1 that comes from the "buttons" field of the corresponding MANUAL CONTROL Mavlink message.

@Jeremy-Frederick Thanks for reverting. In your setup do you have the Radio directly paired or connected with ground unit of the MH carrier without having to any other workarounds?

@Viktor-Gal I am troubling localization with QVIO. So I wanted to change vio algorithm to OpenVINS. I flashed my drone to nightly version but openvins still very unstable. Could you give me some guidance for openvins?

Questions

openvins configuration & versions Did you enable the voxl-feature-tracker? camera settings (single or multi, camera model, etc)

My status

voxl-suite: 1.4.1-202502132201 Camera: old-version of tracking camera (640x480) - link voxl-open-vins-server: 0.3.0-202502061726 voxl-feature-tracker: 0.5.2-202412171357

I was able to replicate your issue and also confirmed that the issue goes away if I move the AR0144 camera from the M0084 cable (connected to J7L) to J6L using M0076 interposer.

I believe the issue is related to potentially insufficient decoupling capacitance in the IMX214 camera, so running it on the same flex with another camera causes noisy pixels.

I hope you can work around the issue by moving the AR0144 camera to another port.

Sorry about that!

Alex

Hi @Jeremy-Frederick
Can you please provide some pictures?
It almost sounds as if you have a faulty RJ45 jack, but these are tested in factory before shipping.
If you can get some close ups of the non-working RJ45 and the LAN7500 chip, that may help.

And, can you clarify that you have Qty-2 M0062's and one works, yet one doesn't? Did the faulty one ever work for you? Was the faulty one in any type of handling mishap (like an accidental drop/fall)?
The RJ45 has integrated magnetics to save space (which is why it is so tall), but that makes them more vulnerable to shock failure than typical RJ45's.

One thing I do know that may also occur is the jack can be installed slightly tilted, making it hard to seat the RJ45 cable in firmly. There is an odd feature on the connector that sometimes allows it to seat at an off-angle, slightly pointing down making the cable slightly interfere with the PCB (but still ok to insert, since as I mentioned, we tested at the factory). Also, the metal along the sides of the RJ5 may also be stiff, preventing a smooth insertion, so sometimes just inserting the RJ45 cable a few times making sure you get that nice tactile "click" may be what is needed to ensure the contacts are engaged and kinda "breaking in" the stiff connector.

Hi @Jeremy-Frederick
This appears to be a fusing open of some (one or more) power signals on the flex, indicating that excessive current was demanded of the flex. A short at the image sensor module of a power rail could cause this, so a loose connector may have certainly been your culprit, and a voltage likely contacted a GND signal or component.

@Jeremy-Frederick, that is great!

Luckily (or by design 🙂 ) the camera connector reversal is typically not fatal, but DO NOT push your luck, please 🙂 . Technically, if damage occurs due to incorrect insertion of the camera connectors, this will void the warranty for the main board.

Always verify connector orientation when changing camera configuration.

Alex

@Jeremy-Frederick , If VIO is working, then there is a very high chance that you got the orientation correct 🙂 . If the camera to IMU orientation is off by something like 90 degrees in any direction, VIO is pretty much guaranteed to fail. So if you are getting normal VIO performance, quick initialization, across multiple tests, then I would say that your orientation parameters are correct for VIO.

Please keep in mind that if you flipped the board and if you are planning to fly with PX4, you will need to change the imu rotation params in PX4 (also keep in mind that PX4 is using a different IMU that is connected to the DSP)

@Moderator Great, I noticed in SDK 1.2 there is now support for dual tracking cameras in the camera server, can both feeds be fed into the QVIO service to allow for the use of both cameras in VIO?

@valvarez , yes, this is the expected correct behavior.

I believe you were initially using older M0065 firmware (version 1) as well as older PX4 build which was working with that version of M0065 (VOXL2 IO board). However that release had some issues that were fixed and you should not use firmware version 1.

The older PX4 version used a different (old) driver for the voxl2-io board, and you can tell that because the debug print was very short and it accepted SW version 1:

SLPI: Detected M0065 protocol version. SW: 1, HW: 35

If you see that, it means you are using outdated (buggy) software. The latest (stable) firmware is verion 2 and the corresponding PX4 driver will require that version and print out a lot more information about the board and the VOXL2_IO params.

Alex

since voxl-streamer can provide RTSP streaming from VOXL2, ffmpeg can be used on the host machine for recording outside of QGC.

You can find some helpful information by searching ffpmeg save rtsp stream to a file . for example : https://medium.com/@tom.humph/saving-rtsp-camera-streams-with-ffmpeg-baab7e80d767

@Jeremy-Frederick No, it should not ever crash in mid flight! Can you provide the console output (journalctl -b -u voxl-px4), px4 log, and dmesg output from one of these in flight crashes so we can try to figure out what is going on?

@Jeremy-Frederick Can you try to lower the bitrate or resolution to see if it's a bandwidth issue?

I understand that, in theory, the rendering software (VLC or QGC) shouldn't matter for your issue. But, it typically helps to see if there is a config that will work reliably and then push it from there.