Posts made by modaltb

@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

Hi @waqaskhan2000 ,

The M0173 was brought into our lineup to support our Starling2 product lines.

We haven't released a reference drone (yet) using VOXL2 mini so the internal requirement to create one hasn't come up.

We will likely create something similar but we don't have a timeline right now for that....

Hi @Janelletran ,
Because this board exposes pins directly from the 865 SIP, we make it kind of hard to find so folks know it will be easier to damage the VOXL2 product with this add on if you're not careful.

This board:
https://docs.modalai.com/voxl2-dev-test-board/

Has a hidden purchase link here:
https://www.modalai.com/pages/beta-voxl-2-b2b-breakout-board

Happy hacking!

@Jetson-Nano not at this time and not with QVIO. We are working on multi cam VIO but can't provide any details or release dates really at this time.

@Jetson-Nano can you take a picture? for example, we make a M0070 board that has this sensor on it. Are you making your own carrier board for the sensor?

@Jetson-Nano what is the VL53L1X on?

@dlee

You can use option 1:

Note, we've seen two connection types from Doodle (legacy and the newer one with multiple JST connectors).

We use this on another product of ours, and from USB3 port, MCBL-00085-1 should suffice:

@Jetson-Nano are you using our M0070 board like this? https://docs.modalai.com/rangefinders/#single-rangefinder-using-m0141-expansion-board

Or custom? If custom check pin 5, which on our M0070 board is pulled up to 3.3VDC.

@SMRazaRizvi we honestly don't have any gimbals on our products at this time so hard for me to say as I would want to have a working reference..... the gremsy gimbals are super nice and if they have a MAVLink interface, but to get this controlled straight from VOXL2 at this point would be some custom coding as we don't have a reference at this time...

@Jetson-Nano If you've reverted back to original config, run voxl-configure-cameras and select the D0005 Starling option.

When you want to use ov9782, you need to copy the correct binary into /usr/lib/camera and also update config file?

A high level helper is here:
https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/master/misc_files/usr/share/modalai/voxl-camera-server/custom_camera_config.txt?ref_type=heads

You can then use voxl-configure-cameras -c to use custom setup, after you've setup the above file into correct place (see top of the file for direction).

see this for logic of setting up proper bins:
https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/master/scripts/qrb5165-configure-cameras

see https://docs.modalai.com/voxl2-image-sensors/ for more info, but since we support a lot of different configs and, because of I2C clashes if we have all binaries in /usr/lib/camera, we copy bins into place using camera-server wizard.

@Aaky agreed - not an issue with camera pipeline at all to do that.

OK all shipped ok.

Above looks good with flat on table test results...

Here's factory test data which shows OK:

2024-05-03T22:01:18.648Z -- {"desc": "IMU1 - APPS PROC - OK", "GYRO_X": 1.001, "GYRO_Y": 0.998, "GYRO_Z": 0.994, "ACCL_X": 0.99, "ACCL_Y": 0.987, "ACCL_Z": 0.957, "FAILURES": []}
2024-05-03T22:01:19.361Z -- {"desc": "IMU0 - SLPI ACCEL - OK", "ACCL_X": 0.11492, "ACCL_Y": 0.20016, "ACCL_Z": 9.89428, "FAILURES": ""}
2024-05-03T22:01:19.960Z -- {"desc": "IMU0 - SLPI GYRO - OK", "GYRO_X": 0.02435, "GYRO_Y": 0.03108, "GYRO_Z": 0.00174, "FAILURES": ""}

If it passes flat on table I think things are OK and it's a result of expecting certain tests to run in this flat orientation during factory test.

Hi @Jetson-Nano

OK we'd expect something on the bus like this:

Can you describe your wiring setup?

@SMRazaRizvi we used this one on a big drone and were able to control via MAVLink:
https://gremsy.com/products/product-gimbals/mid-size-gimbals/gremsy-s1v3

But, re-thinking this, we actually don't have the GIMBAL PX4 driver in voxl-px4, we used our Flight Core to control this which had the driver.... So to get native gimbal support out of a UART from voxl-px4 itself would need some custom work as well.....

Hi @jfuchs ,

The 5G modem is actually just using USB over the PCIe interface! We didn't have many users using PCIe so we disabled it in favor of enabling 4 GPIOs...

That said, roughly a day after we did this, the PCIe requests started coming in (as the SW gods would have it ;).

I am going to generate a new build from the tip of our SDK which is 'alpha/beta' level, if you're up to try this out let me know.

Thanks,
Travis

Hi @Aaky

Yes three camera streams are OK (you can do 4 on voxl2 mini with the interposers we sell, e.g. M0135).

We don't have an SDK camera config that works out of the box but it's not too hard to build one up, see:
https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/master/misc_files/usr/share/modalai/voxl-camera-server/custom_camera_config.txt?ref_type=heads

For example, check out these:
https://docs.modalai.com/voxl2-mini-image-sensors/#quad-tracking

And this, https://docs.modalai.com/voxl2-mini-image-sensors/#camera-configuration-summary:

what about with

i2cdetect -r -y 1