Posts made by zauberflote1

@Myles-Levine
Performance is evaluated with no external masks -- as we don't ship them. With masks, the answer is very dependent on use-case. Honestly, based on practical tests, it might be better to fly single-cam (full-view) with tight params for robustness than to fly multi-cam with obstructed view. Furthermore, you could try changing the location of your cameras, and doing an extrinsic IMU-CAM calibration with our Kalibr setup (guides available in past answered questions)

@Myles-Levine Absolutely, you're forcing the tracker to reduce the tracking continuity window, less persistent features -> SLAM feats drop.

Perhaps, you could try reducing the spacing between features in the estimator_config yaml (track opts) to bump MSCKF feats and potentially SLAM feats; however, these are advanced settings. Please exercise your best judgment when changing this, modifications are not recommended for general/default use-case

@zauberflote1
You could also disable the bottom cam in vio_cams.conf for VIO only

@Myles-Levine
Hello There,

Please check your SDK version, VINS is under constant development, so always prefer the latest tag available.

Regarding occlusion during takeoff, please check your /etc/modalai/vio_cams.conf, if you have the occlusion flag during takeoff enabled, I would attempt disabling and confirm if the behaviour persists...

Regarding Arbitrary mask, please refer to this past forum question, if you have any further questions, please don't hesitate to post.

All the best,
ZBFT

@bendraper
Hello,
I hope this quick clarification helps for warnings:

CMake Policy warnings: OV internally (external dir in the repo) still uses boost and references an older cmake version -- it's a harmless warning for devs (as you are building from scratch)

Yaml-cpp lib warnings: This is a third party dependency that gets compiled from scratch during the make/build process. We use C++ 17 but the library is based on an older C++ version; nevertheless, it compiles fine on C++ 17 with minor warnings. -- it's a harmless warning

TrackOCL warning: ModalFlow is a core library written in C++ 17 that allows function call usage as done in TrackOCL, i.e., the narrowing conversion is harmless in this case.

That being said, we are actively working on the dev branch, so all flight--impacting warnings are hopefully caught early. We currently have no flight-impacting warnings/bugs identified, but if you found one warning/bug that caught your attention, please feel free to share.

All the best,
ZBFT

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

@Nitin-Varma-Vegesna Please update your SDK to the latest... Minimum SDK required does not mean best performance.

Also, please follow this post for posting guidelines: https://forum.modalai.com/topic/2670/please-read-support-request-format-for-best-results

Finally, please provide a screenshot of your voxl-inspect-cpu output...

It will be released on 1.6.3. If you need the feature now, you can always build it from source and deploy to your voxl.

https://gitlab.com/voxl-public/voxl-sdk/services/voxl-portal/-/tree/dev?ref_type=heads

@Nitin-Varma-Vegesna

Hello, please provide your platform specs and sdk version.

@Dronodev

Can you confirm you have the raw feed button? Please give a try if you have.

Example follows:

@Dronodev
ov_overlay is now available under the VIO tab in voxl-portal. Please make sure to update your system to the latest released SDK.

@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

@dvz Hi would you be able to confirm which airframe and SDK versions you are using?

@Muqing-Cao

You should be able to download it and install it, as our betas are now public.

@Muqing-Cao said in starling 2 max qvio vs open-vins performance issues:

do we have to change the configs file to the startling-specific configs after update?

Not necessarily, unless you changed the default values. The new SDK installation will prompt you to identify your platform.

@Muqing-Cao
Please update it to the latest version, 1.6.3.

PS: 1.6.3 is still in Beta phase, but it should be released soon

@Muqing-Cao

Can you confirm your SDK version?

@YUUJI-INOUE
Glad to hear!

All the best,
ZBFT

@YUUJI-INOUE

Happy New Year!
I wanted to take some time to review the video and the configs you’ve posted. Here’s my personal interpretation based on the information provided.

• It doesn’t seem you’re using VFC-position, but PX4 Position mode. Recall that on Stinger the recommended default is VFC-Position. (You can change en_vio to false in VVHUB config and adjust your transmitter settings to reproduce the default configuration.)

• Your position lock break is likely due to SLAM features being rejected during the MSCKF->SLAM promotion and/or not being “rematched” properly. This strongly suggests calibration issues, particularly CAM-IMU extrinsics. Did you use Kalibr? If so, would you be able to post your Kalibr-generated report? Still, you can likely mitigate this at the expense of VINS' accuracy by bumping the chi2 value for SLAM features.

Also, the number of features you see in the inspect-vins tool represents valid SLAM features, so it doesn’t mean that the estimator has no features at all, as MSCKF features can still be available.

@jakkkkobo

Hello,
We currently do not ship any mask files with our airframes, as they are normally not required. In addition, you should be able to use a mask with minor modifications on the server side, namely VoxlCam directory inside voxl-open-vins-server repo. (The mono camera case should be a good starting point, as we already have the masking logic for occluded cams during takeoff.)

Furthermore, as we use a custom interface/backend for OV, loading the mask as done in the traditional OV-ROS format won’t work as intended, i.e., via Yaml.

All the best,
ZBFT

@YUUJI-INOUE
Hello there,
Here are a few things to be aware of:

• VVHUB "Error" for missing extrinsics for imu_body

This is not really an error, just tells you that the IMU in body frame and the body frame itself are connected by the identity. In other words, there's no transformation needed for the IMU data from VVHUB standpoint.

• Position Mode not engaging

Assuming you're able to get the drone arming in Manual/Altitude mode. Are you using VFC in your VVHUB conf or using the classic PX4 position mode? -- If your drone resembles the Stinger D0013, VFC is the suggested format. -- you can use the wizard to configure VVHUB accordingly. Can you confirm your VVHUB setup? Please attach your vision-hub and vfc .conf

• VIO not working

As you described, different frames, different noise characterization. You can change the IMU noise values inside the kalibr_imu_chain.yaml (in the directory you found estimator.yaml). Personally based on your description, I am inclined to believe your performance issue is rooted in your extrinsics values and VVHUB configuration. Did you use Kalibr? -- If you used Kalibr with imu_body pipe, all you have to do is to replace the SE(3) elements inside kalibr_imucam_chain.yaml and make sure the sync_config flag inside voxl-open-vins-server.conf is set to false. Otherwise, unless you have a proper CAD model, physically measured values will likely be inaccurate and cause the estimator to diverge. For future help, please attach all your VIO-related yamls and your voxl-open-vins-server.conf

All the best,
ZBFT