Skip to content

General Questions

2.3k Topics 11.3k Posts

Not sure where your question goes? Ask here. ModalAI engineers and the community answer questions about any VOXL product.

  • Please Read: Support Request Format for Best Results

    Pinned Locked
    1
    1 Votes
    1 Posts
    2k Views
    No one has replied
  • VOXL ADB or Wi-Fi no longer communicating!?!

    Pinned Locked
    1
    0 Votes
    1 Posts
    3k Views
    No one has replied
  • Zorro Blue Audio

    Unsolved
    2
    0 Votes
    2 Posts
    34 Views
    Maxwell SchaeferM
    @Nick-Stroumtsos The Zorro Blue does not have any audio capabilities. It is built with custom electronics which do not include support for a speaker so no firmware can enable audio features.
  • This topic is deleted!

    Unsolved
    1
    0 Votes
    1 Posts
    2 Views
    No one has replied
  • USB camera live streaming through Microhard carrier board

    Unsolved
    15
    0 Votes
    15 Posts
    559 Views
    Jetson NanoJ
    @Zachary-Lowell-0 Thank you for testing it out and for fast response. I am also feeling it is a network issue. I will also try to replicate the same test condition as yours, also will verify the bandwidth. Thanks!
  • Custom companion data Stinger → Ground Control Station

    Unsolved
    4
    0 Votes
    4 Posts
    232 Views
    J
    Hi Alex, Thanks for clarifying the direction. For UAS → GCS with your current voxl-vtx 1.7.1: Autopilot telemetry already goes VTX → VRX → Ethernet UDP: voxl-vtx subscribes to the autopilot's MAVLink stream from voxl-mavlink-server and sends it over the RF link next to the video. The VRX then re-sends it as UDP to: destination: gcs_ip in /etc/modalai/voxl-vrx.conf (default 10.0.0.1), port 14550 (fixed in 1.7.1) source: the VRX at 10.0.0.2 Give your GCS laptop 10.0.0.1 on the VRX Ethernet link (or set gcs_ip to its address) and listen on UDP 14550. QGC will pick it up automatically. This is a one-way telemetry snapshot, not a transparent MAVLink link. The VTX sends at mavlink_telem_rate_hz (30 Hz in your config) and keeps one message of each message ID per send window. Custom companion data: not supported in this release. voxl-vtx only forwards what voxl-mavlink-server publishes on its mavlink_onboard pipe, and that pipe only carries messages received from the autopilot. If a companion app writes MAVLink into that pipe, voxl-mavlink-server sends it to the autopilot and doesn't publish it back onto the pipe, so voxl-vtx never sees it. Writing to the mavlink_to_gcs pipe doesn't help either: voxl-mavlink-server sends those messages out its own UDP sockets, and they have no way to reach the ground over the MVX link. There is currently no supported way to put your observation data onto the VTX → VRX link. Upgrading to SDK 1.6.4, if these features are useful to you: Your voxl-vtx 1.7.1 is older than what ships in SDK 1.6.4, the latest SDK release for Stinger. SDK 1.6.4 includes voxl-vtx 2.2.x, which adds: Parameter, mission and FTP forwarding to the GCS, so QGC can read and set parameters and download missions over the MVX link. GCS → drone MAVLink through the VRX. MAVLink your GCS sends to the VRX on the GCS port is forwarded over the link to the aircraft, for example mission uploads. By default this forwarding stops while the vehicle is armed. To keep GCS → drone MAVLink flowing in flight, set this in /etc/modalai/voxl-vrx.conf and restart voxl-vrx: "allow_mavlink_forward_while_armed": true Only enable this if you want the GCS able to send commands to the aircraft while it is armed. MANUAL_CONTROL messages are dropped. A configurable GCS port (mavlink_gcs_port), replacing the fixed 14550. None of these add a path for custom companion data, so they don't solve the observation use case. WiFi client mode with the VTX active: On the Stinger the M0185 is the VTX radio, and it runs in raw injection/monitor mode while it sends video. It can't also join a network as a WiFi client. A TCP/IP WiFi link would need a second, separate WiFi adapter. Even then, running it on the same band as the video link could hurt video quality, so we'd advise against it for a flight setup unless you deconflict the frequency used by each network device.
  • Starling 2 - Voxl 2

    Unsolved
    2
    0 Votes
    2 Posts
    54 Views
    Marcos CorreaM
    Pressing down on the The M0141 also causes this reboot any thoughts I can show video if needed. @administrators
  • This topic is deleted!

    Unsolved
    1
    0 Votes
    1 Posts
    27 Views
    No one has replied
  • Bots Unlimited Wifi Crash

    Unsolved
    10
    0 Votes
    10 Posts
    684 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.
  • Camera Calibration – Starling 2 Max

    Solved Development Drones
    5
    0 Votes
    5 Posts
    160 Views
    V
    @tom thank you
  • Starling 2 FAA Remote ID

    Unsolved
    1
    0 Votes
    1 Posts
    92 Views
    No one has replied
  • Drone Swarms Hardware Questions

    Unsolved
    1
    0 Votes
    1 Posts
    93 Views
    No one has replied
  • voxl-ardupilot crashing on mission planner reconnect

    Unsolved
    11
    0 Votes
    11 Posts
    708 Views
    Eric KatzfeyE
    Ah, interesting, thanks for the update!
  • Starling 2 Max: WiFi dongle USB link (error -71,) - dongle tested good on PC

    Solved
    4
    1 Votes
    4 Posts
    338 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
    2
    0 Votes
    2 Posts
    212 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.
  • VOXL2 reboots randomly

    Unsolved
    2
    0 Votes
    2 Posts
    190 Views
    VinnyV
    Hi @dvz It sounds like that specific unit may need to be RMA'd and we can give it a full check-out through our tests. Please refer to this page for submitting an RMA, as there is not much we can do remotely given your assessments and noted behaviors. https://www.modalai.com/pages/rma
  • 0 Votes
    1 Posts
    113 Views
    No one has replied
  • Battery Issues

    Unsolved
    7
    0 Votes
    7 Posts
    322 Views
    Adrian HidalgoA
    @Colby-Howell New order# 8874.
  • Autonomous navigation with Starling 2 (trajectory generation via multiple waypoints)

    Unsolved
    1
    0 Votes
    1 Posts
    103 Views
    No one has replied
  • MVX FPV Video Receiver Dual Clean Feed Out?

    Unsolved
    1
    0 Votes
    1 Posts
    93 Views
    No one has replied