Band-Separated Redundant Communication for a Mars-Analog Rover

Band-Separated Redundant Communication for a Mars-Analog Rover Zamiul Rashid, Akid Anis, Tanzim Ahmed, Md. Golam Rabiul Alam∗ , Md. Khalilur Rhaman∗

arXiv:2611.02131v1 [cs.NI] 1 Nov 2026

BRAC University, Dhaka, Bangladesh {zamiul.rashid, akid.anis, tanzim.ahmed3}@g.bracu.ac.bd {rabiul.alam, khalilur}@bracu.ac.bd

Abstract—Teams in the University Rover Challenge (URC) drive their rovers remotely and often out of sight. The organizers name communication failure as the most common reason a team falls short. A rover therefore needs bandwidth for several camera views and a command path that survives the loss of one radio. We describe and field test the communication stack of the BRACU Mongol-Tori rover, which keeps vision and control on separate radios and bands. Video and RTK corrections travel over a 5.2 GHz bridge with a 2.4 GHz backup, and the Babel routing protocol chooses between them. Every command goes out on two sub-gigahertz radios at once, and the rover uses the backup copy only when the primary falls silent. We tested the backhaul on the bench with a power cut and injected packet loss. We also drove the rover more than a kilometer from the base, and line of sight ended about halfway. On the bench, traffic reached the backup within a few seconds. A metric offset kept it on a primary that lost one packet in ten. In the field, the primary failed at 771 m and the backup carried video and corrections to just over a kilometer. The drive also exposed a limit of Babel, which judges a link only by lost Hello messages. It kept traffic on a primary with a faulty receiver, although the backup reported twice the capacity, and it flapped at the edge of range. We close with lessons on antenna aiming, link metrics and logging. Index Terms—rover teleoperation, redundant telemetry, link failover, Babel routing, RTK corrections, field measurement

I. I NTRODUCTION The University Rover Challenge (URC) asks student teams to build Mars analog rovers and to operate them at the Mars Desert Research Station in Utah. Operators drive from command stations that block their view of the rover [1]. Rovers may travel up to 1 km, and in the Delivery Mission line of sight is not guaranteed for more than half the course. One task sits in a remote canyon where communication problems are expected [2]. The organizers call communication failures the most common problem that keeps a team from contending [3]. A rover built for these events therefore has two communication needs that pull in different directions. Operators need several live camera views and a stream of RTK corrections for precise positioning. These need an IP link of several megabits per second, which in practice means a Wi-Fi radio. Such radios lose range quickly once trees or terrain block the line of sight [4], [5]. Commands need little bandwidth but must arrive within milliseconds. Low-rate sub-gigahertz radios suit them and reach farther. Carrying both on one link couples their ∗ Supervisors.

failures, because a saturated or fading video link also delays the commands. Published team reports describe a single link, or a backup link whose transition is not measured (Section II). Routing protocols such as Babel can choose between two links automatically. They have been compared as multi-hop mesh protocols, but not as the switch between the primary and the backup link of one vehicle. A team that chooses a design thus has little measured evidence on how fast a backup takes over, or on what makes it take over. The BRACU Mongol-Tori stack keeps vision and control on separate radios in separate bands. Video and RTK corrections travel over a 5.2 GHz bridge, the Rocket link. A 2.4 GHz bridge, the Bullet link, is its backup. Babel runs on a router at each end and chooses between the two links. Every command goes out on a 900 MHz and a 433 MHz radio at once. The rover’s controller acts on the 900 MHz copy unless none has arrived for about 500 ms. Each of these mechanisms is established practice. Our contribution is a measured account of how they behave together on a Mars-analog rover, both when a link fails and when it only degrades. We measured the stack in three campaigns. All ran in Dhaka, Bangladesh, and none at a competition site. The command switchover was timed in ten trials in which the 900 MHz radio was powered off abruptly. On the bench we powered off the primary video radio. In separate runs, Linux netem injected rising loss and delay on its router ports while the radios stayed associated. Echoes every 10 ms between base and rover timed each outage, and each router’s route was read every second. Runs were made with and without a metric offset that favors the primary. Finally, the rover drove 1.3 km from the base, in line of sight to about 600 m and behind trees beyond. Along the drive we logged signal and capacity from all four radios and the route in use. We also logged echoes, every RTK epoch and correction frame, and one live video stream. The received signal was then compared with the antenna geometry, using the rover’s RTK height and the antenna datasheets (Section V). Our contribution is fourfold. First, we describe a band separated rover stack in which video and corrections share no radio with control (Section III). We also name the single points of failure that remain. Second, we explain Babel as a selector between a primary and a backup link, checked against the babeld source (Section IV). The account covers how lost

Hellos set the link cost and how an offset makes one link primary. It also shows why one route per destination gives failover rather than load balancing. Third, we measure the stack on the bench and in the field (Section VI). The bench gives outage times after a power loss and a blockage, and the loss at which the offset gives up the primary. The drive gives range, echo loss, video continuity, correction delivery, RTK accuracy and route choice over 1.3 km. Fourth, we distill lessons for other teams on antenna aiming, link metrics, load and logging (Section VII). II. R ELATED W ORK Snider et al. survey eight URC teams, most of which rely on a 2.4 GHz link from a tall mast [4]. One surveyed team backs its 2.4 GHz video link with a 433 MHz LoRa link for telemetry. Another declares the link lost after two failed pings sent 3 s apart. Neither reports how long the switch takes. Phoenix carries video on 5 GHz and commands on 900 MHz [6]. A multiplexer moves its commands to 2.4 GHz on an error or delay in the 900 MHz band. The paper reports command response times but not how a fault is detected or how long the switch takes. BYU found its 2.4 GHz link unreliable out of line of sight [5]. The team replaced it with one 900 MHz link and a GPS-steered Yagi antenna and measured 2.53 Mb/s at 1 km in line of sight. West Virginia University paired 2.4 GHz with 900 MHz [7]. Its later rover added 70 cm packet radios for low-rate control and described a seamless transition out of line of sight, without its mechanism or timing [8]. Our team’s earlier rover sent commands over a 2.4 GHz bridge and video on a separate analog transmitter, with no backup for either [9]. None of these reports measures a switchover. Güldenring et al. flew a search and rescue aircraft with three LTE links [10]. Single links were available 68–97% of the time and the combination up to 99.8%. The combined figure counts any link that answered an echo. It therefore bounds what switching could achieve rather than measuring a switch. Lau and Ang switch a delivery drone between cellular, SMS and satellite links when a heartbeat times out [11]. In lab tests their adaptive timeout failed to converge once delay jitter exceeded 1 s. PRP and IEEE 802.1CB avoid switching altogether [12]– [14]. Each frame travels over two paths and the receiver discards the duplicate, so recovery is bumpless. Our command radios also duplicate every message. The controller, however, prefers the primary’s copy instead of keeping the first to arrive. Babel [15], [16] is a distance-vector protocol for networks with lossy wireless links. Neighbors exchange periodic Hellos, and the specification suggests ETX for the cost of a wireless link. ETX is the inverse product of the forward and reverse delivery ratios of broadcast probes [17]. A delay extension adds a penalty that grows with round-trip time [18], [19]. To avoid oscillation, a router switches routes only when the candidate’s metric is no higher and its smoothed metric is lower. No input to the cost reflects signal level or capacity. Testbed studies compare Babel with OLSR and B.A.T.M.A.N. as a mesh protocol. On eight indoor nodes

TABLE I R ADIO L INKS AS C ONFIGURED FOR THE F IELD D RIVE Link

Band

Rocket 5AC Lite

5200 MHz, 20 MHz

Bullet AC

2462 MHz, 20 MHz P900 902– 928 MHz FHSS, one sub-band SATELLINE- 433 MHz, EASy 25 kHz 4FSK

Antenna, base / rover

Height

21 / 21 19 dBi sector, 123◦ ×4◦ , beam 3◦ up / 13 dBi omni, 360◦ ×7◦ 15 / 10 8 dBi omni / 8 dBi omni

TX

3.0 / 1.5 3.0 / 2.0

30

6 dBi

3.0 / 3.0

30

2 dBi

3.0 / 2.0

TX power in dBm and height in m, each as base / rover. Beamwidths are horizontal × vertical, from the datasheets [27]–[32] (patterns in Fig. 2). The sector’s 5◦ uptilt and 2◦ electrical downtilt aim its beam 3◦ up.

it repaired routes fastest but changed routes up to 7.8 times a minute [20]. It had the lowest overhead on small topologies [21]. On 50 nodes it healed more slowly than BMX6, partly because of its longer default Hello interval [22]. Its throughput fell steeply as a Raspberry Pi mesh grew [23]. On quadcopters it was the most stable of three protocols, but the switching time was not measured [24]. We instead use Babel to choose between two parallel links of one vehicle, and we time the switch. ArduPilot Rover’s failsafes act after 1 s without RC input or 5 s without a ground station heartbeat [25]. PX4 waits 10 s by default before it declares a data link lost [26]. Both act on total loss. Neither moves traffic to another link, and both wait at least twice as long as our window of about 500 ms. III. S YSTEM Fig. 1 shows the stack. The base laptop is its hub. It sends the commands and monitors every subsystem. Video returns onto the base LAN, where any base computer can view it. Table I lists the four radio links. Every base antenna sits at 3 m, the URC maximum [1]. The rover PC encodes each USB camera to H.264 with x264 and serves it through MediaMTX [33]. The operator views each stream over WebRTC at 720p and 30 fps. At the base, an SBG Ellipse-D streams raw GNSS observations. RTKLIB’s str2str [34] converts them to RTCM 3 MSM7 messages [35]. An NTRIP caster on the base laptop [36] serves them to a u-blox ZED-F9P receiver on the rover. Both streams cross the backhaul. An EdgeRouter X [37] at each end connects to the Rocket bridge and to the Bullet bridge (Section IV). The base laptop writes every MAVLink command to both command radios at the same time. Kachhim, the rover’s controller, therefore receives two copies of each command. It prefers the P900. SATELLINE frames carry an added cost. Kachhim executes them only after about 500 ms without a valid P900 frame. It returns to the P900 as soon as a valid frame arrives. The backup stream is already running, so a switch waits only for the next SATELLINE frame. This wait has not been measured.

Base station LAN 192.168.2.0/24, antennas at 3 m

radio links

Rover LAN 192.168.1.0/24

USB cameras ×4–6

Base viewers

Rover PC

WebRTC in a browser

IP backhaul, Babel

(A) Vision and data

u-blox ZED-F9P LAN

19 dBi sector eth1

Babel cost 256

13 dBi omni

Rocket 5AC Lite

AP

EdgeRouter X Babel (babeld) Bullet routes +256

Rocket 5AC Lite

Primary: 5.2 GHz, 20 MHz

Backup: 2.4 GHz, 20 MHz

1 GbE

EdgeRouter X

8 dBi omni

cost 256 + 256 = 512

Bullet AC

Bullet AC

AP

x264 → MediaMTX NTRIP client

eth1

STA 8 dBi omni

eth4

RTCM

eth4

Babel (babeld) Bullet routes +256

STA

1 GbE

SBG Ellipse-D Base laptop (hub)

RTK base

(B) Control

telemetry, no IP

MAVLink control TUI monitoring, loggers NTRIP caster

6 dBi

Holybro P900 USB, same MAVLink to both

Primary: 900 MHz FHSS every command

6 dBi

Holybro P900

900 MHz

900 MHz 2 dBi

SATELLINE-EASy

Backup: 433 MHz, 25 kHz every command

433 MHz

Kachhim P900 first, SATELLINE after ~500 ms silence

2 dBi

SATELLINE-EASy 433 MHz

Motor driver

Fig. 1. Communication architecture: (A) Vision and data. Camera streams and RTK corrections travel over the 5.2 GHz Rocket link, and Babel moves them to the 2.4 GHz Bullet link when needed. (B) Control. The same MAVLink stream goes out on the 900 MHz P900 and the 433 MHz SATELLINE-EASy. Solid radio links are primary and dashed links are backups. Each antenna symbol carries its gain.

If both radios fall silent, Kachhim’s firmware stops the rover within 3 s. In that time the rover covers about 2.6 m at its median drive speed and 3.3 m at its maximum (Table VI). A firmware arm and disarm switch is the emergency stop. Both mechanisms run on Kachhim, so neither is independent of the controller. Some rover competitions require that independence [38]. The base laptop, Kachhim, the two routers and the rover power bus remain single points of failure. The stack duplicates radios and paths but not computers. IV. BACKHAUL L INK S ELECTION WITH BABEL The base LAN and the rover LAN are joined by two bridged subnets, one per radio link. Choosing a link is therefore a routing decision. Both routers run babeld [39], and we checked the behavior below against its source code. Each router sends a Hello on each link every 0.5 s. It keeps a history of which of its neighbor’s last sixteen Hellos arrived. A Hello counts as missed 0.85 s after the previous one. The receive cost is crx = 256 · 215 /(s + 1),

(1)

where s is the history read as a binary number. The two newest bits are moved down to weight 213 , so the three newest Hellos each carry a quarter of the weight. Neighbors exchange their receive costs, and the link cost is C = ctx crx /256 + Prtt .

(2)

The delay penalty Prtt rises linearly from zero at 10 ms of round-trip time to 128 at 120 ms [19]. A clean link costs 256. Losing the newest Hello raises the cost to 341, the two newest to 512 and the three newest to 1024. The cost becomes infinite after twelve lost Hellos, or when a port loses carrier with link detection on. A route’s metric is the link cost plus the neighbor’s advertised metric and an input filter offset. The advertised metric is zero here. The daemon switches at once if the installed route becomes infinite. Otherwise it switches only if the candidate’s metric is no higher and its smoothed metric is strictly lower. The smoothing has a half-life of 2 s, and ties never switch. Each router installs exactly one route per destination and chooses only for its own outbound traffic. Our configuration treats both links as wireless and sends timestamped Hellos for the delay penalty. Both also use link detection. Routes go to a separate table, because EdgeOS deleted fast-changing routes in the main table. The only preference is an offset of +256 on routes over the Bullet. A clean Bullet route therefore costs 512. The Rocket keeps the traffic while its cost stays at or below 512, which is about two lost Hellos. It loses the traffic when its smoothed metric exceeds 512 or when its routes are withdrawn. Without the offset, any lost Hello moved traffic to the Bullet. Because ties never switch, the traffic then stayed there. It also flapped. Under our own traffic the routes changed every 10– 20 s. Fig. 3 shows the offset rule at the Rocket’s range limit. With one route per destination, the backhaul is active and standby. No flow uses both links, and the Bullet carries only

(a) Base sector, AM-5G19-120

(b) Rover omni, AMO-5G13

Rocket link cost

Fig. 2. Manufacturer radiation patterns of the Rocket link antennas: Patterns are normalized to the peak, so the outer ring is 0 dB. Each panel gives the azimuth and the elevation cut for the vertically and horizontally polarized ports. In the elevation cuts, 0◦ is the horizon and 90◦ points straight up. Panel (a) is taken from [27] and panel (b) from the manufacturer’s AMO-5G13 pattern plot. Both antennas have 2◦ of electrical downtilt.

∞

On the Bullet

1024 Bullet route with offset, 512

512 256 0

20

40

60

80

Time (s) Fig. 3. Rocket link cost at the range limit: Cost at the base router as the rover passed 713–789 m under load. Shading marks the seconds in which the base router routed over the Bullet. Traffic left the Rocket when the cost crossed 512. It flapped while the cost hovered near that value and stayed on the Bullet once no Rocket Hellos were heard.

Hellos while the Rocket works. Babel can still share load by destination, because an input filter can match a prefix as well as an interface. Giving the offset only to some prefixes would route those prefixes over the Bullet. The RTK stream or one camera host are examples. Each such prefix would keep the other link as its failover. Source-specific routing [40], [41] extends this to source addresses. We have not tested either option. V. M ETHOD A. Command Failover Test The P900 was powered off abruptly while commands were flowing, in ten trials. Kachhim’s window for the primary was about 500 ms. B. Bench Backhaul Tests Both radio pairs stood on the bench in line of sight. A script applied Linux netem [42] to the Rocket ports of both routers. It lost or delayed packets while the radios stayed

associated, as a weak or obstructed link would. Each run stepped through phases of 15–30 s with rising impairment. Distance runs combined loss with added delay, and noise runs added loss alone. Each run then blocked all traffic and finally removed the impairment. In a separate trial the base Rocket was powered off while it carried traffic. An ICMP echo every 10 ms from the base laptop to the rover PC measured each outage. The outage is the length of the first unbroken run of lost echoes. Each router’s installed route was read every second. The +256 offset was added between two series of runs, so each impairment was tested with and without it. Runs with a ping accounting error are excluded. So are two blocked runs in which the script’s control connection stalled over the impaired link. During the last blocked trial, a probe received one video stream over UDP and over TCP and logged every frame. As a reference, iperf3 measured single-stream TCP throughput with all traffic on the Rocket. C. Field Drive The drive took place on open ground in the Purbachal helipad area of Dhaka, at 23.849◦ N and 90.506◦ E. The route ran east from the base antennas. It was in line of sight to about 600 m. Beyond that point the route followed a road lined with trees on both sides, which blocked the line of sight to the base antennas. This ground differs from the competition site. URC runs in the desert around the Mars Desert Research Station, on rocky and uneven ground that includes a canyon [1], [2]. Our route had no such relief, and its only obstruction was trees. The rover stood at 11 m during setup, which is not analyzed. It then drove out to 133 m and stood at 133–164 m for 13 min while a torn motor driver cable was replaced. The radios and loggers kept running, so this stop is the static reference. The rover then drove east from 170 m to 1,339 m in 28 min.

(c) The drive, sketched (not to scale; angles ×3)

am sector be

3° , aimed +

rover at +0.1° to +0.8° rover omni beam (7°, −2°)

toward the rover →

rover, 170–1,100 m away

(a) Base sector, AM-5G19-120 19 dBi, 4° beam, tilted 5° up, beam at +3°

(b) Rover omni, AMO-5G13 13 dBi, 7° beam, 2° electrical downtilt

3D views: main lobe only (gain within 20 dB of peak), vertical scale ×5

Height above base antenna (m)

base

(d) Drive out and the stop (heights ×7) ° +5

° +8

8

drive out, +7.5° to +1.1°

4

+3°

+1°

stop, +1.1°: at the beam's edge, 3 dB down

0 0

50

100

150

Distance from the base (m)

Fig. 4. Antenna patterns and the rover’s place in them: (a) Base sector and (b) rover omni, modeled from their datasheet beamwidths with a parabolic main lobe. Only the main lobe is drawn and the vertical scale is stretched five times. The sector is tilted 5◦ up, so with its 2◦ electrical downtilt its beam points 3◦ up. (c) Sketch of the drive, not to scale and with angles drawn three times larger. The sector’s beam passes over the rover, which the base saw at +0.1◦ to +0.8◦ . The rover therefore sat at the beam’s lower edge, with an estimated 4.2–7.1 dB of pattern loss. The base sat inside the rover omni’s 7◦ beam, which its electrical downtilt aims 2◦ down. (d) Scaled side view of the drive out and the cable-repair stop, with heights stretched by the factor shown. The dark wedge shows where the sector’s gain is within half power of its peak, and the light wedge where it is within 20 dB.

For each link we fit the log-distance model

TABLE II Q UANTITIES L OGGED ON THE D RIVE

P (d) = P100 − 10 n log10 (d/100 m) Quantity

Source

Rate

Signal, capacity, MCS and temperature of the four video radios Echo loss and round-trip time

Base logger

Every 2 s

Base laptop to rover PC Babel daemon on both routers ZED-F9P on the rover Rover PC Base logger

Every 5 s

Installed routes and link costs Position, solution and accuracy RTCM frames and correction age One 640×480 stream over RTSP and TCP

About every second 5 Hz Every frame Every frame

One iperf3 round ran at 54–107 m. Between 575 and 935 m, iperf3 rounds of 20 Mb/s ran every 3 min. The rest of the drive carried only the video, the corrections and the loggers. Table II lists what was logged and how often. Rover logs were re-timed to GNSS time before they were joined with base logs. After the Rocket station became unreachable near 771 m, the radio poller backed off to one poll every 2–5 min. Radio-reported signal and capacity are therefore dense only to 775 m. D. Analysis Distance is horizontal, from the rover’s RTK position to the base’s 20 s averaged position. Signal, capacity and service are summarized as medians over 50 m distance bins, and bins with fewer than eight samples are dropped.

(3)

by least squares to the bin medians of the drive beyond 170 m. Here P100 is the fitted power at 100 m and n is the path loss exponent. We report n with its 95% confidence interval from the t distribution. The shortfall is the gap between the free-space prediction and each measured Rocket sample at the rover end. The prediction uses the configured transmit power, both datasheet antenna gains and 1 dB of other loss. The rover’s elevation θ seen from the base follows from its RTK height above the base antenna and its distance. Each antenna’s vertical pattern is modeled as a parabolic main lobe, ! 2  θ − θtilt A(θ) = − min 12 , 20 dB, (4) θ3dB with the beam elevation θtilt and the vertical beamwidth θ3dB from Table I. The pattern loss of the link is the sum of the sector’s loss at θ and the omni’s loss at −θ. Echo loss and round-trip time come from the echoes every 5 s. Correction delivery is the share of the nominal 1,000 B/s RTCM stream that arrived at the rover over each bin. Age counts fresh corrections, those at most 2 s old. A second counts as smooth video when at least 25 of its 30 frames arrived. Finally, for each capacity sample with both links up, we compare the capacity of the link in use with that of the other link.

Without the +256 offset 1% loss, +2 ms 15% bursty loss 30% bursty loss

0.7% 1.3% 2.6%

– – –

Bullet after 7.9 s Stays on Rocket Bullet after 2.8 s

With the +256 offset 1% loss, +2 ms 3% loss, +5 ms 5% loss, +10 ms 10% loss, +15 ms 20% loss, +20 ms 10% loss, no delay 20% loss, no delay 40% loss, no delay 100% loss (blocked)

1.5% 5.3% 8.8% 18.7% 35.5% 18.4% 36.2% 29.8% –

11.2 17.7 25.9 37.8 45.2 3.7 3.9 3.7 –

Stays on Rocket Stays on Rocket Stays on Rocket Stays on Rocket Bullet after 14.1 s Stays on Rocket Stays on Rocket Bullet after 6.5 s, flaps first Outage 3.19–3.54 s, n = 3

RT loss and RTT: loss and median round-trip time of the 10 ms echoes over each phase. The bursty rows used correlated netem loss, which dropped far fewer packets than its nominal rate. Without the offset, traffic never returned to the Rocket.

RSSI at rover (dBm) Height above MSL (m)

Impairment, each way RT loss RTT (ms) Babel

Capacity (Mb/s)

TABLE III BABEL U NDER I NJECTED L OSS ON THE ROCKET

12

A. Command Failover All ten switchovers succeeded. The mean was 541 ms with a 95% confidence interval of 507–575 ms. Single trials ranged from 482 to 618 ms. The mean is consistent with the window of about 500 ms.

Dip, −0.8 m

Rover antenna (RTK)

8 6

No RTK beyond 1,117 m

Base antenna (SBG Ellipse-D), 5.0 m

4 −40 Rocket lost, 771 m

Bullet

−60

Rocket

−80

(b) (c)

60 40 20 0

VI. R ESULTS

Dip, −0.7 m

(a) 10

0

200

400

600

800

1,000

Distance from base (m) Rocket, 5.2 GHz (carried the traffic)

Bullet, 2.4 GHz (idle backup)

Fig. 5. Rover antenna height, signal and capacity along the drive: (a) Rover antenna height above MSL from its RTK float solution in 10 m medians, and the base antenna’s height as a dashed line. (b) Signal at the rover end of each link, in 50 m medians with interquartile bars. (c) Radioreported downlink capacity in 50 m medians. The base router used the Rocket in every sample from 170 to 700 m. Shading marks the two antenna dips. Beyond 775 m the poller was in back-off.

B. Backhaul Failover on the Bench A dead primary was detected faster than a silent one. When the base Rocket lost power, link detection withdrew its routes at once. Traffic moved to the Bullet with a 1.34 s outage. With all packets lost and the radios still associated, Babel had to notice the missing Hellos instead. The three valid trials gave outages of 3.19–3.54 s. This is consistent with the cost rule of Section IV, which needs several lost Hellos to overcome the offset. Traffic returned to the Rocket 10–13 s after each impairment ended, in all six recovery phases. The smoothing likely sets this delay, since the Bullet route is kept until the Rocket’s smoothed metric is strictly lower. What the operator saw depended on the transport protocol. Over UDP the longest video freeze in a blocked trial was 3.69 s, close to the outage. Over TCP, retransmission backoff stretched it to 6.53 s. Babel tolerated a lossy primary only with the offset in place (Table III). Without it, 1% loss with 2 ms of delay each way moved traffic after 7.9 s, and the traffic never came back. With the offset, Babel stayed on a Rocket that lost 10% of packets each way with 15 ms of added delay. It moved at 20% loss with 20 ms of delay, or at 40% loss without delay. Round-trip loss reached about a third before the switch. The offset thus trades fast failover for stability. The right setting depends on how much loss the video and the corrections can absorb.

C. Signal and Range Along the Drive The drive ran on a degraded Rocket. At the stop, the base Rocket heard −94 dBm on chain 0 against −70 dBm on chain 1, so one receive chain was effectively dead. The link ran at MCS 3 to 4, with one spatial stream in at least 83% of reports. It reported 29.2 Mb/s of downlink capacity against 64.7 Mb/s for the Bullet at MCS 8. Both Rockets and the rover Bullet also linked at only 100 Mb/s on Ethernet. The rover Rocket’s board warmed in the sun from 56 to 80 ◦ C. It peaked at 718 m, shortly before the link was lost. The base Rocket stayed at 55–61 ◦ C. Load rounds began in the same period, so we do not attribute the loss to heat. Signal fell with distance at close to the free-space slope on both links (Fig. 5b). At the rover end the fits give exponents of 2.14 for the Rocket and 2.65 for the Bullet (Table IV). The intervals are wide because each fit rests on only twelve or thirteen bins. The fits cover the line-of-sight section and the first part of the obstructed one. The Rocket’s signal sat 28.5–37.2 dB below free space. It was as large within line of sight as beyond it, at 29.4–37.2 dB against 28.5–34.8 dB. Trees therefore do not explain it. Antenna aiming explains only a small part of the shortfall. Seen from the base, the rover stayed 0.1◦ to 0.8◦ above the horizontal. The sector’s 4◦ beam pointed 3◦ up, so its lower half-power edge was at 1◦ (Fig. 4). For the whole drive, then,

TABLE IV L OG -D ISTANCE F ITS TO THE D RIVE M EDIANS Link, end Rocket, rover Bullet, rover Rocket, base, chain 1 Bullet, base

n (95% CI) 2.14 (1.20–3.09) 2.65 (2.04–3.26) 2.32 (1.33–3.31) 2.38 (1.77–3.00)

TABLE V S ERVICE A LONG THE D RIVE

P100 (dBm) σ (dB) R2 −66.2 −58.0 −62.8 −63.7

2.8 2.0 3.2 2.0

Bins

0.72 0.89 0.71 0.87

12 13 13 13

Fits of (3) to the 50 m medians beyond 170 m. σ: residual standard deviation. The base Rocket’s dead chain 0 is left out.

the rover sat at or just below that edge. Yet the model of (4) predicts only 4.2–7.1 dB of pattern loss for the two antennas together. The rest of the shortfall is unexplained. The rover omni is specified only for 5.45–5.85 GHz [28]. Its gain at 5.2 GHz is therefore unknown and may account for part of the gap. The base Rocket’s cabling and alignment are the next things to check. The rover antenna dipped 0.7 and 0.8 m below its earlier level (Fig. 5a). The Rocket felt it. In the first dip its median fell to −83.5 dBm, while the Bullet’s held at −75.0 dBm. On the drive out, the rover passed down through the sector’s beam. Its elevation fell from 7.5◦ at 15 m to 1.1◦ at 133 m (Fig. 4d). Rocket Hellos stopped at 771 m, which is 171 m into the obstructed section and during a load round. Apart from a few seconds near 958 m they did not return. Bullet Hellos stopped at 1,037 m. The last echo reply arrived at 1,085 m and the last RTCM frame at 1,068 m. An earlier configuration of the video link was also used at URC, but no data were logged there. In those runs, the operators found the video link usable to about 600–900 m, depending on the terrain and the task. This is an operator estimate and not a measurement. It brackets the 771 m that the Rocket reached on the drive in Dhaka. D. Service Along the Drive Without load, the backhaul served the rover well out to 575 m. It lost at most 1.9% of echoes and gave smooth video in at least 91.7% of seconds (Table V). Under the load rounds between 575 and 935 m, smooth video fell to 54.3% of seconds. Correction delivery fell to 80.8% of the nominal bytes, and 87.9% of epochs had a fresh correction. The same band also holds the Rocket’s failure at 771 m, so the effects of load and range cannot be separated there. In the band where the Bullet failed, echo loss rose to 53.1%. The logged video stream itself was light. At the stop it averaged 0.26 Mb/s, with a 95th percentile of 2.8 Mb/s. E. Positioning RTK accuracy held beyond the Rocket’s range (Table VI). The receiver reported 1.4 cm horizontal accuracy at the stop. It reported 1.7 cm within line of sight and 1.9 cm beyond it, where the Bullet carried most corrections. These are receiver estimates and therefore optimistic. The rare fixed epochs jumped about one meter against the float track, so we treat the position as good to decimeters.

Distance (m)

Load

Ping loss

RTT RTCM (ms) bytes

Age ≤2 s

Smooth video

133–164 (stop) None 0.0% 2.1 99.5% 100.0% 100.0% 150–350 None 0.0% 4.5 95.7% 100.0% 100.0% 350–575 None 1.9% 10.0 93.7% 100.0% 91.7% 575–935 20 Mb/s 3.0% 12.7 80.8% 87.9% 54.3% 935–1,000 None 5.0% 4.2 84.4% 92.1% 78.6% 1,000–1,100 None 53.1% 26.4 23.5% 27.6% 26.4% >1,100 None 100.0% – 0.0% 0.0% 0.0% RTCM bytes: share of the nominal 1,000 B/s that arrived. Age: rover epochs with a correction at most 2 s old. Smooth video: seconds with at least 25 of 30 frames. TABLE VI P OSITIONING AND ROVER M OTION ON THE D RIVE Quantity

Value

Base station, SBG Ellipse-D, 20 s SBAS average Scatter, north / east / up (1σ) 6.7 / 9.4 / 1.3 cm Absolute accuracy About 1 m GNSS antenna height 5.0 m above MSL Rover, ZED-F9P, RTK float, receiver-reported Static at the stop, horizontal / vertical Drive 150–600 m, horizontal / vertical Drive 600–1,100 m, horizontal / vertical Drive, 95th percentile, horizontal / vertical Solution share on the drive Rover motion on the drive Speed, median / 95th percentile / max Drive, 170 to 1,339 m

1.4 / 1.8 cm 1.7 / 2.9 cm 1.9 / 3.1 cm 2.4 / 4.0 cm Float 81.7%, none 17.8%, fixed 0.5% 0.87 / 0.96 / 1.09 m/s 28 min

Rover values are medians of epochs with an RTK float solution unless stated. Speed counts epochs moving faster than 0.2 m/s.

The base position is a 20 s average of the Ellipse-D’s SBAS solution. Its absolute error, about 1 m, shifts every rover position equally. Correction latency was 246 ms at the median and 339 ms at the 95th percentile, while the echo round-trip time over that span was 2.6 ms. Latency therefore arises at the base. F. Route Choice and Switching Babel kept traffic on the lower-capacity link for most of the drive. The Bullet reported more capacity than the Rocket in every 50 m bin to 775 m (Fig. 5c). After setup, the base router used the Rocket in 99.2% of the 914 samples with both links up, as the offset intends. In 93.7% of those samples, the link in use reported at least 10% less capacity than the other link. The mean was 24.3 against 50.9 Mb/s. Babel judged the Rocket healthy because it still delivered its Hellos. Its dead receive chain cut capacity but not Hello delivery. The two routers used different links for 35 s. This is 2.6% of the 22 min from the start of the drive until both links were lost. Counting both routers, they switched 24 times in three episodes. The first episode had 6 switches in 9 s when iperf3 saturated the Rocket at 105 m. It left a 3.7 s gap in the corrections. The second had 10 switches in 48 s at the range limit under load. It caused a 19.2 s correction gap and a 57.3 s

video outage. The third had 8 switches in 12 s near 953 m, where the Rocket was briefly heard again. Single-stream TCP at 54–107 m reached 10.6 Mb/s down and 5.6 Mb/s up. On the bench, with all traffic on a healthy Rocket, the same test reached 69–75 Mb/s down and 93 Mb/s up. The gap likely reflects the dead receive chain and the 100 Mb/s ports as well as the distance. VII. D ISCUSSION The drive reversed the assumption behind the offset, that the Rocket is the better link. A hardware fault left the Rocket alive but slow, and Babel cannot see this because its cost counts only lost Hellos. A watcher that raises the Rocket’s cost from its reported capacity or SNR would let the routers react. The same watcher would also catch a primary that is alive but too slow for bulk data. Without an offset, Babel flapped under our own traffic. With it, a blocked primary cost about 3.54 s of outage, and a lossy primary was kept until about a third of round trips failed. A shorter Hello interval should shorten the blocked outage at the cost of more control traffic. This has not been tested. Two of the three switching episodes came under iperf3 load. Saturating the primary raises its delay and loss, and both raise its cost. Bulk transfers should therefore be rate limited on a link that also carries video and corrections. At the 3 m height limit, the rover stayed within one degree of the horizontal for the whole drive beyond the stop. A sector tilted up places that whole range at the lower edge of its beam. Tilting it to the horizon would put the rover inside the main lobe and recover the few decibels that the model attributes to aiming. End-to-end echoes revealed neither the 100 Mb/s ports nor the dead receive chain. One unreachable radio also slowed the polling of all four. Port speeds, per-chain signal and per-device poll failures should therefore be logged from the start of every test. The backhaul failed over within 1.34 s of a power loss and 3.54 s of a blockage. Both are shorter than ArduPilot Rover’s 5 s ground station failsafe [25], so a rover with this backhaul would change links before that failsafe fired. The team reports of Section II give no switch times to compare against. VIII. L IMITATIONS All measurements were made in Dhaka. At URC an earlier configuration of the video link ran without logging. Its competition range (Section VI-C) is therefore an operator estimate. Desert relief and the URC command trailers may change both range and multipath. The bench test was in line of sight. The drive was in line of sight only to about 600 m, so its range results hold for one partly obstructed path. The backhaul results come from one bench session and one drive. The drive ran on a degraded Rocket, so its range understates a healthy link. Only one video stream was logged, over RTSP and TCP. The operator’s WebRTC streams were not measured.

The command switchover rests on ten trials, and the safe stop has not been timed. The RTK accuracy figures are receiver estimates without an independent reference. IX. C ONCLUSION Separating vision and control by radio and band let each part fail on its own. On the bench, Babel moved the backhaul to the backup within 1.34 s of a power loss and 3.54 s of a blockage. In the field, the backup extended service beyond the line-ofsight section from 771 m to 1.04 km, with RTK accuracy near its static value. Teams that copy this design should not judge a link by Hello loss alone. Here a degraded but alive primary kept the traffic while the backup offered twice its capacity. Next are a capacity-aware backhaul metric, a re-aimed sector and logged tests at the competition site. ACKNOWLEDGMENT We thank Rafid Khan, former team lead, and Mollah Md Saif, co-advisor, of the BRACU Mongol-Tori Rover Team. We also thank the rest of the team and BRAC University’s Department of Computer Science and Engineering. R EFERENCES [1] University Rover Challenge, “URC Requirements & Guidelines,” The Mars Society, 2026. [Online]. Available: https://urc.marssociety.org/ home/requirements-guidelines [2] ——, “URC2025 Delivery Mission Course,” The Mars Society, 2025. [Online]. Available: https://urc.marssociety.org/home/about-urc/history/ urc2025/urc2025-delivery-mission-course [3] ——, “URC Advice,” The Mars Society. [Online]. Available: https://urc.marssociety.org/home/resources/urc-advice [4] D. Snider, M. Mirvish, M. Barcis, and V. A. Tezer, “University Rover Challenge: Tutorials and Team Survey,” in Studies in Computational Intelligence, 2018, pp. 315–370. [5] J. Rozsa, T. Averett, M. Killpack, and M. Rice, “BYU Mars Rover at the 2018 University Rover Challenge,” International Telemetering Conference Proceedings, 2018. [Online]. Available: http://hdl.handle.net/10150/631687 [6] A. Zaman, M. Shahjahan Majib, S. A. Tanjim, S. M. A. Siddique, F. Ashraf, S. Islam, A. H. M. M. Morshed, S. T. Shahid, I. Hasan, O. Samir, S. Shafquat, N. I. K. Al Bhuyain, A. M. Rayhan, M. M. U. Islam, M. Akhtaruzzaman, and M. M. Rahman, “Phoenix: Towards Designing and Developing a Human Assistant Rover,” IEEE Access, vol. 10, pp. 50 728–50 754, 2022. [7] WVU Team Mountaineers, “Team Mountaineers System Acceptance Review 2024,” University Rover Challenge SAR report, 2024. [Online]. Available: https: //urc.orgs.wvu.edu/files/d/9600058f-b88d-4103-bf4f-371da7298374/ team-mountaineers-sar-2024.pdf [8] ——, “Team Mountaineers System Acceptance Review 2025,” University Rover Challenge SAR report, 2025. [Online]. Available: https: //urc.orgs.wvu.edu/files/d/063786fe-e7ac-4d1f-b98e-41602ac90b74/ team-mountaineers-system-acceptance-review.pdf [9] N. S. Shourov, M. Rahman, M. Z. Islam, A. Ahsan, S. M. Kamruzzaman, S. Rahman, M. Sakiluzzaman, I. Hasnain, E. Islam, S. Islam, and M. K. Rhaman, “BRACU Mongol Tori: Next Generation Mars Exploration Rover,” arXiv:2111.02004, 2021. [10] J. Güldenring, P. Gorczak, F. Eckermann, M. Patchou, J. Tiemann, F. Kurtz, and C. Wietfeld, “Reliable Long-Range Multi-Link Communication for Unmanned Search and Rescue Aircraft Systems in Beyond Visual Line of Sight Operation,” Drones, vol. 4, no. 2, p. 16, 2020. [11] Y. H. Lau and M. H. Ang, “A Novel Link Failure Detection and Switching Algorithm for Dissimilar Redundant UAV Communication,” Drones, vol. 5, no. 2, p. 48, 2021.

[12] H. Kirrmann, M. Hansson, and P. Muri, “IEC 62439 PRP: Bumpless recovery for highly available, hard real-time industrial networks,” in 2007 IEEE Conference on Emerging Technologies & Factory Automation (EFTA 2007), 2007, pp. 1396–1399. [13] International Electrotechnical Commission, “IEC 62439-3:2021 Industrial communication networks – High availability automation networks – Part 3: Parallel Redundancy Protocol (PRP) and Highavailability Seamless Redundancy (HSR),” 2021. [Online]. Available: https://webstore.iec.ch/en/publication/64423 [14] IEEE, “IEEE 802.1CB-2017: Frame Replication and Elimination for Reliability,” 2017. [Online]. Available: https://standards.ieee.org/ieee/ 802.1CB/5703/ [15] J. Chroboczek, “The Babel Routing Protocol,” RFC 6126, Apr. 2011. [Online]. Available: https://www.rfc-editor.org/rfc/rfc6126.html [16] J. Chroboczek and D. Schinazi, “The Babel Routing Protocol,” RFC 8966, Jan. 2021. [Online]. Available: https://www.rfc-editor.org/rfc/ rfc8966.html [17] D. S. J. De Couto, D. Aguayo, J. Bicket, and R. Morris, “A HighThroughput Path Metric for Multi-Hop Wireless Routing,” in Proceedings of the 9th Annual International Conference on Mobile Computing and Networking (MobiCom ’03), San Diego, CA, USA, Sep. 2003, pp. 134–146. [18] B. Jonglez, M. Boutier, and J. Chroboczek, “A delay-based routing metric,” arXiv:1403.3488, 2014. [Online]. Available: https: //arxiv.org/abs/1403.3488 [19] B. Jonglez and J. Chroboczek, “Delay-Based Metric Extension for the Babel Routing Protocol,” RFC 9616, Sep. 2024. [Online]. Available: https://www.rfc-editor.org/rfc/rfc9616.html [20] M. Abolhasan, B. Hagelstein, and J. C.-P. Wang, “Real-world performance of current proactive multi-hop mesh protocols,” in Proc. 15th Asia-Pacific Conference on Communications (APCC), 2009, pp. 44–47. [21] D. Murray, M. Dixon, and T. Koziniec, “An experimental comparison of routing protocols in multi hop ad hoc networks,” in Proc. Australasian Telecommunication Networks and Applications Conference (ATNAC), 2010, pp. 159–164. [22] A. Neumann, E. López, and L. Navarro, “Evaluation of mesh routing protocols for wireless community networks,” Computer Networks, vol. 93, pp. 308–323, 2015. [23] D. Turlykozhayeva, S. Temesheva, N. Ussipov, A. Bolysbay, A. Akhmetali, S. Akhtanov, and X. Tang, “Experimental performance comparison of proactive routing protocols in wireless mesh network using Raspberry Pi 4,” Telecom, vol. 5, no. 4, pp. 1008–1020, 2024. [24] A. Guillen-Perez, A.-M. Montoya, J.-C. Sanchez-Aarnoutse, and M.-D. Cano, “A comparative performance evaluation of routing protocols for flying ad-hoc networks in real conditions,” Applied Sciences, vol. 11, no. 10, p. 4363, 2021. [25] ArduPilot Dev Team, “Rover Failsafes,” ArduPilot Rover documentation. [Online]. Available: https://ardupilot.org/rover/docs/ rover-failsafes.html [26] PX4 Autopilot Project, “Safety Configuration (Failsafes),” PX4 User Guide. [Online]. Available: https://docs.px4.io/main/en/config/safety. html [27] Ubiquiti Inc., “airMAX Sector Antennas Datasheet (AM-5G19120).” [Online]. Available: https://dl.ubnt.com/datasheets/airmaxsector/ airMAX Sector Antennas DS.pdf [28] ——, “airMAX Omni Antenna AMO-5G13 Quick Start Guide.” [Online]. Available: https://dl.ubnt.com/guides/omni/airMAX Omni AMO-5G13 QSG.pdf [29] ——, “Rocket 5AC Lite Datasheet,” 2022. [Online]. Available: https://www.ui.com/airmax/rocketac-lite/ [30] Ubiquiti Networks, Inc., “Bullet AC Datasheet (B-DB-AC),” 2018. [Online]. Available: https://dl.ui.com/datasheets/bullet ac/Bullet AC DS.pdf [31] PX4 Autopilot Project, “Holybro Microhard P900 Radio,” PX4 User Guide. [Online]. Available: https://docs.px4.io/main/en/telemetry/ holybro microhard p900 radio [32] SATEL Oy, “SATELLINE-EASy Compact-Proof / EASyProof User Guide, Version 10.2,” 2024. [Online]. Available: https://www.satel.com/wp-content/uploads/2024/05/ SATELLINE-EASy-Compact-Proof-EASy-Proof-user-guide-V10.2.pdf [33] bluenviron, “MediaMTX: Ready-to-use real-time media server and media proxy,” GitHub repository. [Online]. Available: https://github. com/bluenviron/mediamtx

[34] T. Takasu and A. Yasuda, “Development of the Low-Cost RTK-GPS Receiver with an Open Source Program Package RTKLIB,” in International Symposium on GPS/GNSS, Jeju, Korea, Nov. 2009. [Online]. Available: http://gpspp.sakura.ne.jp/paper2005/isgps 2009 rtklib revA.pdf [35] Radio Technical Commission for Maritime Services, “RTCM Standard 10403.4, Differential GNSS (Global Navigation Satellite Systems) Services – Version 3,” RTCM Special Committee 104, Dec. 2023, with Amendment 1, Nov. 1, 2024. [Online]. Available: https://www.rtcm.org/publications [36] ——, “RTCM Standard 10410.1, Networked Transport of RTCM via Internet Protocol (Ntrip) – Version 2.0,” RTCM Special Committee 104, 2021, with Amendment 2, Jan. 12, 2021. [Online]. Available: https://www.rtcm.org/publications [37] Ubiquiti Networks, Inc., “EdgeRouter X Datasheet (ER-X),” 2017. [Online]. Available: https://dl.ui.com/datasheets/edgemax/EdgeRouter X DS.pdf [38] Canadian International Rover Challenge, “CIRC 2026 Rules: Safety,” 2026. [Online]. Available: https://circ.cstag.ca/2026/rules/safety/ [39] J. Chroboczek, “babeld(8) Manual Page, babeld 1.13.1,” babeld source distribution, Jul. 2023. [Online]. Available: https://github.com/jech/ babeld/blob/babeld-1.13.1/babeld.man [40] M. Boutier and J. Chroboczek, “Source-specific routing,” in Proc. IFIP Networking Conference, 2015, pp. 1–9. [41] ——, “Source-Specific Routing in the Babel Routing Protocol,” RFC 9079, Aug. 2021. [Online]. Available: https://www.rfc-editor.org/rfc/ rfc9079.html [42] S. Hemminger, “Network Emulation with NetEm,” in linux.conf.au 2005, Canberra, Australia, Apr. 2005.

Related documents

• Privacy Failure in Split-LLM Training, The Returned Gradient Nullifies the Decoys#927676
• Unfair and Deceptive Robots#309809
• Device-independent conference key agreement from two-body correlators with balanced Dicke states#1535036
• MarsLab: A Martian Rover Simulator for Planetary Rover Autonomous Navigation#1128961
• TurtleBot 3#1048252