@Karteek-Gandiboyina Also, for reference: https://forum.modalai.com/topic/4403/starling-2-max-with-ublox-f9p-ultralight/7?_=1772217162290

@Karteek-Gandiboyina Unfortunately, we don't have any experience with that unit. It looks like it is hooked up correctly since you get a response from it. What baud rate did you change it to? You can try running the latest version of px4 but we have spent very little time testing it so use with extreme caution: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mainline-px4_1.17.0-1.0.2-202602240859_arm64.deb. Perhaps load that, remove the propellers, and just verify that it can properly see the GPS? And what if you just remove the baud rate option on the start command, does that change anything?

@Sarika-Sharma We have a variety of parameters sets available in the voxl-px4-params repo https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-px4-params/ However, they are mostly for either indoor or outdoor use. Older versions of PX4, like what our fork is based off of, had a hard time with external vision based navigation coexisting with GPS based navigation. Newer versions of PX4, supposedly, are much better at this but we have not spent the time to prepare a parameter set for that yet. You are free to experiment with our mainline PX4 build here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mainline-px4_1.17.0-1.0.2-202602240859_arm64.deb. However, if you decide to use the mainline build, be aware that it is considered "experimental" at this point and has very little testing on voxl2 so use extreme caution.

@mark , it looks like your version of voxl sdk has an early version of the imx664 driver (not supporting 2704x1540 resolution.

Are you able to upgrade sdk to 1.5.x or 1.6.x?

Alternatively, i could share the latest camera drivers to use with 1.4.5.

I would also recommend updating voxl-camera-server to the latest, but that would also require updating other packages.. would you consider upgrading the sdk or are you locked to 1.4.5?

Alex

@jh81306
Hello there,
Yes, real time performance is achievable with 3 cameras at 30fps, evidencing the benefits of our hardware accelerated GPU feature tracker. From this perspective, if you plan on using GPU-heavy applications, QVIO may be the second best option, as it uses remote procedure calls between the linux processor and the DSP, freeing GPU usage. However, due to the inherent nature of the DSP (L2 Cache, etc) and timing considerations, running QVIO on 3 Cameras may not guarantee a consistent update rate depending on the processor load/scheduler priorities. In essence, choosing one or the other is a trade-off that should be based on user use-case.

In terms of estimator robustness, our branch of OpenVINS has been considerably modified to support accurate estimates under degraded conditions, and all ModalAI UAV platforms have gone through extensive calibration in order to obtain the optimal parameter set. Hence, in terms of estimator quality, OVINS outperforms QVIO, but requires carefully calibration of your visual-inertial sensors. Finally, If you opt to acquire a ModalAI Vision drone, OpenVINS should be fully functional out-of-the-box, facilitating a potential pipeline transition.

@Leo-Allesch , if you are talking about VSLAM, which stands for Visual Simultaneous Localization and Mapping, then this is a sub-class of SLAM which uses only cameras (and often IMUs, then it is VISLAM).

VSLAM and VISLAM usually generate and maintain a sparse map of 3D features (points), which is used for self localization.

If you want to be able to detect a target, and you have your 3D pose from VIO (VIO = VISLAM), then you can either triangulate the target location or get it's location from a single frame if you know the size of the target (such as April tag, etc). Then you can transform the coordinate of the tag from the camera frame into your "world" (VIO) coordinates.

The depth sensor would allow you to build a more detailed 3D map / point cloud using the 3D pose output from the VIO algorithm (or just using a depth sensor, which may be more complicated). You can also build a dense 3D map using camera only (and IMU), but that typically requires a lot more computation than using a depth sensor.

You don't necessarily need a depth sensor for identifying the position of a specific target that is easily detected by a camera.

There is a lot of research material you can find on these topics, please look into it deeper and let us know if you have specific questions about using VOXL2 hardware and software.

Alex

@mark ,

Please try using input resolution of 2704x1540, not the binned one which you have currently selected. Then you can set MISP width and height whatever you need and the output should be properly downscaled and cropped. Choosing higher input resolution will result in a better downscaled image due to debayering artifacts at lower resolution.

The reason why the image decoding does not work has to do with the image line stride of the raw10 buffer not matching the requirement of the opencl debayering functions. In newer versions of camera server, we automatically re-align the image to make it work, but that requires copying the whole bayer image into a different buffer (more cpu overhead).

Using input resolution of 2704x1540 will result in best results in terms of image quality and cpu usage. This resolution works up to 120FPS. Binned mode does not actually provide any advantages (specifically for the IMX664 camera), not even faster read-out or higher max fps or anything like that.

Please try that and let me know if that works for you.

Alex

@greg_s HI there,

The video exhibits classic VIO lost behavior from extrinsics: hovers fine, then on translation just flys away. Can you switch from trajectory mode back to figure_eight mode and confirm the drone can fly in figure 8s for more than 30secs?

Figure 8 also tests the trajectory engine that mapper uses so it will confirm a number of things on the sensor side.

@Catalystmachine , for questions regarding orders, please reach out here : https://www.modalai.com/pages/contact-us

Hi @Hunter-Scott ,

We are looking into this. We may not have an exact CAD model for every single variant of the products. Is there something specific in your product that significantly deviates from the provided CAD files? Maybe we can provide something that is close (but not exactly correct).

Alex