DJI Terra Cluster Reconstruction: Setup & LAN Guide

Decide whether a cluster fits the workload

A cluster is worth investigating when an organization repeatedly processes large supported tasks and has enough suitable resources to operate them reliably. It is less compelling when the main delay is poor input data, manual review or a small occasional job.

• List the required reconstruction methods and outputs.
• Measure the current workstation’s full project turnaround.
• Identify machines that can remain available during production runs.
• Assess the shared-storage and network workload.
• Include operator effort, maintenance and delivery review in the cost comparison.

More computers do not establish a fixed speed multiplier. Coordination, transfers and task stages can limit the benefit. Use our processing-time and optimization guide to establish a comparable standalone baseline.

For example, a team may have several capable workstations but only one slow shared disk. Test the whole system before assuming that unused CPU or GPU capacity is the only obstacle.

Confirm the current task, license and release together

DJI’s Terra 5.1 announcement states that Standard and Flagship include supported visible-light cluster reconstruction, covering aerial triangulation, 2D maps and 3D mesh tasks. It also describes a no-additional-license cluster route for Zenmuse L3 point cloud tasks.

The current cluster manual adds an essential deployment condition: visible-light cluster projects require a Standard-or-higher or applicable Cluster entitlement on all participating devices. A license on one computer does not automatically authorize every unlicensed workstation on the LAN.

The same manual lists no software-license requirement for its LiDAR point cloud cluster route. Verify the installed release and exact sensor, task and outputs before relying on that condition.

Selecting cluster computation does not distribute every step. The current scope table excludes DEM and contour generation from distributed computation; these run locally in the applicable task. Include the task-initiating device’s capacity when planning a terrain delivery.

DJI specifically notes that existing Cluster Edition workers require reconfiguration after the 5.1 upgrade. Read the current release documentation and our license guide before reusing an older installation.

Understand the controller, worker and storage roles

The current feature overview distinguishes the control device, worker devices and the device that initiates a task. In the recent architecture, the control device coordinates connections and scheduling. A control or worker device can submit the task and perform the relevant merging or local-only steps.

The current device-management instructions run DJI Terra on every participating computer. Older support FAQs describe DJI Terra Engine, which should not be substituted for the current deployment procedure.

Create a small inventory with device names, installed versions, CPU, RAM, GPU and working-storage capacity. Include the person responsible for updates and the expected availability of each machine.

For visible-light cluster tasks, check each device’s authorization, not only the group’s first computer. Storage supplies files and does not become a compute node merely because it is a powerful NAS.

Plan capacity, local working space and availability

Use the requirements for the installed Terra release and reconstruction method. DJI’s older cluster preparation material contains historical operating-system and graphics recommendations; those should not replace the current requirements when selecting new hardware.

Our System Requirements & Workstations guide provides the compatibility starting point. For a cluster, also document the differences between nodes rather than describing only the strongest computer.

• Check the RAM and VRAM required for the selected task.
• Provide sufficient local working space for each worker.
• Record free space before submitting a large mission.
• Keep unrelated workloads from competing unpredictably with the pilot.
• Plan stable power and cooling around the actual equipment.
• Review sleep, restart and maintenance schedules with the operator.

A worker that repeatedly becomes unavailable is not a reliable production resource. Base the pilot on the configuration that will actually be available during normal operating hours.

Do not treat RAM on separate machines as one simple shared pool. Record the task’s division behavior and any per-node limits in the installed release.

Separate shared data paths from local worker temporary files

The current network and shared-folder chapter distinguishes shared inputs and project outputs from local cache. Input access and project/output read-write access should match the purpose of each folder. The local cache is configured separately for each device.

• Keep source observations, outputs and local temporary files clearly identified.
• Verify access using the same credentials or process context used by the applications.
• Check read access to inputs and the required write access to output locations.
• Use consistent network paths across participants.
• Keep the worker’s local temporary directory distinct from the shared location.

A generic UNC example is \\storage-host\TerraProjects\SiteA. It illustrates a network path, not a required server name. Use the IP-based or named-host format supported by the current Terra instructions and the organization’s network configuration.

Avoid an arrangement in which a drive letter means one folder on the controller and a different folder on a worker. Test that every participant reaches the same intended files.

Check LAN throughput, addressing and software compatibility

Network and storage behavior can dominate a distributed job. Assess the actual route between controller, workers and shared storage, including switches and the storage connection. The slowest relevant link can limit the group.

DJI’s preparation guide discusses a wired 10-Gigabit environment as a throughput recommendation for substantial workloads. Treat bandwidth selection as an engineering decision around the measured data exchange, not a guarantee of a particular speedup.

• Use stable, non-conflicting addresses and reliable host resolution.
• Confirm the supported network arrangement for all participants.
• Install compatible controller and Engine components from official resources.
• Keep a record of software and driver versions.
• Ask IT to configure the necessary application access and network permissions.
• Record transfer behavior alongside compute time.

Follow the organization’s approved network configuration. Identify blocked application traffic precisely rather than making broad changes to security controls as a routine setup shortcut.

A cloud-hosted machine or remote office connection is not automatically equivalent to the documented local LAN. Validate any nonstandard topology and its support requirements before committing a production project.

Run a staged setup and a representative pilot reconstruction

Use a dataset whose standalone result has already been reviewed. The pilot should test access, task execution and delivery quality as well as elapsed time. Start with a small number of known workers and expand only after the basic arrangement works.

1. Record the task, software release, per-device entitlement and baseline settings.
2. Run compatible DJI Terra installations on the participating LAN computers.
3. Configure the shared paths and each device’s local cache location.
4. Open Device Management and enable the supported cluster arrangement.
5. Add the first device to create the group, then add the intended workers.
6. Set Computation Method to Cluster Computation for the supported task modules.
7. Submit the representative reconstruction and monitor its stages.
8. Review participation, transfers and final outputs against the equivalent standalone task.
9. Archive the accepted configuration before expanding the worker group.

The current task-submission instructions describe this sequence. Keep the default stable efficiency mode for the initial pilot, then test any higher-throughput mode against the hardware and repeatability requirements.

Keep settings and output scope comparable. A smaller reconstruction or lower-detail result cannot demonstrate a cluster speed improvement over a more demanding standalone baseline.

Write down what worked: device list, versions, paths, free-space checks and the tested task. That record is more useful for the next operator than an undocumented installation that happened to complete once.

Investigate worker discovery and preparation failures

Some reconstruction stages use a different subset of resources, so an idle worker is not automatically a failure. Review the stage sequence and task status before changing the configuration.

For support, preserve the controller and worker records for the relevant task and time period. Use the current manual’s log-export instructions. Our reconstruction errors guide helps organize the wider troubleshooting information.

The current manual describes adding workers while a cluster is running: new subtasks can be assigned when a new participant is detected. It also describes reassignment after removal of a worker. Follow that release’s queue and recovery behavior rather than older FAQ instructions that prohibit rejoining an active task.

Move from the pilot to a repeatable production workflow

Acceptance should cover the output, the operating method and the recovery process. Decide who submits jobs, how workers are reserved and how a project revision is identified.

• Keep an approved device and software inventory.
• Define how updates will be tested before production use.
• Retain source data and accepted results outside disposable working folders.
• Record task ownership and worker availability.
• Test the supported recovery method for interruptions.
• Keep the quality report and export checks with each delivery.

Recheck the pilot after a significant software, hardware or storage change. A new configuration can change the bottleneck even when the reconstruction settings remain the same.

Use our quality report guide for output review and versions and release notes guide when planning updates. Cluster deployment increases processing options; it does not improve deficient survey observations by itself.

DJI Terra cluster reconstruction FAQ

Do I always need a separate DJI Terra Cluster Edition license?

The current visible-light route supports applicable Standard-or-higher entitlements, with authorization required on all participating devices. Check the release and exact task before purchasing.

What application runs on a worker device?

The current cluster manual uses DJI Terra running on the participating computers. Older FAQs mention Terra Engine; follow the architecture documented for the installed release.

Can shared storage perform reconstruction calculations?

Storage supplies files. It participates in computation only if it is separately configured as a supported compute device, not merely because it is a NAS.

Will twice as many workers halve the processing time?

Not necessarily. Task distribution, serial stages, network transfers and storage can limit the benefit. Compare a representative pilot with the same standalone workload.

Can local temporary files use the same folder as shared data?

Follow the current arrangement. DJI’s preparation instructions distinguish local worker temporary directories from the shared location.

Can I reuse an older Cluster Edition installation after upgrading?

Check the migration instructions. DJI’s 5.1 announcement specifically notes worker reconfiguration for existing Cluster Edition users.

Official documentation

• Current DJI cluster scope, licensing and device roles
• Current DJI cluster device-management instructions
• Current DJI LAN, shared-folder and local-cache configuration
• Current DJI cluster task submission and queue behavior
• DJI Terra 5.1 entitlement and legacy migration announcement
• Official Terra installer and release documentation

Independent guide by Drone Emotions. Documentation reviewed on 13 October 2026. Consult the documentation for the installed software and capture-system releases.