M0149 camera refocusing and tuning parameters
-
@Aaky , camera calibration parameters are specific to each camera module, so i don't think any other calibration parameters would work for you better than what you have. Does that make sense? Or are you asking about different parameters (please specify).
I will check to see if we can provide reference data sets running QVIO with AR0144
-
@Alex-Kushleyev Alex actually I am asking for voxl-camera-server related parameters for AR0144 and ofcourse not camera calibration parameters. Along with that, like you mentioned even good test datasets recorded by you would be also beneficial with all camera server parameters and maybe qvio server parameters except intrinsic and extrinsic. Let me know.
Thank you! -
having very similar issues to you Aaky, qvio does not like this M0149 camera whatsoever.
-
@Gary-Holmgren , I replied to your new thread, we can discuss your issues there. https://forum.modalai.com/topic/3522/vio-errors-with-new-ar0144-tracking-camera-unstable-flight-crashing
-
@Alex-Kushleyev I wanted one quick help. I am running my drone with AR0144 in dusty environment, imagine an under construction building with lots of dust around and with UAV's prop wash it increases more and more. VIO resets more often in this situation. I am totally aware computer vision algorithms wont work if its unable to find any features, but can the camera parameter be tuned to make it work in dusty environment? I have very important demo tomorrow with this setup and if you can help me to identify if anything can be done with AR0144 camera would be highly appreciated. My MSV in camera-server configuration is set to 80 since my environment would be bit darker. Let me know apart from this if anything can be done.
-
@Aaky , as you already mentioned, dusty environments can very difficult for computer vision, I would say this is more like an open-ended research topic as opposed to parameter tuning task in current VIO. I imagine, you would need to use a different approach to feature detection and tracking, depending on the particular environment.
If you wanted to try to push VIO to the limit, my suggestion would be to do this offline with collected data logs and playback (raw images and IMU data) running in the same environment at different exposures. During data collection, you could fly the drone manually or even do hand-held tests without spinning propellers, although spinning propellers would generate even more dust movement.
Without running offline tests and seeing how the algorithm performs with different parameters across many data sets, there is little hope to magically get it right and improve the performance. There is no shortcut here - it is a complicated problem and needs to be approached in a structured way
Also, we have never tested VIO in very dusty conditions (i am not sure how much dust you are talking about, but I am assuming significant, since you mentioned complete lack of features due to dust). Therefore, we don't have a quick suggestion how to improve performance in these conditions.
Alex
-
@Alex-Kushleyev Thanks Alex for your inputs.
On a seperate note, I wanted to discuss one thing. Can we expand current QVIO architecture to take input from two cameras? Or run two QVIO instances and fuse their odometries into PX4 (Maybe when one fails other Odometry would be fused and vice versa). Just wanted to check if any such kind of concept would work on current QVIO pipeline?
-
@Aaky , please see the following comments:
- the QVIO architecture does not support multiple cameras, there is no way for us to make it work
- You can certainly set up and run multiple instances of QVIO using same IMU and two different cameras. These instances would not know anything about each other, that is not ideal use of the dual-camera set up, but could be used in conjunction with a higher-level fusion software to produce a single estimate. Setting up / running dual (independent) QVIO is the easier part, but then fusing that information is more complicated. However, we do not have any support of this approach (mainly because it has limited value).
- if you REALLY want to try this approach, i can help you set it up (running two instances of QVIO and publishing the independent QVIO outputs), but would not be able to provide further guidance on actual fusing the outputs of the two instances of QVIO. Please note that we have not done this recently, so there could be some complications that i am not aware of. So there is some risk involved here.
- We are currently working on dual-camera VIO solution (using open vins), but it is not officially released yet. I will check the timeline for that..
Alex
-
@Alex-Kushleyev Thanks Alex. I anticipate challenges in the fusion part for sure.
Regarding two camera based VIO using open vins, Any initial results you can share like it's performance as compared to QVIO?Also this will be part of future SDK releases and I hope we would be having full control over the codebase as a user? Timelines would be highly appreciated. -
@Aaky , I just checked the status of open vins and we are currently testing it on several drone configurations (using Starling drone) using single and dual cameras. However, the main issue is that documentation for using openvins on voxl2 in not ready, so we cannot really support it until the project is formally released. I don't have the ETA for the release - if I find out something, I will definitely let you know.
Alex
-
@Alex-Kushleyev Thanks for providing the status Alex. Can I get a prerelease version of open vins? Even that might be fruitful. I can figure out the bringup and executing it on VOXL2.
-
@Aaky , I know this would be an exciting feature to get your hands on, but unfortunately we cannot release it until it is ready with documentation. We need to get it to a point that there is enough documentation so that it can be set up and tested without additional support, otherwise the support process will become very inefficient.
Our goal is to make the open vins application available with the next major SDK release, but I do not have the ETA yet (we are at the SDK 1.3). So it would be SDK 1.4 or whatever the next one will be called..
Alex
-
@Alex-Kushleyev No problem Alex. Let me know once it's released. Thank you!
-
@Alex-Kushleyev Sorry to bug you again but is there any update on SDK releases with dual cam openvins?
-
@Alex-Kushleyev On a seperate note, Wanted to discuss one more point on dual cam QVIO pipeline itself.
Is there a real need to actually fuse the dual qvio instances odometry into PX4 together? Can they be mutually exclusive? Something like say if one qvio instance is failing, only then fuse second qvio's odometry? Since EKF in PX4 operates in global coordinate system and it shouldn't matter to EKF from which source the fusion is actually happening. Say this backup fusion source is present as a switch in voxl-vision-hub package which only sends the fusion source whenever needed to PX4 but only one at a time. Also while changing the source, we can set reset_counter flag which has good handling now in PX4 1.14 firmware. Any thoughts on this quick approach? (I aspire to get myself onto openvins anyways for dual cam due to more control over software pipeline but I am anticipating some delay in release so asking for this alternative)
-
@Alex-Kushleyev Sorry to bug you again. Actually I have urgent customer requirements which could be fulfilled with robust VIO which I feel is going to be with dual cam open vins approach.
- So I wanted to check with you if there is any update over dual cam open vins release?
- Also I have started my study over open source open vins algorithm and also would like to know some insights if there would be any modifications in open source open vins codebase or general camera and IMU driver integration?
- Dual camera part would need frame synchronisation if I am not wrong so is that part also handled in current open vins work?
It would really give me some pathway for further work if you can shade some light over here. Thank you!
