Z
@Noah-Heinen
Hello there,
Yes, we haven't officially supported this package for a while, and our development drones currently do not ship STEREO_RAW8 format by default.
However, even though there are no official plans for this repo, I made some changes that should solve the issue for now. This also expands to RAW8 images. Feel free to test it out, this repo will likely become community driven.
Hello there,
2d Lidar 50gram above the gps bridge
2 x light ilumination (front, down - we are flying and dark tunnels next to tracking cameras)
props guards the are seen by the tracking camera
we have added tof camera, moving from C28 to C29 ( currently its not working or wired in sw), we have changed the extrinsix.conf file in /etc/modalai accordingly.
all of those changes did not effect our filght and we had good flight with good vio during the flight
If the platform we are discussing has this added elements, it is a custom frame.
we are exploting a tunnel for the first time.we use the poshold durung junction turns to hold in place during turbolance. my answer would be we can live with resets assuming we can accumulate the positions for mapping between the resets.
Yes, so that is a mapping/loop closure software responsibility, not VIO.
how do we make sure what you are saying is right and we are passing estimates to px4 ?
Check your voxl-vision-hub.conf, if en_vio is set to true, it passes to PX4 as external vision estimates. Also rectified by:
HGT_REF=3 //VIO
EKF2_EV_QMIN=16
EKF2_EV_CTRL=15
For now, our PX4 flavour doesn't handle VIO resets gracefully always. We currently have overcome this issue by using VFC. Hence, the reason I suggested that you should try to repeat the same maneuver under VFC position. If you have any questions on how to enable VFC, please feel free to ask.
what should I expect ?
Likely more robust performance under resets at the potential cost of manually hover thrust, PID/PD tuning.
PS: I wanted to try reproducing your setup here with non-modded Starling2 Max, but I am unable to match your setup without logs
@RoyAzriel Hello there,
This goes back a bit to my first question, but let's break it down systematically:
Do you need VIO estimates to be always continuos or reset jumps are okay?
If you need VIO during takeoff and your application is not robust to SFM resets (potential jump discontinuity), I recommend never using dynamic init and warm reset
Back to what you reported
"still sometimes it fails to converge. Can you recomend what is the best sequence one should do to get convergence in high precentage after power cycle ?"
Convergence for a initialization would usually refer to a dynamic initialization (nonlinear optimization), as the static initialization does not involve optimization. That being said, some static inits can be bad as soon as the platform is in the air: noisy ZUPT updates, bad IMU calibration and sigma/random-walk values. This is natural under custom frame mods, perhaps a full IMU intrinsics recalibration could help.
Nevertheless, it seems that you're running VIO by passing estimates to PX4, instead of using VFC Position (Local Controller with VIO estimates that send just setpoints to PX4). I am personally curious if the issues you're having are related to the PX4 integration with VIO estimates or if it's truly pure VIO estimates.
Please try:
voxl-configure-vision-hub factory_enable_vfc_starling
If you have logs to share, please feel free to send them.
Q: What is your EV_q (quality minimum) in PX4? Also what your HGT ref?
PS: We are bringing up better VIO debug tools for users, so stay tuned for updates as well.
All the best, ZBFT (Joao Leonardo Silva Cotta)
Hello Roy,
Here are some questions and steps to begin troubleshooting it:
Hello there,
It seems that you're currently running an alpha version of an old version of the SDK. I would recommend updating your SDK.
In regards to VIO, I would recommend running OV pipe instead of QVIO (more details on this available on my past replies/posts). In addition, I would recalibrate your unit IMU via voxl-portal, ensuring your gravity magnitude post calibration is ~||9.81m/s^2||. You can inspect it via voxl-inspect-imu on the devices' shell.
All the best,
ZBFT (Joao Leonardo Silva Cotta)
Regarding the feature track tab, I recommend upgrading to the latest available SDK, features should show on voxl-portal.
The correct overlay is under VIO indeed
@Yonim Hello,
Quick question: Are you using a development drone? If not, have you calibrated your extrinsics and intrinsics properly?
@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.
Web interface hosted on VOXL
GitLab (gitlab.com)
Hello, please provide your platform specs and sdk version.
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.
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?
