Match a robot platform to the task
Choose a robot by proving it can perform the specific job in the place, with the people, software, and operating support you actually have. A form factor or headline specification can narrow the search, but neither establishes task fit. Start with observable outcomes, then ask vendors to demonstrate the complete configuration against them.
Describe the job in observable terms
Write down what a person should see happen from start to finish. “Interact with visitors” is too broad to evaluate. “Move to a marked station, turn toward a visitor, play an approved greeting, wait for an operator cue, and return to the start point” is testable. For a handling task, name the object, where it begins, where it must end, and what counts as a correct placement.
Record the operating conditions alongside the sequence: floor surface, thresholds, available space, lighting, noise, network access, nearby people, object variation, and the time allowed for setup and reset. Say whether the task must work unattended, with a remote operator, or with an operator beside the robot. Those are different requirements. Define what should happen when an input is missing or a step fails; recovery is part of the job, not a footnote.
Separate must-haves from attractive extras
Make a short pass/fail list before reviewing demonstrations. A must-have could be fitting through a doorway, carrying a specified item, accepting a required control interface, or operating on a surface present at the site. Phrase each one so that a test can settle it. If an item is a preference rather than a condition of success, label it as such.
Extras can still matter. A particular appearance, a second sensor, or a broader developer interface may improve a program, but should not compensate for a failed essential task. Assign each requirement an owner who can say why it matters: the instructor, facilities lead, IT team, operator, or project sponsor. This exposes hidden dependencies early and makes later tradeoffs easier to explain.
Compare platform families
Use families to organize questions, not to declare a winner. A fixed arm can suit work at a prepared station where reach and repeatable positioning matter. A wheeled mobile base can move between stations on suitable floors. A quadruped may be considered when the task involves varied terrain, but stairs, obstacles, payload, and interaction still need direct validation. A humanoid can make sense when human-height reach, two arms, or a human-shaped presence is central; that shape does not itself prove safe, dexterous, or reliable behavior.
For tasks that combine travel and handling, assess the base and arm as one system. Northwestern’s Modern Robotics treatment explains mobile manipulation as coordinated control of a mobile base and an arm, including cases where the base first parks and the arm then performs more precise movement (Mobile Manipulation). Ask whether your task needs the base to keep moving while the arm works or whether a stop-and-reach sequence is enough. Those alternatives change the test and the required software.
Test the full operating setup
Evaluate the delivered robot with the end effector, sensors, compute, battery, charger, controller, networking, software version, and accessories named in the proposal. A video of a different unit or an unlisted attachment does not establish what the quoted configuration can do. For example, maker pages distinguish the Unitree G1 from G1 EDU configurations and distinguish AGIBOT X2 editions; check the exact maker-listed variant rather than transferring an observed capability across the product family (Unitree G1; AGIBOT X2 product overview).
Rehearse the setup sequence as well as the task. Can the named operator connect, initialize, confirm status, pause, recover, and shut down using the supplied instructions? Can the team reproduce the demonstration after a restart? Note required accounts, network rules, tools, and specialist help. A capable robot that cannot be prepared or supported by the available team may not fit the program.
Ask for evidence at the task level
Request a demonstration using your written task and conditions. Ask the supplier to identify the exact model, options, software and firmware versions, operator role, and any environmental assumptions. Agree beforehand on observable pass conditions: which steps must complete, what counts as an intervention, and what should be recorded when the task fails. Repeat the scenario with relevant variations, not only the best-looking run.
Keep evidence separate from claims. A polished video can show that a motion occurred once; it may not show setup, failure handling, or the delivered configuration. Request a live demonstration, a written test record, or both. If a requirement remains unverified, put it on the open-questions list and make the decision conditional on that evidence rather than silently treating it as solved.
Method and limits
This guide turns task definition and platform concepts into a buyer’s evaluation method. The Northwestern source explains mobile-manipulation concepts; maker pages provide examples of configuration-specific descriptions. Neither source establishes that a particular robot will succeed in your environment. Confirm task performance, integration, support, and site requirements with the supplier and your technical and institutional reviewers. Product models, options, and documentation can change. Maker-source check: October 20, 2026.