I am working on a project recording movement in an irregular outdoor space. I am doing 20+ minute recordings on iOS in a rugged, outdoor area with the phone attached to a person.
I am interested in a reliable and robust track without any drift, but I do not need much in terms of 3D scan results. I need just enough reference geometry to align multiple tracks together and align them to a photogrammetry scan of the same region. In the end I am taking the motion data into VFX tools (Blender -> Unreal Engine). I have been using some of the basic ARKit-based apps, but I have been having issues with crashing and lost data, overheating etc. It occurred to me that RTAB-Map may be just the tool. I have been testing the various settings and reading documentation but I was wondering if anyone could point me to best practices for this use case? Ideally biasing towards lowest possible RAM and performance, battery etc. impacts while capturing, with a reliable offline post-processing stage. Do you have any recommended best practices for this use case based on the iOS app on the App Store? |
Administrator
|
Hi,
To limit to maximum the RAM usage of the app (for longer scanning sessions), here some settings that can be changed: * Point Cloud Density -> Very Low * Point Size -> Can be increased (e.g. 30) to better see the cloud * Mapping -> Update Rate -> Set 0.5 Hz if you don't move fast or if you don't care having some holes in the resulting mesh * Mapping -> Max Features Extracted (Vocabulary) -> Can be reduced (e.g., 200) to decrease visual vocabulary size * Mapping -> Database in Memory -> Make sure this is disabled (default) By clicking the "Eye" bottom right button in the main view, set rendering mode to Point Cloud instead of Texture Mesh or Mesh. When you stop scanning, don't click on "Only Optimize" or "Yes" options, click on "Save First". I would then recommend to do post-processing using RTAB-Map Desktop app (File -> Export 3D Clouds...). After doing small tests here with these parameters, the RAM is still increasing almost 1 MB every 2 sec. With some small code modifications, we could save significantly even more RAM. With Android app, we can launch a "trajectory" mode that will show only the trajectory so far without any 3D rendering. I could check to bring that mode on iOS app. I created an issue about that. cheers, Mathieu |
Hi,
I’m very interested in this topic as well, particularly for scanning large indoor areas (such as barns) using an iPhone. I’m currently using the ‘data-recording’ mode of the iOS app, with typical scan durations ranging from 15 to 30 minutes, recorded at 2Hz. For our use case, obtaining a robust and accurate estimate of the pose trajectory is the highest priority. Since iOS already provides good odometry, the main focus seems to be on global loop closures (LTM?). Memory and optimization time are not major concerns for us. What are the best settings to use with the 'rtabmap-reprocess' command line tool to maximize accuracy? From my understanding, this set of settings appears to replicate what the iOS device does in normal mode, but it may not necessarily be the optimal configuration. Do you have any recommendations for achieving better results? |
Administrator
|
If you are reprocessing databases taken in Data Recording mode, use "-default" option to reprocess with RTAB-Map's default mapping parameters instead of the ones from the recorded database (tuned for recording). rtabmap-reprocess -default recorded_data.db output.db I updated my answer here with "-default" explicitly set, though I think the original answer was correctly setting back some parameters to defaults that were changed for recording mode. "Optimal" for loop closure detection is to use SURF or SIFT features. If you have rtabmap built with these features, you coudl do something like I commented in this post (here using SIFT): rtabmap-reprocess -default \ --Mem/UseOdomFeatures false \ --Kp/DetectorStrategy 1 \ --Vis/FeatureType 1 \ --Vis/CorNNDR 0.6 \ --Kp/NndrRatio 0.6 \ recorded_data.db output.db cheers, Mathieu |
Free forum by Nabble | Edit this page |