Matching research robot platform to research goal

The domain-platform mismatch problem

The most common source of research friction after procurement is a domain-platform mismatch: a platform that technically works but is a poor fit for the research question's actual requirements. A legged locomotion lab that buys a platform without torque-controlled joints cannot study compliant contact. An HRI lab that buys a platform optimized for outdoor navigation will fight the form factor for every user study. A multi-robot swarm lab that buys platforms with no peer-to-peer networking layer will rebuild that infrastructure from scratch.

This article maps each major research domain to the platform characteristics that matter, the ROS/ROS 2 ecosystem considerations specific to that domain, and the openness criteria that determine whether the platform is a research asset or a research obstacle.

The buy-vs-build-vs-simulate decision that precedes platform selection is addressed in the previous article: "Buy vs build vs simulate: the research robot decision."

Domain 1: Manipulation

What the research needs from the hardware

Manipulation research—grasping, dexterous in-hand manipulation, assembly, tool use—places the most demanding requirements on hardware of any research domain. The key hardware properties are:

• Joint-level torque sensing or torque-controlled actuators. Impedance control and compliant manipulation require either a series elastic actuator (SEA) or a field-oriented current-controlled motor with torque feedback. Position-controlled joints (the standard in most industrial arms) are unsuitable for compliance research.
• Wrist force-torque sensor access. Research on contact estimation, tactile sensing, and contact-rich manipulation requires real-time, low-latency access to wrench data.
• End-effector flexibility. Research grippers need to be swappable. A platform that only supports its own proprietary gripper closes off a large class of research.
• Payload and reach appropriate to task scale. Table-top manipulation (objects 50g–2kg, reach ~0.7m) requires different arm geometry than manipulation of objects at human scale.

ROS 2 ecosystem considerations

The manipulation community in ROS 2 centers on MoveIt 2, the motion planning framework. MoveIt 2 requires URDF and SRDF (Semantic Robot Description Format) models. A platform without a well-maintained MoveIt 2 configuration package is not ready for manipulation research until someone writes one.

For platforms with good ROS 2 support, the integration stack for manipulation is: ros2_control (hardware abstraction) → joint_trajectory_controller (execution) → MoveIt 2 (planning) → custom research stack (grasping, learning, etc.). Each layer adds a debugging surface; verify vendor support for each layer before purchase.

Toyota's Human Support Robot (human-support-robot-1) and DLR's Agile Justin (agile-justin) illustrate the range: the former is a research-oriented humanoid torso with a focus on assistive manipulation at human scale; the latter is a DLR-internal research system representing state-of-the-art bimanual manipulation capability. Community MoveIt 2 support varies significantly between platforms in this category.

Key evaluation question

"Does the vendor provide a ros2_control hardware interface and a MoveIt 2 configuration package, and when were they last updated?"

Domain 2: Legged locomotion

What the research needs from the hardware

Legged locomotion research—gait generation, contact planning, terrain traversal, whole-body control—has a short list of hard requirements:

• Torque-controlled joints with low-level API access. Virtually all state-of-the-art legged locomotion research requires direct torque commands at the motor level. Platforms that expose only high-level walking controllers (stand, walk, sit) cannot support whole-body control or novel gait research.
• Onboard IMU with high-rate, low-latency access. State estimation on legged systems depends on fusing IMU data with leg kinematics. Vendor-gated IMU access is a research blocker.
• Impact-tolerant mechanical design. Locomotion research involves falls. A platform designed for controlled demos will not survive a research lab's fall rate.

ROS 2 ecosystem considerations

Legged locomotion has a more fragmented ROS 2 ecosystem than manipulation. Most locomotion research groups maintain their own state estimator, contact planner, and whole-body controller rather than relying on shared community packages. The platform's role is to expose clean hardware interfaces, not to provide high-level controllers.

ANYbotics' ANYmal (anymal, anymal-d) has been extensively used in legged locomotion research, with published datasets and simulation models. The platform's design philosophy—torque-controlled SEA joints, full onboard compute, published URDF—was built for research extensibility. The legged community around ANYmal has produced a body of benchmark results that make it a reference platform for comparison.

MIT's Mini Cheetah (mini-cheetah) is a university-designed open-hardware platform with published specifications that has been adopted by multiple research groups specifically because its control architecture is accessible at the motor level. It illustrates the custom-build-to-research-community-adoption pipeline.

Key evaluation question

"Can the vendor provide a joint-level torque API with documented latency bounds, and is there a published simulation model with accurate mass properties?"

Domain 3: Mobile navigation and SLAM

What the research needs from the hardware

Mobile navigation and SLAM (Simultaneous Localization and Mapping) research—where the robot builds a map of an unknown environment while localizing itself within it—is the domain with the most mature commercial platform support. The requirements are relatively standard:

• LiDAR or depth camera with hardware timestamping. Sensor fusion accuracy for SLAM depends on tight timestamp synchronization between the sensor and the robot's motion estimate. Sensors without hardware timestamps are a research quality issue.
• Wheel odometry access at high rate (>100 Hz). Most SLAM systems fuse LiDAR measurements with wheel odometry. Odometry locked behind a slow high-level API degrades SLAM quality.
• Differential-drive or omnidirectional kinematics. Most indoor SLAM research uses differential-drive or omnidirectional bases. Ackermann steering (car-like) requires different kinematic handling.

ROS 2 ecosystem considerations

Mobile navigation has the most mature ROS 2 community support of any domain. Nav2 (Navigation 2) is the standard navigation stack in ROS 2, with active development and extensive documentation. The SLAM community has ros2-compatible packages for Cartographer, RTAB-Map, and several other algorithms.

Clearpath Robotics platforms like the Husky (husky-observer) and Dingo-O (dingo-o) have extensive Nav2 integration tutorials and community support. A new graduate student can move from platform receipt to running a SLAM experiment in under two weeks on these platforms, which is measurably faster than most alternatives.

For outdoor or large-scale SLAM research (parking lots, building exteriors, forests), the platform requirements shift toward GNSS integration, larger wheel diameters for terrain, and weatherproofing. Platforms optimized for indoor SLAM often do not transition well to these environments without significant modification.

Key evaluation question

"Are odometry and LiDAR timestamps hardware-synchronized, and is there a working Nav2 configuration in the vendor's ROS 2 package?"

Domain 4: Human-robot interaction (HRI)

What the research needs from the hardware

HRI research—studying how humans perceive, trust, and collaborate with robots—has unusual platform requirements because the robot's physical form and behavior affect the human subjects' responses. The relevant hardware properties are:

• Appropriate physical form for the study. An HRI study about robot expressiveness needs a robot with expressive degrees of freedom (head tilt, gaze, LED displays). A study about collaborative manipulation needs a platform capable of that manipulation. The form factor is not decorative.
• Quiet operation. Robot noise is an experimental confound in most HRI studies. High-frequency motor whine or hydraulic actuation noise affects user perception in ways that are not always controllable for in the analysis.
• Safety for close human proximity. HRI research requires IRB (Institutional Review Board) approval for human subjects, which in turn requires demonstrating that the platform is safe for close proximity. Platforms without published safety certification documentation add IRB friction.

ROS 2 ecosystem considerations

HRI research is more heterogeneous than navigation or manipulation. The software needs vary by study: some require speech integration (microphone array, text-to-speech, ASR), some require face tracking, some require whole-body motion generation. ROS 2 has packages for some of these (speech_recognition, face_recognition wrappers), but the integration effort varies.

Toyota's Human Support Robot (human-support-robot-1) was designed specifically for assistive and interaction use, with a form factor optimized for close human proximity and a focus on whole-body mobility in domestic environments.

The DFKI AILA (aila) is a research platform designed for studying human-robot cooperation in task-level interaction, illustrating the upper end of what purpose-built HRI hardware looks like versus a general-purpose platform adapted to HRI tasks.

Osaka University's Affetto (affetto) is a research-grade android face focused entirely on studying facial expression perception, illustrating how narrow-focus custom platforms can serve highly specific HRI research questions that no commercial platform addresses.

Key evaluation question

"Does the platform have published safety ratings for close-proximity operation, and is there a documented ROS 2 package for the speech/expression modalities my study requires?"

Domain 5: Multi-robot and swarm robotics

What the research needs from the hardware

Multi-robot and swarm research—coordination, consensus, formation control, distributed sensing—places requirements on the platform that single-robot work does not:

• Peer-to-peer communication hardware. Swarm research often requires robots to communicate directly with each other, not just with a centralized ROS master. Platforms with only WiFi interfaces add network topology constraints.
• Scalable unit cost. Swarm experiments require multiple robots—often five to fifty. Platform cost per unit directly determines experiment scale. A $15,000 platform limits most labs to three or four units; a $3,000 platform enables a dozen.
• Physical robustness at scale. When twenty robots are running simultaneously, hardware fault rate matters more than when one is. Mean time between failures becomes a throughput constraint.
• Accurate localization without external infrastructure. Many indoor multi-robot experiments rely on a MoCap (motion capture) system for ground-truth localization, but outdoor or large-scale experiments need onboard localization.

ROS 2 ecosystem considerations

ROS 2's DDS (Data Distribution Service) communication layer is better suited to multi-robot scenarios than ROS 1's centralized master architecture. ROS 2 supports namespaced nodes, multi-robot topic isolation, and ROS 2 domain IDs that let multiple robots operate without topic collision. This is an architectural advantage for multi-robot research.

The Clearpath Dingo-O (dingo-o) was designed partly with multi-robot use cases in mind—its small footprint and omnidirectional drive make it deployable at moderate fleet sizes. The DFKI MANTIS (mantis) is a research-grade multi-modal locomotion platform that illustrates a different point on the swarm morphology spectrum.

Key evaluation question

"What is the unit cost at quantities of five or more, and does the platform support ROS 2 namespace isolation for multi-robot operation?"

Domain 6: Underwater and aerial

Underwater

Underwater robotics research—ocean monitoring, seafloor mapping, subsea inspection, underwater manipulation—requires platforms built for the physical environment in ways that land-based platforms are not. Pressure housing, connector integrity, buoyancy control, and hydrodynamic modeling are domain-specific engineering that cannot be retrofitted onto dry platforms.

Nauticus Robotics' Aquanaut (aquanaut) and Independent Robotics' Aqua2 (aqua2) represent different points on the underwater capability spectrum—the former a large, capable subsea manipulation system; the latter a research AUV (Autonomous Underwater Vehicle) with a history of academic use. Festo's Aqua Ray (aqua-ray) and Aqua Penguin (aqua-penguin) are bionic research platforms that study bio-inspired underwater locomotion rather than operational surveying.

ROS support in the underwater domain is less mature than in terrestrial robotics. The Robot Operating System for underwater vehicles has seen effort from the MBARI and WHOI communities, but commercial underwater platforms are less likely to offer ROS 2 integration out of the box. Integration effort should be budgeted as high (two to four months) unless the vendor specifically supports ROS 2.

Export control is a significant consideration for underwater platforms; see "The research-robot procurement RFP" for ITAR and EAR treatment.

Aerial

Aerial research platforms—UAVs (Unmanned Aerial Vehicles), multirotor systems—occupy a distinct niche in research robotics. The PX4 and ArduPilot open-source autopilot ecosystems have strong ROS 2 integration (via MAVROS and the newer PX4-ROS 2 bridge). This makes commercial quadrotor platforms based on these autopilots more accessible for research than bespoke flight controllers.

NASA's Astrobee (astrobee), a free-flying robot designed for microgravity research on the International Space Station, represents the outer bound of aerial research platform specialization—purpose-built for a specific physical environment with open-source software that has been released for community use.

Aerial platforms face regulatory constraints (FAA Part 107 in the United States, similar frameworks in other jurisdictions) that affect where experiments can be run. Indoor flight test facilities are a common workaround, but they impose their own constraints on platform size and sensor placement.

Quick-reference domain summary

What comes next

Once the platform is selected, the lab needs to stand it up correctly. "A 90-day playbook to stand up a new platform in a lab" covers safety review, ROS environment setup, reproducibility and version control, dataset hygiene, and how to run the first reproducible experiment.