Hi @Matthew-Howlett ,

No the m500 currently has a BMP388.

The official product documentation is located at https://docs.modalai.com/

The purpose of this forum is to supplement that documentation, and to update the official docs when we find information missing.

Hi @rapit ,

OK we validated that a USB3 device can show up, here's a "guide", but there's no new info really, just an example: https://docs.modalai.com/voxl-as-usb-host/

-Travis

Hi @mrawding ,

The current early release on the EVT hardware relies on gstreamer.... for example:

cd /data/misc/camera
rm *

gst-launch-1.0 -e qtiqmmfsrc camera=0 name=tracker ! video/x-h264,format=NV12,width=640,height=480,framerate=30/1 ! queue ! h264parse ! avdec_h264 ! videoconvert ! pngenc ! multifilesink enable-last-sample=false location="/data/misc/camera/cam0_img_%d_.png"

This will save images to the path specified. We're actively working on getting the same interfacing as VOXL up on this ;). Next few weeks should have some good PUBLIC REPO updates.

Hi @gauravshukla914,

If voxl-vision-px4 is setup for VOA it will connect to the stereo and 'take over', if that's the case can you try the following before launching?

systemctl stop voxl-vision-px4

FYI for the future, the MPA architecture (https://gitlab.com/voxl-public/modal-pipe-architecture) will provide 'fan out' and allow multiple clients for a given camera.

@Gaurav-Borade , we have one in the works that should be ready shortly, I'll send a link once we get it posted!

Hi @mrawding ,

You are correct, there's something wrong, and I'm investigating this now.

The UART is active after bootup but then something fishy is happening.

When used with PX4 (ran on bootup) there's no issue.

I'll post here when there's an update to fix.

Hi @gauravshukla914 ,

Our flight controller is a little unique in that it can't be powered off USB so yes, it will lose power and connection during the standard process. (The reason being our Flight Controller shares the 5V rail with the companion computer and 500mA off USB won't suffice!)

To get around this, we have a tool that has a user guide here:
https://docs.modalai.com/flight-core-pwm-esc-calibration/

This allows you to keep the battery connected during the ESC calibration process.

This is for the STM32 based FlightCore.... not SLPI which I think you're super aware of but making sure!

Hi @Kevin ,

The VOXL2 (M0054) and RB5 Flight (M0052) images aren't compatible as they have different kernel and rootfs. So flashing the VOXL2 onto the RB5 leads to bricking.

But, on the RB5, you can get to a 'factory state' following this:
https://docs.modalai.com/Qualcomm-Flight-RB5-QDL/

That image is a factory image that is pretty old and not fully useable, so we need to flash an update.

You then have two choices.... reflash the same (9.1 based) image and use the RB5 Flight software (now in maintenance mode).

Or, use the ModalAI maintained VOXL SDK. To use the VOXL SDK, you need to update your RB5 Flight hardware with this from downloads.modalai.com :

We are currently working on an improved update guide and will post shortly.

Hi @Amir-Avni,

Does your silkscreen on VOXL2 show M0154 or M0054?

If M0054, it's 'hard coded' as an output only... behind a uni-directional level shifter.....

If it's M0154, there's a directional level shifter in front of that GPIO that allows us to (with a kernel tweak) switch between UART and SPI.

By default we are configured for UART use case, and the level shifter is set to allow an INPUT, by setting GPIO 67 low (as default), which is setup in device tree here, see "67" in modalai,gpio-init-output-low
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/v1.8.02/recipes-kernel/linux-msm/files/dts/common/m0xxx-modalai-gpio.dtsi?ref_type=tags#L12

To enable VOXL2 J10 pin6 (gpio46) as an input, make sure gpio67 is set to low

Hey @Andrew-Martin thanks for reporting, I also saw the gitlab issue. Have you tried increasing that buffer size and rebuilding ? We could try to provide you a test deb.

We just got the MVP of remote ID in place and kept this open source so we can fix as needed...

Hey @jcai ,

Are you building a "debug" or "perf" kernel?

There's a little slop I have with voxl-gpio-mod and voxl-platform-mod.... they're being built out of tree and shipping in the rootfs... which if you load a debug kernel, causes problems like above....

By default the build is 'perf':
https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel-build-docker/-/blob/qrb5165-ubun1.0-14.1a/bin/qrb5165-build.sh?ref_type=heads#L13

If you are using 'perf' and still having issues please let me know.

I want to move these two modules IN TREE, then this can go away... we're planning on doing this in future (major) release.

@smilon we're still working on it but slower than I had originally planned. we're using it on a feature light product right now without camera support, once we have camera support in place I'll try to get some preview releases in place, 'hoping' that's in Q1/Q2 but as an optimistic engineer speaking

@valvarez

A bit hidden but it's /dev/ttyHS2

https://docs.modalai.com/voxl2-linux-user-guide/#devttyhs2---hsb2b-connector-uart

We ship a little helper tool that you can do a loop back test real quick if you make a cable that shorts pins 2/3:

qrb5165io-uart-test -d /dev/ttyHS2

Hi @wifa799 ,

For FLIR Lepton.
This one would work off the M0173 J6 connector:
https://groupgets.com/products/purethermal-breakout-board

I need to update the M0173 data sheet... but a here's pinout for that connector for now for reference, for Lepton 3.5 BTW:

For FLIR Boson.

MIPI Boson:
The M0153-1 is intended for a MIPI based Boson. Currently, the only way to get BOSON into MIPI mode (as shown on the link you provided), is to use a USB backpack (M0153-2) first to put the sensor into MIPI mode (along with other settings). Also, when buying a Boson with MIPI support, it needs to be a Boson+. You will receive it and need to use M0153-2 over USB to connect to it to a Windows machine and then setup for MIPI which can then be used with VOXL using MIPI camera ports, and use VOXL Camera Server

USBC Boson:
The VOXL2 hardware needs to have M0154 on the silkscreen (not M0054) for the USBC port to work as a host. I just validated a USBC backback on a Boson to the USBC port on VOXL2.

Using the USB2.0 port (e.g. where the WiFi dongle is plugged in) would work for the USB2.0 backback. VOXL UVC server would be used here for the USB cameras.

Please keep hitting me with questions here if not clear!

@jcai are you using a single IMX412 off M0173 J5?

C28 will setup a additional 4 sensors that likely will create some 'noise' in the logs when they fail to probe (assuming above sentence is accurate).

The sensor off J5 is "sensor ID 2", so we will want to use something like com.qti.sensormodule.imx412_fpv_2.bin:

E.g.
cp /usr/share/modalai/chi-cdk/imx412-fpv/com.qti.sensormodule.imx412_fpv_2.bin /usr/lib/camera

If only a single sensor off J5, you won't want other com.qti.sensormodule*.bins in /usr/lib/camera/

After copying the .bin above to /usr/lib/camera, If you run voxl-camera-server -l , do you get a single sensor?

Hi @Trinadh

Can you confirm (using voxl-version) what version you have?

e.g. should paste this info:

--------------------------------------------------------------------------------
system-image: 
kernel:       
--------------------------------------------------------------------------------
hw platform:
mach.var:     
--------------------------------------------------------------------------------
voxl-suite:   
--------------------------------------------------------------------------------

To confirm, you are using:
VOXL2 Mini -> J6 -> M0135 --> JL for ov9282, and JU for IMX214?

We don't have a binary setup for IMX214 or ov9782 on J6 upper, which is "ID 1".

ls /usr/share/modalai/chi-cdk/ov9782
com.qti.sensormodule.ov9782_0.bin  com.qti.sensormodule.ov9782_2.bin  com.qti.sensormodule.ov9782_3.bin  com.qti.sensormodule.ov9782_4.bin

voxl2:/usr/lib/camera$ ls /usr/share/modalai/chi-cdk/imx214
com.qti.sensormodule.imx214_0.bin  com.qti.sensormodule.imx214_2.bin  com.qti.sensormodule.imx214_3.bin  com.qti.sensormodule.imx214_4.bin

So it seems like you would need a binary built for imx214 on "slot1", correct?

Hi @TomP ,

The last image you have shows correct orientation, you can find "pin1" and align to that:

For SW configuration, you want to have /usr/lib/camera/com.qti.sensormodule.imx412_fpv_0.bin for this setup off J6. Reach back out if you get stuck here.

Hi @jcai ,

Please build the kernel using the argument to specify a 'variant' of the kernel:

./qrb5165-build.sh -m M0054 -v var00.1

I'm using this var00.1 variable to pull in these device tree files basically:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/tree/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/dts/variant/m0054/var00.1
Specifically for cameras:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/files/dts/variant/m0054/var00.1/m0054-modalai-camera.dtsi?ref_type=heads#L4
This happens here:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2-bsp/-/blob/qrb5165-ubun1.0-14.1a/recipes-kernel/linux-msm/linux-msm_4.19.bbappend?ref_type=heads#L187

For reference, the kernel tracks and exports info about itself to filesystem using this:
https://gitlab.com/voxl-public/system-image-build/meta-voxl2/-/tree/qrb5165-ubun1.0-14.1a/recipes-kernel/voxl-platform-mod

-Travis