Skip to content
  • Custom companion data Stinger → Ground Control Station

    Unsolved General Questions
    3
    0 Votes
    3 Posts
    144 Views
    Alex Z 1A
    Thanks — to clarify, we are not asking about MAVLink over ELRS. Direction we need: UAS → GCS (aircraft companion → ground laptop), not ground → UAS. Link we mean: MVX VTX → VRX (SoftAP off / VTX on), then VRX Ethernet to the GCS. ELRS stays RC-only (CRSF_RAW / M0184). Questions still open: With VTX on, does stock autopilot telem already forward VTX→VRX→Ethernet UDP (gcs_ip / port 14550)? Can an onboard companion inject custom MAVLink (TUNNEL / similar) into that same VTX telem path so it appears at the GCS? If custom injection is not supported, what is the supported way to get ~0.5–2 KB @ 1 Hz observations to the GCS while VTX video stays up (without SoftAP)? Also still need the SoftAP-off question: can the aircraft join an external WiFi network as a client while VTX RF video is active, or do SoftAP/client and VTX mutually exclude on wlan0?
  • 0 Votes
    4 Posts
    77 Views
    Zachary Lowell 0Z
    Ok lastly - can you please list out your OpenVINS package version? Previous versions of vins has a callback that alternates between processing and dropping frames when VIO is intiialized and its static jerk test permits throttling - so that first the 66.7 ms spacing you described. Restarting it would also bypass this throttle during init which is why it would go back to 30 hz
  • USB camera live streaming through Microhard carrier board

    Unsolved General Questions
    12
    0 Votes
    12 Posts
    387 Views
    Zachary Lowell 0Z
    @jetson-nano I am testing this right now and am not seeing an issue - can you describe the following: How long is the voxl on when you see this issue/how long has the stream been going? Have you confirmed that voxl uvc camera library did not die and that is the cause? Have you confirmed via the voxl streamer logs that the service did not die? I am trying to understand which library is the source of the error in the mpa. Thanks!
  • M0155 datasheet

    Unsolved ESCs, Sensors and Accessories
    2
    0 Votes
    2 Posts
    40 Views
    Alex KushleyevA
    The pinout is not specified in the M0155 docs, but it is identical on the camera side and is listed here, for example : https://docs.modalai.com/M0186/#module-connector-pinout-for-j1-s-h26-hr-ds-412
  • Bots Unlimited Wifi Crash

    Unsolved General Questions
    10
    0 Votes
    10 Posts
    614 Views
    John KellerJ
    Hi Luke, Sorry for the late response. When I ran the verification after installing and power cycling, I got this: unit enabled : static unit state : failed [up=112s] driver not present (mlan0 or /proc/mwlan/adapter0 missing) RESULT: NOT ACTIVE -- ADDBA timeout reads '<unreadable>', expected 0 It seems like it is because my system is missing mlanutl. Claude thinks there is a specific of version of that program that I might need. If you know the version, I can build it or if you wanted to sent the binary that would work too, whichever is easier. Here is claude's full summary in case it helps: I read the bundle and ran read-only checks against the drone (no changes made). The install is fine — the problem is a missing dependency the script never names. What's actually wrong mlanutl does not exist on this board. Nothing else is broken. On 10.3.1.82 right now: check result mlan0 up, holds 10.3.1.82/16 — you are SSH'd in over it /proc/mwlan/adapter0 present (config, mlan0/, uap0/) lsmod usbxxx + mlan loaded, USB dev 1286:204e (post-firmware, normal) mlan0 registered at uptime 7.9 s, associated at 11.4 s find / -name mlanutl* nothing — not in /usr/sbin, not in any package The botsu-sparrow 1.0.8-r0 deb ships 9 files (2 .ko, 6 firmware blobs, sparrow.conf) and no userspace tools; ModalAI's voxl2-wlan doesn't provide mlanutl either. Their bench board has it, yours never did. Why that produces those two misleading messages sparrow-ba-fix.sh:53 — have_driver() { [ -d "$ADAP" ] || return 1 [ -x "$MLANUTL" ] || return 1 # <-- fails here ip link show "$IFACE" >/dev/null 2>&1 || return 1 } MLANUTL falls back to /usr/sbin/mlanutl, which doesn't exist, so have_driver returns false while the driver is perfectly healthy. Every caller then lies: status prints driver not present (mlan0 or /proc/mwlan/adapter0 missing) — both of which are present. apply-wait spins 15 × 2 s and prints mlan0 did not appear within 30s, hence unit state: failed. verify's own mlanutl mlan0 addbapara produces nothing → '<unreadable>'. The journal confirms the wiring works: udev fired on mlan0 creation and started the unit at up=8 s (matching the 7.9 s dmesg line), and it died at up=38 s — exactly the 30 s loop. (The journal's wall clocks look 13 min apart because the VOXL2 has no RTC and the clock jumps once the network syncs; trust the up= numbers.) unit enabled: static is also expected — the unit has no [Install] section on purpose; udev starts it. Meanwhile the crash trigger is live and unmitigated — /proc/mwlan/adapter0/mlan0/debug shows BA streams on tid 0 and tid 4, win_size 64, at the default 65535 TU timeout. What to change Ask ModalAI for an aarch64 mlanutl built against this driver, and ask them to add it to the botsu-sparrow deb. The version string to quote them: USB8997---16.197.121.p2-MX5X16505.p7.2-(FP197), firmware 16.197.121. (mlanutl lives in NXP's mxm_wifiex tree at mapp/mlanutl — buildable yourself, but it drives private ioctls whose subcommand numbering tracks the driver release, so ask which release the sparrow build came from rather than grabbing an arbitrary tag.) Drop it at /usr/sbin/mlanutl, chmod 755. Then no power cycle is needed — it's a runtime ioctl: sh /usr/sbin/sparrow-ba-fix.sh apply, then sh sparrow-ba-install.sh verify should read ADDBA timeout = 0. The existing udev rule + oneshot will then handle it at every boot with no reinstall. Consider reinstalling as install monitor instead of oneshot — the setting is runtime-only and silently reverts on a module reload or warm reset, which is exactly the situation you're in after a wifi wedge. Two things worth sending back to ModalAI with the request: the deb ships no mlanutl, and have_driver() conflates "tool missing" with "driver missing" — that's what sent you looking at the power cycle instead of the toolchain. Same as the region_code note, it's a packaging gap on their side. Also note robot/setup/copy.sh runs this installer on every drone you provision, so all of them will fail verify identically until mlanutl is in the image.
  • 0 Votes
    2 Posts
    42 Views
    Eric KatzfeyE
    Please provide a PX4 log.
  • 1 Votes
    2 Posts
    98 Views
    Marcos CorreaM
    Pressing down on the The M0141 also causes this reboot any thoughts I can show video if needed. @administrators
  • 0 Votes
    1 Posts
    19 Views
    No one has replied
  • Third Party ESC integration w/ VOXL2

    Unsolved ESCs, Sensors and Accessories esc
    13
    0 Votes
    13 Posts
    805 Views
    Alex KushleyevA
    @patkirkmartin , so sorry for the delay. We are ready to proceed with sharing the source code for M0065 board and I just wanted to double check that you are still interested. Please let me know and we will get this going right away. If you use our APM, it will provide power for VOXL2 and the APM also includes voltage and total current sensing and has PX4 support for that. The information is delivered to px4 via I2C. If ModalAI ESCs are used, such as M0129 (mini esc) or M0138 (larger / racing ESC), they both provide power for VOXL and measure voltage and total current and provide this information to PX4 via telemetry via UART. Alex
  • Camera Calibration – Starling 2 Max

    Solved Development Drones
    5
    0 Votes
    5 Posts
    89 Views
    V
    @tom thank you
  • 0 Votes
    2 Posts
    81 Views
    ModeratorM
    Most power issues with VOXL 2 relate to MCBL-00001 connector becoming dislodged. People often pull the cable instead of depress the connector for proper removal. Is there any chance you have a cabling issue? This is the most common cause of failure. Assuming you don't have major software changes, we're not tracking any issues that cause random flight reboots.
  • 0 Votes
    2 Posts
    49 Views
    ModeratorM
    The source code you're referencing is a good starting point as an example for what you want to develop. We do not have a ready made tracker for use today and do not have plans to implement one. We just have those references as a development starting point
  • Custom voxl-camera-server config service aborts itself

    Unsolved ESCs, Sensors and Accessories
    2
    0 Votes
    2 Posts
    68 Views
    ModeratorM
    Thanks for the detailed report. A few notes based on what's in the log: The missing intrinsics files are not the cause of the abort — those ERROR in json_from_yaml, failed to open file / tracking_front_intrinsics.yml warnings are expected if you haven't run camera calibration yet, and voxl-camera-server falls back to default intrinsics. That's noise, not the crash. The actual "Aborted" with no further message is what we need to isolate. The docs' Debugging Camera Issues page is the right starting point for this class of failure, but the excerpt we have doesn't show the specific abort signature you're hitting, so I don't want to guess at root cause here. Can you get us: dmesg output right after the crash (look for a segfault/kernel oops around the same timestamp) Whether there's a core dump generated (check /data/core* or wherever core dumps land on your image) — if so, a backtrace via gdb would tell us exactly which line aborts Run voxl-camera-server under gdb directly (gdb --args voxl-camera-server, then run, then bt once it aborts) — this is the fastest way to get a real stack trace instead of guessing The "works after a couple of systemctl restart calls" behavior strongly suggests a race/init-order issue rather than a config problem — since your config itself (both the custom_camera_config.txt and generated voxl-camera-server.conf) looks structurally correct for two independent ar0144 cameras. One thing worth double checking: you're using ar0144-fsin-combo on J6_LOWER_COMBO1 for tracking_down, but I don't see a J6_LOWER_COMBO1_NAME2 or combo-mode field set — since this is a combo slot, confirm whether that flex is truly running in single-sensor mode. If the combo detection is flaky on init (i.e. it doesn't always see the second physical sensor consistently), that could cause a transient failure on cold start that clears on restart. Please also confirm which mach.var / carrier board (M0054) revision and whether tracking_down is on a combo flex physically wired for single-sensor use — a photo of the flex connection would help us rule out a physical/timing issue on that port.
  • USB3 On M0062

    Unsolved ESCs, Sensors and Accessories
    2
    0 Votes
    2 Posts
    86 Views
    M
    I think the cable you need comes bundled with the MDK-M0151-1-01 "board plus cables" variant. https://www.modalai.com/products/m0151?variant=47083941757232
  • plz

    Unsolved Development Drones
    2
    0 Votes
    2 Posts
    83 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".
  • 0 Votes
    2 Posts
    272 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
    79 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
    165 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
    82 Views
    No one has replied
  • 0 Votes
    1 Posts
    130 Views
    No one has replied