ModalAI Forum

Alex Kushleyev

This is most likely due to the updated version of camera server and vio applications, as performance enhances may have impact on the cpu / gpu usage. We can help double check this. A few suggestions:

if you are able, can you please use voxl-inspect-cpu to measure the top CPU consumers for both drones and post here. This way we can check if something looks abnormal. Both drones should be in the same state (on bench, everything running.. or whatever environment you want to test in).
you can downgrade your new drone to earlier SDK and see if the CPU usage / temps reduce to original value

Alex

Vinny

Hi @hartll244 , Please see these related posts.
https://forum.modalai.com/topic/3664/voxl1-and-2-environmental-testing-documents/7?_=1790881535163
https://forum.modalai.com/topic/5316/need-operating-and-storage-temperature-ranges-for-5-components?_=1790881629795

VOXL 2 Mini falls under VOXL 2 as the core components are the same.
Hope this helps you.
Thanks!

Vinny

Hi @marcos-correa Apologies for the delays here, I was out on leave for a couple weeks.
It sounds like the M0141 issue you might be having is very similar to this one:
https://forum.modalai.com/topic/1356/sentinel-drone-randomly-reboots/2?_=1790714717250
It's important to use 5mm spacers between any VOXL 2 plug-in board, especially if it only picks up J3 and not J5, since that leave all the pins on J5 vulnerable to contacting circuitry from whatever plug-in board is installed. Symptoms from that contact are most certainly proven to be resets and brown outs, as we have seen that before.
If you are already using spacers between your board, then I'd need to think about other potential root causes.
Hope this helps.
Thanks!
Vinny

Vinny

Hi @schuyler.kellogg , the USB-A cable is back up for sale... sorry about that...
https://www.modalai.com/products/mcbl-00022

Maxwell Schaefer

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

Vinny

Hi @schuyler.kellogg
Sorry for the delays, I was out for a couple weeks. We have many of the MCBL-00022 in stock, checking with the team why it was removed from our store. It should be an active product. Hang tight and sorry for the confusion. Hopefully by tomorrow all the links for purchasing MCBL-00022 will be active again.
Thanks!
Thanks!

Moderator

It looks like we have one M10000633 on hand. Reach out to https://modalai.com/contact and see if they can get it to you

Jacob Camarillo

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.

Moderator

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

Moderator

The older Starling 2 batteries are DJI Mini 2, or very similar. So, you might be able to make those work. We wouldn't be able to tell you how effectively you could hack different motors together. That seems far riskier than soldering.

Drones can be dangerous, it is not advisable to hack parts together.

The Starling 2 batteries are 2S LiIon. 2S Sony VTC6 3000mAh 2S 7.4V, 10C discharge

ModalAI Forum

Global Moderators

Posts

Member List