NimbRo Rescue: Solving Disaster-Response Tasks through Mobile Manipulation Robot Momaro

1 Introduction

• Four articulated legs ending in steerable wheels let Momaro drive omnidirectionally on suitable terrain and switch to stepping over larger obstacles.The hybrid design aims to combine fast wheeled travel with the terrain capability of legged locomotion.Source: §1 · pp. 1–2
• Two 7-DOF arms with dexterous grippers support one-handed work, bimanual manipulation, and tool use across an adult-sized workspace.Adjustable base height and attitude, together with a spine yaw joint, expand the workspace.Source: §1 · p. 2
• A 3D laser scanner, multiple cameras, microphone, and infrared distance sensor provide operators with environmental and auditory feedback.The paper motivates teleoperation because autonomous systems are not yet feasible for the complex DRC environments described.Source: §1 · p. 2
• A stereoscopic head-mounted display and two 6D hand trackers map operator head and hand motions to robot views and arm commands.A low-latency, low-bandwidth channel combined with a high-latency, high-bandwidth channel supports situation awareness under degraded communication.Source: §1 · p. 3
• Seven of eight DRC tasks in 34 minutes earned NimbRo Rescue fourth place overall and made it the best European team.The system was also tested in the DLR SpaceBot Cup and laboratory experiments.Source: §1 · p. 3

2 Related Work

• Earlier mobile manipulation platforms used wheeled, tracked, or legged bases, including NimbRo Explorer, a six-wheeled rough-terrain robot with a 7-DOF arm.The cited projects include purely wheeled systems and a platform designed for planetary exploration.Source: §2 · p. 3
• Four of the five best-placed DRC teams combined wheeled and legged locomotion, using wheels for fast flat-terrain travel and stepping for more complex terrain.The passage presents this placement pattern as a possible indication of advantages for the challenge tasks.Source: §2 · p. 3
• DRC-HUBO combined bipedal walking with knee- and ankle-mounted wheels, while CHIMP used powered tracks and avoided stepping over larger obstacles.DRC-HUBO could rotate its upper body to climb a ladder; CHIMP drove over obstacles on four tracks while maintaining a low center of mass.Source: §2 · pp. 3–4
• RoboSimian could step or drive on two active trunk wheels and two limb-mounted casters, whereas Momaro drove omnidirectionally and reserved two of its six limbs for manipulation.The paper links Momaro’s four locomotion legs to a large, flexible support polygon during mobile manipulation.Source: §2 · p. 4
• Momaro’s telemanipulation used consumer-grade Oculus Rift and Razer Hydra equipment, with the paper distinguishing its approach by intuitive operation under degraded communication.The related-work discussion contrasts the Hydra’s absolute-position sensing via a magnetic field with the Wiimote’s linear-acceleration measurements.Source: §2 · p. 4

3.1 Kinematic Design

• Momaro’s four legs each combine three pitch joints, ankle yaw, and independently driven wheels, enabling omnidirectional driving or stepping over obstacles.The design sought to reduce fall risk relative to bipedal locomotion while retaining wheeled travel speed.Source: §3.1 · p. 5
• Carbon-fiber spring legs passively adapt to terrain, adjust base height and attitude, and extend the manipulation workspace; two 7-DOF arms end in force-deforming, reconfigurable-finger grippers.The forelegs vary 40 cm in extension, and the minimum configuration provides 32 cm of chassis clearance; Momaro weighs 58 kg and has an 80 cm × 70 cm base footprint.Source: §3.1 · p. 5

3.2 Sensing

• A rotating 3D laser scanner, IMU, panoramic and top-down cameras, and cameras in the hands and beneath the base support scene perception and operator views.The right hand also carries a microphone for auditory feedback and an infrared distance sensor.Source: §3.2 · p. 7

3.3 Electronics

• A Core i7 computer with 32 GB RAM connects six microcontroller boards and 16 USB devices, while the laser scanner uses 100 Mbit/s LAN; 16 Ah batteries provide about 1.5–2 hours of task-dependent runtime and are hot-swappable.Two emergency-stop switches stop active servo commands; one is wireless, as required for DRC competitors.Source: §3.3 · pp. 7–8, Figure 5 · p. 8

3.4 Design Iterations

• After DARPA changed the task set, the team lowered the base box and lengthened the hind legs to improve car egress, completing these modifications only days before the competition.The paper describes this base iteration as the only major change from the robot’s initial design before the DRC.Source: §3.4 · p. 8

4 Perception

• Registered 3D laser scans update an egocentric local map, whose alignment estimates robot motion and compensates for wheel-odometry and IMU drift.The system registers each new scan against the accumulated map before updating it.Source: §4 · p. 8, Figure 6 · p. 9

4.1 Preprocessing and 3D Scan Assembly

• Robot and scanner motion are compensated during scan assembly using scan-line interpolation and a 6D state estimate from the head-mounted IMU and filtered wheel odometry.The state estimate captures motions caused by external forces such as rough terrain and environmental contacts.Source: §4.1 · p. 9

4.2 Local Multiresolution Map

• The local multiresolution map stores measurements and occupancy in increasingly large grid cells with distance, using ring buffers to bound memory and enable constant-time shifting.Per-cell sample means and covariances support scan registration; multiresolution uses fewer cells than a uniform grid without losing relevant information.Source: §4.2 · pp. 9–10, Figure 7 · p. 10

4.3 Height Mapping

• For footstep planning, the 3D map becomes a 2.5D height map whose nearby gaps are filled with local minima and whose heights are median-filtered.The local-minimum fill is motivated by occlusions: the high-mounted laser is more likely to occlude low terrain.Source: §4.3 · p. 10

5 Communication

• Stationary environmental information travels over a high-latency, high-bandwidth channel, while frequently changing data uses a low-latency, low-bandwidth channel; the operator station combines them for immersive 3D visualization.The DRC link imposed limited uplink and downlink bandwidth, intermittent high-bandwidth bursts inside the building, and possible packet loss.Source: §5 · pp. 10–11

5.1 Communication Architecture

• A field computer placed after the DCE buffers and relays data between an unreliable, bandwidth-unlimited wireless link and the reliable but bandwidth-limited DCE link.The operator station is the central unit, with separate ROS masters on the robot, field computer, and operator station.Source: §5.1 · p. 11

5.1.1 Low-bandwidth Channel

• The always-available low-bandwidth channel carries robot telemetry, selected-camera low-resolution video downscaled to 160×120 pixels, and up to 125 laser-scan-derived 3D contour points for live manipulation feedback.The selected image provides low-latency feedback; contour points outline the end effector and nearby objects.Source: §5.1.1 · pp. 11–13

5.1.2 High-bandwidth Burst Channel

• The burst channel buffers ROS messages on the field computer and streams the latest messages at 200 MBit/s, including camera images, map point clouds, logs, and diagnostics.Received 3D data is transformed into a fixed frame using low-latency transform information from the low-bandwidth channel.Source: §5.1.2 · pp. 13–14

5.1.3 High-bandwidth Direct Imagery

• When the high-bandwidth link is continuously available outside, a separate channel streams 5 Hz H.264 video from the overhead and right-hand cameras for low-latency control.This streaming mode is not used inside, where communication blackouts would corrupt the stream.Source: §5.1.3 · p. 14

6.1 Kinematic Control

• Limb goals are specified in Cartesian or joint space, interpolated to arrive concurrently, converted through inverse kinematics when needed, and collision-checked before execution.The 7-DOF arms use selectively damped least squares with nullspace optimization; the four-DOF legs use an analytical solver, and motion is aborted before self-collision.Source: §6.1 · pp. 14–15, Figure 11 · p. 15

6.2 Omnidirectional Driving

• A joystick’s base-velocity command is transformed into local wheel velocities, with wheel pairs rotating to their required yaw angles before moving.The wheel-velocity transform includes the wheel’s position relative to the base and permits simultaneous leg movement while driving.Source: §6.2 · pp. 15–16

6.3 Semi-autonomous Stepping

• The stepping module uses a 2.5D height map to choose steps automatically or manually, shifts weight to place the center of mass within the support polygon, and waits for operator adjustment if stability cannot be achieved.The target is the first possible foothold beyond the height difference being stepped over; balance control shifts weight back after placement.Source: §6.3 · pp. 16–17

7 Operator Interface

• Two operators control the lower and upper body, while up to seven support operators assist with views, maps, hardware monitoring, and motions.The system is designed for a minimum of two operators, and the actual number is flexible.Source: §7 · p. 17

7.1 Situational Awareness

• The main station combines camera feeds and a 3D environment view with diagnostic information, a height map, and configurable system modules.Camera views show the last received image, so operators use the newest available data.Source: §7.1 · pp. 17–18, Figure 14 · p. 18

7.2 Motion Design

• A keyframe editor supports offline motion design and online teleoperation through single-goal motions that can be adapted before execution.Users can specify joint configurations or Cartesian end-effector poses, with interpolation governed by velocity constraints.Source: §7.2 · p. 18, Figure 16 · p. 19

7.3 Immersive Bimanual Telemanipulation

• An Oculus Rift presents a robot-perspective stereoscopic view that follows the operator’s head, while two Hydra trackers map hand poses to the robot grippers.For small-scale manipulation, the operator can switch to a precision mode that scales down motion.Source: §7.3 · pp. 19–20, Figure 17 · p. 20, Figure 18 · p. 20

7.4 Locomotion

• During driving locomotion, a four-axis joystick controls base velocity, while a GUI lets the operator adjust the footprint, attitude, and stepping interface.The stepping display includes the robot footprint, center of mass, support polygon, and candidate step locations.Source: §7.4 · p. 21, Figure 19 · p. 21

7.5 Teleoperated Car Driving

• For the car task, a steering wheel controls the robot hand at the vehicle’s wheel, and a pedal controls the front right leg pressing the gas pedal.The driving interface also provides camera views, including a hand camera used to monitor nearby obstacles.Source: §7.5 · pp. 21–22, Figure 20 · p. 21

Evaluation scope

• The system was evaluated in simulations and lab experiments, at the DRC Finals, and during DLR SpaceBot Cup qualification runs.The qualification runs took place in September 2015; the DRC Finals were held in June 2015.Source: §8 · p. 22

Lab experiments

• Momaro cleanly stepped over a 20 × 15.5 × 154 cm wooden bar using a fixed sequence of basic stepping primitives.The obstacle was used to demonstrate that the robot met a DRC qualification requirement.Source: §8 · p. 22
• Momaro stood up from its lowest configuration, with the chassis on the ground, to a configuration suitable for driving.The motion relied mainly on strong hip actuators, supported by wheel rotation.Source: §8 · p. 22

8.1 DRC Finals

• Leg compliance provided passive terrain adaptation and let the trunk respond to environmental contact; leg actuator strength also contributed to opening the door.The hand was positioned under the door handle, then the robot raised its body to turn the handle upward.Source: §8.1 · p. 23

8.1.1 Car Driving and Egress

• Momaro completed the car task despite limited preparation; it exited successfully in the trial and first competition run, but an operator mistake caused the second-run attempt to be aborted.The robot was placed sideways on the passenger seat and used a combination of driving and stepping to climb backwards out; only a small wooden foothold was added.Source: §8.1.1 · p. 23

8.1 DRC Finals

• All attempted manipulation tasks were successfully solved, with reported times including locomotion from the preceding task.The listed times were calculated from recorded video.Source: §8.1.2 · p. 24

8.1.2 Door Opening

• After initially missing the door handle because it was too far away, the robot succeeded following a small pose correction.For the opening motion, leg extension pushed the handle upward from below.Source: §8.1.2 · pp. 23–24

8.1.3 Turning a Valve

• Momaro turned the valve successfully in both runs by repeating a grasp-and-turn sequence, since kinematic limits allowed only 286° of hand rotation per turn.A gripper fingertip was damaged during retraction in the first run, but the team continued without problems.Source: §8.1.3 · p. 24

8.1.4 Cutting Drywall

• The first cutting attempt was paused when the tool was found incorrectly assembled; in the second, base misalignment left material uncut, so a support operator finished the task manually.The cutting workflow used a fitted wall plane to correct angular alignment and an infrared sensor to monitor distance to the wall.Source: §8.1.4 · p. 25

8.1.5 Operating a Switch

• The switch surprise task was completed on the first attempt despite having no mockup for prior training.The operator closed the right fingers halfway, grasped the lever, then lowered the robot base to push it down.Source: §8.1.5 · p. 26

8.1.6 Plug Task

• The plug task required several attempts to move a plug 0.5 m between sockets, with a support operator controlling the left gripper by interactive marker.Additional finger segments increased the left hand’s contact area; a right-hand camera verified insertion.Source: §8.1.6 · p. 26

8.1.7 Traversing Debris

• Momaro drove through debris with its legs folded for stability, but became stuck in a traverse on the second run and overheated several actuators during recovery.The robot nevertheless completed the task after a prolonged recovery.Source: §8.1.7 · p. 26

8.1.8 Stairs

• Although stairs were not demonstrated at the DRC Finals, a lab climb took 149 s using the base as a ground contact and both forelegs to lift onto each step.Source: §8.1.8 · p. 27

8.1.9 DRC Summary

• Seven of eight DRC tasks were solved in 34 minutes, the lowest overall time among teams with seven points.Source: §8.1.9 · p. 27
• Momaro had the shortest locomotion time, while KAIST was fastest in five tasks; full-run testing began only about two weeks before the finals.Source: §8.1.9 · p. 27

• In the September 2015 qualification, Momaro crossed extraterrestrial-like terrain while manipulating objects on the ground with both hands.Source: §8.2 · p. 28

• The hose task required bimanual teleoperation to join two flexible hoses that were not attached to a stable base, with no locomotion needed.Source: §8.3 · p. 28
• Slightly more than three minutes were needed on average across ten completed trials, and connecting the hoses took more than half the elapsed time on average.The upper-body operator needed more than one attempt to connect them; one of 11 trials was stopped after the right arm moved into the robot base.Source: Table 5 · p. 29, §8.3 · p. 29
• A support operator managed HMD camera views and triggered grasps, while the upper-body operator relied on point-cloud and 2D camera feedback.The operators were in another room and received information only from robot sensors; communication bandwidth was not limited.Source: §8.3 · p. 29

9.1 Mechatronic Design

• Low-cost off-the-shelf actuators overheated under high torque, constraining teleoperated stair attempts; the authors propose cooled or stronger leg actuators and autonomous hybrid locomotion planning.Delays while reaching stable configurations could lead to overheating and falling.Source: §9.1 · p. 29
• Spring compliance reduced precision demands and helped the robot ignore small obstacles, but unmeasured leg deflection could shrink the support polygon.The authors propose measuring compliant-part deflection so operators and autonomous behaviors can respond to unintended configurations.Source: §9.1 · pp. 29–30

9.2 Operator Interfaces

• An operator’s wrong motion caused a second-run failure, and the interfaces lacked safeguards against dangerous commands; the authors propose anticipating errors and adding automatic pauses.Source: §9.2 · p. 30

9.3 Sensors

• Seven strategically placed color cameras augmented the 3D laser map because their images were inexpensive, interpretable, and useful in harsh light.Source: §9.3 · p. 30

9.4 Preparation Time

• The stair solution was found the night before the second run, and the authors note that another preparation day might have been needed to solve all tasks.They also acknowledge that other factors could still have prevented that outcome.Source: §9.4 · p. 30

10 Conclusion

• DRC success demonstrated the feasibility, flexibility, and usefulness of Momaro’s robotic platform and telemanipulation interfaces.The system was also evaluated in the DLR SpaceBot Cup qualification and lab experiments.Source: §10 · p. 30
• Operators rely on point clouds, visual and auditory feedback, and joint sensors; added touch and force-torque sensing could improve manipulation.The authors identify peg-in-hole tasks such as the DRC plug and hose tasks as potential beneficiaries because they require precise, dexterous manipulation.Source: §10 · pp. 30–31
• The telemanipulation system has low autonomy and requires multiple operators, creating a staffing burden when trained operators are unavailable.The authors identify autonomous monitoring, operator assistance, and more autonomous task execution as ways to make the system manageable by fewer operators and reduce cognitive load.Source: §10 · p. 31