Forums - Important mvVISLAM Parameters and Performance Notes

1 post / 0 new
Important mvVISLAM Parameters and Performance Notes
jackdoc Moderator
Join Date: 14 Nov 16
Posts: 59
Posted: Mon, 2018-01-08 10:26
A few parameters may significantly impact the performance of the mvVISLAM algorithm (part of the Machine Vision SDK). The purpose of this post is to increase awareness of these parameters, provide some insight into their purpose, and to explain how to set them when using Snapdragon NavigatorAdditionally, a few other topics concerning mvVISLAM initialization are mentioned at the end of this post.
 
Some parameters affect the initial convergence of mvVISLAM, which impacts the overall drift in the estimated pose. In particular, see the following documentation from the mvVISLAM.h header file:
 
logDepthBootstrap: Initial point depth (log(meters)), log is natural log. By default, initial depth is set to 1m. However, if e.g. a downward facing camera on a drone is used and it can be assumed that feature depth at initialization is always e.g. 4cm, then we can set this parameter to 4cm (or -3.2). This will improve tracking during takeoff, accelerate state space convergence, and lead to more accurate and robust pose estimates.
 
useLogCameraHeight: Use logCameraHeightBootstrap instead of logDepthBootstrap.
 
logCameraHeightBootstrap: Initializes point depth based on known geometry, assumes (1) camera pointing partially at ground plane and (2) board/IMU aligned with gravity at start (= accel measures roughly [0, 0, -9.8] in units of m/s^2), required input is camera height over ground (log(meters)), log is natural log.
 
Understanding when to use logDepthBootstrap versus logCameraHeightBootstrap and how to set these values appropriately can improve the initialization of mvVISLAM and has the potential to reduce the amount of odemetry drift observed.
 
Other parameters impact mvVISLAM performance during normal operation. One such parameter to be aware of is given below along with its description from the mvVISLAM.h header file:
 
limitedIMUbWtrigger: If difference in one of the dimensions of consecutive accelerometer samples exceeds this threshold, IMU measurement noise is increased (also, chance of reset is increased); motivation: prevent tracking failure during/right after landing; risk: if platform vibrates heavily during flight, this may trigger mid- flight; check accelerometer readings if mechanical dampening should be improved (and/or if this threshold should be increased) \n RECOMMEND:  35 (m/s^2)
 
The default threshold for limitedIMUbWtrigger may be reached for certain mechanical designs, which could lead to poor estimation performance and mvVISLAM resets during flight.
 
Snapdragon Navigator exposes many Machine Vision SDK parameters through its XML configuration files. The parameters for mvVISLAM are defined in /etc/snav/app_params.snav_dft_vio_app.xml. Note that many parameters appearing in this file directly correspond to parameters defined in the Machine Vision SDK, so you can find more information about them in the mvVISLAM.h header file. For example, the mv_vislam_use_log_camera_height parameter defined in the app_params.snav_dft_vio_app.xml file corresponds to the useLogCameraHeight parameter defined in mvVISLAM.h.
 
In addition to the parameters mentioned above, there are other things to consider when attempting to get the best possible performance out of mvVISLAM. A good camera calibration performed specifically for a given camera has the potential to significantly reduce the overall odometry drift. Snapdragon Navigator reads the downward camera calibration from /etc/snav/calibration.downward.xml. Furthermore, rich motion just after mvVISLAM starts can accelerate the state space convergence and lead to lower drift. For the drone application, rolling/pitching and high linear accelerations are good types of motion for mvVISLAM convergence.
  • Up0
  • Down0

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.