UGV development brief checklist

1. Describe the task and the decision

Write one sentence explaining what the operator needs to achieve and why a robotic system may help. Identify the user, the buyer and the person who can accept the result. NASA's systems engineering guidance starts with stakeholder expectations and turns them into requirements; the same distinction helps keep a small robotics brief focused.

• Name the task, the current method and the problem to improve.
• Separate essential outcomes from preferences and possible later features.
• State what this stage should deliver: an assessment, design, prototype or trial.

Reference: NASA Systems Engineering Handbook: System Design Processes

2. Put boundaries around the operating environment

Describe representative ground and access conditions. 'All terrain' does not establish a design requirement. Include the awkward parts of the route, the space available to turn and how the vehicle reaches the starting point. Photos or a simple route sketch can reveal constraints that a long written description misses.

• Record surface type, gradients, obstacles, minimum width and turning space.
• Describe expected weather, lighting, dust and exposure to water.
• Identify people, other vehicles and areas outside the permitted trial boundary.

3. Describe the working payload

Include the payload, its mount, cables and protective enclosure in the mass estimate. Explain where it must look, reach or measure. A high-mounted sensor may change the vehicle's centre of gravity; a sensor that works while stationary may have different requirements while moving. Record those conditions before treating a payload allowance as settled.

• Provide dimensions, mass, mounting position and clearance needs.
• List movement restrictions and access needed for adjustment or replacement.
• Identify any platform equipment that is already fixed and cannot change.

4. Define the duty cycle and support

Break the working period into driving, waiting and payload operation. Endurance should describe that cycle, the ground and the carried load. Include time to prepare, charge, inspect and recover the system. State whether the operator can swap batteries and what power supply is actually available at the intended location.

• Record the duration and frequency of each activity.
• List continuous, intermittent and startup payload power demands.
• Identify transport, storage, charging and routine maintenance arrangements.

5. Define control, stopping and recovery

Identify who can command movement and how the operator recognises the active control state. Describe what should happen when communications, positioning or power becomes unreliable. The recovery method must suit the surroundings: a stationary vehicle can still present a hazard. For ArduPilot-based designs, pre-arm checks are one part of setup verification, not a complete safety assessment.

• Record operator location, visibility and expected communications limitations.
• Define stopping, loss-of-link and restart expectations for engineering review.
• Identify who authorises a trial and who can stop it.

Reference: ArduPilot Rover: Pre-Arm Safety Checks

6. Agree what evidence will answer the question

Turn each priority requirement into an observable result. Attach conditions and a measurement method. For example, a transport requirement could be checked by measuring the agreed vehicle configuration against a stated access opening. Keep design targets separate from results already demonstrated. Agree who reviews the evidence and how unresolved findings affect the next stage.

• Use one requirement identifier per result.
• Record the threshold, configuration, method and evidence owner.
• Keep an assumptions list with an owner and a date to resolve each item.

7. Review the brief before requesting a proposal

Ask whether an engineer could explain the intended task without filling gaps by guessing. Mark each item as confirmed, provisional or unknown. Share only information suitable for the agreed channel. RCDEN is developing unmanned systems; the brief helps establish a realistic assessment or development scope, with availability and performance confirmed for the relevant stage.

• Identify the first decision needed and its deadline.
• Attach available drawings, interface documents and relevant existing evidence.
• Record exclusions so that optional features do not silently enter the scope.

Further reading

• NASA Systems Engineering Handbook: System Design Processes
• ArduPilot Rover: Pre-Arm Safety Checks