Wheeled unmanned ground vehicles are usually the first architecture to evaluate for continuous, traversable routes. Legged robots become attractive when steps, discontinuities, or constrained access prevent a suitable wheeled platform from reaching the work. Choose by asking whether the additional access justifies the legged system's control, integration, and support requirements. Neither architecture wins on every surface or mission.

A legged robot can itself be an unmanned ground vehicle (UGV). Here, the comparison is between walking platforms, principally quadrupeds, and conventional wheeled platforms. Mobility also says nothing by itself about who makes mission decisions: unmanned and autonomous describe different vehicle properties.

On This Page

Compare access before headline performance

Use the route's hardest unavoidable feature to shortlist architectures, then compare the complete mission. This table gives engineering selection guidance, not guaranteed performance for every robot.

DecisionLegged platformWheeled platform
Continuous firm routeWalking may add little mission value if all destinations are already accessibleA strong starting point for repeated transport or patrol
Steps and separated footholdsCan place feet beyond some obstacles, within its reach and balance limitsMust negotiate the obstacle through wheel geometry, traction, clearance, or a different route
Payload installationCheck leg sweep, body motion, mass properties, and sensor obstructionCheck mounting, clearance, combined center of mass, and terrain-dependent payload limits
Long mixed routeAccess gains must compensate for walking time and energyDetours may matter more than cruise speed if a direct route is impassable
Interrupted missionEstablish supported stopping, stable posture, and retrieval proceduresEstablish braking, slope holding, and retrieval procedures

The mechanism comparison draws on ETH Zurich's locomotion teaching material. Payload and stopping qualifications follow the manufacturer documentation discussed below. The mission choices are editorial interpretation.

Do not treat “rough terrain” as a single requirement. Describe the actual surface, obstacle shape, available clearance, and approach direction. If a wheeled platform fails that screen, wheeled versus tracked UGVs is another relevant comparison before deciding that walking is necessary.

How walking and rolling change the control problem

A wheel produces motion through rolling contact. Wheel arrangement and steering determine the vehicle's possible motions. Legs instead change the locations of support contacts: joints move a foot, establish contact, and transfer load as the gait progresses. The controller must coordinate these movements while maintaining the required body motion and stability. ETH's material identifies contact geometry, friction, center of gravity, and coordinated joint control as central distinctions.

For a concrete example, Boston Dynamics documents 12 degrees of freedom, three per leg, for Spot. Its specification page identifies the robot as Spot Gamma and gives a maximum step height of 300 mm. That is a model-specific specification, not a statement that every quadruped can traverse any 300 mm obstacle. The same page describes a stair geometry and operating constraints. Check the exact robot and documentation revision when assessing a staircase. Boston Dynamics: About Spot

Separate the locomotion controller from navigation and mission software. A command interface that can move the body is not evidence that the integrated robot can choose a route, detect every hazard, or finish an inspection without intervention. Our explanation of autonomous versus automated systems separates those decision responsibilities.

Compare useful work per charge

On suitable firm surfaces, rolling offers an efficiency advantage that helps explain interest in robots combining wheels and legs. Lee and colleagues demonstrated a system integrating walking and driving with local navigation and larger-scale route planning in urban missions. Their work supports the potential of hybrid locomotion; it does not establish a universal energy ratio between commercial legged and wheeled robots. Lee et al., 2024

Manufacturer runtime figures need similar restraint. The Spot Gamma page lists a 605 Wh battery and a typical runtime of 90 minutes. Clearpath's Husky A300 manual separates 40, 80, and 120 Ah configurations, with different battery energy, vehicle mass, runtime, and payload figures. Dividing one advertised runtime by another would mix configurations and operating conditions. Spot specifications, Husky A300 manual

For a site comparison, request energy consumed and elapsed time for the same completed task, with the intended sensor package operating. Include inspection dwell, detours, return travel, and charging access. Record incomplete runs separately rather than giving a robot credit for low energy use when it did not reach the destination.

A useful procurement question is: can the robot return with the required reserve after the most demanding scheduled route? The answer requires route measurements. Battery capacity alone cannot establish it.

Payload integration extends beyond kilograms

Start with the payload's geometry and mass distribution. Boston Dynamics warns that wide body-mounted payloads can interfere with Spot's legs and reduce mobility. Its configuration guidance also covers payload ports and placement. A sensor enclosure that fits on the back may still restrict the movements needed for the route. Spot payload configuration requirements

The software description must match the hardware. Spot's payload interface requires physical properties including center-of-mass location and moments of inertia for proper locomotion. It also documents time synchronization for measurements collected while moving. For an inspection payload, confirm the mounting transform, timestamps, and configured mass properties after the final assembly is installed. Spot payload software interface

For Husky A300, assess the combined center of mass and the applicable terrain payload limit. An allowable mass is not permission to place it anywhere on the chassis.

Then resolve the electrical and data interfaces. Clearpath's integration guide describes USB and Ethernet connections and recommends a separate network for custom CAN devices. It says adding devices to existing CAN networks requires significant testing. A shared connector or bus name therefore does not establish plug-and-play compatibility. Husky A300 integration guide

Ask the integrator to demonstrate the complete sequence: power-up, sensor availability, timestamped acquisition, mission interruption, and restart. Specify what happens to payload power and stored data during a stop. Mechanical access and successful sensor output need to be demonstrated together.

Make the payload configuration reproducible

Keep an installation record alongside the mission result. Identify the physical assembly, the mounting reference frame, the configured mass properties and the software revision used during the trial. Include cables, brackets and protective housings in the assembly being described. If equipment moves or is replaced, review whether the geometry and software description still represent the fitted configuration before repeating the test. This is an integration recommendation based on the payload dependencies above, not an additional manufacturer payload allowance.

The distinction is particularly important when comparing architectures: a bare-platform demonstration and a fully instrumented inspection run answer different questions. Ask each supplier to show the delivered sensor output from the configuration being evaluated. For Spot, the cited software interface describes both payload physical properties and time synchronization; successful service registration alone does not demonstrate those measurement and locomotion dependencies. For either architecture, retain the configuration record so a later software or mounting change can be compared with the setup that produced the accepted result.

Limits that can overturn the architecture choice

Stopping behavior deserves an explicit review. Clearpath warns that an unpowered Husky A300 can roll on a slope, and that it can also roll while in an emergency-stop state on a slope or ramp. Do not generalize “wheels stay stable” into a claim that stopping guarantees position holding. For a legged candidate, obtain the manufacturer's corresponding instructions for stopping, loss of power, posture, and recovery. Husky A300 manual

Maintenance should be compared through documented tasks and support terms. Request inspection intervals, replaceable wear items, diagnostic access, repair turnaround, and the permitted recovery method. Do not assign a failure rate or ownership cost merely by counting wheels or joints. A platform requiring retrieval from an inaccessible location can lose the mission benefit that justified its mobility.

Hybrids add another option, but also another integration question. Lee and colleagues' research combines adaptive locomotion with navigation that accounts for mobility. When evaluating a wheeled-legged candidate, ask how transitions are selected and what happens when the anticipated surface differs from the observed one. A driving demonstration and a separate stair demonstration do not establish reliable transitions on your route.

Match the mission and specify the trial

For a repeated delivery route on firm, accessible surfaces, begin by evaluating a wheeled solution. For inspection points reached only by unavoidable stairs or discontinuities, evaluate a legged solution against those exact access features. For a route mixing substantial rolling distance with unavoidable steps, include a hybrid or a route redesign in the comparison. These are starting hypotheses for testing, not product endorsements.

NIST distinguishes a standard test method from a standard robot: repeatable methods measure particular capabilities and enable comparisons. Use that principle to separate terrain, sensing, communication, and operator performance instead of accepting one impressive demonstration as proof of the whole mission. NIST: Ground Robot Tests

Agree on a trial that records:

  1. The exact robot, software, battery, payload, and permitted operating conditions.
  2. Every required destination and the obstacles on both outbound and return routes.
  3. Completion time, energy used, usable sensor output, and operator interventions.
  4. Controlled stopping and recovery demonstrations conducted within the manufacturer's instructions.
  5. Inspection, charging, and support work needed before the next mission.

Separate access, useful output and recovery in the trial record

Create a route matrix before the demonstration. Give each required destination its own row and identify whether the constraint is an unavoidable obstacle, a narrow approach, an operating surface or the sensor's required observation position. Record the allowed alternative route where one exists. This prevents a comparison from silently granting one candidate an easier task while describing both results as the same mission. It also makes a route redesign visible as a separate option rather than treating every access problem as a reason to buy a different locomotion mechanism.

Record arrival and usable work separately. A robot that reaches an inspection point has demonstrated access; the evaluation still needs the required sensor record, its location and its timing. Define that output before the trial and retain unsuccessful captures as unsuccessful results. If an operator repositions the robot or repeats a measurement, record that assistance with the corresponding run. These are proposed acceptance-record practices connecting the article's mobility and payload questions, not reported performance from either manufacturer.

Include the return path and the transition into the next mission. Keep travel, stationary work, interruptions and preparation time identifiable instead of presenting only one combined duration. When a trial ends early, record where it stopped, the observed reason and the permitted retrieval procedure that was used. Do not extrapolate an uncompleted route into a full-mission endurance result. The comparison can then distinguish a platform that lacks access from one that has access but needs additional integration or operator support.

Use the cited NIST methods when measuring an applicable individual capability, and label a custom site mission as a custom test. Preserve its route definition, operating conditions and scoring rule so another run can be interpreted against it. A repeatable comparison is useful only when the reader can tell what was held constant and what changed.

Choose the architecture that repeatedly completes the required task with acceptable intervention and recovery demands. Legs have value when they unlock necessary access; wheels have value when continuous travel serves the mission efficiently. The decisive evidence is the complete configured mission, including the return journey.

Sources

Last checked: September 10, 2026.