A rule-based autonomous controller maps sensor measurements directly to actions using explicitly specified logic such as if–then–else rules. In contrast to path planners and optimization-based model predictive controllers, a rule-based controller is often memoryless (or has only a small discrete memory such as a mode/state flag) and is therefore easy to implement on embedded systems.

Denote by \( y_k \) the vector of sensor measurements at discrete time step \( k \) (e.g., distances from range sensors) and by \( u_k \) the control input (e.g., wheel velocity commands). A rule-based policy is a mapping

\[ \pi : \mathbb{R}^m \to \mathbb{R}^p, \quad u_k = \pi(y_k), \]

where \( \pi \) is typically defined piecewise on regions of the measurement space. For regions \( R_i \subset \mathbb{R}^m \), \( i = 1, \dots, M \), that form a partition of the measurement space, we can write

\[ \pi(y) = \sum_{i=1}^M u^{(i)} \mathbf{1}_{R_i}(y), \]

where \( u^{(i)} \) is the constant (or simple linear) action associated with region \( R_i \) and \( \mathbf{1}_{R_i} \) is the indicator function of that region. Each rule can be read informally as:

“If the sensor vector \( y \) falls in region \( R_i \), then apply control \( u^{(i)} \).”

At system level, these rules live inside the familiar Sense–Think–Act loop:

flowchart TD
  S["Sensors (ranges, bump, imu)"] --> P["Preprocess / filter measurements"]
  P --> R["Evaluate logical rules on measurements"]
  R --> C["Compute command (v, omega)"]
  C --> A["Actuators (motors, drivers)"]
  A --> W["Robot moves in environment"]
  W --> S
        

This lesson focuses on how to design these rules so that the robot realizes a simple autonomous task (e.g., obstacle avoidance and wall-following) and how to reason about the resulting behavior using basic discrete-time control theory.

To keep the math transparent, we first study a one-dimensional abstraction: a robot moves along a line toward a wall and we want it to stop or slow down so that its distance to the wall never drops below a safe distance \( d_{\text{safe}} > 0 \).

Let \( x_k \) denote the robot position at time \( k \) (larger \( x_k \) means closer to the wall) and let \( u_k \) be the scalar command velocity. Approximating the robot motion as a discrete-time integrator with sampling period \( T > 0 \), we write

\[ x_{k+1} = x_k + T u_k. \]

If the wall is fixed at position \( x_{\text{wall}} \), then the distance between robot and wall at step \( k \) is

\[ d_k = x_{\text{wall}} - x_k. \]

The safety requirement is that the distance never becomes smaller than the threshold:

\[ d_k \ge d_{\text{safe}} \quad \text{for all } k \ge 0. \]

Using the discrete-time model we obtain the closed-loop dynamics of the distance. Because \( x_{k+1} = x_k + T u_k \), we have

\[ d_{k+1} = x_{\text{wall}} - x_{k+1} = x_{\text{wall}} - x_k - T u_k = d_k - T u_k. \]

Thus, specifying a rule that computes \( u_k \) from the current distance \( d_k \) determines the evolution of \( d_k \). The key question becomes: Can we design simple rules that make the set \( \{ d \mid d \ge d_{\text{safe}} \} \) invariant?

Consider the following rule that combines a proportional controller with a hard stop very close to the wall:

\[ u_k = \begin{cases} k_p \bigl(d_k - d_{\text{safe}}\bigr), & d_k \ge d_{\text{safe}},\\[4pt] 0, & d_k < d_{\text{safe}}, \end{cases} \]

where \( k_p > 0 \) is a proportional gain. When the robot is far from the wall \( (d_k \gg d_{\text{safe}}) \), the velocity is large; as the robot approaches the wall, the velocity decreases linearly, and once the distance is below the safe threshold, the rule commands zero velocity.

Substituting this rule into the distance dynamics for the case \( d_k \ge d_{\text{safe}} \) yields

\[ d_{k+1} = d_k - T k_p \bigl(d_k - d_{\text{safe}}\bigr). \]

Let \( e_k = d_k - d_{\text{safe}} \) be the distance error with respect to the safe threshold. Then

\[ e_{k+1} = d_{k+1} - d_{\text{safe}} = d_k - T k_p(d_k - d_{\text{safe}}) - d_{\text{safe}} = \bigl(1 - T k_p\bigr) e_k. \]

This is a scalar linear system. The following proposition shows that the rule enforces safety if the step size and gain satisfy a simple inequality.

Proposition (Forward invariance of the safe set).

Suppose \( 0 < T k_p \le 1 \) and \( d_0 \ge d_{\text{safe}} \). Then for the rule above, the safe set \( \mathcal{S} = \{ d \mid d \ge d_{\text{safe}} \} \) is forward invariant, i.e., \( d_k \in \mathcal{S} \) for all \( k \ge 0 \).

Proof.

Because \( d_0 \ge d_{\text{safe}} \), \( e_0 = d_0 - d_{\text{safe}} \ge 0 \). Assume that for some \( k \ge 0 \) we have \( e_k \ge 0 \). Then by the update equation

\[ e_{k+1} = \bigl(1 - T k_p\bigr) e_k. \]

Under the condition \( 0 \le 1 - T k_p \le 1 \), the factor \( 1 - T k_p \) is nonnegative. Thus \( e_{k+1} \ge 0 \) whenever \( e_k \ge 0 \). By induction this implies \( e_k \ge 0 \) for all \( k \ge 0 \), and therefore \( d_k = e_k + d_{\text{safe}} \ge d_{\text{safe}} \) for all \( k \). Hence the safe set is forward invariant. \(\square\)

This calculation illustrates an important idea: even a simple rule-based controller can often be viewed as a hybrid system whose behavior on each region is governed by familiar linear dynamics and whose switching conditions are the logical rules.

Real robots rarely operate in exactly one mode; instead, we often describe their autonomy as a finite-state machine (FSM) with modes such as “explore”, “avoid obstacle”, and “follow wall”. Each mode uses its own control law (often linear or linearized), and simple conditions trigger transitions between modes.

For a differential-drive robot with three range measurements \( y_k = (d_{f,k}, d_{\ell,k}, d_{r,k}) \) (front, left, right), a typical rule-based autonomy for corridor navigation is:

• State 1: Explore — move forward with constant velocity if the front is clear.
• State 2: Avoid — if the front distance is small, rotate in place until an opening is found.
• State 3: FollowRightWall — keep a roughly constant right distance by adjusting angular velocity.

The figure below shows the high-level FSM, where each node corresponds to a mode with its own low-level control law.

stateDiagram-v2
  [*] --> Explore
  Explore --> Avoid : "front_close"
  Explore --> FollowRightWall : "right_detected"
  Avoid --> Explore : "front_clear"
  Avoid --> FollowRightWall : "right_detected"
  FollowRightWall --> Avoid : "front_close"
  FollowRightWall --> Explore : "no_wall_detected"
        

In code, these transitions are implemented with nested if structures or a small state variable. Each state corresponds to a rule set \( \pi^{(s)} \), and the overall closed-loop dynamics are those of a switching system whose mode is chosen by logical predicates on the measurements.

We now specify a concrete rule set for the corridor navigation task. Denote by \( d_{f,k} \), \( d_{\ell,k} \), and \( d_{r,k} \) the front, left, and right distances at time step \( k \). Let the control input be the pair \( u_k = (v_k, \omega_k) \), where \( v_k \) is the forward velocity command and \( \omega_k \) is the angular velocity command.

Choose positive thresholds \( d_{\text{front}}^{\text{safe}} \) and \( d_{\text{right}}^{\text{ref}} \), and gains \( k_v, k_{\omega} > 0 \). A simple rule set is:

\[ (v_k, \omega_k) = \begin{cases} (v_{\text{cruise}}, 0), & d_{f,k} \ge d_{\text{front}}^{\text{safe}} \text{ and } d_{r,k} \text{ not measured},\\[4pt] (0, \omega_{\text{turn}}), & d_{f,k} < d_{\text{front}}^{\text{safe}},\\[4pt] \bigl(v_{\text{cruise}}, k_{\omega}(d_{r,k} - d_{\text{right}}^{\text{ref}})\bigr), & d_{f,k} \ge d_{\text{front}}^{\text{safe}} \text{ and } d_{r,k} \text{ measured}, \end{cases} \]

where:

• \( v_{\text{cruise}} > 0 \) is a nominal forward speed in free space.
• \( \omega_{\text{turn}} > 0 \) is a constant angular rate for turning in place.
• In the third branch the robot follows a right wall by steering with a proportional law on the wall distance error \( d_{r,k} - d_{\text{right}}^{\text{ref}} \).

In this example, the continuous dynamics (e.g., the mapping from \( (v_k,\omega_k) \) to the robot pose) are handled by lower-level controllers and kinematics (which you will study in a later course), while this lesson focuses on how the high-level logic structures those continuous controllers.

In Python, a typical robotics workflow uses ROS 2 via rclpy. The snippet below shows a minimal structure of a node that subscribes to range data, evaluates the rule set, and publishes velocity commands. The focus is on the rule logic, not on ROS boilerplate.

import rclpy
from rclpy.node import Node
from sensor_msgs.msg import Range
from geometry_msgs.msg import Twist

class SimpleRuleBasedController(Node):
    def __init__(self):
        super().__init__('simple_rule_based_controller')
        # Parameters
        self.d_front_safe = 0.5     # [m]
        self.d_right_ref = 0.6      # [m]
        self.v_cruise = 0.2         # [m/s]
        self.omega_turn = 0.6       # [rad/s]
        self.k_omega = 1.0          # proportional gain

        # Internal measurements
        self.d_front = None
        self.d_right = None

        # Subscriptions and publisher
        self.create_subscription(
            Range, '/front_range', self.front_callback, 10)
        self.create_subscription(
            Range, '/right_range', self.right_callback, 10)
        self.cmd_pub = self.create_publisher(
            Twist, '/cmd_vel', 10)

        # Control loop timer
        self.create_timer(0.05, self.control_loop)  # 20 Hz

    def front_callback(self, msg: Range):
        self.d_front = msg.range

    def right_callback(self, msg: Range):
        self.d_right = msg.range

    def control_loop(self):
        # Only act when we have at least the front measurement
        if self.d_front is None:
            return

        v = 0.0
        omega = 0.0

        # Rule 1: if front is too close, stop and turn
        if self.d_front < self.d_front_safe:
            v = 0.0
            omega = self.omega_turn

        # Rule 2: if front is clear and we have a right wall, follow it
        elif self.d_right is not None:
            v = self.v_cruise
            error_right = self.d_right - self.d_right_ref
            omega = self.k_omega * error_right

        # Rule 3: otherwise, just cruise forward
        else:
            v = self.v_cruise
            omega = 0.0

        cmd = Twist()
        cmd.linear.x = float(v)
        cmd.angular.z = float(omega)
        self.cmd_pub.publish(cmd)

def main(args=None):
    rclpy.init(args=args)
    node = SimpleRuleBasedController()
    rclpy.spin(node)
    node.destroy_node()
    rclpy.shutdown()

if __name__ == '__main__':
    main()
      

The if structure implements the three-region rule set. Provided the low-level motor drivers track the commanded velocities accurately and the sampling time is small enough, the discrete-time analysis of Sections 2–3 provides a first approximation of the closed loop behavior.

In C++, the same logic can be implemented within a ROS 2 node using rclcpp. Only the core structure is shown; error checking and full initialization are omitted for brevity.

#include <rclcpp/rclcpp.hpp>
#include <sensor_msgs/msg/range.hpp>
#include <geometry_msgs/msg/twist.hpp>

class SimpleRuleBasedController : public rclcpp::Node {
public:
  SimpleRuleBasedController()
  : Node("simple_rule_based_controller"),
    d_front_(std::numeric_limits<double>::quiet_NaN()),
    d_right_(std::numeric_limits<double>::quiet_NaN())
  {
    d_front_safe_ = 0.5;
    d_right_ref_ = 0.6;
    v_cruise_ = 0.2;
    omega_turn_ = 0.6;
    k_omega_ = 1.0;

    sub_front_ = this->create_subscription<sensor_msgs::msg::Range>(
      "/front_range", 10,
      std::bind(&SimpleRuleBasedController::frontCallback, this, std::placeholders::_1));

    sub_right_ = this->create_subscription<sensor_msgs::msg::Range>(
      "/right_range", 10,
      std::bind(&SimpleRuleBasedController::rightCallback, this, std::placeholders::_1));

    pub_cmd_ = this->create_publisher<geometry_msgs::msg::Twist>("/cmd_vel", 10);

    timer_ = this->create_wall_timer(
      std::chrono::milliseconds(50),
      std::bind(&SimpleRuleBasedController::controlLoop, this));
  }

private:
  void frontCallback(const sensor_msgs::msg::Range::SharedPtr msg)
  {
    d_front_ = msg->range;
  }

  void rightCallback(const sensor_msgs::msg::Range::SharedPtr msg)
  {
    d_right_ = msg->range;
  }

  void controlLoop()
  {
    if (!std::isfinite(d_front_)) {
      return;
    }

    double v = 0.0;
    double omega = 0.0;

    if (d_front_ < d_front_safe_) {
      v = 0.0;
      omega = omega_turn_;
    } else if (std::isfinite(d_right_)) {
      v = v_cruise_;
      double error_right = d_right_ - d_right_ref_;
      omega = k_omega_ * error_right;
    } else {
      v = v_cruise_;
      omega = 0.0;
    }

    geometry_msgs::msg::Twist cmd;
    cmd.linear.x = v;
    cmd.angular.z = omega;
    pub_cmd_->publish(cmd);
  }

  // Parameters
  double d_front_safe_;
  double d_right_ref_;
  double v_cruise_;
  double omega_turn_;
  double k_omega_;

  // Measurements
  double d_front_;
  double d_right_;

  // ROS interfaces
  rclcpp::Subscription<sensor_msgs::msg::Range>::SharedPtr sub_front_;
  rclcpp::Subscription<sensor_msgs::msg::Range>::SharedPtr sub_right_;
  rclcpp::Publisher<geometry_msgs::msg::Twist>::SharedPtr pub_cmd_;
  rclcpp::TimerBase::SharedPtr timer_;
};

int main(int argc, char ** argv)
{
  rclcpp::init(argc, argv);
  auto node = std::make_shared<SimpleRuleBasedController>();
  rclcpp::spin(node);
  rclcpp::shutdown();
  return 0;
}
      

The logic mirrors the Python version. Because C++ is often used in performance-critical robot stacks, clarity in rule specification is crucial for debugging and safety analysis.

Java is widely used in educational and competition robotics (e.g., FIRST robotics via WPILib) and can interface with robots through a hardware abstraction layer. The example below illustrates how the same rule set can be implemented using a simple Java interface with polling.

public interface RangeSensors {
    double getFront();
    Double getRight(); // may be null if not available
}

public interface MobileBase {
    void setVelocity(double v, double omega);
}

public class RuleBasedAutonomy implements Runnable {

    private final RangeSensors sensors;
    private final MobileBase base;
    private final double dFrontSafe;
    private final double dRightRef;
    private final double vCruise;
    private final double omegaTurn;
    private final double kOmega;
    private final long periodMillis;

    public RuleBasedAutonomy(RangeSensors sensors,
                             MobileBase base,
                             long periodMillis) {
        this.sensors = sensors;
        this.base = base;
        this.periodMillis = periodMillis;
        this.dFrontSafe = 0.5;
        this.dRightRef = 0.6;
        this.vCruise = 0.2;
        this.omegaTurn = 0.6;
        this.kOmega = 1.0;
    }

    @Override
    public void run() {
        while (true) {
            double dFront = sensors.getFront();
            Double dRightObj = sensors.getRight();
            boolean haveRight = (dRightObj != null);
            double v = 0.0;
            double omega = 0.0;

            if (dFront < dFrontSafe) {
                v = 0.0;
                omega = omegaTurn;
            } else if (haveRight) {
                double dRight = dRightObj.doubleValue();
                v = vCruise;
                double errorRight = dRight - dRightRef;
                omega = kOmega * errorRight;
            } else {
                v = vCruise;
                omega = 0.0;
            }

            base.setVelocity(v, omega);

            try {
                Thread.sleep(periodMillis);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                break;
            }
        }
    }
}
      

Here, the same mathematical rule set is expressed using Java control structures. A real system would plug in hardware-specific implementations of RangeSensors and MobileBase.

MATLAB is well suited to simulate discrete-time rule-based controllers before deploying them on actual robots. The following script simulates the one-dimensional distance-keeping rule from Section 3.

% Parameters
T = 0.05;                 % sampling period [s]
k_p = 0.8;                % proportional gain
d_safe = 0.4;             % safe distance [m]
N = 200;                  % number of steps
d = zeros(1, N+1);        % distance trajectory
u = zeros(1, N);          % control input

% Initial condition (safe)
d(1) = 1.2;

for k = 1:N
    if d(k) >= d_safe
        u(k) = k_p * (d(k) - d_safe);
    else
        u(k) = 0.0;
    end
    d(k+1) = d(k) - T * u(k);
end

% Plot results
k = 0:N;
figure; subplot(2,1,1);
plot(k*T, d);
hold on; yline(d_safe, '--');
xlabel('time [s]'); ylabel('distance d_k [m]');
legend('d_k', 'd_{safe}', 'Location', 'best');
grid on;

subplot(2,1,2);
stairs(k(1:end-1)*T, u);
xlabel('time [s]'); ylabel('velocity command u_k [m/s]');
grid on;
      

In Simulink, the same logic can be modeled using a discrete-time integrator for \( d_k \) and a MATLAB Function block or Switch blocks that encode the rules. This allows you to connect the rule-based autonomy to more detailed robot dynamics models while still reasoning about invariance using the discrete-time equations.

In this lesson we constructed a simple rule-based autonomy loop for a mobile robot and analyzed it using discrete-time control concepts. Starting from a one-dimensional distance-keeping model, we showed how piecewise linear rules can guarantee invariance of a safety set under mild conditions on sampling and gains. We then lifted these ideas to a finite-state behavior machine for corridor navigation and illustrated how the same mathematical rules translate into Python, C++, Java, and MATLAB/Simulink implementations.

This style of autonomy is widely used in real systems when robustness and interpretability are more important than optimality. Later courses will connect these rule-based architectures with more advanced planning, learning, and formal verification techniques.