Skip to content
English
  • There are no suggestions because the search field is empty.

Orbit Mission with Autel Evo Max4T XE



 One Orbit, Two Datasets: Turning a Single Autel Orbit Mission Into a Measurable 3D Deliverable

Agri Spray Drones | Autel EVO Max 4T XE → Pix4DMatic / SkyeBrowse


The short version

We flew one orbit mission around a grain handling site with an Autel EVO Max 4T XE. The mission captured photos automatically as the aircraft circled, and we hit record at the same time — so a single three-minute flight produced two independent datasets from one trip around the yard.

The photos went into Pix4DMatic and produced a georeferenced mesh and point cloud: 780,000 triangles across a 185-meter footprint. The video went into SkyeBrowse for a fast videogrammetry pass.

The point of this write-up isn't the model. It's that the workflow is short enough to be routine. If you already own the aircraft for spray work, this is a second product line that costs you a battery and a coffee break.


Why an orbit, and why both captures

A mapping mission and an orbit mission solve different problems.

A standard grid or lawnmower mapping flight looks straight down. It's the right tool for acreage, plant health, and orthomosaics — but it sees roofs and the tops of bins and almost nothing of their sides. Ask a nadir map how tall a bin is, or what condition the north wall of a shed is in, and you get a shrug.

An orbit flies a circle around a target with the gimbal tilted down, so every structure gets seen from all sides across the arc. That's what produces geometry you can measure vertically and inspect visually.

Run the photos and the video together. The orbit mission is already taking stills on its own as it circles; starting a video recording alongside them costs nothing and gives you a second, independent capture of the same pass. Two datasets, two processing paths, two different turnaround times — off one battery. There is no reason not to.


Which software takes what

This trips people up, so it's worth stating plainly.

Input Pix4DMatic Pix4Dmapper SkyeBrowse
Photos Yes Yes
Video No Yes Yes

Pix4DMatic is image-only — JPEG or TIFF. It will not ingest an MP4, and it cannot process multispectral or thermal imagery either; RGB only. The older Pix4Dmapper can import video and auto-extract frames, but Matic is the better engine for this kind of dataset and is where the photo workflow belongs.

So: photos to Pix4DMatic, video to SkyeBrowse. Don't try to feed the recording into Matic and don't waste time wondering why it's rejecting the file.


The flight

Aircraft: Autel EVO Max 4T XE, wide camera, 4:3 sensor readout. Orbit mission with simultaneous video recording.

Flight parameters, reconstructed from the capture:

Parameter Value
Capture duration ~190 seconds
Revolutions ~1.75
Angular rate ~3.5°/second
Orbit radius ~87 m from the yard center
Altitude ~55 m AGL
Camera depression ~33° below horizontal
Horizontal field of view ~74°
Video frame rate 30 fps

Why these numbers matter:

Angular rate is the one to get right. A slow orbit gives you dense photo spacing and enormous frame-to-frame overlap. That redundancy is what lets the solve discard a bad frame without opening a hole in the model. Speed the orbit up and you spend that margin.

Depression angle drives what you can see. Roughly 30–45° is the useful band. Steeper and you're doing a slow, expensive nadir map. Shallower and structures start occluding each other, plus you pick up sky and horizon, which adds noise rather than information.

More than one revolution is cheap insurance. The second pass covers whatever the first lost to a bird, a glare hit, or a gust. It costs 90 seconds.


Processing the photos in Pix4DMatic

  1. Create the project and import the images. Matic reads geolocation from EXIF/XMP. Input imagery is expected in WGS 84 — and if you aren't setting ground control, the output lands in the corresponding UTM zone automatically. That's where the georeferencing comes from on an uncontrolled flight.
  2. Calibrate. This is the bundle adjustment: tie points, camera model optimization, and geolocation. Read the quality report here, not after you've spent an hour on densification.
  3. Dense point cloud (Densify). Image scale drives the tradeoff between detail and processing time. There's a hardware-accelerated option that Pix4D measured at roughly half the processing time of the standard algorithm on comparable data.
  4. Mesh. Built from the dense point cloud, and viewable directly in Matic's 3D view.
  5. DSM and orthomosaic. The 2.5D surface model and orthomosaic — the DSM is what volume computation runs against.
  6. Export. Textured mesh, dense point cloud in .laz, DSM, orthomosaic. Matic will also generate a point cloud from the mesh, which fills areas the densification left empty — useful when you want a hole-free cloud, at the cost of a substantially larger file than the densify-step cloud.

If you need vectorization, terrain filtering, or volumes, a finished Matic project opens directly in Pix4Dsurvey.


Processing the video in SkyeBrowse

The video path is the fast one. SkyeBrowse is built for videogrammetry — an orbit recording is exactly its intended input, and turnaround is a fraction of a full photogrammetric solve. It exports GLB with textures embedded in a single file, which is the least painful format to hand to anyone who just wants to look at the model.

Use it when someone needs a model today. Use the Pix4DMatic output when the model has to be measured against.


What came out of Pix4DMatic

Output Value
Vertices 527,317
Triangles 779,751
UV coordinates 2,339,253
Material groups 4
Texture atlases 4 × 8000 × 8000 px JPEG
Model extent 185.4 × 185.4 × 26.0 m
Georeference offset 514986.000 E, 4318982.000 N, 245.000 m

The offset values are consistent with UTM Zone 15N, the correct zone for central Missouri — matching Matic's documented behavior of falling back to the corresponding UTM zone when no GCPs are supplied. That offset file is what makes the export georeferenced rather than a floating object: coordinates inside the .obj are local, and adding the offset back puts the model on the earth. Ship the offset file with the model or you've shipped a decoration.

Structures resolved cleanly: three grain bins, the machine shed, the barn, equipment parked in the yard, the gravel drive, fence lines, the road with its painted centerline, and the large oak. Individual tractors and a planter are identifiable.


Verifying it actually lines up

A textured 3D model always looks convincing. That's not the same as being correct, and "looks convincing" is not something you can hand a client.

Running photos and video on the same pass makes a genuinely useful check possible. The mesh was built from the photos. The video was a separate capture. So the video can be used to test the model without being the thing that produced it.

The procedure:

  1. Rasterize the mesh into a top-down orthophoto and matching surface model at a known scale — 0.25 m per pixel here. Because the mesh is georeferenced, every pixel has a real-world coordinate, and the surface model supplies height.
  2. Take a single frame from the video. Run feature matching between that frame and the orthophoto.
  3. Each match now links a pixel in a photograph to a real 3D point. Feed those into a perspective-n-point solve to recover where the camera was standing, where it was pointed, and its focal length.
  4. Render the model from that solved pose and blend it against the original video frame.

Result on this dataset: 0.69 pixel mean reprojection error. In the 50/50 blend, shed roof edges, bin walls, the parked tractor, the planter, the gravel drive, and the road centerline all superimpose.

That's a photo-derived model agreeing to sub-pixel with an independently recorded video frame. Not a self-consistency check — a cross-check between two captures.

One honest caveat on the method: with a limited number of inlier correspondences, focal length and camera distance trade off against each other, so single-frame focal estimates are unstable even when the direction of view is solid. Solve several frames and treat the pose direction as the reliable output.

This is also what makes the match cut in the promo video honest rather than a trick. The transition from real footage to rendered model isn't eyeballed — the render camera sits at the solved position of the real camera, so the cut holds because the geometry agrees.


What it's good for

  • Vertical measurement — bin heights, structure dimensions, clearances, stockpile geometry
  • Roof and structure inspection without putting a person on a ladder
  • As-built documentation for a yard, lot, or facility
  • Storm damage and insurance records — a dated, dimensional record of condition
  • Site planning before concrete gets poured or a building goes up
  • Volume computation from the DSM
  • Client-facing visuals that don't look like a hobby flight

Limitations — read this part

No ground control was set on this flight. Relative geometry is demonstrably sound and the model is georeferenced from aircraft GPS, but absolute positional accuracy is unverified. Do not quote survey-grade numbers off an uncontrolled flight. If a deliverable requires stated accuracy, that means GCPs, checkpoints, and a reported RMSE — a different job at a different price.

The two outputs are not interchangeable. The SkyeBrowse videogrammetry model is fast and fine to look at. The Pix4DMatic photo-derived model is the one to measure against. Don't hand a client the quick one and let them assume it carries the same weight.

Thin and complex structures reconstruct poorly. Tree canopy, ladders, railings, power lines, antenna masts — noisy or partially missing. Inherent to photogrammetry, not a software defect. Say so up front rather than letting a client discover it.

Bin tops and canopy show texture noise in this model on close inspection. Mixed pixels on complex geometry. Cosmetic, but disclose it.

Reconstruction edges are unreliable. The outer boundary of the covered area has weak coverage and shouldn't be measured against. Fly a wider orbit than the area you intend to deliver.

Matic is RGB-only. No thermal, no multispectral. The 4T XE's thermal payload is a separate workflow.


Repeatable checklist

Before the flight

  • Orbit mission configured; confirm photo capture is on
  • Start video recording too — free second dataset
  • Orbit radius roughly 1.5× the site's longest dimension
  • Altitude 50–60 m AGL for a typical farmstead
  • Gimbal 30–45° down
  • Angular rate ≤ 4°/second
  • Plan at least 1.5 revolutions
  • Overcast or high sun; hard low-angle shadows bake into the texture
  • Note takeoff point and obstacles in the orbit path

Processing

  • Photos → Pix4DMatic. Video → SkyeBrowse. Never the reverse.
  • Confirm image geolocation imported before calibrating
  • Read the quality report after Calibrate, before Densify
  • Densify → Mesh → DSM → Orthomosaic
  • Export mesh, point cloud, DSM, orthomosaic

Delivering

  • Ship .obj + .mtl + texture atlases and the offset file
  • State which model came from which capture
  • State what was and wasn't controlled
  • Never imply accuracy you didn't measure

Agri Spray Drones | 13620 Old Highway 40, Boonville, MO 65233 | 573-519-5000 | agrispraydrones.com Empowering Rural America With New Opportunities