@Nikos-Mavr You're welcome! And can you please start a new forum post for this new issue? Thanks!

Hi there, just to confirm: does flying manually in position mode work and follows the XYZ position in voxl-portal's VIO page. as well as follows figure 8 mode too? This will confirm the vio pose estimate is correct and more of a issue on mapper.

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

Hi @austin-c ,

You can find the latest M0138 firmware with regen completely disabled here

Also, I added the esc config that i've been using for testing here

For step tests, i have been using pretty aggressive step command:

./voxl-esc-spin-step.py --id 2 --rpm 2000 --step-amplitude 4000 --step-frequency 2.0 --timeout 2.0 --cmd-rate 2000 --enable-plot 1

In order to make the ESC not de-sync (due to long demag time of the motor), the following params were adjusted:

max_rpm_delta set to 4000 (you can go lower), to cap the maximum rpm transitions. Although in my test, the step is 4000, so this had no effect timing_advance: 45 -- this is pretty high commutation advance to trigger commutation earlier so that there is more time for back-emf sensing -- high advance wiil reduce motor efficiency and will cause the motor to heat up a bit more sense_advance: 30 -- delay back-emf sensing so that we don't sample back-emf during the motor coil demagnetization more details : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/doc/low_kv_motor_tuning.md

I had another thought.. What if you use a small battery to absorb the voltage spikes? Basically hook up a 6-7S battery with a beefy Schottyky diode (10A) set up with Cathode (negative) pointing to the battery.

you will have to make sure the power supply voltage never exceeds battery voltage + diode drop. you will also need to make sure that you don't over-charge the battery with repeated spike absorption.. It is possible to have some sort of self-discharge circuit to slowly discharge the battery to a certain voltage (using a Zener diode + resistor or something similar).

Anyway, just an idea..

Try out the no-regen firmware..

Alex

@Myles-Levine , if you are masking out 90% of down-facing camera, then it is probably useless any movement of the features will get it out of the unmasked region very easily and feature will be dropped.. It may hurt VIO as there may be features going in and out, only trackable for a few frames (just adds to the complexity).

You should try to move the down-facing camera to free up it's FOV or even have it facing slightly angled to the back of the drone..

Alex

@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

@Dan-Jennings I'm also guessing that the driver may not be detecting the hardware so is not able to get the data for the battery_status. Have you tried swapping some other hardware to see if the problem is associated with a particular unit?

I have just tested this on voxl2 using SDK 1.6.3 and it seems to be working. The prints were updated, but what you see is normal (i saw the same messages). Did you check dmesg for any errors from wifi dongle? I used the following wifi adapter, which is unfortunately EOL (with our M0141 expansion board) :

30d3fe55-c5dd-49a9-8d65-3b2baadd3179-image.png

──────────────────────────────────────────────────────────────────────────────── system-image: 1.8.06-M0054-14.1a-perf kernel: #1 SMP PREEMPT Wed Oct 22 04:13:18 UTC 2025 4.19.125 ──────────────────────────────────────────────────────────────────────────────── hw platform: M0054 mach.var: 1.0.1 SKU: MCCA-M0054-C8 ──────────────────────────────────────────────────────────────────────────────── voxl-suite: 1.6.3 ──────────────────────────────────────────────────────────────────────────────── no current network connection ──────────────────────────────────────────────────────────────────────────────── voxl2:/$ voxl-wifi station xxxxxx yyyyyy Detected WiFi interface: wlan0 NetworkManager not installed, using legacy wpa_supplicant/hostapd stopping softap mode Enabling station mode on wlan0 (legacy)... creating wpa_supplicant configuration for station mode Station mode enabled on wlan0 Station mode configured! voxl2:/$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=11.806 ms

@Aniruddha
On QGC, do the Parameters ever fully load? The reason I am asking is because if the connection to the GCS is not fast enough or strong enough for QGC to fully download the parameters then the other tabs like sensors and actuators in QGC will not appear. Which is why you are having an issue doing the level horizon from QGC. I know that QGC is seeing the video feed meaning you are connected, is the Green bar going across the full length of the fly view bar on QGC?

@cbay ,

Here is the diagram for M0188 showing resistor R10 and R11 that need to be added (0 ohm) in order to connect the sync signal to the camera slot 1 and 3.

For some historical reasons, these resistors were DNI'ed in order to prevent (incorrectly configured) hires cameras from outputting a sync signal and interfering with the tracking cameras.

Please be careful when adding the resistors, as spacing between components is pretty tight.

We will update the docs for M0188, M0195 and M0173 to reflect the default state and how to enable the sync on the camera ports that do not have it already connected.

m0188_sync_resistors_fix.png

Thank you for the quick reply.
I will try doing as you instructed and post the results.

Thank you.
Kim

@jameskuesel ,

For item 1, (a frame from hires recording with eis), you can do this already by just capturing the YUV from the hires_misp_color stream. you could do this using existing tool voxl-record-raw-image.

For item 2, the full frame can also be captured (using the same tool) but only in raw bayer format. This would be good for offline processing, if you wanted to get the maximum image quality, however this image would not have any processing applied from MISP.

Additionally, since MISP supports multiple outputs, as you already know, (misp channels), you could set up one channel to be a full frame image (which you normally dont stream), with EIS off.

So with correct voxl-camera-server.conf, you should be able to get all the streams you want

full frame hires recording low-res streaming

And grab YUVs from any of those streams. The last part would be then just encoding them to JPG (which could be done separately or part of voxl-record-raw-image, which we could add)

If you send me your voxl-camera-server.conf (or the part specific to the hires camera), i can update it to show you how you can get the three streams.

Alex

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads

Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.

@qubotics-admin First you need to determine the version of PX4 running. With ssh or adb you can run the following at the command line: px4-ver all. You will see PX4 version and Vendor version. So, for example, for px4 version 1.14.0 and vendor version 8.134.3 then you would checkout the tag v1.14.0-8.134.3-dev from the repo to see that commit.

I have uploaded the latest ar0144 drivers with fsin versions for all camera slots here : https://storage.googleapis.com/modalai_public/temp/ar0144/ar0144_drivers_20260402.zip

There are two additional files (inside the zip), which you should copy to /usr/lib/camera to make sure you have the latest updates:

com.qti.sensor.ar0144.so -- contains functions for exposure / gain control (we recently made some improvements to make gain control smoother) com.qti.tuned.default.bin -- fixed gain scaling so that min gain (1.0x analog gain) is equal to 100 in the HAL3 gain units, not 54 (and the max gain will be 29.6 = 29600 for AR0144) -- you can also double check this using voxl-camera-server -l and update the min/max gain settings in your voxl-camera-server.conf to make sure you are using the full range.

My colleague will follow up with a diagram for locations of the DNI resistors that need to be installed to enable sync signal for camera slots 1 and 3 (0402 0-ohm resistor)

Alex

@ndwe Whether you use a VOXL or Jetson as a companion computer shouldn't make any difference unless you want to use the VOXL SDK. The version you run is totally up to you. If our v1.14.0 based version works for you then use it. We do plan to transition to v1.17.x in the near future. I don't think the issues you are seeing are related to something specific in the flight core v2 hardware setup. I would think that if you swapped it out for some other brand you would see the same issue. I would ask on the PX4 forums to see if others have experienced the same issues.

Hi @irw
Can you please post High Res and clear photos of both sides of the VOXL 2?

@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

@Piyush-Singh , can you please provide more details

how exactly all cameras are connected to VOXL2 mini (including interposers, flexes), etc. A diagram would help a lot which kernel variant are you running on your voxl2 mini (2.0.0 or 2.0.2).

Are all the other cameras working if you disable the TOF sensor in the camera server config?

Alex

@cbay voxl-fpv-px4 is based on voxl-px4 but has some custom tuning code / parameters for our fpv drones that isn't in voxl-px4. So, it's kind of a superset. But there isn't anything related to low level i2c drivers so I have no idea how that could be causing this issue.