Skip to content

Survey3 Mapping Camera

This page tells you how to set up, fly and process the MAPIR Survey3W on the TerraHawk. The mount, its fit in the Fuselage Mid, and the balance are on two other pages. Refer to the mapping payload section of the parts list, and to the custom parts page. This page starts from there. Checked 2026-09-26.

From MAPIR’s product page:

Spec Survey3W
Sensor Sony Exmor R IMX117, 12MP Bayer RGB, 6.20 x 4.65 mm
Image 4,000 x 3,000 px
Lens 3.37 mm f/2.8, 87° horizontal field of view, -1% distortion (not fisheye)
Shutter speeds 1/2000 s down to 60 s, or auto
ISO 50, 100, 200, 400, or auto
Interval 1.5 s per JPG, 2.75 s per RAW+JPG
Files JPG (8-bit) or RAW+JPG (12-bit), micro SD up to 512 GB
Power 5.2 V over USB or its own 1,200 mAh battery; 0.3 A idle, 0.33 A shooting
Mass 50 g without battery, 76 g with
Size 59 x 41.5 x 36 mm
Trigger 2,000 µs PWM pulse on the HDMI port; 1,000 µs is idle
Feedback 3.3 V exposure pulse on the HDMI port, about 100 ms after the trigger
GPS External only; MAPIR’s USB GPS receiver ships with the camera
Price $400, the same for every filter

The IMX117 is a rolling-shutter sensor. Its rows are read out one after another, so a fast-moving aircraft skews each frame slightly. Photogrammetry software corrects for this if you turn the correction on (refer to Processing).

Every Survey3 costs $400 and has the same sensor. The variants differ in filter and lens.

Choice Pick Why
Lens Survey3W (3.37 mm, 87°) The narrow Survey3N (8.25 mm, 41°) has an along-track footprint of only 68 m at 120 m. At cruise and the 1.5 s interval that is 56% forward overlap, too little to map from
Filter RGB for maps, terrain and orthophotos RGN or OCN if you want NDVI crop health; NGB for water and submerged plants; NIR and RE for specialist indices

The NIR-capable filters need two extra steps: a photograph of a reflectance calibration target before each flight, and processing in MAPIR Camera Control. RGB needs neither.

The flight controller for the first flights is the Lumenier LUX F765 NDAA (Ryan, 2026-10-04; params/board-luxf765.parm). The camera does not fly on the first build, so the board file sets output 8 and the camera off and carries the rows below as comments, to set when the camera flies (2026-10-19). The trigger is on output 8 (M8), in timer group 5 to 8 with the elevons and the pusher (all PWM, no DShot motor). The strobe goes on the S2 pad (output 10), set as a GPIO input with SERVO10_FUNCTION -1.

Camera lead LUX F765 pad ArduPilot
PWM trigger (white) M8 signal SERVO8_FUNCTION = 10 (camera trigger)
Exposure strobe S2 pad (PB1, GPIO 59) CAM1_FEEDBAK_PIN = 59, SERVO10_FUNCTION = -1
Ground A ground pad
Power A 5 V pad, to the camera’s USB As on the 6C Mini below

The strobe is 3.3 V, which the F765’s pins take directly.

The flight controller for the first flights was the HKUST NxtPX4v2 (Ryan, 2026-10-04, replaced by the LUX F765 the same day; params/board-nxtpx4v2.parm). The trigger is on output 8, in timer group 7 to 8 with the pusher (both PWM, no DShot motor). The strobe goes on the AUX2 pad, a plain GPIO on the H743.

Camera lead NxtPX4v2 pad ArduPilot
PWM trigger (white) PWM 8 signal SERVO8_FUNCTION = 10 (camera trigger)
Exposure strobe AUX2 pad (PC1, GPIO 82) CAM1_FEEDBAK_PIN = 82
Ground PWM 8 ground
Power A 5 V pad, to the camera’s USB As on the 6C Mini below

The strobe is 3.3 V, which the H743’s pins take directly. MicoAir’s pinout sheet and ArduPilot’s README agree that the AUX2 pad is PC1.

The flight controller for the first flights was the Pixhawk 6C Mini (2026-09-27 to 2026-10-04). The camera goes on the FMU’s AUX pads, in group AUX 1 to 4, which has no motor in it. The pusher is on AUX 5.

Camera lead 6C Mini pad ArduPilot
PWM trigger (white) AUX 1 signal SERVO9_FUNCTION = 10 (camera trigger)
Exposure strobe AUX 2 signal (GPIO 51) SERVO10_FUNCTION = -1 (GPIO), CAM1_FEEDBAK_PIN = 51
Ground AUX 1 ground
Power A 5 V pad, to the camera’s USB Camera switches on with the aircraft; its battery can stay out to save 26 g

The strobe is 3.3 V. The pins of the FC take it directly. The Lucid wiring below applies only if the Lucid is fitted.

The timer groups of the board come from ArduPilot’s hardware definition, which the Lucid H7 Wing includes. The groups are outputs 1 and 2, 3 and 4, 5 and 6, 7 to 10, 11 and 12, and 13. Outputs 1 to 4 carry the DShot lift motors. Outputs 7 and 8 carry the elevons. The camera goes on outputs 9 and 10, in the same group as the elevons. That group runs PWM only.

Camera lead Lucid pad ArduPilot
PWM trigger (white) Output 9 signal SERVO9_FUNCTION = 10 (camera trigger)
Exposure strobe Output 10 signal (GPIO 59) SERVO10_FUNCTION = -1 (GPIO)
Ground Output 9 ground
Power A 5 V pad, to the camera’s USB Camera switches on with the aircraft; its battery can stay out to save 26 g

The strobe is 3.3 V. The pins of the FC take it directly.

Current ArduPilot uses the CAM1_ names. Older firmware used CAM_ and CAM_FEEDBACK_. The values come from the camera shutter guide and MAPIR’s trigger guide:

Parameter Value Why
CAM1_TYPE 1 Servo trigger. Reboot after setting it
SERVO9_FUNCTION 10 Output 9 drives the trigger (6C Mini). On the LUX F765 and the NxtPX4v2: SERVO8_FUNCTION 10
CAM1_SERVO_ON 2000 The Survey3’s take-a-photo pulse
CAM1_SERVO_OFF 1000 Idle. Never 1500, which puts the camera into USB transfer mode
CAM1_DURATION 0.1 Seconds the pulse stays high
CAM1_INTRVAL_MIN 1.6 Just above the camera’s 1.5 s JPG interval, so ArduPilot never asks faster than it can shoot
SERVO10_FUNCTION -1 Output 10 becomes a GPIO input (6C Mini, and the LUX F765’s S2 pad). The NxtPX4v2’s AUX2 pad is already a GPIO
CAM1_FEEDBAK_PIN 51 On the LUX F765: 59, the S2 pad (PB1). On the NxtPX4v2: 82, the AUX2 pad (PC1). Output 10’s GPIO number on the Pixhawk 6C Mini: output 10 is AUX 2, GPIO 51, because the IO co-processor drives MAIN 1 to 8 (th-avionics, Pixhawk6C hwdef). 59 is correct only on a board with no IO co-processor, such as the Lucid H7 Wing below. With the wrong number, the feedback never arrives and each photo carries the trigger position
CAM1_FEEDBAK_POL 1 The strobe goes high when the photo is taken

On the camera, turn the Interval option off. If it is on, the camera also shoots on its own timer.

Test on the bench:

  1. WARNING: Remove the props before the bench test. A prop that starts can cause injury.
  2. In Mission Planner, right-click the map and select Trigger Camera NOW.
  3. Check the log for both TRIG (the command) and CAM (the actual exposure) messages.

The feedback pin matters here. The exposure comes about 100 ms after the trigger, which is 2 m at cruise. CAM records where the aircraft really was.

Across-track is the 87° axis, along the span. Along-track is the 69° axis. All the figures are computed from the sensor and lens above, at the 20 m/s cruise in the manual.

Altitude Ground resolution Footprint across x along Photo spacing at 80% Line spacing at 70%
60 m 2.8 cm/px 110 x 83 m 16.6 m 33 m
80 m 3.7 cm/px 147 x 110 m 22.1 m 44 m
100 m 4.6 cm/px 184 x 138 m 27.6 m 55 m
120 m 5.5 cm/px 221 x 166 m 33.1 m 66 m

The shooting interval sets the minimum altitude, not the resolution. Photogrammetry needs about 75 to 80% forward overlap. At 1.5 s per photo and 20 m/s, the aircraft covers 30 m between shots. Thus the along-track footprint must be long enough to overlap that distance:

Airspeed 75% forward overlap 80% forward overlap
16 m/s (AIRSPEED_MIN) 70 m or higher 87 m or higher
20 m/s (cruise) 87 m or higher 109 m or higher

Thus, fly at 110 to 120 m at cruise, or at 90 to 100 m at 16 to 17 m/s for finer detail. Any lower altitude leaves gaps, whatever the mission plan. RAW+JPG at 2.75 s would need about 200 m, which is above the 120 m (400 ft) limit. Shoot JPG only.

Fly the lines crosswind. Ground speed sets the photo spacing. At 120 m and 80% overlap, the camera keeps up with 22 m/s over the ground. Thus a 20 m/s cruise with a tailwind of more than 2 m/s misses frames on the downwind legs. Crosswind lines keep the ground speed near the airspeed in both directions.

Shutter. In daylight, lock the shutter at 1/1000 s or faster, with ISO 100 to 200. At 20 m/s that is 20 mm of motion, 0.36 px at 120 m. In shade, auto exposure can drop to 1/500 s or slower and blur the frame.

Coverage. At 120 m with 70% side overlap, each line sweeps 66 m. At 20 m/s that is about 475 ha an hour before turns. Fixed-wing turns take a third or more of a survey. Plan on about 300 ha an hour.

Rules. Part 107 limits altitude to 400 ft (122 m) and requires visual line of sight. To keep a 1.5 m wingspan in sight, a practical survey block is about a square kilometre around the pilot. That is well under what one pack can cover.

Use Plan, right-click, Auto WP, Survey (Grid) with a custom camera:

Field Value
Sensor width x height 6.20 x 4.65 mm
Image width x height 4,000 x 3,000 px
Focal length 3.37 mm
Orientation Long side across the flight line (landscape)
Overlap / sidelap 80% / 70%
Altitude 110 to 120 m
Speed 20 m/s

The grid tool writes DO_SET_CAM_TRIGG_DIST at the start of the lines and a distance of 0 at the end. Thus the camera only shoots on the survey legs. Start the mission with a VTOL take-off and end it with a VTOL landing.

  1. Transfer the JPGs from the SD card. Download the .bin log of the flight.
  2. Geotag the images: in Mission Planner, use Ctrl-F, Geo ref images, with the CAM messages. MAPIR Camera Control can also geotag from the log.
  3. Build the map in WebODM (OpenDroneMap, which you can host in Docker). Turn on the rolling-shutter correction (rolling-shutter), because the IMX117 reads out row by row. WebODM produces the orthophoto, the elevation models and the point cloud.
  4. NIR filters only: before you build the index maps, calibrate reflectance with the target images in MAPIR Camera Control.

MAPIR’s documents for the camera, mirrored for the builder behind the same login as the kit manual. Each page links its original PDF:

From the kit’s makers, Nomadium Robotics, in their Pathfinder series:


Source: docs/survey3.md in the repo. Edit it there; this page is generated.

Comments on

    Comments are reviewed before they appear. Please leave out places, addresses and other personal details.

    A Supported Systems Flight

    This build log is written and kept by Supported Systems, a small studio that makes thoughtful, user-first technology. The airframe, the hangar and the simulation are ours.

    Visit supported.systems