Skip to content
  • USB3 On M0062

    Unsolved ESCs, Sensors and Accessories
    1
    0 Votes
    1 Posts
    21 Views
    No one has replied
  • Custom companion data Stinger → Ground Control Station

    Unsolved General Questions
    1
    0 Votes
    1 Posts
    30 Views
    No one has replied
  • 1 Votes
    1 Posts
    35 Views
    No one has replied
  • plz

    Unsolved Development Drones
    2
    0 Votes
    2 Posts
    54 Views
    Eric KatzfeyE
    Most of this can be answered by our documentation here: https://docs.modalai.com/. If after reading through that you still have any specific questions feel free to reach out here on the forum. The short answer to most of your questions is "yes".
  • USB camera live streaming through Microhard carrier board

    Unsolved General Questions
    9
    0 Votes
    9 Posts
    267 Views
    Eric KatzfeyE
    That's kind of pointing to VLC as the issue. Can you try with QGC?
  • 0 Votes
    2 Posts
    223 Views
    Alex KushleyevA
    Hello @ישראל-בן-שלמה , Please see some options below and the recommendations at the end. For reliable VIO, we recommend dual tracking cameras. The tracking cameras are very light, so the extra 3 grams will give you lots of safety margin AR0144 is probably the best option since this is what we use. 2.2g with 80mm coax cable OV7251 camera (M0014) is probably the smallest (it is lower resolution also 640x480 vs 1280x800 for AR0144). ov7251 is EOL but it looks like we have some in stock. the weight of M0014 module is 0.5g (with the flex cable). However, to connect it to VOXL2 / mini, you would need an interposer like M0076 (0.6g) ( or M0135 (1.0g) IMX214 (M0025 module, https://docs.modalai.com/M0025/ ) may be the lightest 4K camera we have (0.7g with flex cable), but it is very old and sensor + lens quality is very far from our newer (and heavier) IMX412- and IMX664-based camera modules. Flir Boson 320 is a bit heavy too. The one i have with lens is about 23g. Most of the weight is the lens, i think. for connecting Boson to a Voxl2 Mini, you should use M0194 ( https://www.modalai.com/products/m0194 ) Boson → M0201 → coax → M0194 → VOXL 2 Mini J6 or J7? you can plug in another camera into M0194, such as AR0144 (coax version) or the IMX412 (coax version) The best option in terms of support (no EOL components) and hardware quality, would probably be: VOXL2 Mini (11g) M0195 (5.0g) -- see C43 configuration : https://docs.modalai.com/M0195/ Boson + M0201 + coax -> plugs directly into M0195. weight of M0201 + 80mm coax is 1.7g + 0.7g = 2.4g. Need to add weight of Boson! one or two AR0144 (M0166) -- 2.2g with 80mm cable (each) hires camera (IMX412) M0161 : 8.5g with 800mm coax cable Minimal Config VOXL2 Mini (11g) M0194 plugged into J7 (1.4g) + 80mm coax (0.7g) + M0201 (1.7g) + weight of Boson M0166 AR0144 (2.2g with 80mm coax) plugged into M0194 M0076 (0.6g) plugged into VOXL2 mini J6 M0025 IMX214 camera (0.7g) plugged into M0076 ** note that this is mixing the coax and non-coax cameras, but i think this should work. we would need to give this a quick test to make sure. Alex
  • Starling 2 FAA Remote ID

    Unsolved General Questions
    1
    0 Votes
    1 Posts
    47 Views
    No one has replied
  • M0184 ELRS no CRSF data after SDK 1.6.4 upgrade

    Unsolved ESCs, Sensors and Accessories
    4
    0 Votes
    4 Posts
    128 Views
    Ben LinneB
    @chiu-pk The LED status is good, this receiver should be recoverable assuming the wiring is correct. Could the M0184 firmware update have caused the receiver to lose its previous binding/configuration? Yes some updates will unbind the receiver. If you want to put the receiver back in bind mode and voxl-elrs doesn't work, hold the button for 5 seconds and it should enter bind mode indicated by the led status rapid double blink Is it expected that voxl-elrs ping gets no response while the receiver is waiting for binding? voxl-elrs ping should work in both cases, but to be sure try to bind and see if it works Is there a recommended recovery/reflash or reconfiguration procedure for the M0184 in this situation? Try to get voxl-elrs working if possible, if not then using the expresslrs configurator pointed to our custom fork of ELRS with a USB serial adapter that supports 420000 baud will allow you to update https://docs.modalai.com/elrs-configurator/
  • Drone Swarms Hardware Questions

    Unsolved General Questions
    1
    0 Votes
    1 Posts
    57 Views
    No one has replied
  • 0 Votes
    1 Posts
    99 Views
    No one has replied
  • 0 Votes
    2 Posts
    95 Views
    chiu pkC
    [image: 1789351046551-voxl-2-connectors.c61811zg_1.jpg]
  • Possible camera orientations for Starling 2 Max dev drone

    Unsolved Development Drones
    3
    0 Votes
    3 Posts
    187 Views
    Dylan GreshamD
    Hi @tom, That's exactly what I was looking for, thank you!
  • voxl-ardupilot crashing on mission planner reconnect

    Unsolved General Questions
    11
    0 Votes
    11 Posts
    543 Views
    Eric KatzfeyE
    Ah, interesting, thanks for the update!
  • Starling 2 Max - Power issues when starting process

    Unsolved Development Drones
    5
    3
    0 Votes
    5 Posts
    134 Views
    Eric KatzfeyE
    There are likely 2 issues here. One was a floating point math fix that is in newer versions of PX4. Can you update to latest px4: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.146-202607161052_arm64.deb and try again? The other issue is that sending in trajectory setpoints from your external application, even when in altitude mode, will go straight into the position controller and affect flight. So, I would only send those in when in offboard mode.
  • 0 Votes
    1 Posts
    40 Views
    No one has replied
  • 0 Votes
    3 Posts
    235 Views
    tomT
    Hi @alraj, 05c6:900e QUSB_BULK is not EDL (that is 9008). It is the SoC crash-dump mode, so the board is attempting to boot and failing before the OS comes up. Since Sahara/Firehose completed with the correct M0054-2 image, the flash contents are unlikely to be the problem. In past cases a board that returns to 900e after a successful QDL has not been recoverable by reflashing (https://forum.modalai.com/topic/1468 and https://forum.modalai.com/topic/3263), and a similar Sentinel case came back from RMA as a damaged main board (https://forum.modalai.com/topic/2131). Two things worth ruling out first. Pull the VOXL 2 out of the drone and boot it bare with every camera and add-on disconnected, since a mis-seated camera connector produced this same 900e state once (https://forum.modalai.com/topic/3230). Then re-check the steps at https://docs.modalai.com/voxl2-unbricking/#if-the-device-still-shows-900e-or-boot-loops-after-a-successful-flash and repeat the flash once. If it still comes back as 900e, an RMA is the next step: https://www.modalai.com/pages/rma. Include the serial number and QDL log. Keep the crash dump private, support can request it if needed.
  • 1 Votes
    4 Posts
    260 Views
    tomT
    Hi @kristi , Not a known issue. error -71 on the descriptor read happens before the WiFi driver loads, and getting worse over weeks with only a power cycle recovering it points to a failing part in the USB path rather than software. Working on a PC does not rule out the dongle, since we have seen these Alfa dongles fail in service (https://forum.modalai.com/topic/4538). On Starling 2 Max the dongle sits in the M0141 breakout on VOXL 2 J3, so the likely fix is replacing one of them: Try a new AWUS036EACS or AWUS036ACS (https://docs.modalai.com/voxl-2-wifi-setup/). If a new dongle fails the same way, open an RMA so we can inspect the board: https://www.modalai.com/rma Posting voxl-version and dmesg | grep -i usb from a failing boot would help us confirm.
  • Support for SXGA LWIR Cameras

    Solved General Questions
    2
    0 Votes
    2 Posts
    162 Views
    VinnyV
    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.
  • Flight Deck for M500

    Solved Design Reviews and 3D Models 3d-model
    2
    1
    0 Votes
    2 Posts
    1k Views
    VinnyV
    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!
  • 0 Votes
    2 Posts
    171 Views
    VinnyV
    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.