Knowing how to write a field report comes down to discipline rather than prose. A field report is the written record of what you set out to do, how you did it, what you saw, and what it means. Writing one well takes about the same discipline as the fieldwork itself: fix your objectives before you leave shore, note what you see while you see it, and keep what you measured separate from what you concluded. This guide walks through the whole process for marine robotics deployments, and the format works just as well for environmental sampling, construction inspections, or any site visit where the reader was not there.
Most people get a field report wrong in one of two directions. They either produce a diary that reads like a stream of consciousness, or they produce a polished essay that quietly drops the failures and the anomalies that would have mattered most. The fix is structural, and it costs a couple of hours of planning before you start. Updated for 2026, the steps below follow the order that holds up when the same test gets run more than once.
Table of Contents
- What You Need
- How to Write a Field Report: Step-by-Step
- Define the Mission and Reporting Objectives
- Prepare the Test Plan and Risk Controls
- Record the Test Setup and Operating Conditions
- Document Observations and Measurements
- Analyze Results Against the Objectives
- How to Write a Field Report Structure and Executive Summary
- Add Conclusions, Recommendations, and Evidence
- Common Mistakes
- Frequently Asked Questions
- How long should a field report be for a marine robotics test?
- What should a field report include after testing an ocean drone?
- Should a field report use first person or third person?
- How many photographs and data tables should I include?
- How should I document a failed deployment or technical incident?
- Can a field report be used as a press release or project update?
- Conclusion
What You Need
A field report is written from three separate piles of material: what you planned before deployment, what you recorded during it, and what you decide afterwards. Gather all three and the writing takes an hour instead of a weekend.
Planning documents. The deployment brief or test plan is your baseline. It holds the objectives, the operating area, the weather limits, and the abort criteria you agreed to before anything was floating. Keep the version that actually governed the day, not the cleaner draft you wrote in the office.
Field equipment records. Serial numbers, firmware versions, calibration dates, and the configuration you loaded before launch. For a sailing robot or an autonomous surface vehicle, that includes hull configuration, ballast weights, sensor mounting angles, battery state at launch, and the radio or link settings you used.
Data sources. The mission log itself, telemetry and sensor exports, photographs and video with timestamps, weather data from the forecast source you actually used, and any manual readings taken on deck. Pull the raw files before you clean anything, and keep them.
Safety materials. The risk assessment, the communications plan, the emergency stop and fail-safe procedure, permission and permit documents, and the names and numbers of everyone on the water. If a coastguard station or harbour master had to be contacted, note when and by whom.
Reporting tools. A template with the sections already in order, a camera whose clock you have synchronised, and a spreadsheet for the observation table. Set up the file structure on shore: one folder for raw logs, one for images, one for the draft. You will not enjoy sorting this at 6pm from a car park after recovery.
How to Write a Field Report: Step-by-Step
These seven steps take a deployment from a set of objectives and observations to a finished report that someone else could act on. Work them in order. The tempting shortcut is to jump to the results section, but almost every weak report I have read was written out of that order, which is why the conclusions ended up describing something the test never actually did.
Define the Mission and Reporting Objectives
Start by turning the deployment brief into specific questions the report has to answer. “Test the new buoyancy controller” is a task, not a reporting objective. “Does the hull hold heading within 5 degrees across a 2-knot beam swell” is a question with a measurable answer.
Write down four things before anything else: the purpose of the deployment, the operating area with its coordinates or landmarks, the success criteria with thresholds, and the limits of what you can conclude. That last one saves you later. If you only ran a single sortie in one location on one day, the report cannot support a claim about general reliability in open water, and saying so up front protects you from the “we were wondering about winter performance” question two months later.
Then name the reader. A supervisor needs detail on methods. A funder needs outcomes and next steps. A student needs the structure explained. A technical write-up and a grant report look similar on the surface and are not the same document, so decide which one you are writing before you open a blank page.
Prepare the Test Plan and Risk Controls
The test plan is report content, not just paperwork. It tells the reader what the day was supposed to look like, which makes it possible to judge deviations as they appear in the observations.
Document the weather limits you set (wind speed, wave height, visibility), the launch and recovery procedure, the communications plan including primary and backup channels and check-in intervals, the emergency stop procedure, the fail-safe behaviour, the permissions and permits you held, and the contingency route for a disabled vehicle. For marine work, that usually means a tow line and a chase boat, plus the point at which you abandon a vehicle rather than risk it.
Do not sanitise this later. A report that shows a defined abort threshold and then describes an aborted test is more credible than one that reports an uninterrupted success, because it proves the threshold was real.
Record the Test Setup and Operating Conditions
This section answers the question every reviewer asks: could someone else have run this test? List the hardware and software as configured on the day, the calibration performed and against what reference, the sensor configuration and sampling rates, the location, date, and times, plus the operating conditions that affect interpretation.
For water-based work, operating conditions carry real weight: significant wave height, wind speed and direction, swell period, water temperature, tide state, current, and visibility. A sensor drift that looks like a hardware fault at one sea state is normal behaviour at another, and the reader cannot tell which without this section. Note anything that changed mid-session, such as a re-tuned gain or a swapped battery, because a mid-session change splits your data into two datasets.
Document Observations and Measurements
Capture observations the moment they happen. Write the time first, then what you saw, then your interpretation, clearly separated. That three-line pattern is the whole trick: a log that mixes observation and interpretation becomes unusable when you return to it three weeks later, because you cannot tell which claims were evidence and which were assumptions.
Record measurements as numbers with units and reference points (heading error in degrees, position in decimal degrees, voltage in volts). Record unexpected behaviour as it occurs rather than reconstructing it: an erratic starboard turn at 11:42, a telemetry drop lasting 90 seconds, a control input that was rejected twice before it took. Note every intervention and who made it, because a manual override changes the meaning of everything after it.
Photograph and film with the clock synchronised, and shoot context shots, not just close-ups. A close-up of a cracked connector proves nothing; a shot showing which connector, where it sits, and how it was routed does. Label images the moment you download them, not at write-up time.
Three evidence types carry a report: quantitative data from the log, visual evidence from images, and contemporaneous written notes. A claim with two of the three behind it holds up. A claim with one is an assertion.
Analyze Results Against the Objectives
Now do the part most people skip: take each objective from step one and address it directly. State the result against the criterion, not just the number. “Heading error held at 3.2 degrees mean with a 1.1 degree peak, inside the 5 degree threshold, across 4.2 hours of operation” answers the question. “The controller performed well” does not.
Keep measured results and interpretation visibly apart. Measurements belong in one subsection, what you think they mean in the next. Quantify uncertainty where you can: number of sorties, duration of the sample, sensor uncertainty, the effect of any calibration drift. A single 20-minute run with one sensor reading is a preliminary observation, not a result, and saying so is a strength rather than a weakness.
Explain failures without inflating them. Describe what happened, the evidence for it, and the most likely cause, and mark the cause as a hypothesis unless the evidence settles it. Resist the urge to explain away an anomaly as an operator error until you have checked the logs.
How to Write a Field Report Structure and Executive Summary
Use a fixed order so the reader can navigate: header block, executive summary, background and objectives, methods and equipment, operating conditions, observations, analysis, conclusions and recommendations, appendices and references. The header block carries title, dates, location, author, observers, and a one-line summary of conditions.
The executive summary is 150 to 250 words and must stand alone. It states the mission, the headline findings with the numbers, what limited the work, and the next actions. Write it last, even though it appears first, because it is the only section that depends on everything else being settled.
Then write observations as a table: time, parameter or observation, value, source, notes. Tables beat paragraphs for anything numeric, and they let a reader find one row instead of reading a page. Use graphs when the relationship is temporal, photographs when the finding is visual or spatial, and always caption them with what they show, the date, and the conditions.
Add Conclusions, Recommendations, and Evidence
The conclusion answers each objective in one sentence and adds nothing new. If a number appears for the first time in the conclusion, it belongs in the observations.
Recommendations must be actionable and tied to evidence. “Investigate the autopilot filter” is weak; “re-test the autopilot filter with the gain set to 0.3 rather than 0.5, since the oscillation appears above 0.4 in both log runs” is a recommendation someone can act on Monday. Separate completed work from proposed work, and state clearly what remains untested.
Close with appendices: raw logs, full data tables, calibration certificates, photo sets, and the test plan as issued. Cite any protocols, standards, or prior reports you used. Appending the raw data lets the next person repeat your work, which is the entire point.
Common Mistakes
Vague objectives. If success is not defined before the test, the report ends up declaring success on the day. Fix: write measurable criteria into the test plan, then mirror them in the analysis section, one result per objective.
No baseline data. A reading on its own means little. Without a pre-deployment value, a shore-side test, or a previous run under comparable conditions, the reader cannot tell improvement from drift. Fix: capture a baseline before you launch, and say what it was.
Unlabelled photographs. “Figure 3” with no date, location, or direction tells the reader nothing, and undated photos in a report are effectively unusable. Fix: caption every image with content, date, conditions, and orientation.
Missing time references. “During the test” is not a time reference. Elapsed time from launch, local clock time, and log timestamps should be used consistently so observations line up with telemetry. Fix: adopt one time standard at the start and use it everywhere.
Unsupported conclusions. Claims that drift past the evidence are the fastest way to lose a reader’s trust. Fix: for each conclusion, name the evidence behind it, and if the evidence is thin, downgrade the wording to an observation or hypothesis.
Undocumented changes. Re-tuned parameters, swapped parts, added sensors, and skipped sorties get left out of the report and then get discovered in the raw logs. Fix: keep a change log during deployment and reproduce it in the methods section.
Two smaller habits help. Write the executive summary last, not first. And keep raw data immutable: work on copies, and never edit the file the instruments wrote.
Frequently Asked Questions
How long should a field report be for a marine robotics test?
For a single-day sea trial, 1500 to 3000 words plus appendices is the usual range. A multi-day campaign covering several sorties or sensor types needs more, usually 4000 to 6000 words. Length should follow the evidence rather than a page count. If a section has nothing to report beyond a single number, keep it short; if the analysis carries uncertainty, give it room. Check any assignment or funder limit before you start, since those override general guidance.
What should a field report include after testing an ocean drone?
At minimum: a header block with dates, location, crew and conditions; the objectives with measurable success criteria; the hardware and software configuration as loaded; the launch, operation and recovery procedure; operating conditions including sea state, wind and tide; a timestamped observation table; analysis comparing each objective against its criterion; conclusions; recommendations; and appendices with raw logs, calibration records and photographs. Anything you changed mid-deployment belongs in the methods section, not buried.
Should a field report use first person or third person?
Both are acceptable, but pick one and hold to it. First person (I launched, we observed) suits operational and technical reports because it makes responsibility for decisions clear and is easier to read. Third person suits academic coursework where a department style guide requires it. Passive voice is useful only when the actor genuinely is unknown or irrelevant. What matters is consistency: mixing I with the robot was across a paragraph reads as carelessness, whichever one you choose.
How many photographs and data tables should I include?
Include enough to support every claim and no more. In practice that is usually one table per measured parameter, one photograph per finding that has a visual or physical component, and one conditions summary table. Every image needs a caption with what it shows, the date, and the conditions. Extra photographs that no conclusion refers to get skimmed and then ignored. If you have a large photo set, put the selected images in the report and the full set in an appendix.
How should I document a failed deployment or technical incident?
Report it the same way you would report a success: neutral description, timeline with times, evidence, cause stated as confirmed or hypothesised, and what you changed as a result. State whether the test met its abort criteria and whether the decision to stop was correct. A failed deployment with a clear analysis and a revised test plan is one of the most useful documents a team produces, and hiding it makes the next attempt repeat the same fault.
Can a field report be used as a press release or project update?
Not directly, though the executive summary is the source for both. A press release leads with the headline outcome and needs no methods detail; a project update adds progress and next steps for a specific audience; a field report documents methods, evidence and limitations for people who may question them. You can quote from your own report freely. Republishing it unchanged does not work, because a report that admits real limitations reads as a confession rather than a success story.
Conclusion
Start with the objectives, not the writing. Write down what you are testing, what counts as success, and what the test cannot prove, then keep a timestamped log and a change record while you are on the water. Everything else in a field report follows from those three habits, and the report writes itself from the evidence.
Nobody masters how to write a field report by reading about it. The first one you produce will be too long and slightly defensive about what went wrong. Write it anyway, mark the gaps in a change log, and the second version is usually half the length and twice as useful.
