UAV/UGV Autonomous Cooperation: UAV assists UGV to climb a cliff by attaching a tether

In short: robots that explore dangerous places keep getting stopped by steep drops, and what lies above stays unexplored.

The paper opens with the places exploration robots must work in: disaster areas, rough outdoor fields and planet surfaces. In all of them the ground is broken, steep and unknown, and no one can go ahead to prepare a route.

The robot you want there is a ground robot (a UGV, an unmanned ground vehicle). It has a large battery and can carry heavy equipment: sensors, strong computers, even robot arms that can pick things up. But a ground robot can only go where its tracks can take it. A drop taller than the robot, like a collapsed floor, a steep bank or a crater wall, ends the mission.

The player scene shows these settings as simple illustrations. The paper itself tests the idea in an indoor lab field (scene 4).

In short: a drone can see and reach the top but can’t carry much; a ground robot can carry a lot but can’t get up. Earlier teams only used the drone as a camera.

The paper sets up a simple trade-off:

• A drone (UAV, an unmanned aerial vehicle) is easy to get anywhere. It flies over obstacles, rough ground and steep slopes, and sees a wide area from above. But its payload and battery are small, so heavy equipment and complex handling are out of reach.
• A ground robot has a bigger battery and payload, but its sensors don’t see far, and it is poor at crossing rough terrain and climbing.

What people did before, and where it stops

Drone as a flying camera. Many air–ground teams fix the ground robot’s short sight: the drone scans a wider area so the ground robot can find its way. One team, for example, mapped an earthquake-damaged building with a drone that rode on the ground robot until the way was blocked. Tether-powered drones fix the drone’s battery problem by sending power up a cable, and some systems even connect a drone and a ground robot with a cable. In all of them, though, the drone only senses.

A winch and a cable. For climbing, a winch (a motor that reels in cable) works, like a climber being hauled up on a rope. Off-road cars winch themselves up very steep slopes; two-wheeled tethered rovers have explored steep crater walls with the help of a “mother” vehicle; one tethered rover built 3-D maps of steep terrain. The catch: the tether must be fixed at the top beforehand, by a parent rover or a person. So the robot can only reach places someone could already get to, plus what hangs below them. One exception fires a grappling hook upward, but it can’t get over a cliff or aim at an anchor it can’t see from below.

In short: the drone carries the cable over the cliff and winds it around a pole; the ground robot then reels itself up. The drone is both the scout and the one who fixes the rope.

The proposal: connect the two robots with a tether and let the UAV fix its end on top of the cliff. The drone is then two things at once: a flying sensor that maps the terrain for the ground robot, and the device that attaches the anchor where the ground robot can’t go. The UGV carries a winch strong enough to lift its own mass and winds the tether to climb.

The authors say that, to their knowledge, this is the first system that uses a UAV to attach a tether the UGV then uses to extend where it can reach. For it to work on its own, the drone must detect an anchor point and attach the tether automatically; the drone also needs state estimation, trajectory following, obstacle avoidance and 3-D mapping; and the ground robot must plan paths from the drone’s map.

What the paper contributes

1. A cooperative system that navigates an unknown environment together, uses the drone to attach a tether where the ground robot can’t reach, and lets the ground robot climb steep terrain with that tether.
2. A comparison of ways to attach a tether (scene 7).
3. A framework for autonomous joint navigation, cliff detection and tether attachment.

In short: in a lab field with an obstacle, a steep slope and a pole, the two robots did the whole job by themselves, one step after another.

The test mission, in the paper’s words, runs like this. Both robots start together and head for a goal. Until they reach a cliff, the UAV flies ahead of the UGV and builds a voxel map (a 3-D map made of small cubes); the UGV plans a path on that map that avoids obstacles and rough ground, and follows the drone. Once a cliff is detected, the UAV flies above it and searches for an anchoring point. When it finds one, it flies around it to attach the tether, then lands autonomously in a safe area. Finally the UGV winds the tether and climbs. The mission ends when the cliff is climbed.

The field was built indoors: an obstacle in front of the UGV, a steep slope in the middle, and a pole on top of the slope as the intended anchor. The two robots share their positions and maps over Wi-Fi through ROS (the Robot Operating System, common robot software).

The 3-D scene follows this layout. Its timing and paths are illustrative, not replayed from logs. In the real run, the UAV’s motor stop and the winch switch were triggered by hand for safety.

In short: the drone works out where it is, maps what it sees and plans around obstacles, all with its own small computer, and shares the map with the ground robot.

Hardware. A custom-made quadrotor with an NVIDIA Jetson TX2 for fully on-board localization, mapping and navigation, plus a custom flight controller for attitude control and sensor interfaces. Sensors: a global-shutter monocular fisheye camera, a time-of-flight (ToF) depth camera, a laser for height, and the flight controller’s IMU. The TX2 and the flight controller talk over serial, with telemetry and commands both at 100 Hz.

What this means: the slow sensors (camera, depth) give position and shape; the fast ones (laser, IMU) fill in between, so the controller gets odometry quickly enough to fly close to a pole.

Software. The drone has no GPS indoors, so it must work out its own position from what it sees. It uses visual-inertial odometry (VIO: tracking its motion from camera images plus the motion sensor, the IMU), following an earlier drone framework. The VIO library ROVIO was chosen because it needs no start-up motion and is light to compute. A Kalman filter fuses the VIO pose with the laser height, estimates both the VIO and the laser bias, and throws out laser outliers by Mahalanobis distance. An extended Kalman filter (EKF, a standard way to blend noisy sensors) then fuses that with the IMU for fast position updates.

For obstacles, the Octomap library builds a voxel map from the ToF camera’s depth points, and a motion-primitive planner (a customized MRSL Motion Primitive Library ROS package) computes an obstacle-avoiding reference trajectory at 5 Hz, which matters because attaching the tether means flying close to structures. A linear MPC (model predictive control: repeatedly plan the next moments of motion with a simple model, apply the first step), using a measured model of how the drone tilts, turns the trajectory into roll, pitch, yaw-rate and thrust commands; the flight controller’s PID loop does the rest.

Test: fly, dodge, land

The drone took off to 1 m, flew towards a goal 2 m ahead, and had to dodge an obstacle a person held up on the way. At the end, the grid map was used to pick a safe landing spot, computed on the UGV, and the drone landed there (the final motor stop was done by hand for safety). The paper reports that localization and control were good enough for a fully autonomous mission.

In short: the ground robot turns the drone’s map into a “how easy is it to drive here” score, plans the cheapest route, and concludes “cliff” when every route is too expensive.

Hardware. A custom robot on a commercial tracked (caterpillar) platform with an UP Core computer, an IMU, per-motor PID control with encoders, and a custom winch. The winch motor uses a simple sensorless relay switch to get high power output. The computer exchanges commands and odometry with the motor controller at 100 Hz.

Software. The UGV keeps track of its position by dead reckoning: adding up wheel-track motion and IMU readings. It receives voxels from the UAV, converts them to a grid map, and runs path planning and cliff detection on it; a standard path-following method (Pure Pursuit: steer toward a point a little way ahead on the path) drives it.

From voxels to traversability

The ToF depth data are noisy, so the grid map is filtered in several passes: inpainting of holes, slope and roughness, then traversability:

A minimum filter with a 30 cm radius then spreads low traversability to the neighbouring cells, so the robot keeps its distance from bad spots.

Path cost and cliff detection

A* (a classic shortest-path search) finds the cheapest route across the 2-D grid. Each cell costs

The planner doesn’t model the tether or the robots’ motion. Cliff detection reuses it: if a cheap path to the goal exists, there is no cliff. If even the best path costs more than a threshold, the way is blocked. To avoid a false alarm when the goal itself sits on an obstacle, the goal is moved around within a range and the lowest-cost variant is kept. If that still exceeds the threshold, there is an unavoidable cliff, and that lowest-cost goal is handed to the state machine for the next manoeuvre.

Landing spot. Around the drone’s current position, the UGV looks for cells with a defined value, a small elevation difference, low slope and high traversability, and hands such a spot to the state machine.

In short: to find something to wind the cable around, the drone looks for spots where the height is concentrated in one point, like a pole, rather than spread along a line, like an edge.

A good anchor stands some height above the surface, is not in a cluttered area, and sticks up clearly: a tree trunk, a stump, an outcropping rock, a pole. The drone searches the UGV’s grid map around its current position with a filter on the elevation layer that scores peakness.

For a candidate cell c, take the valid neighbours 𝒩 within a radius, and let h(p) be each neighbour’s height above the lowest cell in 𝒩. Weighting offsets by that height gives a covariance:

Above a threshold, the cell is an anchor. The filter only runs on cells that are the highest within their radius. The key choice is the larger eigenvalue: a pole keeps both small, but an edge spreads height along one direction, so the smaller eigenvalue or the mean would also mark edges as anchors.

In short: of six ways to fix a cable, the paper picks a hook plus winding. The drone circles the pole once and then half a turn more, because that stopping point caught best in tests.

This is the most unusual part of the system. The paper weighs six ways to fix a tether to the environment:

1. Grappling hook: light and simple, but it is hard to find a spot to hook, and the hook can come loose.
2. Winding the tether a few turns around a pole, held by friction: no special device, but the drone must find a pole and fly the right path. A rope bridge was once built this way, but with pre-computed trajectories and motion capture.
3. Grasping device: the drone itself becomes the anchor and can let go easily, but it can’t grip large structures and may get too heavy for the torque a large UGV needs.
4. Peg driven into soil: works almost anywhere there is soil, but the insertion mechanism gets complex.
5. Magnet launched at the target: limited to magnetic surfaces.
6. Hybrid hook + winding: the drone winds a grappling hook around the structure, which raises the chance of a successful anchor compared with 1 or 2 alone.

Criterion	Hook	Winding	Grasp	Peg	Magnet	Hook + wind
device simplicity	★★★	★★★	★★★	★★★	★★★	★★★
control simplicity	★★★	★★★	★★★	★★★	★★★	★★★
lightness	★★★	★★★	★★★	★★★	★★★	★★★
unhooking capability	★★★	★★★	★★★	★★★	★★★	★★★
strength	★★★	★★★	★★★	★★★	★★★	★★★

What this means: the hybrid ties for best on simplicity and lightness and is the only one with full marks for strength. Its weak spot, shared with hook and winding, is getting the tether back off, which the paper leaves for future work.

How far to go around

After one full revolution around the pole, the drone keeps going by a revolution angle before leaving. To choose it, the authors placed the hook by hand every 20° and pulled it with the winch on a smooth floor. Only cases where the hook caught the tether counted as success; catching on the surroundings counted as failure. The most successful angles were near 0° or 180°. The mission uses 180°: it raises the chance of hooking onto some structure, and it keeps clear of the UGV after it climbs.

In short: every part worked in a test, and the full mission succeeded once in the lab. The paper reports these as outcomes, without success rates.

Each component was tested first, then the whole mission. The paper reports all outcomes in words; there are no success rates or trial counts for the navigation or the mission.

What this means: every step of the chain worked at least once in the lab, which shows the idea is feasible. How reliably it works was not measured.

In short: the biggest problem was a slack cable tangling the ground robot; keeping the cable tight is the key next step.

Tether slack. This was the main lesson. With no tension sensor there was no tension control, so the tether had to be let out from the start. Lying on the ground, it got tangled in the UGV many times as the robot drove towards it, and the experiment had to be stopped. Without the tether, the navigation succeeded “with a high probability”.

• Safety steps were manual: the UAV’s motor stop and the winch switch in the mission, and the final motor stop in the flight test.
• One indoor field, with a pole placed as the anchor. Natural anchors (trees, rocks) are discussed but not tested.
• No reliability numbers. Outcomes are reported as successes, without trial counts.
• Unhooking the tether after the climb is not solved.
• The path planner ignores the tether and the robots’ motion models.

Future work named in the paper: smarter tether tension control (called crucial), tether-aware planning, power and communication over the tether, collaborative mapping and localization, and tether unhooking.