Research robots: check the software before the hardware

For a university or development team, the right platform is the one that supports the experiment. Hardware access, software and technical support matter as much as appearance.

Start with the research question

Is the work about navigation, manipulation, balance, perception or human interaction? Identify what must be measured or controlled. A large humanoid may be useful for one experiment and unnecessary for another. A smaller wheeled platform or an arm on a bench can sometimes provide the required access with a simpler experimental setup.

Ask for the exact access level

Request documentation for the offered configuration, including control interfaces, sensor streams, logging and supported programming languages. Ask which functions are available to users and which remain restricted. “SDK included” is not enough: the software development kit must expose what your project needs, on terms your institution can accept.

Check versions and dependencies

ROS is distributed in versions with their own documentation and supported environments. Ask for the precise version used by the robot, operating-system requirements and supported examples. A general claim of ROS compatibility does not establish that your existing code will run. Have the intended researcher review installation instructions before an order.

Separate a demo from a reproducible experiment

Ask whether example behaviours are supplied as editable code or only as demonstrations. Check whether simulation models are available and what they represent. Record any limits or differences between simulated and physical behaviour. For an initial evaluation, choose a small experiment that your own team can reproduce using the supplied documentation.

Plan people, space and support

Identify who will commission, maintain and supervise the platform. Agree the required experimental space with the relevant technical and safety teams. Ask how faults are diagnosed, where repairs happen and how research modifications affect support. A low purchase price may be poor value if the platform is unavailable during a funded project.

Agree the acceptance evidence

Before payment, define what delivery should include: the exact configuration, accessories, software access, documentation and training. Ask for a demonstration of the interfaces that matter to the experiment. Keep claims about future software separate from functions available today. The purchasing decision should reflect the project you can run, not only the capabilities promised on a roadmap.

Further reading

ROS: distributions, installation and documentation. The questions and example approaches in this guide are Robodromo’s buying guidance, not a supplier specification or a completed customer project.

Tell us what your organisation wants to achieve.

Related guides

• Robot kits for education: what should a good package include?
• Humanoid or quadruped robot: which makes sense for you?

Exploring robotics for your organisation? Find out how we help you find a robotics supplier, or tell us what you would like to achieve.