Defining Measurable Robotic System Performance Requirements

Hello, and welcome to the first stage of your mechatronics build course. The goal is not to begin by choosing motors or printing parts; it is to define what the robot must demonstrably do. This module turns a broad idea—an arm on a mobile base—into an engineering project with measurable targets, clear interfaces, and safe test plans.

Your primary build will be a practical robotic arm, complemented by an indoor autonomous mobile base. In this lesson, you will convert desired capabilities into requirements for reach, payload, repeatability, speed, and runtime. These requirements will guide every later choice: arm geometry, actuators, battery, chassis, electronics, and software.

---

Start with a mission, not a parts list

A requirement describes an observable result under stated conditions. It should not prematurely prescribe a solution.

Compare these statements:

• Design decision: “Use high-torque servos and a 3S LiPo.”
• Requirement: “The arm shall move a $250\mathrm{g}$ object plus gripper through the specified workspace and complete a transfer cycle in $20\mathrm{s}$ or less.”

The first statement may become appropriate later, but it cannot tell you whether the finished robot succeeds. The second statement can be tested.

A useful requirement has five parts:

1. Object: what system is being discussed?
2. Action: what must it do?
3. Measured quantity: what number represents success?
4. Operating conditions: with what load, surface, battery state, or starting position?
5. Acceptance test: how will you verify it?

For example:

REQ-A-03: With the specified gripper and a $250\mathrm{g}$ object, the arm shall return its tool center point to a taught target with a maximum endpoint spread of $5\mathrm{mm}$ across 10 trials, starting from the same home position and approaching the target from the same direction.

That one sentence prevents several future misunderstandings. It identifies the load, the reference point, the metric, the number of trials, and the test conditions.

The tool center point, usually abbreviated TCP, is the point that represents the end effector in your measurements. For a simple gripper, use a repeatable physical point such as the midpoint between the gripping surfaces when closed. Define it once in your build log and use it consistently.

For this project, write a short mission statement before assigning numbers. A practical first version might be:

The system will transport itself on a smooth indoor floor, stop at a designated work area, and use a tabletop arm to pick small objects from a pickup zone and place them in a drop-off zone.

This is still not a specification. It is the narrative that gives each number a purpose.

---

Turning arm capability into measurable numbers

The central arm requirements are linked, but they are not interchangeable. A long arm is not automatically useful if it bends under load; a strong arm is not automatically useful if it cannot return reliably to a pickup point.

Reach: define a usable workspace, not just a link length

Reach is the allowable distance from the arm’s base reference to the TCP. For your arm, it should be defined by task locations rather than by the sum of printed link lengths.

A useful arm reach specification normally includes:

• Horizontal range: distance from the base rotation axis to the TCP.
• Vertical range: table-relative height the TCP must attain.
• Joint limits: the allowed angular ranges that define the practical workspace.
• Exclusions: regions blocked by the base, table, arm links, cables, or an unsafe posture.
• Payload condition: reach must be usable while holding the specified load.

For instance, “$400\mathrm{mm}$ reach” is incomplete. A much better requirement is:

REQ-A-01: With the gripper installed, the arm shall place its TCP anywhere within a horizontal radial range of $150\mathrm{mm}$ to $400\mathrm{mm}$ from the base axis and at heights from $80\mathrm{mm}$ to $280\mathrm{mm}$ above the work surface, subject to stated joint limits.

The inner radius matters. Many rotary arms cannot reach close to their own base without folding into a collision or singular posture. The height range matters because a robot must approach, grasp, lift, and release rather than merely touch a single flat point.

For a first arm, choose a modest workspace that fits your printer, available actuators, and tabletop. Reach increases torque demand rapidly because more mass is held farther from each joint.

Payload: include everything carried at the wrist

Payload is not simply the mass of the object. The arm must accelerate and support the combined wrist load:

$$m_{\mathrm{wrist}}=m_{\mathrm{gripper}}+m_{\mathrm{object}}+m_{\mathrm{adapters}}+m_{\mathrm{movingcable}}$$

For requirement writing, separate the user-facing object mass from the total carried wrist load. This makes future upgrades easier: changing to a heavier gripper should not silently invalidate the arm.

A sensible pair of requirements could be:

REQ-A-02a: The gripper shall securely grasp objects with masses up to $250\mathrm{g}$.

REQ-A-02b: The arm shall operate through its required workspace with a total wrist load of at least $400\mathrm{g}$, including gripper, object, adapters, and moving cable allowance.

The arm’s own links, fasteners, motors, and transmissions are also loads on upstream joints. They are not part of the wrist payload requirement, but they will dominate shoulder-joint torque calculations later in the course.

The distinction is especially important if the elbow motor is mounted out on the upper arm. The motor then becomes dead weight that the shoulder must lift.

Repeatability: distinguish it from accuracy

Repeatability asks: when the arm tries the same move several times, how tightly do the results cluster?

Accuracy asks: how close is the result to the intended physical target?

An arm may have good repeatability but poor accuracy. For example, it may return to a point consistently $12\mathrm{mm}$ away from the marked target because its geometric model or calibration is wrong. That can still be useful for a fixed pick-and-place task if the pickup and drop locations are taught. Conversely, an arm with inconsistent backlash may occasionally hit the correct location but be unreliable.

For this early project, repeatability is the more useful requirement. Define it with an endpoint test:

1. Home the arm.
2. Command a fixed target pose.
3. Mark or measure the TCP location.
4. Return to home.
5. Repeat at least 10 times with the same approach direction.
6. Record the largest endpoint deviation from the group of results.

A starter requirement might read:

REQ-A-03: At a target $300\mathrm{mm}$ from the base axis and $150\mathrm{mm}$ above the work surface, the arm shall achieve a maximum TCP repeatability spread of $5\mathrm{mm}$ or less over 10 full-payload trials.

The specified target should be within the normal working region, not at full extension. Full extension is useful as a separate stress test but often exaggerates deflection and backlash.

Speed: specify a task cycle

“Fast” is not measurable enough. Servo no-load speed, motor RPM, and a robot’s useful cycle time are different things.

For an arm, cycle time is usually the most meaningful speed requirement:

$$T_{\mathrm{cycle}}=T_{\mathrm{approach}}+T_{\mathrm{grasp}}+T_{\mathrm{transfer}}+T_{\mathrm{release}}+T_{\mathrm{return}}$$

This includes the pauses that make the movement useful, such as closing the gripper and allowing an object to settle.

An example requirement:

REQ-A-04: With a $250\mathrm{g}$ object, the arm shall complete a pick, lift, transfer over $250\mathrm{mm}$, release, and return-to-home cycle in $20\mathrm{s}$ or less for 10 consecutive cycles, without dropping the object.

This does not require the arm to move as rapidly as possible. It establishes a pace that can be validated safely and repeated. Later, motion profiles and feedback control will help the robot meet this target without overshoot or destructive impacts.

---

Defining the mobile-base requirements

The base has a different job. It does not provide reach in the same geometric sense as the arm; instead, it positions the arm near the work area. Its most relevant initial requirements are travel speed, runtime, maneuvering space, carried mass, and floor conditions.

The chassis type should follow those requirements. A differential-drive base is a strong provisional choice for an indoor robot because it can turn in place and is mechanically accessible. It is not automatically the best choice for every surface or maneuver.

For the mobile base, define the environment explicitly:

• Smooth indoor floor, short-pile carpet, or uneven outdoor ground?
• Maximum slope or threshold height?
• Minimum aisle width?
• Maximum total robot mass?
• Is the arm stowed while driving?
• Must the base turn in place, or is a larger turning circle acceptable?

A starter set of base requirements might be:

REQ-B-01: The mobile base shall carry the completed arm, battery, electronics, and a $250\mathrm{g}$ object on a smooth indoor floor.

REQ-B-02: The base shall sustain a straight-line travel speed of $0.25m/s$, measured over a $2\mathrm{m}$ indoor test course with a nominal battery charge.

REQ-B-03: The base shall be able to rotate in place within a $700\mathrm{mm}$ square clearance area.

REQ-B-04: During travel, the arm shall be in a defined stowed pose. Arm motion while the base is moving is outside the initial project scope.

That last requirement is valuable. It reduces both tipping risk and software complexity while you develop and test each subsystem. Mobile manipulation can come later, after the arm and base work independently.

---

Runtime is an energy requirement and a peak-current requirement

A mobile robot’s runtime must be tied to a duty cycle. “Run for 45 minutes” is ambiguous if the robot spends most of that time standing still.

Define the repeated activity. For example:

• Drive for $30\mathrm{s}$ at normal speed.
• Stop and perform one pick-and-place operation.
• Remain idle for $30\mathrm{s}$.
• Repeat this pattern.

Then state the required operating duration and reserve condition:

REQ-P-01: Starting with a fully charged battery, the integrated robot shall complete its defined duty cycle for at least $45\min$, retaining a $20\%$ energy reserve and without controller resets, excessive motor heating, or unsafe battery-voltage behavior.

Two electrical ideas matter from the start:

1. Energy capacity determines roughly how long the system can run.
2. Peak current capability determines whether the battery and power system can handle motors accelerating, lifting, or briefly stalling without voltage sag.

Average power provides a first runtime estimate:

$$t_{\mathrm{runtime}}\approx \frac{E_{\mathrm{usable}}}{P_{\mathrm{avg}}}$$

Battery energy is often approximated as:

$$E_{\mathrm{nominal}}\approx V_{\mathrm{nominal}}{C}_{\mathrm{Ah}}$$

Suppose an early bench measurement suggests an average system power of $35\mathrm{W}$, and the desired mission time is $0.75\mathrm{h}$. The mission energy estimate is:

$$E_{\mathrm{mission}}=35\mathrm{W}\times 0.75\mathrm{h}=26.25\mathrm{Wh}$$

This is not yet the required battery rating. You still need reserve capacity and must account for regulator and wiring losses. For a preliminary estimate using $80\%$ usable capacity and $85\%$ overall power-path efficiency:

$$E_{\mathrm{nominal}}\ge \frac{26.25\mathrm{Wh}}{0.80\times 0.85}\approx 38.6\mathrm{Wh}$$

That calculation is only an initial planning estimate. Actual runtime should always be verified with the real duty cycle. Motors do not draw their maximum current continuously, but their brief peak demands can be much higher than the average.

At this stage, do not select a final battery simply from the runtime calculation. The later power-distribution module will develop current budgets, motor stall current, regulator capacity, fusing, low-voltage protection, and battery safety in detail. For now, record two distinct future verification needs:

• The system must meet the required duration on the defined duty cycle.
• The power source must tolerate the expected peak current without unsafe heating or system resets.

---

Your initial requirements sheet

Create the first page of your engineering build log with a table like this. Treat the numerical values below as an editable starter envelope, not as universal targets.

ID	Priority	Measurable requirement	Verification method
REQ-A-01	Must	Arm TCP covers the required radial and vertical work zone with gripper installed.	Measure reachable TCP positions against a marked work surface.
REQ-A-02	Must	Arm operates with a stated total wrist load, including gripper and object.	Perform full-range motion and hold tests with measured mass.
REQ-A-03	Should	TCP repeatability is within a stated maximum spread at a defined target.	Run 10 home-to-target trials and measure endpoint locations.
REQ-A-04	Should	Full pick-and-place cycle time is below a stated limit at full payload.	Time 10 complete cycles.
REQ-B-01	Must	Base carries full integrated mass on the intended floor.	Drive and turn test with arm stowed.
REQ-B-02	Should	Base achieves a specified steady travel speed.	Time travel over a measured course.
REQ-P-01	Must	System completes a stated duty cycle for the specified runtime while retaining battery reserve.	Run logged endurance test under realistic loading.

Add these contextual assumptions beneath the table:

• Intended environment: indoor, level floor, supervised operation.
• Object family: list approximate dimensions, mass range, and surface type.
• Pickup and drop zones: sketch the table and write their distances from the arm base.
• Arm state during driving: stowed, with a stated joint configuration.
• Success condition: no dropped object, no uncontrolled motion, no controller reset, and no visible structural damage.

A requirement may change as you learn more, especially in a first custom robot. That is normal engineering. Preserve the original value, record the reason for the change, and revise the verification test along with it. A requirement changed silently is difficult to learn from; a requirement changed with evidence becomes a design decision.

---

Wrap-up

You have established the foundation for the rest of the build:

• Requirements describe outcomes that can be measured and tested, not preferred parts.
• Reach is a usable TCP workspace under stated conditions.
• Payload includes the gripper and all carried wrist-side mass, not only the object.
• Repeatability is consistency across repeated moves; it is distinct from accuracy.
• Speed is best expressed as a realistic, loaded task cycle time.
• Runtime must be attached to a duty cycle and separated into energy capacity and peak-current capability.

Next, you will turn these requirements into a functional block diagram that separates the mechanical, electrical, sensing, control, and software subsystems. That diagram will make the relationships between your arm, mobile base, microcontroller, Raspberry Pi, power system, and sensors explicit before any integration begins.