Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Steep feature dropoff every maxFeatureAge #71

Closed
violetteavi opened this issue May 12, 2020 · 1 comment
Closed

Steep feature dropoff every maxFeatureAge #71

violetteavi opened this issue May 12, 2020 · 1 comment

Comments

@violetteavi
Copy link
Contributor

Description:
I was examining the Jupyter notebooks in Kimera-Evaluation when I noticed something strange. The feature count hovers around 300, then has periodic dips to as low as 100 features. After doing a little sleuthing, I discovered that these dips happen every maxFeatureAge number of keyframes, regardless of other factors. I suspect that when you initialize many features at once (like on startup or after a period of motion blur), they all expire at once and must be replaced. I suspect that the only features still being tracked at that point are ones generated from motion-- old features falling out of frame and being replaced by new ones.

Command:

roslaunch kimera_vio_ros <offline launch file>
jupyter notebook

Additional files:
Here are the feature graphs for a maxFeatureAge of 25, varying the intra_keyframe_time. Note that the periodic spikes always coincide with a multiple of 25 keyframes.
intra_keyframe_time = 0.2
TrackerSpikes02Keyframe
intra_keyframe_time = 0.12
TrackerSpikes012Keyframe
intra_keyframe_time = 0.1
SpikesWith01Keyframe
intra_keyframe_time = 0.05
TrackerSpikes005Keyframe

Console output:
I also ran the same inputs, but online. Here's a sample of the timing output. Note the huge disparity between max and average time-- I suspect this is because every maxFeatureAge of keyframes, a large number of features die off and must be recomputed.

-----------                        #	Hz	(avg     +- std    )	[min,max]
Data Provider [ms]            	      0	
IMU Preintegration Timing [us]	    661	29.0218	(70.9395 +- 31.0521)	[25,400]
Mesher [ms]                   	     56	2.48127	(0 +- 0)	[0,0]
VioBackEnd [ms]               	     56	2.48136	(48.125 +- 32.0806)	[1,154]
VioFrontEnd [ms]              	    660	28.8361	(27.3697 +- 29.9491)	[5,163]

Please give also the following information:

  • SparkVio branch, tag or commit used: master
  • SparkVioRos branch, tag or commit used: sequential rosbag
  • GTSAM version used:
  • OpenGV version used:
  • OpenCV version used:
  • Operating system and version (e.g. Ubuntu 16.04 or Windows 10): Ubuntu 18.04
  • Did you change the source code? (yes / no): yes, extra launchfile and for online changed publishing rate
@violetteavi
Copy link
Contributor Author

One possible solution would be to cap the number of new features added per keyframe. This would smooth out the dropoff across several keyframes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants