Geofencing

Geofencing – definition

Geofencing is a method for defining a virtual spatial boundary and attaching system behavior to that boundary. In mobile robotics, a geofence is usually represented as a 2D polygon, a circle, or a set of geographic coordinates in a known reference frame. The robot monitors its estimated position and checks whether it is inside, outside, or near that boundary. When a rule is violated, the software can trigger an event such as speed reduction, mission stop, waypoint rejection, or operator alert.

For UGV platforms, geofencing is a safety and mission-control mechanism rather than a navigation algorithm by itself. It does not localize the robot and it does not plan a path. Instead, it consumes position estimates produced by localization, GNSS, odometry, SLAM, or sensor fusion, and applies spatial constraints to robot behavior. In ROS 2 systems, geofencing is commonly implemented as a supervisory node that subscribes to pose-related topics such as /odom, /tf, /amcl_pose, or GNSS-derived poses, then publishes status, alarms, or control overrides.

On Fictionlab platforms, geofencing is relevant in outdoor and mixed indoor-outdoor deployments. Leo Rover can use geofencing for education, field robotics experiments, and constrained teleoperation. Raptor Rover can use the same concept in larger workspaces where higher payload and larger operational envelopes require stricter area constraints. In both cases, geofencing depends on the quality of the pose estimate and on consistent coordinate frames.

How geofencing works in mobile robotics

The basic logic is straightforward. A geofence definition is stored in software, the robot state estimator provides position updates, and the system evaluates whether the robot remains within allowed limits. The technical difficulty comes from frame handling, estimator uncertainty, and update timing.

In practice, a geofencing pipeline for a UGV usually includes the following elements:

a reference frame such as map, odom, or a global geographic frame converted to a local Cartesian frame
a localization source, for example wheel odometry, SLAM, AMCL, GNSS, or GNSS + IMU fusion
a geometric representation of the allowed area or exclusion zone
a rule engine that checks boundary crossing and issues actions
an interface to the navigation stack, teleoperation layer, or motor control safety layer

For ROS-based robots, the reference-frame model follows REP 105, which defines standard mobile platform frames such as base_link, odom, and map. This matters because a geofence drawn in map is only valid if localization also produces a stable map -> base_link relation. If the robot is operating purely on wheel odometry, then drift in odom can gradually invalidate the geofence check over longer distances.

For outdoor robots, geofences are often authored in latitude and longitude but evaluated in a projected local frame. A common implementation converts GNSS coordinates to a local ENU frame and then performs point-in-polygon checks. This avoids repeated spherical geometry calculations inside the control loop and integrates more naturally with ROS navigation components.

Geofencing in ROS 2

ROS 2 does not define one mandatory geofencing package in core distributions, so implementations vary. The concept is normally built from standard message types, TF transforms, and navigation-layer hooks. The most common integration pattern is a node that subscribes to localization data and exposes a boolean state such as inside_geofence, plus optional action topics or services.

Typical ROS 2 interfaces used in geofencing include:

geometry_msgs/msg/PoseStamped for pose estimates
nav_msgs/msg/Odometry for odometry and fused state
sensor_msgs/msg/NavSatFix for GNSS position
tf2 transforms between map, odom, and base_link
geometry_msgs/msg/PolygonStamped for 2D fence geometry
diagnostic_msgs or custom status topics for violation reporting

A minimal ROS 2 configuration can store fence vertices in YAML and evaluate them at the localization update rate. For slow UGV motion, a 5-10 Hz geofence check is usually sufficient. For higher-speed outdoor motion or noisy GNSS, engineers often run the check at 20 Hz or more, with hysteresis or safety margin buffering to avoid oscillation at the border.

geofence_node:
  ros__parameters:
    frame_id: map
    check_rate_hz: 10.0
    safety_margin_m: 0.5
    action_on_violation: stop
    polygon:
      - [0.0, 0.0]
      - [8.0, 0.0]
      - [8.0, 6.0]
      - [0.0, 6.0]

ros2 topic echo /odom
ros2 topic echo /tf
ros2 topic echo /fix
ros2 param get /geofence_node frame_id

Key parameters and metrics

Geofencing quality depends less on the boundary math and more on localization quality and timing. For that reason, the main engineering parameters are measurable and should be documented per platform.

Parameter	Typical unit	Why it matters
Localization update rate	Hz	Determines how quickly boundary crossing is detected
Pose accuracy	m	Sets the minimum safe distance to the fence
Fence safety margin	m	Compensates for estimator error and latency
Control reaction latency	ms	Affects stopping distance after violation
Robot speed	m/s	Higher speed requires larger margins
Reference frame stability	qualitative	Drifting frames can create false violations or missed violations

A simple engineering rule is that the safety margin should exceed the sum of position uncertainty and travel distance during system reaction time:

margin >= position_error + speed * reaction_time

If a UGV moves at 0.8 m/s and the combined sensing, computation, and stopping reaction time is 0.5 s, then motion alone adds 0.4 m. If fused localization uncertainty is 0.3 m, a practical minimum margin is about 0.7 m before any additional conservatism.

Supported sensors and integration patterns

Geofencing can be implemented with different localization sources. The right choice depends on whether the robot works indoors, outdoors, or in mixed environments.

Common sensor and estimator combinations include:

wheel odometry only – acceptable for short indoor runs, weak over long distance due to drift
LiDAR SLAM – useful when the fence is defined in a mapped local environment
visual SLAM or depth-camera odometry – possible in structured spaces, sensitive to lighting and texture
GNSS – suitable for coarse outdoor geofencing, limited by absolute positioning error
GNSS + RTK + IMU fusion – preferred for outdoor boundary enforcement where meter-level error is not acceptable

For Leo Rover, the default onboard compute is Raspberry Pi-based, so geofencing logic should stay lightweight. Point-in-polygon checks and frame transforms are inexpensive, but high-rate sensor fusion or dense perception may require offloading to additional compute. Leo Rover supports ROS and can be integrated with ROS 2-based software stacks, so a geofence node can be integrated with Nav2, teleoperation, or custom mission software. Since Leo Rover is not autonomous out of the box, geofencing must be added as part of a larger navigation and safety stack.

For Raptor Rover, larger payload capacity makes it more practical to integrate RTK GNSS receivers, higher-grade IMUs, and companion computers. This is important when the geofence is used in open terrain, agriculture, or construction-like test fields where long travel distances amplify odometric drift.

Use cases with Leo Rover and Raptor Rover

The same geofencing concept can serve different operational goals depending on platform scale and sensor configuration.

On Leo Rover, typical use cases include:

limiting student experiments to a safe outdoor test patch
preventing teleoperated exits from an area covered by Wi-Fi or local observation
stopping autonomous Nav2 goals that fall outside a mapped research zone

On Raptor Rover, typical use cases include:

keeping a higher-payload UGV inside a designated inspection corridor
enforcing exclusion zones around terrain obstacles or fragile field equipment
segmenting large outdoor missions into approved operational sectors

Limitations and trade-offs

Geofencing is only as reliable as the pose estimate used for evaluation. A precisely drawn polygon does not improve a poor localization pipeline. This is the main source of implementation error.

The main limitations are:

GNSS-only geofences can be too coarse for narrow corridors or small exclusion zones
odometry-frame geofences drift over time and are unsuitable for long missions without correction
boundary chatter can occur if noise causes rapid inside-outside switching near the edge
hard stop behavior may be unsafe on slopes or loose terrain if not coordinated with the motion controller

For robust deployments, engineers usually add hysteresis, confidence thresholds, and layered actions such as warning, speed limit, then stop.

Normative references and standards

The frame semantics used in ROS mobile robots are defined in REP 105, which standardizes coordinate frames for mobile platforms. Geographic coordinate conventions in ROS are described in REP 103 for units and conventions. Message semantics for GNSS data come from sensor_msgs/msg/NavSatFix in ROS interface documentation. In practice, geofencing implementations should also follow hardware vendor specifications for GNSS accuracy, IMU bias stability, and update rate, because these parameters determine whether a boundary is operationally meaningful.