How robots work and how to judge their results

Follow one object from the camera to the tray

Consider an illustrative bench task. A robot must move a small block from a table into a tray. A conventional implementation could follow the sequence below. Some learned controllers combine several of these stages, so this is a teaching model rather than a required architecture.

MoveIt's planning documentation gives one concrete part of this process. A request can specify an end-effector pose and constraints. The planner checks modeled collisions and produces a trajectory with timing and joint limits. A collision-free plan still depends on the scene model matching the workspace. [1]

1. 1
   Observe

   Capture an image and identify the block and tray. Record when the image was taken.

2. 2
   Locate

   Express the block position in coordinates the arm uses. A camera mounting error can shift the target even when the image looks correct.

3. 3
   Plan

   Choose an approach and a path that keeps the arm, tool and carried block away from modeled obstacles.

4. 4
   Move and grasp

   Send commands to the controller. Confirm that the block remains in the gripper before moving away.

5. 5
   Verify

   Check that the correct block reached the tray and was released. An arm arriving at the target does not by itself establish a successful placement.

Use a failure to find the next measurement

Troubleshooting becomes easier when each observation has a corresponding check. In the bench example, an empty grasp and a dropped block happen at different stages. Combining both into a single failure count would hide useful information.

The table is an engineering diagnostic example. It does not establish the cause of a fault on a particular robot. Compare logs and observations before changing a controller.

Scroll sideways for all columns.

Read a success rate with its denominator

Suppose an illustrative report contains 20 attempts. Sixteen finish without assistance, two finish after an operator intervenes and two fail. The unassisted completion rate is 16/20, or 80%. Completion including assistance is 18/20, or 90%. Both figures can be correct, but they answer different questions.

Write down what counts as an attempt. Excluding difficult objects before the count begins can make the percentage look better while leaving much of the intended job uncovered. Also record setup time, restart time and whether the same object positions were reused.

A published industrial example is BMW's 2024 Figure 02 trial. The robot placed sheet-metal parts into fixtures for a downstream body-production process. That identifies a task and a setting. The announcement does not supply a trial denominator from which to calculate a task success rate. Do not add one. [2]

Choose the architecture from the job

Start a comparison with the part that must touch the world. Moving a pallet, reaching a valve, picking fruit and assisting a person during therapy produce different requirements. The route, payload, contact and operating conditions should be written down before choosing a robot shape.

For an illustrative fixed tabletop task, compare the arm's reach and tooling first. Add a moving base when the task requires travel. Add legs only after examining the terrain and the consequences of a fall. This ordering is a way to structure the comparison, not a universal purchasing rule.

The directory below keeps broad guides separate from their specialist subjects. Agriculture introduces the field workflow; harvesting explains fruit selection and handling. Aerial robotics introduces flight architecture; inspection drones focuses on usable inspection evidence.

Choose a guide for your task

The groups below separate machines used for a task from the software that commands them. Each link opens a guide with a worked example and the limits of the available evidence.