@linmur02 When you say "latest", which version, specifically, are you using? Yes, the FC V2 does have an internal magnetometer, but in both the ModalAI fork and on mainline the internal magnetometer is not enabled so any mag issues should be related to the mag on the GPS unit. Is the GPS being seen reliably? The barometer is on the board and shouldn't have any issues. If you disconnect that GPS unit do you still see occasional barometer missing errors? Also, can you start swapping out hardware to see if the issues are related to a hardware problem?

@marian Unfortunately VOXL1 has really been phased out but this board has the "fastboot" button on it and should work for you: https://www.modalai.com/collections/expansion-board/products/voxl-microhard-modem-usb-hub

@Alex-Kushleyev The IMU is being configured with an 8K ODR so by increasing IMU_GYRO_RATEMAX you are reading the FIFO more often but reading less samples each time. So you are mainly increasing the overhead of context switching. Can you characterize how much the load increases just by increasing IMU_GYRO_RATEMAX and not doing any of the extra UART IO? Unfortunately we don't have a lot of control over the low level implementation of the IO drivers that are in the Qualcomm code. And there is no DMA that could help lower IO overhead. One idea would be to lower the ODR to 1K so that you are only reading one sample from the FIFO at each interrupt.

@Allister-Lim ,

If you are not monitoring the battery voltage while working with your battery-powered VOXL, it is possible that you are over-discharging the batteries to the point of failure. Especially with LiPo batteries, it is unsafe to over-discharge them, so please be careful. (It seems that you are also using LiPo batteries, in addition to ModalAI Li-Ion batteries also shown (green)). There is nothing wrong with using LiPo batteries, but you have to be more careful with those. Over-discharged batteries lose capacity and Lipo Batteries may become dangerous.

It is a good idea to use an appropriate DC power supply when working with VOXL2 while it is powered on continuously. 12V 3-5A Power supply, connected to the APM (which will provide 5V for VOXL) should be sufficient. You should have no problem finding one, but in case you need, here is a link to the AC adapter that we sell : https://www.modalai.com/collections/accessories/products/ps-xt60

Alex

Hi @isaac,

We only have two variants of the kernel for VOXL2. The default (original) kernel and one that supports M0173. (mach. var 1.0.0 and 1.0.1 respectively, which you can see in output of voxl-version).

If you are using M0135 camera interposer board, you would have to use the first kernel. However, this kernel is set up for a stereo setup in J8, so J8U is not available for regular cameras. If you are using J6 and J7 for cameras, then using M0135 in J8 to enable J8U, is not really possible, even with a kernel modification (due to some shared reset lines that will affect several cameras, if enabled). I would need to know exactly what cameras are connected where in order to provide more details.

Now, if you use the second kernel in combination with M0173, you can also use other adapters such as M0181, M0172. Enabling a hi-res camera in J8U has been discussed in the following thread, with images and instructions : https://forum.modalai.com/topic/4757/connecting-2-boson-cameras-and-2-mipi-cameras-4-cameras-total . Please note that you can use the smaller boards such as M0181 and M0172 instead of M0173 with the second kernel.

I would strongly suggest going the second route, but if you have an issue with this, let me know. I don't have the full understanding based on your brief question.

Alex

@tom Thank you @tom

@tom Thank you very much for your information.

@adiprin1 Can you please start a new forum topic for this? And please include information about the device that you are looking to attach? Thanks!

@Karthik-Bharadwaj You'll need to insert this into the unused XT30 connector: https://www.modalai.com/products/mcbl-00109?_pos=1&_sid=cc83b4694&_ss=r

3A is more then enough to power the drone on the bench, just make sure never to spin motors on wall power! (You can damage the drone and will not be able to RMA it)

In order to disable arming you'd have to look through the PX4 parameters

@jmltt I understand it is personal preference, I just wanted to give more detail on the issue that you were originally seeing incase anyone else ran into the same problem. Shouldn't happen in the future with the recent changes, but some still use older SDK versions.

Thank you @Alex-Kushleyev for the clarification. Currently I just redefined the magic numbers on my own and voxl-inspect-pose works as usual. I am hoping that this breaking change only affects a small number of use cases. If anyone else faces the same issue with magic numbers theres at least the discussion that might help them as well 🙂

@roy-crosthwaite , please submit an RMA form for a replacement : https://www.modalai.com/rma

Thank you

Alex

@dan64 Unsure if you have resolved this issue, but I am going to add some more information to anyone that stumbles across this. There was a bug in the voxl-mavlink-server setting and sending all System ID numbers to 1. The deb file below should solve this issue where the MAV_SYS_ID can be changed an reflected on the VOXL2.

http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mavlink-server_1.4.12-202509181025_arm64.deb

Hi @souksakone
We do not support powering and arming any sUAS from a power supply. The ESC and other electronics will be damaged, and our warranty does not cover that.

If you need a bench top supply for code config, development, etc (without arming motors at all), then we sell a 30W adapter for XT60 here and you can adapt to Starling 2 max without much trouble: https://www.modalai.com/collections/accessories/products/ps-xt60

Hi @Martin-Lukac
Good catch on the pin swap. The Table is correct, with Pin 6 = GND.

The one thing I was wondering is related to this comment:
" I can power the ESC and the FCv2 separately."
That is not necessarily a good thing, and likely to lead to problems if you are powered up or down at different times. If one output (TX) is driving an unpowered input (RX), it could put the HW in a bad state. Please make sure to have them synced for ON and OFF.
Thanks.

@oiler251 You should be able to arm with the arm gesture (e.g. moving the left stick to bottom right). But since that isn't working I suggested to configure an arm switch. I do see that the RC2_TRIM parameter is set to 1000.0 which is odd. Normally it is around 1500.00. When you look at the QGC radio configuration screen and you move the sticks around do they look normal? And when sticks are centered are they all showing that they centered on the graphics? You could try setting RC2_TRIM to 1500.0 and see if that allows you to arm with the gesture. Please make sure you have the propellers removed when doing this testing!

I just disconnected/reconnected the USB to 4-pin JST cable from the microhard carrier board and rebooted the vehicle. Now the wlan0 interface has been up the entire time the vehicle's on, but none of the other devices on the vLAN the wifi adapter is connected to can ping the vehicle over wifi.

Output from dmesg looks the same except the following output after the microhard interface is found:

[ 26.460342] usb 1-1.2: new high-speed USB device number 4 using xhci-hcd [ 26.550901] usb 1-1.2: New USB device found, idVendor=1f94, idProduct=3002, bcdDevice= 4.14 [ 26.550915] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 26.550922] usb 1-1.2: Product: pMDDL2450AES256 [ 26.550929] usb 1-1.2: Manufacturer: Microhard [ 26.550935] usb 1-1.2: SerialNumber: 1592348 [ 26.639101] rndis_host 1-1.2:1.0 usb0: register 'rndis_host' at usb-xhci-hcd.0.auto-1.2, RNDIS device, 16:4f:08:e4:e1:09 [ 26.643401] cdc_acm 1-1.2:1.2: ttyACM0: USB ACM device [ 33.765387] vdd_tof: disabling [ 33.765393] vdd_hap_boost: disabling [ 37.240138] hrtimer: interrupt took 112083 ns [ 101.412343] boot log copy done [ 114.937520] qcom_rpmh DRV:apps_rsc TCS Busy, retrying RPMH message send: addr=0x41b08 [ 233.747906] perf: interrupt took too long (2778 > 2500), lowering kernel.perf_event_max_sample_rate to 72000 [ 339.990578] perf: interrupt took too long (3473 > 3472), lowering kernel.perf_event_max_sample_rate to 57500 [ 386.060248] perf: interrupt took too long (4425 > 4341), lowering kernel.perf_event_max_sample_rate to 45000