@Vinny Sorry for the delay, the weather here has prohibited more flight tests until today, and we were trying a few things that we thought may have been related. I'm nearly 100% confident that this is a hardware issue, fwiw.

1. We're using a Voxl2, LTE I/O breakout board, USB2 from that board to an Alfa wireless (which is it's own set of problems), and three Sony ILX-LR1's, with custom wiring harnesses connecting their control ports to an ATmel 4809 board for control and feedback, which is in turn connected to the VOXL2 via the I/O board and UART. That piece is extremely reliable, and is the most consistent part of the entire system. I've attempted to use a whole host of different USB hubs, ranging from the mundane (typical Amazon low-profile non-powered unit) to the exotic (SeaLevel's optically isolated $400 USB monstrosity).
2. The VOXL, and only the VOXL, is powered from the typical VOXL power supply. We were also powering a few accessories (like the GPS) from this, but we've broken them all out onto separate power systems.
3. I can't send a picture here, but am happy to send one to an email address. The power cables, usb cables, etc., are ModalAI cables. The cables to our GPS receiver, ATmel board, and the entire downstream wiring harness on the cameras are made in-house. The cameras are also connected via USB, which seems to be much more reliable than the storage drive.
4. I can't actually check this, as multiple components require USB3. When I tried to getting creative with testing, and using dd to test write speed without any of the data generating components connected, it still had issues after a seemingly random amount of time.
5. The issue persists regardless of the number of cameras plugged in. If the drive is plugged directly in and not through the hub, it never actually connects at all, which I don't understand. Often the ModalAI board will either restart or disconnect the connected ADB client when a drive is plugged in, if that is plugged in while running.
6. They'll disappear from lsusb, then re-appear one by one, sometimes with all cameras and the drive coming back, sometimes with just one or two cameras coming back before everything drops off again.

When you say overload, do you mean in terms of data or power?

I've tried several sets of cables, and also plugged the entire thing into a raspberry pi, where it works flawlessly.

I'm not sure which GPIO that is, so that's entirely possible, but we're currently only using UART2.

The cameras, fwiw, are not really being used as cameras in the typical fashion that ModalAI systems use cameras, but rather are being used for still image collection on a frame-by-frame basis, and are not being used for any onboard image processing.

Thanks!

Good afternoon,

We're using the USB3 port on the LTE I/O expansion board, and have it connected via a hub to 4 devices - one storage and 3 cameras. It sometimes works, but the port is unreliable at best, and totally unusable most of the time. We've tried going through passive hubs, powered hubs, and a $400 optically decoupled hub - all yielding the same results; it appears to sort-of work until you actually go to use it, at which point everything downstream of that port just disappears. It will occasionally sporadically start coming back, but not reliably enough to do anything useful. Any ideas?

A week ago, this was all largely working, though the week before it was not. We never did figure out why it suddenly started working again, and certainly don't know why it stopped.

Thanks!

@Alex-Kushleyev we needed three outputs and three inputs, so we ended up using an entirely different board (an AVR system) connected to the VOXL2 via ttyHS1 through the expansion board, and that seems to be doing what we need, with the added benefit of the pulldown resistors being built into that control board. There is certainly something odd about the PX4 build on this unit, both in terms of available camera controls and GPS options, which is the next thing we're trying to tackle.

@restore unfotunately I'm under an NDA and can't say much about what we're doing with the Sony hardware, but I will say that their documented processes for the Raspberry Pi 4 also work on the Voxl2, as long as you have the USB3 available. Try not to use the SDK to trigger the camera though; the performance there isn't exactly consistent. The hardwired options (be it through the not-quite-USB port or the phsyical interface on something like an ILX-LR1) are rock solid, but as they're designed to be button-triggered, you'll need a resistor between your control board and some sort of transistor (2N222) and then control the actual interface with the transistor. Otherwise, the trigger input is looking for the output from its own source, which is an indeterminate voltage and will quite likely damage the VOXL. The transistor will take essentially whatever current you give it, so that resistor is also mandatory - 10kOhm works for me with the AVR 440 chip controlling it.

@Alex-Kushleyev

We are trying to trigger all three at the same time, but they will likely not all respond at the same time so we will need individual feedback. The cameras are controllable via physical pins, not through a software interface. They can be triggered via software (Sony SDK) but that is not something that works within the VOXL platform on it's own today, in my understanding, nor do we really want to go that way as it's been the source of delays in our experience (the Sony SDK for triggering, that is). The camera feedback, similarly, is a rising edge that must be received by some sort of GPIO. FWIW, we're using the LTE/IO expansion board.

We're getting the images directly from the camera after the fact via USB and the Sony SDK.

-Nathan

System Image: 1.7.6-M0054-14.1a-perf
kernel: 4.19.125
platform: M0054
mach var: 1.0
voxl-suite: 1.2.0

Good afternoon!

We're trying to configure a Voxl2 for use with 3 still image cameras, and I'm struggling to determine the best way to interface with the control pins and input pins (center-of-exposure) from the cameras.

I would ultimately prefer to use a GPIO pin interface directly from PX4, but that seems fairly unlike without major modifications at this point. However, it appears that the Mavlink Trigger Interface is also disabled. Does anyone know of a straightforward way to enable that interface? We will need to trigger multiple devices, but I can configure our control system to use a single output if needed.

Once the camera output is fixed, we will also need to determine the best course for input - this would also ideally go straight into PX4, to avoid the timing delay. We have the GPIO/Modem breakout board. Can you provide any guidance on this step?

Thanks!

-Nathan

@tom Sorry, I've been out on a job OCONUS for the past two weeks. I tried the fastboot force, and that seemed to work - thank you!

@tom FYI 1.1.3-1 can be installed with no problems, board was previously on 1.1.2.

@tom I'm having the exact same message, host system is Ubuntu 23.10 x86_64, there's enough space on the local machine; screenshot of error and picture of board attached.