@John-Nomikos Hi, Can you please explain how you solved this? I am facing same problem where my camera is connected via USB to ethenret convertor with Microhard add-on board and my host machine is unable to ping my camera but can ping voxl2.

@Seungjae-Baek , the resolution of the camera should depend on the use case. However, it is also important to keep in mind what exactly you are doing with the images coming from the hires cameras. For example, if you set the resolution to 4K and you try to view those uncompressed images using voxl-portal, this process will be very taxing on the CPU for the following reason: when you view uncompressed images in voxl-portal, these images are encoded with a software JPG encoder and then sent from voxl2 to your browser. This process is very cpu-heavy. On the contrary, if you use h264 / h265 stream, it should be perfectly fine to encode 4K30 video to disk or even stream, since H264 / H265 encoding is done by a hardware encoder. voxl-portal, actually does support showing h264 (but not h265) 30FPS streams, so that would be a lot more efficient for the CPU, since there would be no jpg encoding. Otherwise, if you are using raw frames (not _encoded) in voxl-portal , please keep in mind that you will always have a lot of cpu overhead. voxl-portal is designed for debugging / development purposes, so it's not necessarily the most efficient solution for video streaming. For real video streaming use cases, you would use h264 or h265 encoding and save to disk on voxl2 + stream the encoded video for remote viewing. You could encode the same camera source with two different resolutions / codecs / bitrates. If you need help setting up a specific use case, please provide some details and I can help you further. Alex

Actually, I see from the log that your FPV camera is IMX214 (please confirm). So then my next questions are: which Voxl2 SDK are you using? does the crash happen if you only view the Hadron EO stream (this is OV64B camera) can you please check the cpu temps when you view many cameras (using voxl-inspect-cpu) The dmesg error suggests some sort of low level error during MIPI transmission, but it could be tied to the SoC overheating. When voxl-portal is used to view images (especially in multi-view), the images on VOXL2 are converted from YUV to Jpeg using a software Jpeg encoder (which is very taxing on the cpu for large images). This can cause the cpu to overheat and start throttling operating frequencies to reduce the temperature). We are aware of this issue and it is on the list to fix the multi view to be more efficient and not overheat the CPU. Alex

@Eric-Katzfey interesting, think you for this information. Once i demo this drone for a couple weeks in its current BNF w/ ndaa add ons configuration I will be looking to move to a smart system and incorporating optical hold and other gps denied search features.

@jeremyrbrown5 we figured it out, we just changed the name of the model to yolov8n_float16.tflite. Pretty spot on now!

@jeremyrbrown5 , it is possible that overheating VOXL2 cpu could be causing your SoftAP performance slowdown. You can run voxl-inspect-cpu which is a tool that will show you cpu usage, temps and other stats. If the CPU cores reach 95 deg C, the thermal management will slow down the cpu clock, so all the processes will run slower, including SoftAP. Alex

@lhermosillo That is harsh. Do you have a bare board, or one with some additions? If you can use the bare voxl2, try that. If you have been using the bare board all along, I'm stumped here. I'd maybe try to reinstall the modalai-qdl env, or use another image. Maybe the qdl command itself instead of the webUI. Hope you'll be able to save your board!

@N-Chen I tried the webUI and the command line and as near as I can tell the webUI uses lsusb (or something along those lines) to detect the presence of the board. The install.sh uses adb or fastboot to detect the board and will sit waiting until the board is detected or CTL C is sent. My guess is the usb controller interface is alive and reporting but everything beyond it is dead.

@ravi I'm suspecting you have a bad cable or the cable is subject to some interference. Can you try this on a benchtop with just a VOXL 2 and an FC v2 and no other components? Is it currently integrated into a custom drone? Can you look at the signal quality on the TX and RX UART lines with an oscilloscope?

@Robbie-McCue worked, thanks so much!

I have the same problem before — turns out the compass setup finally worked after I did a full sensor recalibration in QGroundControl and made sure the GPS/compass was facing the right direction. Worth a try if you haven’t done that yet! You can also try this tool for free. https://123compass.org/

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

@Dmytro-Stolbovyi Here is the updated link: https://docs.modalai.com/voxl2-unbricking/

@Moderator Many thanks for your reply Our goal is to develop a drone capable of indoor/confined-space autonomous flight without GPS, using SLAM-based navigation. The system should perform 3D mapping, obstacle avoidance, and full-area path planning. We would like to confirm the correct set of components and the required algorithm stack. Planned Algorithm Stack: State Estimation: QVIO (Visual-Inertial Odometry) providing position and velocity to PX4/EKF2 via voxl-vision-hub. Mapping: voxl-mapper (TSDF/ESDF) using a depth source. Planning and Avoidance: voxl-mapper’s path planner or PX4 avoidance, using VIO as the pose source. Autopilot: PX4 running on VOXL2 via voxl-px4. Proposed Hardware: VOXL2 Autopilot – https://www.modalai.com/products/voxl-2?variant=39914779836467 VOXL2 Tracking Camera (Mono Global-Shutter) – required for QVIO (please confirm the correct part number). -- https://www.modalai.com/collections/image-sensors/products/msu-m0149-1 VOXL2 Compatible adapter https://www.modalai.com/products/mdk-m0076-1 VOXL2 Time-of-Flight (ToF) Depth Sensor – https://www.modalai.com/products/m0178?variant=48528287793456 VOXL2 Mini 40-Pin Connector ToF Adapter (MDK-M0172-1-00) – https://www.modalai.com/products/mdk-m0172-1-00 Questions: Please confirm if this set (VOXL2 + Tracking Camera + Camera adapter + ToF sensor + ToF adapter) is sufficient for robust indoor SLAM navigation using PX4. For the tracking camera, which exact ModalAI part number is recommended for QVIO on VOXL2? Are there any best-practice configurations for voxl-mapper when using ToF instead of stereo depth? Would you recommend any additional sensors for improved performance in larger or more complex indoor environments? Goal Summary: We want the drone to hold position, generate a 3D occupancy map, avoid obstacles, and autonomously plan paths throughout the flyable space—without any GPS input. Thank you in advance for your guidance and confirmation. Best regards, Nitin

@adiprin1 On Ardupilot there is currently no way to use apps side UARTs (Some day we will add a method to use them). So, you would have to use one of the 3 UARTs attached to the DSP. If you removed the RC or the GPS and used that port then, theoretically, it could work. However, we have not tried that so can't make any guarantees. Also on PX4 you can use an apps side UART if there is one available on an add-on board. And, as you mention, you could use an SBUS RC on the VOXL 2 IO board and free up the standard RC UART.

@Aaron-Porter , perhaps systemd-timesyncd works together with systemd to correctly interpret the clock adjustments, so that run-time of systemd services is properly calculated. Alex

@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.

@tom Thank you for the support.

@Huynh-Gremsy No, there is no way to do that. There is no display output