@jeremyrbrown5 Ah, yes, that'll do it.

Hey @dvz, thanks for your query

We’re currently in the process of updating the voxl-tag-detector to support additional AprilTag families beyond just the 36h11.

If you’d like to try this yourself in the meantime, the following line in main.cpp creates the detector for the 36h11 family: here

To add support for the tagCustom48h12 family, you can:

Add the include:

#include <tagCustom48h12.h>

Replace the detector creation line with:

tf = tagCustom48h12_create();

Please note that this change may affect the current functionality, you’ll likely need to make additional modifications in main.cpp to ensure it builds and runs correctly.
As mentioned, we’re actively working on making this a much smoother process in the future. But if you’d like to get started now, the above steps should point you in the right direction.

@jameskuesel , it looks like EIS was merged to the main branch shortly after SDK 1.5.0 was released.

If you have not updated you camera server, please do so : https://docs.modalai.com/camera-video/electronic-image-stabilization/#latest-source-code . You may also need to update libmodal-pipe library.

Alex

@Vinny , I have the schematics ready for review. I will wait for your email to share them with you.

Regards and thanks in advance,
Fernando

@Cliff-Wong Hi there. Thank you for answering my questions. We’re still using the same voxl-open-vins-server.conf settings with "en_vio_always_on": false and "en_auto_reset": true. I also updated the system to SDK 1.5.0 as suggested, but unfortunately, it didn’t seem to resolve the issue.

To further investigate, I tested VIO performance by holding the drone in my hand and moving it manually while observing the trajectories in the VIO visualization. I noticed two distinct trajectories being displayed: QVIO and OV. Sometimes the OV trajectory appears more accurate when I move the drone in a “plus” pattern, and sometimes the QVIO trajectory is more accurate, but most of the time it tends to drift significantly, and sometimes QVIO doesn't move at all.

I have two questions:

1-) What is the difference between QVIO and OV, and which one is actually used during flight for position estimation?

2-) What could be causing QVIO to fail to track properly, while OV performs well? (or the other way around)

Also, I'm not getting any 'manual control lost' errors in QGC, and I'm able to control the drone perfectly fine. However, it doesn't respond to any control inputs on rare occasions, where the drone can't hold its position and continues to ascend when I use VIO in 'Position Hold' mode.

Hi @Jetson-Nano
Here is our info for Doodle Labs support:
https://docs.modalai.com/cable-datasheets/#mcbl-00085
Sorry it's buried in a cable page, but it makes the case clear (we think) how to support Doodle 🙂
b1fa4a9a-f883-4566-b3e2-ae9ab14b7264-image.png

regarding probing USB signals, unless you had a USB decoder on the scope, I do not think that will prove anything useful. You may be better off running usbview:
Windows:
USBTreeView by Uwe Sieber — uwe-sieber.de/usbtreeview_e.html
It shows enumeration hierarchy, configuration descriptors, endpoints, VID/PID, power requirements, etc.
Linux equivalent:
Use usbview — it’s essentially the same utility (GTK front-end to lsusb).

Hope that helps!

@Alex-Kushleyev
Thank you for the information and support!
the calibration worked well after stopping other services.

Akira

@emarcphera Huh, interesting. Okay, thanks for posting the update!

Hi @will-huang-oksi
Are you willing to share some pics? Might be a cabling issue (GND loop or lack of a common GND), or some other intermittent connection causing your problems.
It really is hard to debug without seeing the setup.

Thanks!
Vinny

@tom Thank you for your quick response. Do you have a model with these dimensions and technical specifications that is also waterproof, or is it possible for you to develop one? Thank you again in advance for your response.

@nickrobbins I would take at stinger as a place to start: https://www.modalai.com/products/stinger-vision-fpv?variant=48373207695664

It is on the Blue UAS list: https://www.diu.mil/blue-uas-cleared-list (Stinger Vision FPV)

Hi @Riccardo-Benedetti and @paul-foley ,

This issue is not common. There is a potential condition (which we are going to look into) when a MPA client crashes and does not close the pipes properly, the MPA server side will keep the allocated resources open. If the client crashes repeatedly, eventually there will be no more memory for the Kernel to allocate for the new pipes.

Please check to make sure that you have no client processes that are subscribing to image streams and are crashing and restarting (perhaps restarting automatically by systemd). It is possible that a process that is not your test app is misbehaving for some reason and is causing this memory leak by continuous crashing and re-starting.

Also, what if you just use voxl-inspect-cam to inspect the single camera stream and no other camera clients running, does the same issue happen?

Alex

@Dmytro-Stolbovyi
voxl2:~$ usb-devices |less [1/1]

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1
😧 Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev=04.19
S: Manufacturer=Linux 4.19.125 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.0.auto
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 5
😧 Ver= 2.10 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=2744 Rev=02.21
S: Manufacturer=Microchip Tech
S: Product=USB2744
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub

T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
😧 Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0bda ProdID=0811 Rev=02.00
S: Manufacturer=Realtek
S: Product=802.11ac WLAN Adapter
S: SerialNumber=00e04c000001
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtl88XXau

T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 4 Spd=480 MxCh= 0
😧 Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=2740 Rev=02.00
S: Manufacturer=Microchip Tech
S: Product=Hub Controller
😄 #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=10000 MxCh= 1
😧 Ver= 3.10 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev=04.19
S: Manufacturer=Linux 4.19.125 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=xhci-hcd.0.auto
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 4
😧 Ver= 3.20 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=0424 ProdID=5744 Rev=02.21
S: Manufacturer=Microchip Tech
S: Product=USB5744
😄 #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub

T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0
😧 Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=2c7c ProdID=0801 Rev=05.04
S: Manufacturer=Quectel
S: Product=RM530N-GL
S: SerialNumber=4543cb18
😄 #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

@Robbie-McCue yes this worked thank you so much Robbie!!

@Dmytro-Stolbovyi Here is the updated link: https://docs.modalai.com/voxl2-unbricking/

@owf226 As soon as PX4 thinks it has taken off then it is trying to level the drone but can't since there are no propellers on the drone. So, it keeps increasing the speed of the motors on the side that needs to come up. That all seems normal to me.

@cguzikowski these had been marked NRND (not recommended for new designs) for a while and we removed them due to lack of demand.

We may still have some on hand if there is something specific you are looking for. Please reach out to modalai.com/contact and we can see what we can enable

@Sam-Kiley
Correction on my statement above. Holybro Ultralight F9P seem to perform better due to their antenna setup (RCP Helical Antenna) rather than L2. L2 isn't fed into the NMEA like I originally thought.