Reference/fleetless.yaml/Low Bandwidth

📶 Low Bandwidth

The bridge caps what it sends when its datapoints stop arriving in time. This section overrides the bridge’s ROS parameters of the same names; an absent key leaves the parameter alone. The mode is visible on every robot as bridge_state.low_bandwidth.

yaml

low_bandwidth:
  mode: auto
  datapoint_max_hz: 0.5
  camera: stop

The mode is bridge 4.0.0 and up. An older bridge ignores this section and reports bridge_state.low_bandwidth as false for as long as its protocol version is still served.

What the bridge measures

Two numbers decide. Lag is how late datapoints reach the cloud: the median arrival delay over five seconds, minus the smallest delay this connection has seen in ten minutes, handed back to the bridge on the ping it already gets. Subtracting that baseline is what keeps a robot with a wrong clock from reading as a slow link.

Dwell is how long the bridge’s own send queue holds a sample before the send completes, as the 95th percentile over the last five seconds. Either number above enter_lag_ms enters the mode, and both at or below exit_lag_ms leave it. A number that is missing counts as calm on its own side, so a robot whose pings have stopped decides on dwell alone.

The keys

Key	Default	Bounds	Meaning
`mode`	`auto`	`auto`, `on`, `off`	`auto` decides from the link; `on` and `off` force it.
`enter_lag_ms`	2000	integer, at least `100`	Lag or dwell above this enters the mode.
`enter_after_s`	10	integer, at least `1`	How long the entry condition must hold.
`exit_lag_ms`	500	integer, at least `0`, at or below `enter_lag_ms`	Lag and dwell both at or below this leave the mode.
`exit_after_s`	60	integer, at least `1`	How long the exit condition must hold.
`datapoint_max_hz`	1	number above `0`, at most `20`	Ceiling for every datapoint in the mode. Backfill pauses; a datapoint with `retention` buffers what the cap held back and fills its history in afterwards, one without it has a gap.
`camera`	`reduce`	`reduce`, `stop`	`reduce` lowers running streams to `camera_bitrate_kbps`; `stop` ends them. New streams are refused either way, with the code `low_bandwidth`.
`camera_bitrate_kbps`	300	integer, `50` to `20000`	The reduced bitrate.

exit_lag_ms must stay at or below enter_lag_ms: an exit threshold above the entry threshold is a mode that leaves as it arrives. This document checks the pair only when you write both keys, so a lone exit_lag_ms publishes clean and is refused on the robot when the configuration is applied.

That refusal names the rule it broke in the publish result, under low_bandwidth, and the bridge keeps its previous settings and keeps running. Name both keys whenever you change either.

A datapoint that must keep its rate says low_bandwidth: keep in its own entry; the rate cap is all it exempts, and its backfill still pauses.

Forcing it by hand

The same keys exist as ROS parameters under low_bandwidth. on the bridge node, so ros2 param set /fleetless_bridge low_bandwidth.mode on forces the mode without a publish. Physics wins: a link that carries 1 kbit/s carries 1 kbit/s, and the mode only chooses what rides on it.