Hi, VOXL Portal doesn't look at anything related to the extrinsics, it's just a debug tool to help visualize the data that's being passed around between the services. Any services that use the data coming from the tof sensor will use the data in the extrinsics config file to reorient the pointcloud to whatever frame that service is using (you can find examples of this in voxl-mapper and voxl-vision-px4).

@Chad-Sweet Thanks

@Matt-Turi Thank you

Thanks will do!

You only need the Docker on VOXL 1 if you want to use Debian OS VOXL 2 has Debian native so you don't need the Docker Both platforms have opencl libraries in the native OS and do not require a Docker for OpenCL

@czarsimon Yes, it should be possible. But there are probably hard coded parameters in the code that make it only work with the hires camera right now. That code has been archived but is still available here: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-hires-server

The VOXL 2 is the main PCB, and can come in kits with accessories for power and image sensors The VOXL 2 Flight Deck has a plastic enclosure that includes VOXL 2, 6 image sensors and is fully calibrated. The flight deck has a number of modem add-on options as well

Have you looked through the troubleshooting VIO doc? https://docs.modalai.com/flying-with-vio/#troubleshooting-vio

@Alex-Gardner said in Acceptable tracking camera calibration reprojection error: Ah, If you're talking about the calibration for the fisheye tracking lens the rules are different. It's much easier to calculate the intrinsics of the fisheye lenses since there's much more warp in the images, hence why there's only 4 images required for the calibration. A result of this is that the reprojection cutoff will be much higher because it's such a distorted image (we have found that <=5 works for the fisheye). If you run the calibrator on one of the pinhole stereo cameras you'll see a lot more of the target rectangles, some of which have been intentionally elongated as to force the user to include some skew in the input set. This isn't necessary for the fisheye though. Do you know if the reprojection error is a good and reliable metric to determine if the calibrationis done well? I have on rare occasions calibrated the fisheye cam, obtained reproj errors of less <0.3, but the calibration was obviously off. The aircraft was very unstable at takeoff, hovering and pure yaw rotations. The instability went away after i performed a recalibration (even if the reproj error ismore than what i had before) I could confirm this because i kept the old intrinsics fileand i can reproduce the instability simpyly by swapping back to the old file

All of the files for the demonstration TF Lite server models live in: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-tflite-server/-/tree/master/misc_files/usr/bin/dnn On the VOXL itself they reside at: /usr/bin/dnn You can add your specific model and execute voxl-configure-tflite-server to point to the new model. https://gitlab.com/voxl-public/voxl-sdk/services/voxl-tflite-server/-/blob/master/src/main.cpp#L238 shows an example with YoloV5.

Wanted to update this by saying I experienced same issue, but I resolved this by disconnecting tracking camera that had been installed upside down. So, if anyone is reading this in the future....try disconnecting your cameras attached to the board

Wanted to update this by saying I experienced same issue, but I resolved this by disconnecting tracking camera that had been installed upside down. So, if anyone is reading this in the future....try disconnecting your cameras attached to the board

Hi, You don't need voxl-mapper to use collision prevention, you just need to enable an auxiliary input for the tof sensor in /etc/modalai/voxl-vision-px4.conf. Mapper is a completely separate service that's still in alpha and should only be used after understanding the majority of the codebase.

@Eric-Katzfey Thanks, it works! I didn't know the last part (push the debian package and install there).

@Matt-Turi thank you very much. Really appreciate your help

Here are some pictures of the issue. Did some more testing and it might not be the props as I tested with the props off and the close points are still there. Is there something wrong or blocking the TOF sensor on the seeker? [image: 1668213067386-screenshot-from-2022-11-11-17-07-51.png] [image: 1668213085769-screenshot-from-2022-11-11-17-11-39.png]

@wxyLuna we do offer express delivery. If you would like an estimated time and cost I would send an email to contact@modalai.com with your preferred selection of drone config and address. The ten days you are referring to is the estimated lead time to build the drone, not shipping time duration. We build each drone to order, making sure the product is built to our high standards.

@modaltb Hey! Thank you for the reply ahaha, I understand its a busy quarter for everyone We are connecting the IMU to the I2C3 pins of the J9 6-pin pinout of the 5G Modem. On other devices (such as the jetson AGX orin) we are able to get a data rate of 928 hz , but on the VOXL its stuck at around 628 Hz in ROS. For the ORIN we were able to increase the rate by modifying a bus_clk_rate file in /sys/bus/i2c/devices/i2c-1 but there appears to be no equivalent here. I found a voxl_i2c_write function in your docs that looks like it could increase I2C bus rate, but unsure how to access and use it. Also tried changing the device tree file to increase the rate ceiling and making a .patch to change it and add changes to kernel_patches but that dropped the rate to 120-ish, and never increased it. Quite confusing! Thanks for your time and have a nice day!