M0149 camera refocusing and tuning parameters
-
@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!
