Hi @Sam-Kiley
We do try to state on there directly the following:
e389e9ff-ddd2-4aa6-a26a-32acb43e1800-image.png
9bd88fcb-93bd-4b28-9565-4ade539bcd12-image.png
So yes, if you bought a 5G card from us in the past for Quectel, it was a different SKU, likely MDK-M0090-3-01-00, not the current offering for Sierra MDK-M0090-3-02-00
5f09fe55-6bb8-46d7-bb3c-4308a94357be-image.png

We do not make the Quectel variants anymore since we source the Sierra's to be NDAA compliant.

Hello @Nathan-Raras and @Nathan-Raras ,

I don't see any Qualcomm device with running "lsusb".
I also have confirmed that the USB-C cable is able to access another VOXL device.
So I have submitted the RMA
d45c5737-8bf3-4c8b-9e7d-851acbfe82a8-image.png

Please let me know if any questions or suggestions.
Thank you very much for supporting.

@Alex-Kushleyev Thank you for reverting, I will check this out and get back to you

@brendan424 https://www.modalai.com/pages/rma

@tom Thanks Tom. I already checked the link. I understand that for gpu delegate "gpu" needs to be specified in /etc/modalai/voxl-tflite-server.conf. My question is what value needs to be used in this configuration file to trigger npu deployment. According to my exploration, specifying "npu" is the same as specifying "gpu".

cpu monitoring reports there are 8 cpus for sentinel. Which of the 8 cpus are opus?

Looking forward to hearing from you.

@wrossi17 ,

Starling 2 Max uses two 2S batteries connected in series, using the two xt30 connectors. If one of the batteries is not plugged in, the circuit is incomplete and the drone will not be powered. If you want to use a power supply to power the Starling 2 Max, with the drone we ship a special plug that plugs into one of the xt30 connectors, shorting it, so that the other xt30 can be powered with a single source. Please check the packaging of the drone for the plug (it may be in a small envelope) or you can make your own plug. Please let me know if you need more details about that.

If you use a power supply, use a 3-4S (12-16V) to power Starling 2 Max for bench testing and it is not advised to try to arm while connected to a power supply.

Alex

@KnightHawk What are you trying to do? Why would you want to communicate with your FC via i2c?

@James-Strawson

hmmm, by any chance are you failing to link against symbols from libgmb.so? That is a new library dependency of libmodal_pipe. Most of our packages use the following linker flags to avoid recursive linking, I think this would be a better solution than specifying the libmodal_pipe version in install_build_deps.sh

set(CMAKE_C_FLAGS "-Wl,--unresolved-symbols=ignore-in-shared-libs ${CMAKE_C_FLAGS}")
set(CMAKE_CXX_FLAGS "-Wl,--unresolved-symbols=ignore-in-shared-libs ${CMAKE_CXX_FLAGS}")

@wifa799 @Viktor-Gal You can use any CRSF (ELRS) receiver with the VOXL 2 and it will work. While we don't support flashing upstream builds of ELRS from the VOXL, if you update it yourself it will work without requiring any additional modification or patches. The patches from ModalAI just include some extra utilities for managing the receiver with the voxl-elrs tool such as the "unbind" command and pwm configuration from the VOXL. I'll see if I can provide a build for the betafpv receiver which matches the 3.5.3 version provided for our in-house M0184 receivers, but in the meantime you can definitely use firmware from the upstream ELRS repo.

@Tyler-Scott We recommend users to run linux natively as it can be tough to get USB devices to pass to WSL correctly.

You may also be able to resolve your issue by switching to voxl-cross:4.0 docker image, which was recently released.

@claw That is definitely not the expected behavior, I recommend going through the RMA process

@Alex-Kushleyev this is exactly what I need. Thanks! I was able to reconfigure voxl-tflite-server to use the new cropped image data.

@shawn_ricardo Hi!

To my understanding EKF2_EV_CTRL 15-->13 only remove EV from pos_z estimation, so it should be ok to do that if the range sensor is active. However, I did revert all parameters to the default settings (matching the VOXL-SDK definitions).

As my attempts to integrate the range-sensor data in altitude estimation did not seem to succeed, I decided to try and integrate the range-sensor in the VIO solution.
I created a version of the voxl-qvio-server in which pos_z estimation from VIO is replaced by the equivalent value based on the rangefinder:

s.T_imu_wrt_vio[2] = - down_range_m;

This seem to work better, however it is a workaround and not a full solution. My current experiments are performed in low altitude (~40-90 cm), so I am not concerned with the limited range of the rangefinder sensor.

I'm not sure what is the current implemented behaviour when EV estimation is not good, there should be some fall-back relying on the range sensor and imu. From my short experience with such cases of poor EV estimation mid-flight, the drone just crushes or jump to the ceiling with no control.

Any suggestions or further explanations will be much appreciated. Thank you

@Moderator ok thanks, do you know if VOXL2 can do multiple drone communication ? seems cant find this on VOXL website?

@Vinny For sure I think SD Express--with a major consumer device which uses them coming out in a week--won the very short lived MicroSD replacement war, even though UFS is (thankfully) taking over the internal storage market. Thanks for the hints; we'll see what we can come up with.

@Alex-Kushleyev thank you! It works now.