@mkriesel , we do not have enough information to be able to pinpoint the root cause, so please try to perform the following test:

on voxl2

systemctl stop voxl-px4 cd /usr/share/modalai/voxl-esc-tools ./voxl-esc-scan.py

The output should look similar to this . Run this scan back to back several times and check if all 4 ESCs are detected each time.

If the esc scan result on voxl2 is not consistently detecting all 4 ESCs, please repeat the same test on a linux PC (you will need the aforementioned UART cable). You can download voxl-esc tools from the git repository here and run the same test, the output should look like this -- almost identical to what is expected when scanning on voxl2.

Thank you

Alex

@ravi The documentation has been updated. If you are running a recent release from us then you will be using the ICP-20100 barometer. The BMP388 will not be started.

@Vinny Thank you for reverting back, I will follow the steps you mentioned along with the ESD safe method.

@Vinny Got it. Thanks!

Hi @18257581
Sometimes our newer boards are lacking in full documentation, so thanks for your patience.
We have not publicly posted our uCoax pinouts and not sure yet if we plan to. For now it is required to use our full solution which is host adapters, cables, and sensor boards.
I'll bring it to the team. But, we are unlikely to open this up since in order for us to test the components, which are very fragile, they need to be bundled together and not separated, so it would actually cost us more (costing our customers more) to test units individually for customer designs.
Only the Coax cable we sell individually and that is pinned 1:1 with all 26 conductors present unlike some of the other COTS FPV systems.

However, for JST and other cable-to-board and board-to-board connectors, yes, we need to get that listed.
The pinout on J4 of M0201 (the replacement for M0153) is in the same Dronecode inspired format we use at ModalAI for UART + I2C, but in this case since it is not UART, it is 2 GPIOS.
So,
Pin 1 = 3.3V
Pin 2 = GPIO_1 (Undefined/Unavailable/Reserved for Future Use)
Pin 3 = GPIO_2 (Undefined/Unavailable/Reserved for Future Use)
Pin 4 = GIMBAL_I2C_SDA (3.3V Logic Levels, 2.2K pull-up resistor present)
Pin 5 = GIMBAL_I2C_SCL (3.3V Logic Levels, 2.2K pull-up resistor present)
Pin 6 = GND

@Jetson-Nano When you say "while using the internal px4, it is loading fast" are you saying that when running px4 on voxl2 it connects but when running px4 on flight core v2 it doesn't?

We have updated the M0129 in the past few months to support 2S-6S, it looks like the datasheet is out of date. Thanks for pointing that out.

If it is marked M0129-63 or M0129-65 it supports 6S

M0129-3 and M0129-5 are the older version and they only go up to 4S

@Andrew-Jue , you can find the latest firmware for the IO board in /usr/share/modalai/voxl2-io-tools/firmware/modalai_m0065_firmware_v0_2_RC1_f94baad1.bin on your VOXL2 or on gitlab: https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl2-io/-/tree/master/voxl2-io-tools/firmware

You can update the firmware using our voxl-esc tools, as documented here : https://docs.modalai.com/voxl2-io-firmware/#how-to-update-firmware

This version of the firmware is the latest and has been stable for over one year.

Alex

@Steven-Girouard Are you using PX4? ArduPilot? You could run that directly on the VOXL 2 mini depending on what your IO needs are.

@Ege-Yüceel Hi Ege, the most likely scenario is that the tflite-server is starving the open-vins process causing backups and missed data. Can you increase the "skip frames" parameter in tflite-server or reduce the number of cores it is using?

@wifa799 ,

Please see the following post : https://forum.modalai.com/topic/4274/hadron-boards-to-order/ (at the end)

In short, Hadron works in J8 only using the kernel variant that works with M0173. I need to update the documentation.

So you can have 3x tracking, 1x hires, 1x TOF, and Hadron (IR + OV64B hires). That is 7 cameras which is the maximum number of MIPI cameras that VOXL2 supports. I know you did not ask for the other hires camera (recommended IMX412 M0161 module), but just wanted to mention that.

This set up is not standard, but you would just need to set up for a standard Starling camera setup (C27) then go from there.. copy the sensormodules (camera drivers) for Boson in slot 4 and ov64b in slot 5 and update your voxl-camera-server.conf. I can help you with that if needed.

Alex

@Jing-Yu , the tof_depth image is a 8-bit image where each pixel represents a scaled depth. this may not be the best way to use the output of TOF sensor.

You can subscribe to the point cloud directly.

Here is the code that handles the output of the TOF sensor and publishes it to MPA clients. This shows how the different images are generated, including how the TOF depth is scaled to produce an image : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L3214 ( RoyaleDataDone function).

Here is an example for receiving the TOF point cloud using an MPA client. it is very basic, but you can update it. The data that is sent out is an array of XYZ float points : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-points.c?ref_type=heads

and finally here is another example in voxl mpa-to-ros library, which handles conversion from the MPA messages to ROS. It has a few point cloud formats, but the one you need is the XYZ : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-to-ros/-/blob/master/catkin_ws/src/src/interfaces/point_cloud_interface.cpp?ref_type=heads

Alex