ModalAI Forum

Hi ModalAI team,

We are planning a 7-port USB 2.0 hub for VOXL 2, connected through J3, using the Microchip USB2517. We wanted to use this to connect more sensors and USB cameras to the VOXL 2 board.

I’m following the USB expansion guidance in the VOXL 2 Expansion Design Guide and wanted to ask:

• Do you have a reference schematic for a USB 2.0 hub connected to J3 that you could share?
• The guide mentions that ModalAI may review customer expansion-board designs. Once I have my schematic ready, would you be willing to review it before I proceed to PCB layout?

Thank you in advance!

Hi @Eric-Katzfey

Thank you for your help!
I got it to work on J19 through PX4.

Hi @wilkinsaf

Thank you for this post!

I had the same issue and was able to solve it using these steps.

Hi @Eric-Katzfey

These are the specific commands I used on the VOXL2.
From an adb shell on the VOXL, I first tried PX4 / qshell on the J19 external I2C bus:

MINIMAL_PX4=1 voxl-px4
px4-qshell i2cdetect -b 4

To make sure there should be repeated bus activity while checking with the oscilloscope, I also ran:

while true; do px4-qshell i2cdetect -b 4 >/dev/null 2>&1; sleep 0.1; done

I also cross-checked from Linux userspace with a small libvoxl_io test program I wrote based on the VOXL I2C API and the qrb5165-rangefinder-server example. That test uses:

• voxl_i2c_init()
• voxl_i2c_set_device_address()
• voxl_i2c_read_bytes()
• voxl_i2c_read_byte()

It tries to read the devices expected on my custom PCB:

• ADS7828
• PCA9685

On the J19 external I2C paths, the result was the same: repeated failed to write to bus, no ADS7828/PCA9685 detected, and no visible SCL activity on the corresponding J19 clock pin.
If there is a preferred known-good command for exercising J19 bus 1 or bus 4 on VOXL2, I’m happy to try that as well.

Hi @Eric-Katzfey

Yes, mainly via PX4 / qshell, and I also cross-checked once from Linux userspace.
I tested both J19 I2C paths:

• pins 4/5
• pins 7/8

With both methods I could not communicate with the devices on my custom PCB, and on the oscilloscope the SCL lines stayed flat at 3.3V with no clock activity.
So it looks less like a device/address issue and more like the J19 I2C lines are not being driven out to the connector.

Do J19 pins 4/5 and 7/8 require any additional enable/configuration on VOXL2 before they can be used for external sensors and whats the preferred way to access them?

Hi @Eric-Katzfey

We have a custom PCB which we use for different sensors e.g. to measure temperatures. The board is tested with an Arduino where it works with I2C.

I now used the same PCB and connected it to the I2C lines on the J19 plug (4/5) and (7/8) but with neither of these I was able to establish communication to the I2C chips on the PCB. I then analyzed the SCL lines (pins 4 and with an oscilloscope and realized that no signal is present there.

Therefore I was wondering if any additional configuration is needed for using J19's I2C lines with external sensors?

Thank you in advance!

Hello ModalAI Support,

I am trying to use external I2C on a VOXL2 M0054 through J19.

I checked the hardware side and found:

• J19 I2C lines sit high at about 3.3V when idle
• continuity from J19 to my external board is good
• ground connection is good

However, when I try to access the external I2C buses from the VOXL, I do not see any clock activity on the J19 I2C clock pins with an oscilloscope. The lines remain at steady 3.3V and no external device responds.
From the documentation, my understanding is that:

• J19 pins 4/5 are the external magnetometer I2C path
• J19 pins 7/8 are the spare external I2C path
• the J19 I2C path goes through a TCA9517 level shifter/buffer

Could you please advise:

• Whether I should expect visible clock activity on these J19 pins when accessing the external I2C buses?
• Whether any additional configuration is required to enable the J19 external I2C path on VOXL2 M0054?
• Whether this symptom suggests a known issue with the J19 / external I2C buffer path?

I can provide more details if needed.
Best regards
Joel

Hi @Vinny

Thank you for your reply! That's good news:)
We are looking forward to it!

Hi Team,

Is there any support planed to integrate other thermal cameras other than the ones from Flir?
We are especially interested in other options like Seek Thermal and Contrastech.

I'm aware that they can already be integrated over the USB interface but a lower latency connection over MIPI would be preferred.

Thank you for your help!
Best,
Joel

@Alex-Kushleyev
Thank you very much for your reply!

We bought the USB C adapter from Flir and followed your guide to enable MIPI. Now it works and I can get the video from the Boson over MIPI.

Thanks for your help!

@Alex-Kushleyev

I just noticed with the updated documentation that the J4 connector on the M0201 board is not the USB connector but J3, which is the USB one, is not soldered on. Our Boson+ 640 is purchased separately and is therefore not configured properly.

Is this J3 port the one which has to be used to enable MIPI output on the camera? If so, is it possible to solder the connector on or are also other components on the M0201 board required?

Also is the functionality of the J3 connector on the M0201 the same as Flir's adapter board: https://www.apliter.com/en/product/usb-vpc-kit-para-flir-boson/

Thank you for your help!

Hi @Alex-Kushleyev

I'm currently encountering the same issue. When connecting a Boson+ 640 to the VOXL 2, no image is received. The same configuration worked with the Hadron, where I'm able to get the thermal image.

I assume the Boson is not sending images over the MIPI interface. As you described in the docs (https://docs.modalai.com/M0153/ ), this has to be enabled first with the Flir Boson application. The only versions I could find online are v3.0 and v4.6 which both not connect to the Boson and just freeze when connecting. Is this the same problem why in the guide only version 4.2 is recommended?
I'm connecting the camera with a JST-GH to USB adapter to my laptop.

Is there anything I can try to get thermal images over MIPI from the Boson+?

Thank you for your help!

@tom Thank you for your answer!

Unfortunately the overlay does not appear, even when the drone is armed. We are using Starling 2 drones with SDK 1.6.2.
Also in the voxl-open-vins-server.conf we can't find a setting for something related to the overlay.

Do you have any ideas what we can try to see the ov_overlay again?

Thank you in advance!

Hi Team,

After upgrading to SDK 1.6.x we noticed that the ov_overlay for voxl-open-vins-server is not present anymore.
Is there any plan to bring it back since this is quite helpful for debugging OpenVINS in different environments and with different camera setups.

Thank you for you help!

Best,
Joel

Hi @tom,

Unfortunately, I don’t have a QGC file with the parameters. Do you know where the original parameters come from when the Starling 2 drone is shipped? Are they the ones from the voxl-px4-params repository?

Thank you in advance!

Hi,

I ran the voxl-configure-mpa command on our Starling 2 drone (SDK 1.5.0). Unfortunately, I didn’t realize that this command also resets some of the PX4 parameter configuration files, and since then the drone seems noticeably more unstable in flight.

When we got the drone, I pulled the /data and /etc/modalai folders to my local machine since I thought these will contain the important configuration.
From the command output, I can see that it also overwrote the following files (among others) in the /usr/share/modalai/px4params/v.14/ folder:

• platforms/VOXL_2_defaults.params
• platforms/D0014_Starling_2.params
• other_helpers/starling_2_indoor_position.params

My questions are:

1. Is there a way to restore or recover the previous parameter files that were on the drone before running voxl-configure-mpa?
2. I found the GitLab repository with parameter files, but it seems to only contain the new defaults (the ones that replaced my old configs). Where did the original parameters that shipped with the drone come from?

Thanks a lot for your help!