Drone Image Processing in Drone Tasking Manager

[nrjadkry]

Overview

We are at a crucial stage of our project where we need to determine the best approach for processing drone images. These images, collected from various drone missions, need to be processed efficiently and accurately. We need to figure out how are we going to process those Images. Open Drone Map (ODM) appears to be a strong candidate for this task.

This discussion is created to determine the best approach for using ODM in Drone Tasking Manager.

We can have different way of integrating ODM in the DroneTM. Some of the options can be:

1. Integrating WebODM.

WebODM is a user-friendly interface for Open Drone Map. It offers an API that can be utilized to process images, manage tasks, and retrieve results.

• We can add the webodm service within the DroneTM but it requires high server specs.
• We can also allow users to add their own wed odm credentials when creating the project like we do in fmtm for ODK.

Benefits

Simplifies the integration process with a higher-level interface and offers a web-based management tool.

2. Integrating ODM CLI.

The ODM CLI provides direct access to the core functionalities of Open Drone Map, allowing for more granular control over the processing pipeline.

• Directly use the ODM CLI within our system for processing images.
• Manage the execution and handling of CLI commands programmatically.

Benefits

Provides more control and flexibility over the processing workflow and can be tailored to specific needs.

Discussion Points

Pros and cons of integrating WebODM vs. using ODM CLI.
Potential challenges we might face with either approach, including scalability, error handling, and maintenance.
Other solutions or tools we should consider for processing drone images.
Best practices for managing user credentials (webodm creds) securely within the system.
Experiences and insights from anyone who has implemented similar solutions.

[ramyaragupathy]

Initial thoughts: Integrating WebODM within the Drone TM seems feasible since it saves a lot of time and effort on thinking of a UI/UX that works best for image processing. Also the learning curve could be less for people who are already familiar with the tool.

[sijandh35]

I am also quite inclined towards using WebODM as we can connect to it using basic auth, which returns a token that can be used with other APIs. My only concern is how WebODM handles images from our S3 storage. Is there a direct connection mechanism with S3 for WebODM, or do we have to download the images from S3 for processing, which will be time-consuming due to the large size of the images.

[nrjadkry]

I am also inclined towards integrating webodm. Like in the fmtm, we could allow users to add their webodm credentials. I would love to hear your thoughts in this @spwoodcock @ivangayton

[ivangayton]

Of course we should integrate WebOSM, but as a self-hosted instance, not using their commercial service! So we don't need to interact with WebODM commercial users' credentials.

[ivangayton]

I suppose it would make sense in some circumstances for project creators to specify an external ODM instance.

[spwoodcock]

Exactly like FMTM's usage of ODK Central then 👍

[spwoodcock]

Integrating it would be nice!

Just like with FMTM and ODK Central, it's a very tight integration.

Having them on the same server makes our lives significantly easier too - we can process imagery a lot quicker over a local network. Also, if necessary we could have an rsync service to copy files between containers (if ODM can process the files on disk better)

[spwoodcock]

As we also host the S3 in the same network, we could work directly with the files and avoid many HTTP requests entirely

[spwoodcock]

Should I look into adding it to the compose stack? (I like challenges like this 😁)

[nrjadkry]

Should I look into adding it to the compose stack? (I like challenges like this 😁)

Yes please, if you have got time. Else, I am also happy to try it out.

[spwoodcock]

I made a PR starting the ODM integration:
#116

Summary

• WebODM should be bundled as optional (in future), to more easily view and manage processing workflows.

• NodeODM is bundled for the actual processing. It's pretty lightweight at idle, but takes a lot of CPU during processing. We should allow the containers to scale as needed.

Uploading Imagery For Processing

At the start we could just have users go to the bundled WebODM, but this is a bit inefficient. Users would have to download all imagery from S3, then reupload via the WebODM UI.

The more efficient solution is to use the existing zipUrl param on the NodeODM API.
This allows us to point to a remote zip to process, but to do that the images must be zipped on S3 for the project...

Option 1: use zips. But as we can't update zip files in an object store (S3) in place, it's a bit inefficient to write all files to S3, download at the end to zip them, then re-upload. We can do better - needs research / thought. Not a good option for viewing the files directly in a web frontend, for example for image validation (can't stream zips easily, but cab stream jpg data)

Option 2: explore the NodeODM API endpoints and options further. I haven't done this yet. Perhaps we just mount the Minio docker volume to the NodeODM worker where it can pick up the files directly from disk.

This option raises a bigger question about storing the imagery via Minio S3 on-disk. That's not a sustainable solution. We probably need external S3 once we are outside the POC phase.

Option 3: consider using something like https://github.com/freegroup/kube-s3 to mount the S3 bucket as local file storage in the NodeODM container. Although this approach is limited to use only in Kubernetes. We will probably deploy to prod using Kubernetes, but shouldn't require all users/deployments to need to. One option to use set the default install to use K3S instead of docker compose.

Option 4: we contribute to NodeODM with a PR to support processing from an S3 bucket. This is a feature requested multiple times, so I'm sure the community would appreciate it.

Output Processed Imagery

NodeODM has config options to output the final processing result to an S3 bucket, so this isn't an issue 😄