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

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.

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

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.

@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

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

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

@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

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

Thanks will do!

@Matt-Turi Thank you

@Chad-Sweet Thanks

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).

Turns out it was a bent pin in the hires port.

I was thinking of something simple, eg:

Use tracking cam qvio until reported quality drops below a particular value (near blowup). If it does, switch to stereo qvio feed as long as the position + velocity were recently in agreement within some threshold and its reported quality is sufficient. If not, switch to manual mode and call an adult. Once the main qvio recovers, store the position offset (for future switchovers) and switch back.

I'm sure proper fusion will obtain a smoother and more robust result, but I'd just like something that can handle a blowup without crashing.