OpenDroneMap(opendronemap.org)
opendronemap.org
OpenDroneMap
https://www.opendronemap.org/
65 comments
Lovely! Try bumping --mesh-octree-depth by 1 or 2 for sharper models. Also if you're capturing photos in motion, definitely enable --rolling-shutter which will help compensate for the rolling shutter distortion of the DJI Mini 2's camera (it will take a bit longer to process though).
How does it compensate for rolling shutter? Out of curiosity :)
It implements the method outlined in "A two-step approach for the correction of rolling shutter distortion in UAV photogrammetry" by Y. Zhou and others: https://www.sciencedirect.com/science/article/abs/pii/S09242...
The Python code is probably easier to understand: https://github.com/OpenDroneMap/OpenSfM/blob/287/opensfm/act...
The Python code is probably easier to understand: https://github.com/OpenDroneMap/OpenSfM/blob/287/opensfm/act...
Cool idea, which I've wanted to exist (so I'm glad it does). I have two suggestions for improving the site:
1) The huge list of software in the ecosystem is overwhelming. Bury it. The choice of picking the two alternative ways of running it at the top is fine, but that's all the front page should have to say about software.
2) Critically, on the front page you need a quick demo or diagram showing how you get data into it. As a potential user, I really don't care about the open ecosystem or joining a community (this is good content for a "Developers" tab) - instead I want to know how much effort it's going to take me to capture the images and turn them into a cool map. What software does the drone need to run? Can you push video into ODM and get a map out, or do I need to preprocess those images? How far can I go with it, and how are those results achieved? Do I need to be a developer or can I be a semi-technical drone operator? FPV drones ok, or just DJI? Etc etc.
1) The huge list of software in the ecosystem is overwhelming. Bury it. The choice of picking the two alternative ways of running it at the top is fine, but that's all the front page should have to say about software.
2) Critically, on the front page you need a quick demo or diagram showing how you get data into it. As a potential user, I really don't care about the open ecosystem or joining a community (this is good content for a "Developers" tab) - instead I want to know how much effort it's going to take me to capture the images and turn them into a cool map. What software does the drone need to run? Can you push video into ODM and get a map out, or do I need to preprocess those images? How far can I go with it, and how are those results achieved? Do I need to be a developer or can I be a semi-technical drone operator? FPV drones ok, or just DJI? Etc etc.
These are great suggestions, thanks! I'll see if we can make some improvements.
I've been trying to get my organization to use ODM, but finding it difficult. The problem is analogous to the issues that Gimp has to Photoshop or Linux to Windows -- ease of use. Additionally, even if you properly configure the software the quality still is not comparable to the big proprietary players in the photogrammetry field: Bentley Systems; Pix4D; Drone Deploy.
A major reason for the quality issues is that the major drone manufacturers work directly with the proprietary photogrammetry software providers in the field to optimize the algorithms to their drones. These drone manufacturers then promote these proprietary solutions. This puts ODM at a disadvantage as there is no short-term financial incentive for manufacturers to promote ODM.
Like other fields, the proprietary photogrammetry industry is increasing moving to implementing their solutions exclusively in the cloud. This is forcing folks to give up their data and building a data moat - a problem for my organization.
I hope ODM keeps developing and becomes as ubiquitous as linux. Its quality is getting close for my organization to consider its implementation. Keep up the great work!
A major reason for the quality issues is that the major drone manufacturers work directly with the proprietary photogrammetry software providers in the field to optimize the algorithms to their drones. These drone manufacturers then promote these proprietary solutions. This puts ODM at a disadvantage as there is no short-term financial incentive for manufacturers to promote ODM.
Like other fields, the proprietary photogrammetry industry is increasing moving to implementing their solutions exclusively in the cloud. This is forcing folks to give up their data and building a data moat - a problem for my organization.
I hope ODM keeps developing and becomes as ubiquitous as linux. Its quality is getting close for my organization to consider its implementation. Keep up the great work!
Are you aware of solutions like Alicevision/Meshroom (MPLv2)?
https://alicevision.org/
https://alicevision.org/
Thanks for championing ODM! :) It's true that proprietary systems have had a lead in development for a long time, but especially of late the software has gotten really good. If you haven't tried the software in a while, I'd recommend updating and giving it another try.
The quality issue is an interesting one; I remember having a discussion with a client that was considering transitioning away from Bentley's ContextCapture (CC) and they mentioned that CC was generating much denser point clouds compared to ODM. CC tends to generate very good looking point cloud models, except its algorithms extract points from a mesh interpolation approach, so sometimes you end up with points where geometrically there shouldn't be any. Sure they look good, but is that "good" quality?
The quality issue is an interesting one; I remember having a discussion with a client that was considering transitioning away from Bentley's ContextCapture (CC) and they mentioned that CC was generating much denser point clouds compared to ODM. CC tends to generate very good looking point cloud models, except its algorithms extract points from a mesh interpolation approach, so sometimes you end up with points where geometrically there shouldn't be any. Sure they look good, but is that "good" quality?
> A major reason for the quality issues is that the major drone manufacturers work directly with the proprietary photogrammetry software providers in the field to optimize the algorithms to their drones.
Would you care to elaborate? My belief is that all the photogrammetry engine wants is that the drone manufacturer does as few processing as possible on the images, in order to not alter the geometry. I don't see what kind of algorithms coming from the drone manufacturer would help, and therefore I don't see how that's a problem for ODM.
Would you care to elaborate? My belief is that all the photogrammetry engine wants is that the drone manufacturer does as few processing as possible on the images, in order to not alter the geometry. I don't see what kind of algorithms coming from the drone manufacturer would help, and therefore I don't see how that's a problem for ODM.
Direct knowledge of the lens distortion model and complete control of the image generation, with perfect knowledge and use of the associated metadata tags, can certainly give an engine a leg up in some cases. One example I can think of is the Parrot Sequoia which is a camera that works OK-ish in ODM, but works flawlessly with Pix4D (which is owned by Parrot).
But none of that is private data, right? It feels like "tuning". Surely one could characterise Sequoia to improve the camera model, and I doubt they encrypt the exif data, do they? Also Sequoia is a bit of a special example here, that most likely has been carefully tuned by Pix4D. But DJI most probably does nothing for Pix4D that ODM couldn't access.
Not criticising ODM (I love OpenSfM and ODM), on the contrary: I feel like those are not fundamental limitations of ODM, and one could put the work of improving support for specific cameras without the need for proprietary information available only to Parrot employees.
Or am I missing something?
Not criticising ODM (I love OpenSfM and ODM), on the contrary: I feel like those are not fundamental limitations of ODM, and one could put the work of improving support for specific cameras without the need for proprietary information available only to Parrot employees.
Or am I missing something?
EXIF data is not encrypted, but often times is not documented (or documented well). DJI has many differences between models (even between firmware versions). They also sell DJI Terra, which is their own photogrammetry solution.
The point being that you are correct, these are not limitations of ODM, but in some cases it does give vendors a head start (a leg up) in implementing good support for certain cameras, especially multispectral cameras like the Sequoia.
The point being that you are correct, these are not limitations of ODM, but in some cases it does give vendors a head start (a leg up) in implementing good support for certain cameras, especially multispectral cameras like the Sequoia.
This is a very cool software! I highly recommend to try it out if you own a drone, even if just for a fun, I learned so much when I was tinkering with it.
Around a year ago I needed to obtain an aerial map of some specific area, but due to recent drastic changes (construction work) and poor quality of the public maps I had to somehow create my own. I fly drones for recreational purposes so I was thinking about using it to make that map when I found out about ODM which is exactly what I was looking for. ODM itself just processes already obtained images (AFAIK) so there is also a whole process of getting them from drone. That's when I found about other software for planning fully automated flight paths so there is a perfect overlap between the photos (required for quality maps and 3D reconstruction). I managed to make a high quality map with 1px:1cm ratio via ODM that I still use from time to time.
Like I mentioned if you own a drone I would recommend to try it out even if it's just for fun as for my case I learned a lot of other stuff I didn't knew before like that automated flight path planning.
Around a year ago I needed to obtain an aerial map of some specific area, but due to recent drastic changes (construction work) and poor quality of the public maps I had to somehow create my own. I fly drones for recreational purposes so I was thinking about using it to make that map when I found out about ODM which is exactly what I was looking for. ODM itself just processes already obtained images (AFAIK) so there is also a whole process of getting them from drone. That's when I found about other software for planning fully automated flight paths so there is a perfect overlap between the photos (required for quality maps and 3D reconstruction). I managed to make a high quality map with 1px:1cm ratio via ODM that I still use from time to time.
Like I mentioned if you own a drone I would recommend to try it out even if it's just for fun as for my case I learned a lot of other stuff I didn't knew before like that automated flight path planning.
So it is basically just footage from GoPros strapped to drones, and not something requiring building BetaFlight/iNav with a new feature?
Without any idea how to do anything, I was able to use the cheapest DJI drone (Mini 2) and ODM to stitch together a giant orthophoto of my parent's maple sugar bush. It overlays extremely nicely over Google Maps without any ground control points. The resolution is such that one can pick out individual buckets on each tree.
This is _very_ cool software and I've started making maps of my own property every ~month or so just to see how things change. I started by manually flying missions and eyeballing where to take photos, and everything worked great. I see other mentions here that say the "capture" part can be done for free by PIX4D, I ended up paying for Dronelink to do the same thing.
It's much nicer to have a consistent mission so things always come out the same, and way more efficient to have the software handle where to take the photos. Having the overlap in both directions taken care of is very nice. Now I just sit back and make sure nothing crazy happens (e.g. strong winds) and swap the battery out when it dies before resuming the mission. SO neat!
This is _very_ cool software and I've started making maps of my own property every ~month or so just to see how things change. I started by manually flying missions and eyeballing where to take photos, and everything worked great. I see other mentions here that say the "capture" part can be done for free by PIX4D, I ended up paying for Dronelink to do the same thing.
It's much nicer to have a consistent mission so things always come out the same, and way more efficient to have the software handle where to take the photos. Having the overlap in both directions taken care of is very nice. Now I just sit back and make sure nothing crazy happens (e.g. strong winds) and swap the battery out when it dies before resuming the mission. SO neat!
I found it neat that it really can make use of all the cpu and memory you can throw at it. I used it to stich around 1000 photos, and watched as it maxed my 32 cores and 64gb ram in my workstation for hours.
I wanted to annotate a map of my property to keep track of the fruit trees I am planting. Google maps resolution for the area is extremely low, but a basic DJI drone, pix4d capture (free for capture) and ODM can give you a nice detailed imagery with very little work. The difference was being able to see a stand of trees vs individuals.
I wanted to annotate a map of my property to keep track of the fruit trees I am planting. Google maps resolution for the area is extremely low, but a basic DJI drone, pix4d capture (free for capture) and ODM can give you a nice detailed imagery with very little work. The difference was being able to see a stand of trees vs individuals.
It's great, but several times it does fall back to single threaded performance. I regularly use it to generate photos of hundreds of acres, and I end up needing a machine with more RAM and less CPU.
Yep, RAM is usually the bottleneck for processing larger datasets. We do have a divide-and-conquer approach to push the limits of your hardware though: https://docs.opendronemap.org/large/
I found, in practice, that the divide and conquer approach led to weird altitude artifacts, where different divisions would result in different heights, so the point clouds didn't line up. Could have been a one off bug though.
It can happen; point cloud alignment between submodels can be tricky. Sometimes increasing the amount of split overlap can help, but not always.
Amazing piece of software! I've a question. It's a bit unclear to me, is there a global adjustment applied to the sub-blocks that would help with the overlap issues?
There is; the alignment uses affine transformations, but it cannot account for certain cases (e.g. severe bowling effects). It's an interesting area of research.
I use ODM to map large areas (100-300) acres regularly. It's pretty much fire and forget on AWS spot instances.
Combined with Dronelink, my workflow is largely automated. Just a few more pieces I'd need to have in place to be able have it be more or less hands off.
The next piece I want to tackle is creating a watched directory or S3 bucket that automatically spins up a spot instance, monitors for the completeness of the work, downloads the results to S3, and shuts down the spot instance. Then all I'd have to do is watch the drone fly and move photos into a folder.
Combined with Dronelink, my workflow is largely automated. Just a few more pieces I'd need to have in place to be able have it be more or less hands off.
The next piece I want to tackle is creating a watched directory or S3 bucket that automatically spins up a spot instance, monitors for the completeness of the work, downloads the results to S3, and shuts down the spot instance. Then all I'd have to do is watch the drone fly and move photos into a folder.
Something like https://github.com/hobuinc/codm ? :)
Time to read up on this and AWS Batch!
By coincidence I tried this last week; it really is pretty impressive.
The one thing I missed is some intros/guidance on how best to take photos to feed it; which angle, how much spacing, any tools to use in flight etc. I got pretty good results with my first run but was going to blindly experiment to see if I could improve it. Any tips?
The one thing I missed is some intros/guidance on how best to take photos to feed it; which angle, how much spacing, any tools to use in flight etc. I got pretty good results with my first run but was going to blindly experiment to see if I could improve it. Any tips?
https://docs.opendronemap.org/flying/
We might need to put this page in a more visible place.
We might need to put this page in a more visible place.
I've only done a handful of captures, but found this to be a reasonable guide:
https://help.dronedeploy.com/hc/en-us/articles/1500004964282...
I use the pix4d capture app for setting the flight path. It can be used to just do the capture part for free, where as their paid product can also do the stitching for you but seems prohibitively expensive for a non-professional who just wants to make a small number of maps.
https://help.dronedeploy.com/hc/en-us/articles/1500004964282...
I use the pix4d capture app for setting the flight path. It can be used to just do the capture part for free, where as their paid product can also do the stitching for you but seems prohibitively expensive for a non-professional who just wants to make a small number of maps.
What did you use it for? Agree on the intros, I have a DJI drone but have no idea how I'd use this software. Does it install on my controller, do I fly in a special way?
I love this software. We recently purchased 60 acres of former Weyerhaeuser Forest land with nothing on it except a logging road. Used my air2s to map it (using DroneLink as flight planning software [thank you DJI for finally releasing the SDK]) taking over 2000 images and stitching it all together with ODM, which I can then import into QGIS as a GeoTiff. From there I can add roads and buildings for our building sites. Plan is to map the property after something gets added, like roads, the well, clearing land, solar farm, outbuildings, so we can view the progress over time. The 3d capabilities are also pretty wild, which I import into Blender3D and can make little movies with. After the solar field is put in we will be using it for remote solar panel inspection as well.
OpenDroneMap co-founder here: happy to see this on HN and to answer any questions.
Very cool! I noticed AGPL 3 License, do you offer licensing options if folks want to host this integrated with other closed source code? Or would it be permissible to create a "microservice" with ODM only that closed source software can use API calls to contact?
Are maps created by the OpenDroneMap community catalogued anywhere? I may have missed the obvious answer, but only found docs about creating maps (which is, of course, extremely cool!).
Here's also a few example maps compared side by side with other software: https://opendronemap.github.io/UAVArena/
I haven't seen a list, but here's a set of well known datasets: https://www.opendronemap.org/odm/datasets/
Some of them include the resulting imagery.
Some of them include the resulting imagery.
Cool. Looking forward to checking these out.
This is really cool, just took my drone out and took 64 pics of my neighborhood and turned them into a TIFF viewable on qGIS via the ODM CLI. Love it. There are a few oddities, for example it produced a few geoTIFFs for viewing, two of them are correctly placed, but the high resolution one doesn't seem to contain geo bounds and just displays in qGIS adjacent to the world map. Seems like there's still some development to be done, but this seems like a really cool and interesting project. Excited to see where it goes from here!
edit: the above was user error (or my lack of patience waiting on the high-rez final photo to load!), everything works wonderfully.
edit: the above was user error (or my lack of patience waiting on the high-rez final photo to load!), everything works wonderfully.
Glad you like it! :) Is this the odm_orthophoto_render.tif file? If so, that's normal. That file is not a higher resolution image, it's just an intermediate file that doesn't have georeferencing and compression. The final georeferenced image, odm_orthophoto.tif, by default is cropped to the bounds of the model and you can disable that by passing "--crop 0". The two images will look identical without crop.
Very interesting, thank you! i mostly drone as a hobby to get some interesting shots, so this is my first foray into using it to do anything like this. Indeed I am talking about odm_orthophoto_render.tif, I assumed it was the higher resolution one because of the size (about 3x the size of the other two), and qGIS was not treating odm_orthophoto.tif well, but after closer inspection looks like qGIS just didn't like odm_orthophoto.tif because it was having trouble loading it full resolution, but it did end up loading it correctly if I gave it a few more moments to load, and works really well!
Thanks so much for the ad hoc tech help, will definitely be playing with this more!
Thanks so much for the ad hoc tech help, will definitely be playing with this more!
Welcome!
You can also use --build-overviews for speeding up load times in QGIS or --cog for generating Cloud Optimized GeoTIFFs that both open fast in QGIS and can be streamed fast over HTTP.
You can also use --build-overviews for speeding up load times in QGIS or --cog for generating Cloud Optimized GeoTIFFs that both open fast in QGIS and can be streamed fast over HTTP.
Love it!, i’ve flown my dji mini2 for exploration porpoises and got decent cartography with ODM i used later some abseiling and the measurements where off by 2 mts (not bad since the GPS wasn’t RTK or similar)
What sort of setups does this support? What drone models and firmware? What sort of cameras are supported? Quads? Fixed? DJI? Betaflight? Ardupilot? Does it need a camera with a gimbal?
The nice thing is that the drone is completely independent :-). You can use any frame (quad, heli, fixedwing, vtol, rover, boat, submarine, ...) with any autopilot (betaflight, ardupilot, px4, ...) and try it with any camera you want.
At the end of the day, all you need is pictures taken "the right way" for the engine. Typically, you want:
* Sufficient overlap between the pictures: you need multiple pictures looking at each point in the scene from different angles. * Don't change the focal length, because that changes the camera model and makes it at least harder for the engine. * Ideally have some fairly accurate GPS location in the exif metadata of the pictures. * Avoid motion blur (i.e. don't fly too fast for your camera), and blur in general (i.e. you don't want too much vibration, but you don't need a gimbal).
Some Android/iOS apps out there do "flight planning" for you, so it may help (you select the area you want to map and the app instructs the drone to take the right pictures for you). Different apps support different drones, so that's something you want to check.
But anyway you should try ODM, because it does not depend on the drone, it just needs pictures =).
Hope this helps.
At the end of the day, all you need is pictures taken "the right way" for the engine. Typically, you want:
* Sufficient overlap between the pictures: you need multiple pictures looking at each point in the scene from different angles. * Don't change the focal length, because that changes the camera model and makes it at least harder for the engine. * Ideally have some fairly accurate GPS location in the exif metadata of the pictures. * Avoid motion blur (i.e. don't fly too fast for your camera), and blur in general (i.e. you don't want too much vibration, but you don't need a gimbal).
Some Android/iOS apps out there do "flight planning" for you, so it may help (you select the area you want to map and the app instructs the drone to take the right pictures for you). Different apps support different drones, so that's something you want to check.
But anyway you should try ODM, because it does not depend on the drone, it just needs pictures =).
Hope this helps.
Pretty much any camera (even multiple cameras), from any orientation (no gimbal required). Also works with your cellphone camera or DSLR camera. Just try not to change the focus between shots too much. DJI models are well supported.
Are DJI models the only ones supported?
Nop, you can use pretty much any drone camera.
i highly highly recommend trying Colmap if you like ODM. it's not suitable for drone footage by itself (it works but why), but it has amazing performance for just handheld video walkthroughs or if you have a lot of geotagged photos. basically the next generation / natural extension of the original Bundler that brought open source unstructured SfM to the mainstream. not photo realistic or anything but very usable for most practical applications.
Colmap is pretty amazing. It takes about 6-10x longer to run when you max everything out, but it does things no other software has managed to do for me.
That said, I made our drone photogrammetry pipeline with ODM and I wouldn't use colmap.
There's still some annoying things that no software can seem to do: with a single camera, I'd love to create a 3D map of a road. But no matter how much overlap of photos I get, (I mounted a stabilized GoPro to a truck and took video, than pulled together geotagged stills) for some reason I could never get a good point cloud out of that data. Even colmap. Colmap does it's absolute best if you walk around in a circle with a common central point of focus. It's frustrating because I KNOW the 3D information is there. I can see it. Plenty of features to match. But for some reason this seems to be a hard task for current SFM libraries.
That said, I made our drone photogrammetry pipeline with ODM and I wouldn't use colmap.
There's still some annoying things that no software can seem to do: with a single camera, I'd love to create a 3D map of a road. But no matter how much overlap of photos I get, (I mounted a stabilized GoPro to a truck and took video, than pulled together geotagged stills) for some reason I could never get a good point cloud out of that data. Even colmap. Colmap does it's absolute best if you walk around in a circle with a common central point of focus. It's frustrating because I KNOW the 3D information is there. I can see it. Plenty of features to match. But for some reason this seems to be a hard task for current SFM libraries.
I can chime in on the road: there's probably insufficient color variation and that gets filtered out during patch-match. You can relax the NCC Threshold parameter and you should be able to reconstruct the road (you'll also get more outliers in other areas though). There might be an option in COLMAP to do that. In ODM you need to modify the fNCCThresholdKeep parameter in OpenMVS (you'll need to recompile OpenMVS).
That's an interesting idea. I'm a bit skeptical though, since these were dirt and gravel forest roads with lots of different colors and apparent features.
Exciting project and I'm a proponent. I'm curious about privacy aspects and how they're are handled. I didn't see anything in my cursorily glance at the website.
For example if neighbor complains about their land being mapped. I don't even know if it's a justifiable complaint. I'm sure it depends on the local laws.
I guess my question is, how is this project (or drone pilots) going to defend against lawsuits. (if they occur) (seems inevitable)
For example if neighbor complains about their land being mapped. I don't even know if it's a justifiable complaint. I'm sure it depends on the local laws.
I guess my question is, how is this project (or drone pilots) going to defend against lawsuits. (if they occur) (seems inevitable)
This is (mostly) governed by the FAA and their license granted to drone pilots [1]. Your concerns are also touched on by the FAA during the training [2]. Please consider that plenty of smart people have considered these same things before you comment.
1. https://www.faa.gov/uas/commercial_operators/become_a_drone_... 2. https://www.faa.gov/uas/commercial_operators/operations_over...
1. https://www.faa.gov/uas/commercial_operators/become_a_drone_... 2. https://www.faa.gov/uas/commercial_operators/operations_over...
> before you comment.
his question seemed clear and reasonable to me, which you answered well, minus your comment in the final sentence.
his question seemed clear and reasonable to me, which you answered well, minus your comment in the final sentence.
You know how there was the first airplane flight across America?
Then the first car driven across America.
Much later cycling, running, walking.
When is going to be the first drone flight across America?
Lots of technical and political hurdles.
I am sure the military has already done it, I mean at the consumer level.
Then the first car driven across America.
Much later cycling, running, walking.
When is going to be the first drone flight across America?
Lots of technical and political hurdles.
I am sure the military has already done it, I mean at the consumer level.
What are some algorithms involved in building a project like this?
The Colinearity Equation is a (the?) major backbone of most point cloud and photogrammetry algorithms
Structure from motion
What motivated the choice of AGPL license?
OpenDroneMap has dependencies on GDAL, Proj4J, GeoPackage, SciPy, Python, Nginx, and Django, among other packages. Those foundational libraries tend to have more permissive licenses (PSF, MIT, BSD 3-Clause, Apache 2.0 etc.).
OpenDroneMap has dependencies on GDAL, Proj4J, GeoPackage, SciPy, Python, Nginx, and Django, among other packages. Those foundational libraries tend to have more permissive licenses (PSF, MIT, BSD 3-Clause, Apache 2.0 etc.).
OpenDroneMap co-founder here: to make sure modifications to the software continue to be released as open source to end users. Other licenses allow companies to just take the software, modify it to their needs and not release those changes back. ODM is very suited for use in cloud environments, so the AGPL works very well here.
https://www.opendronemap.org/2020/12/ghost-busting-speed-imp... references https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
Here's a forum post covering the same issue: https://community.opendronemap.org/t/licensing-queries/6545/...
Disclosure: I'm not an opendronemap community member, so this is based on some googling only.
Here's a forum post covering the same issue: https://community.opendronemap.org/t/licensing-queries/6545/...
Disclosure: I'm not an opendronemap community member, so this is based on some googling only.
Thanks. Those are great links.
I'm mostly on a weekly basis capturing the progress of my home as it is built. I have a DJI Mini 2 and using Dronelink to create the missions. I was originally using DJI Flight Planner + Litchi but it's paths it was generating for the area I wanted to cover wasn't great and it forced my gimble to look straight down, I'm sure Litchi may have let me adjust that somewhere but I couldn't figure it out. I had 85% overlap but even with that, as the house started getting built ODM seemed to be unable to generate point cloud points for some of the walls thus resulting in large holes in the geometry. I switched to Dronelink which overall has been a much more user-friendly experience for the mission planning and it lets me control the gimbal angle. While my photo clarity isn't as great as now, my drone doesn't stop for each photo, having my camera angled slightly throughout the mission has greatly reduced the missing geometry in the outputted model. I've been very pleased with ODM thus far though the amount of settings in WebODM have been overwhelming and I've settled on just using the Default as it seems the best at giving me decent 3D geometry that is compressible in a GLTF format.
I'm working on a explorer to catalog the phases. https://crysin.github.io/new-construction-explorer/
Any suggestions on better ways to improve the output are welcome.