laxnpander
Frame poses with very large roll/pitch are not rejected causing excessive map sizes
If our tracking gets completely messed up and decides are frames are facing the horizon, the current system will still add them to the map. This drastically expands the map and can cause the system to run out of RAM and crash.
We should add one or more of the following:
- Limit the maximum amount of RAM or size of the map to prevent this
- Add a filter to avoid adding solutions with a high pitch/yaw
- Throw away any obviously bad matches inside OpenVSlam itself
Since the mapping system is expected to be used in a nearly NADIR configuration, setting up a rejection for images that are far off NADIR would likely be the most straightforward.
@zthorson: In general I agree, we only need to make sure that the "mapping plane" scenario is not affected. I'd like to see more people use it in plane configuration in the future as it is the better suited hardware for fast and large scale mapping in my opinion. One might argue that you won't use the images at the turning points anyway due to the large distortions, but I am not really experienced with planes. So not exactly sure how to design it flexible, yet robust.
@laxnpander We have flown quite a few flights with a PHX plane and run direct referencing on it. In our experience with it the images during a turn or more likely to be blurry as well as have much lower GSD than the user is interested in. We typically have thrown them out, or only used those at the beginning and end with the roll/pitch was less than 30 degrees.
That said, if you want it to be more general, it could be a user settable threshold. Say if the post comes back X degrees past NADIR, don't publish / use the frame for mapping or mosaics. Then if a user really wanted to use oblique imagery, they would just set the threshold higher.
However, heavily oblique images will still take a VERY large amount of RAM with the mosaic approach being used.