ModalAI Forum

@tom thank you

@eric-katzfey @Zachary-Lowell-0 Thank you guys for the response. The voxl 2 was on max 8 minutes. The video streamed for 2 minutes, then the frame froze on QGC. I had to restart the voxl-stream command to restart the rtsp on QGC. There was no error message on the debug window, the frames were passed constantly, during the RTSP freeze also. The voxl-Stream only through error once I tried to connect to the VLC. While connecting to QGC,and while the video freeze there was no error message. Thanks!

The ExpressLRS receiver requires* one additional wire. The ghost atto only connects one wire to the VOXL RC RX pin, but the ELRS receiver will also require a connection to the VOXL RC TX pin, otherwise the wiring is identical. Pre-crimped wires can be found easily for the JST GH connectors (J19) to make adding connections simple. *You could leave the receiver's RX line (the VOXL's RC TX) disconnected; this would make updates and other control using the voxl-elrs application impossible but basic RC functionality would work.

@Colby-Howell New order# 8874.

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.

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.

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

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

Thanks for responding, and if that board should have any other issues, refer to this post in an RMA where we will waive the removal of the IMU from consideration of other failures. Thanks!

Hi again, Thank you for the clarification on the battery specs and for highlighting the risks. Given that the original motor (1504 3000KV, PN: M10000633) is now officially obsolete/end-of-life (as shown in your product specs) and replaced by M10001231, we will strictly follow your advice and avoid any hardware hacks or mixing different motor specs. PNG However, having to replace three perfectly operational motors simply because the single original part was discontinued leaves us in a difficult position for a routine repair. Since we need a reliable and official path forward to get our Starling 2 flying again, could you please advise on how ModalAI handles this situation? EOL Support / Single Motor Solution: Is there any remaining stock of the original M10000633 motor for RMA/repair cases, or any official solution to avoid replacing the entire set of 4 motors when only one is damaged? Official Replacement Path: If replacing all 4 motors with the 1503 2900KV (M10001231) model is strictly mandatory, do you offer a replacement bundle/discount for users impacted by this EOL transition? Firmware / PID Configuration: If we are forced to replace all 4 motors with the 1503 2900KV model, does ModalAI provide an updated PX4/VOXL parameters file/tune for this hardware revision, or does the default factory tune handle the change automatically? We appreciate your guidance to ensure our autonomous flight testing remains safe, supported, and cost-effective. Best regards, [image: 1790346499104-074a5467-963f-4cde-812f-9d77ff039cfb.png]

We have added the pinouts here: https://docs.modalai.com/M0155/

Hi @tom, That's exactly what I was looking for, thank you!

Pressing down on the The M0141 also causes this reboot any thoughts I can show video if needed. @administrators

Please provide a PX4 log.

Pressing down on the The M0141 also causes this reboot any thoughts I can show video if needed. @administrators

@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

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.

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

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.

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