Hi @greg We have not investigated or researched that image sensor. I do not know of any plans for us to officially support it at this point. Sorry if this is not what you wanted to hear.

Hi @noah-heinen, Thanks for the very detailed write-up and troubleshooting. There is a lot of useful information here, and this is a tough challenge. I hope we can help get it resolved with you. The first thing that stands out to us is the custom extended-length USB harness between the Doodle Labs radio and VOXL 2 Mini. Before digging further into software, ESC firmware, or platform parameters, I would focus on that physical USB connection. USB 2.0 High Speed is sensitive to cable construction and signal integrity. Extending the MCBL-00080 interface using discrete, untwisted, unshielded JST-GH conductors is not equivalent to extending it with a properly constructed USB cable. The added length also increases susceptibility to both radiated and common-mode noise, particularly in an electrically noisy environment such as a high-current multirotor. We should also acknowledge that our standard development cables are not necessarily optimized for the highest-noise or final-production UAS environments. They are primarily intended to help get systems connected and operating during development. For final aircraft integrations, we generally encourage additional cable optimization where appropriate, including shielding, ruggedization, strain relief, and dedicated cable routing or cable channels that keep sensitive interfaces away from high-current and high-noise paths. We have seen USB stability issues on aircraft when cabling and routing are not ideal, especially around ESCs, motors, and high-current battery wiring. The fact that your disconnects correlate strongly with motor current transients rather than steady-state current makes the custom USB harness and associated grounding/noise coupling particularly worth investigating. I would recommend addressing the USB harness first: Keep D+ and D- as a tightly coupled twisted pair and keep the run as short as practical. Use a shielded USB-rated cable rather than individual discrete wires for the extended portion. Adding shielding is absolutely a good approach here. Ideally, use the cable shield as a shield rather than simply adding another signal-ground conductor. Keep the USB harness physically separated from ESC phase wiring, battery leads, and other high dI/dt paths. Your plan to improve the ground path and experiment with ferrites is also reasonable, although I would first correct the basic USB cable construction before trying to solve the problem primarily with ferrites. I would not assume there is a specific maximum J3 cable length where it suddenly becomes unreliable. Cable construction, impedance, routing, grounding, and the surrounding EMI environment all matter. A longer run made from discrete untwisted/unshielded conductors is certainly more susceptible than the stock harness, and yes, it could plausibly produce the transient-induced disconnect behavior you are seeing. Moving the ESC bulk capacitor to the recommended location is also important, particularly on 6S, and I would still make that change. The improvement you observed when powering VOXL from a bench supply is another useful indication that conducted or common-mode noise may be contributing. There may be more than one coupling path here. However, given the custom extended USB cable construction, I would correct that first and repeat your 0 -> 65% actuator transient test. That is actually a very good controlled reproduction test.

@alex-kushleyev Thanks for the response! A control model is a simple MLP (multi-layer perceptron) Input observation space: PX4 odometry topics, ToF depth/Depth estimation model, object detections. Output action space: PX4 offboard commands ( position and yaw for now, but we might extend to velocity/Collective thrust and body rates)

@qqa , we have document how to achieve folder-level encryption on VOXL2 here : https://docs.modalai.com/enabling-file-encryption/ . Please let us know if you have any other questions.

@MattK This is a generalized question but did your Starling Max 2 come with a ToF?

Hi ModalAI team, I’m developing a sub-250 g UAV and am trying to determine the lightest practical VOXL 2 / VOXL 2 Mini camera and sensor architecture for the aircraft. The target payload functions are: Daylight RGB video / imaging FLIR Boson+ 320 thermal video Camera input required for reliable VIO / navigation Lowest possible total camera, adapter, cabling, and interposer mass I am specifically trying to avoid carrying unnecessary stereo, ToF, or additional cameras if they are not required. Could you recommend the exact minimum hardware stack you would use for this application? In particular: For reliable VIO, can we use a single tracking camera, or is a stereo pair required/recommended? Which current ModalAI tracking camera/module would give the lowest installed mass? For RGB imaging, what is the lightest currently supported color camera/module that can provide useful daylight video? For a Boson+ 320, is the current recommended connection still: Boson → M0201 → coax → M0181 → VOXL 2 J8? Can the Boson, RGB camera, and minimum VIO camera configuration operate simultaneously on one VOXL 2 / VOXL 2 Mini? If yes, could you provide the exact ModalAI part numbers/interposers/cables required and, if available, approximate individual masses? Is there a supported camera configuration close to this, or would it require a custom voxl-camera-server configuration? The aircraft has a very tight mass budget, so I am trying to establish the absolute minimum viable sensor stack rather than starting from one of the larger development-kit camera configurations. Thanks, Yisrael

Please update your VINS to our master branch here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server For epoch-synced cams, tracking AR0144, please use: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-open-vins-server/-/tree/synced-timestamp?ref_type=heads

Hello. Can a Starling 2 drone autonomously fly while flying over the pipe inside a sewer? The drone must fly autonomously in a dark place to inspect cracks or internal conditions while flying along the water pipe. I'm not sure if this feature can run on Starling, so I'm asking for help!

Hello everyone, I am looking for some expert advice on a VOXL 2 companion computer setup for a long-range platform. I have two main integration challenges: Challenge A: VIO at Higher Altitudes To solve the motion blur and pixel density issues at higher altitudes, I am planning a 6-camera configuration. I want to use 4 downward-facing sensors (2 daylight + 2 IR) equipped with narrow-angle lenses, alongside 2 standard wide-angle sensors (front and rear). Could you advise on the best supported sensors (e.g., IMX series) for this? Has anyone successfully tuned the voxl-qvio-server for narrow-angle lenses, and what were the altitude limits you achieved? Challenge B: LAN Integration & WireGuard The payload data flow will be: External RTSP Camera -> Ethernet -> VOXL 2 (WireGuard encryption) -> Ethernet -> Digital RX. Because VOXL 2 lacks multiple LAN ports, I will need a miniature industrial Ethernet switch. Does ModalAI have any tested hardware recommendations for this? Furthermore, what is the best practice for routing this VPN traffic through the VOXL 2 Ubuntu environment without bottlenecking the CPU? We are currently evaluating the VOXL 2 for a broader fleet deployment and want to ensure the ecosystem can support this custom optics requirement. Any feedback on off-the-shelf solutions or standard configurations for this use case would be greatly appreciated. Thank you!

Hi, This post is quite old now, so going to mark it as resolved. If it is not, please start a new topic in the correct category for your needs. Thanks!