@mkriesel It's possible the kernel you're flashing is incorrect. Can you provide the full terminal output of the install?

Hi Cbay, There is a small clock buffer on the edge of the PCB. An RMA can only replace the whole board, not replace a single device. The part to check would be here: [image: 1779297839725-image-1.png]

Thanks @Eric-Katzfey ! Here is the pinout for the dev board "UART" port that includes i2C_SCL and I2C_SDA. [image: 1778773646212-0cda71eb-2c0f-4b1b-ba91-8b3862fc9763-image.png] The dev board pins 1-6 matching to J19 pins 1-6 We will give the COMPASS_DISBLMSK parameter a shot and see if that works.

@Plingaas02 Regarding odometry in voxl-mavlink-server, it will not modify timestamps on this message. There will be, potentially, VIO odometry messages going to the flight controller from voxl-vision-hub via voxl-mavlink-server and flight controller odometry messages being routed out to the GCS and to the onboard stream. The odometry messages coming from PX4 will have the DSP monotonic timestamp which is different than the Linux monotonic clock and these will drift with respect to each other over time. PX4 runs the timesync service so it can correct the incoming messages from VIO.

Hi @austin-c Sorry I missed this message somehow. I will email you to kick this off with your team.

@austin-c , The GPS driver is built for SLPI as well as APPS PROC, so you could connect it to a apps-proc UART and start the driver on the apps proc side of PX4. This was done on RB5 : https://docs.modalai.com/Qualcomm-Flight-RB5-linux-user-guide/ https://docs.modalai.com/voxl2-linux-user-guide/ Regarding magnetometer, just like with the GPS driver, you should be able to enable the mag driver to build for apps proc. Since the apps proc i2c uses standard posix interface, it should just work. However, i don't think we have ever tried it. Alex

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.

@cbay voxl-fpv-px4 is based on voxl-px4 but has some custom tuning code / parameters for our fpv drones that isn't in voxl-px4. So, it's kind of a superset. But there isn't anything related to low level i2c drivers so I have no idea how that could be causing this issue.

Hey @svempati I trained a model in the docker command as provided by you. I am able to run an inference on potholes following exactly the steps provided by @Zachary-Lowell-0 earlier. Could I ask you what your voxl-tflite-version is? And if you havent yet, could you try to run this version: http://voxl-packages.modalai.com/dists/qrb5165/sdk-1.6/binary-arm64/voxl-tflite-server_0.5.1_arm64.deb Make sure to change the .tflite model and labels as shown in the loom video after the install, then run voxl-configure-tflite Thanks

@Moderator Thanks for the clarification on the ~50 ms glass-to-glass number. Trying to get a better understanding the performance envelope: 1. Does the 50 ms include RF transport over Doodle, decode, and HDMI output latency, or is that measured only within the VOXL + VRX software stack? 2. Was this measured in point-to-point mode or mesh routing mode? 3. Can you expand on bitrate, resolution, and encoder settings were used (GOP structure, B-frames disabled, UDP vs RTSP)? 4. Is MAVLink or other traffic running on the same link during that measurement? 5. Do you have a latency breakdown per stage (encode / RF / decode / display)? Appreciate any information you can provide. I just want to make sure I can test and validate this effectively.

Hi @wetherbeej Oh yikes.. You should really work with us on that change. There is a high likelihood to damage your VOXL 2 and the MEMs sensors are likely all broken now from the extra reflow cycles. Flash provisioning is all done over QFIL tools, not PCAT.

@Moderator The description to MCBL-00128 (https://docs.modalai.com/cable-datasheets/#mcbl-00128), the TOF for the Voxl 2 Mini says it's supported with M0188 (https://docs.modalai.com/M0189/) without specifying any sub P/N (-1 or -2), even in the documentation of the M0188 doesn't say anything about P/N -1 or -2 (https://docs.modalai.com/M0188/).

@alan123 Hi, sorry for the late reply. Unfortunatly, we have not finished it yet. We're switching from ntrip to ros2

@Morten-Nissov , Is it just the specific camera (tracking) not working in a specific port? what if you connect TOF or IMX214 camera there? For your configuration using the M0135 interposer, kernel variant 2.0.0 is the correct one to use. Using kernel 2.0.2 will result in some cameras not working due to different pins used for camera reset (which get properly routed in M0188 and M0195 camera adapter boards for the coax cameras). So i would suggest using the correct kernel 2.0.0, then test one camera at a time and see if you can narrow it down to a camera or port not working. Alex

Hey @yunwool Just to be clear, consider only your first drone, if you run export ROS_DOMAIN_ID=1, then run ros2 topic list, you aren't seeing any topics right? After you set the ROS_DOMAIN_ID of a drone to 1, to get the PX4 topics to show up, on QGC > Analyze Tools > MAVLink Console, run the following commands: param set XRCE_DDS_DOM_ID 1 param save Then power cycle the drone, give it like 15s after boot up, then the topics should come up directly when running ros2 topic list on that drone.

@sja123 No, unfortunately, we do not currently support boot from SD card.

@magnetocircuit Yes, this is supported. In the config file for px4 /etc/modalai/voxl-px4.conf set ESC=VOXL2_IO_PWM_ESC.

@Aaron-Porter Hello there, voxl-evaluate-vins is currently not used by the Autonomy team @ ModalAI, we opted for our new benchmark solution, a bit more consistent in terms of statistical rigor and better integration with voxl-portal. Still, when replaying logs for VINS, it is imperative that one replays them using the ION pipes, as our VINS solution is optimized for cl_mem ptrs. Note that when replaying ION pipes, it is recommend to stop camera-server before replaying -- as clean killing ION pipes via the voxl-replay args is currently being optimized. This should resolve the common segfaults experienced during the replay/benchmark operation itself. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-benchmark-vio Finally, I would recommend updating your VINS to the latest available tag on Gitlab