A social robot is a robot whose primary function involves social interaction with humans, using cues such as speech, gaze, gestures, and spatial positioning. From a control perspective we can think of:

• An internal human latent state \( x_k \in \mathbb{R}^n \) (e.g., engagement, comfort, trust) at discrete time step \( k \).
• A vector of robot social actions \( u_k \in \mathbb{R}^m \) (e.g., speech rate, distance, facial expression parameters).
• An observation vector of measured cues \( y_k \) obtained from sensors (vision, audio, touch).

A simple discrete-time state-space model of human–robot interaction is

\[ x_{k+1} = A x_k + B u_k + w_k, \qquad y_k = C x_k + v_k, \]

where \( A \), \( B \), and \( C \) are matrices of appropriate dimensions, \( w_k \) and \( v_k \) represent unmodeled dynamics and sensor noise. Even for \( n=1 \), this view is useful: we can treat \( x_k \) as a scalar “engagement level”.

The behavioral design problem is then: choose a control law \( u_k = \pi(x_k, y_k, \ldots) \) (possibly with memory) such that \( x_k \) remains in a socially acceptable set, e.g. \( x_k \in [x_{\min}, x_{\max}] \) where extreme boredom or stress are avoided.

flowchart TD
  Hobs["Human observable cues y_k"] --> INF["Infer latent state x_k (engagement, comfort)"]
  INF --> POL["Behavior policy pi(x_k)"]
  POL --> ACT["Robot social actions u_k (gaze, speech, motion)"]
  ACT --> HUM["Human internal dynamics x_{k+1} = A x_k + B u_k + w_k"]
  HUM -->|new cues| Hobs
        

Consider a very simple scalar model for human engagement:

\[ x_{k+1} = a x_k + b u_k, \]

where \( x_k \in \mathbb{R} \) is engagement at time \( k \), \( u_k \) is a scalar control (e.g., amount of robot initiative), and \( a, b \in \mathbb{R} \). Suppose we want to regulate engagement around a desired level \( x_{\mathrm{ref}} \). A simple linear feedback law is

\[ u_k = -K\,(x_k - x_{\mathrm{ref}}), \]

where \( K > 0 \) is a design parameter. Substituting, we obtain the closed-loop dynamics:

\[ x_{k+1} = a x_k + b\big(-K(x_k - x_{\mathrm{ref}})\big) = (a - bK)x_k + bK x_{\mathrm{ref}}. \]

Let \( e_k = x_k - x_{\mathrm{ref}} \) be the engagement error. Then

\[ e_{k+1} = x_{k+1} - x_{\mathrm{ref}} = (a - bK)x_k + bK x_{\mathrm{ref}} - x_{\mathrm{ref}} = (a - bK)e_k. \]

This is a scalar linear system \( e_{k+1} = \lambda e_k \) with eigenvalue \( \lambda = a - bK \). From discrete-time linear systems theory, the origin \( e_k = 0 \) is asymptotically stable if and only if \( |\lambda| < 1 \), i.e.

\[ |a - bK| < 1. \]

Thus, any gain \( K \) satisfying \( |a - bK| < 1 \) yields a stable regulation of engagement. A common design is to pick a desired closed-loop eigenvalue \( \lambda_{\star} \) with \( |\lambda_{\star}| < 1 \) and set

\[ K = \frac{a - \lambda_{\star}}{b}, \qquad b \neq 0. \]

This connects behavioral design to familiar eigenvalue placement from linear control: we are placing the “social dynamics” eigenvalue of engagement.

High-level social behavior is often modeled as a finite-state machine (FSM). Let \( \mathcal{S} \) be a finite set of discrete behavior states, for example:

• \( s_1 = \) Idle
• \( s_2 = \) Greeting
• \( s_3 = \) SmallTalk
• \( s_4 = \) TaskAssist
• \( s_5 = \) Goodbye

Let \( \mathcal{O} \) be a set of discrete observations (e.g., detected user presence, speech activity). An FSM is then a map

\[ f : \mathcal{S} \times \mathcal{O} \to \mathcal{S}, \]

where \( s_{k+1} = f(s_k, o_k) \). The continuous engagement level \( x_k \) from Section 2 can influence transitions by quantizing it into bins, e.g. “low”, “medium”, “high” engagement.

As a simple rule, suppose we define thresholds \( \theta_{\text{low}} \) and \( \theta_{\text{high}} \) such that \( \theta_{\text{low}} < \theta_{\text{high}} \) and

\[ \begin{cases} x_k \le \theta_{\text{low}} &\Rightarrow \text{low engagement}, \\ \theta_{\text{low}} < x_k < \theta_{\text{high}} &\Rightarrow \text{medium engagement}, \\ x_k \ge \theta_{\text{high}} &\Rightarrow \text{high engagement}. \end{cases} \]

The FSM transitions can then be specified in terms of \( s_k \) and the engagement category (plus other observations like user presence).

flowchart TD
  I["Idle"] -->|user detected| G["Greeting"]
  G -->|"short dialog"| T["SmallTalk"]
  T -->|"user asks help"| A["TaskAssist"]
  T -->|"user disengaged (x low)"| BY["Goodbye"]
  A -->|"task done and x high"| BY
  BY -->|"no user"| I
        

In practice, behavior trees and hierarchical state machines extend FSMs with modularity and concurrency, but the above formalism is sufficient for an introductory treatment.

A complementary approach is to define a reward function that captures the desirability of a social state–action pair. Let \( \mathcal{S} \) be a finite state set (e.g., FSM states) and \( \mathcal{A} \) a finite action set (utterances, gestures). A reward function is

\[ R : \mathcal{S} \times \mathcal{A} \to \mathbb{R}, \]

where \( R(s,a) \) is large for socially appropriate behaviors (e.g., polite greeting when user appears) and small or negative for bad behaviors (e.g., interrupting frequently).

Let \( \{(s_k,a_k)\}_{k=0}^{\infty} \) be the sequence of states and actions under a behavior policy \( \pi \). The infinite-horizon discounted return is

\[ G(\pi) = \sum_{k=0}^{\infty} \gamma^k R(s_k, a_k), \qquad 0 < \gamma < 1. \]

Here \( \gamma \) is a discount factor that trades off immediate versus long-term reward. A fundamental observation is that if \( |R(s,a)| \le R_{\max} \) for all \( (s,a) \), then \( G(\pi) \) is well-defined (finite). Indeed:

\[ |G(\pi)| = \left|\sum_{k=0}^{\infty} \gamma^k R(s_k, a_k)\right| \le \sum_{k=0}^{\infty} \gamma^k |R(s_k, a_k)| \le \sum_{k=0}^{\infty} \gamma^k R_{\max} = \frac{R_{\max}}{1 - \gamma}, \]

using the geometric series formula. Thus, any bounded reward model with \( 0 < \gamma < 1 \) yields a finite measure of “social utility” for a given policy.

In more advanced courses, one can formulate social behavior design as an optimization problem:

\[ \pi^{\star} \in \arg\max_{\pi} \; \mathbb{E}\big[G(\pi)\big], \]

where the expectation is over stochastic human responses and sensor noise. In this introductory course, we focus on designing hand-crafted rules that implicitly aim at high reward (e.g., maintaining engagement near a desired level) without solving the full optimization problem.

We now implement a small simulation of the scalar engagement model and a finite-state behavioral controller in Python. In a ROS-based system, such logic would be embedded inside a node subscribing to human state estimates and publishing high-level behavior commands.

import enum
import math
import random

class BehaviorState(enum.Enum):
    IDLE = 0
    GREETING = 1
    SMALLTALK = 2
    ASSIST = 3
    GOODBYE = 4

class SocialRobot:
    def __init__(self,
                 a=0.9, b=0.3,
                 x_ref=0.7,
                 K=0.8,
                 theta_low=0.3,
                 theta_high=0.8):
        self.a = a
        self.b = b
        self.x = 0.0          # initial engagement
        self.x_ref = x_ref
        self.K = K
        self.theta_low = theta_low
        self.theta_high = theta_high
        self.state = BehaviorState.IDLE

    def engagement_control(self):
        # simple linear feedback u_k = -K (x_k - x_ref)
        return -self.K * (self.x - self.x_ref)

    def update_engagement(self, u, noise_std=0.02):
        w = random.gauss(0.0, noise_std)
        self.x = self.a * self.x + self.b * u + w
        # clip to [0,1]
        self.x = max(0.0, min(1.0, self.x))

    def observe_presence(self):
        # toy model: presence probability increases with engagement
        p = 0.2 + 0.6 * self.x
        return random.random() < p

    def step_behavior_fsm(self, presence):
        x = self.x
        if self.state == BehaviorState.IDLE:
            if presence and x < self.theta_high:
                self.state = BehaviorState.GREETING
        elif self.state == BehaviorState.GREETING:
            # after greeting, move to small talk
            self.state = BehaviorState.SMALLTALK
        elif self.state == BehaviorState.SMALLTALK:
            if x < self.theta_low:
                self.state = BehaviorState.GOODBYE
            elif x > self.theta_high:
                self.state = BehaviorState.ASSIST
        elif self.state == BehaviorState.ASSIST:
            if not presence or x < self.theta_low:
                self.state = BehaviorState.GOODBYE
        elif self.state == BehaviorState.GOODBYE:
            if not presence:
                self.state = BehaviorState.IDLE

    def step(self):
        presence = self.observe_presence()
        self.step_behavior_fsm(presence)
        u = self.engagement_control()
        self.update_engagement(u)
        return self.state, self.x, presence, u

if __name__ == "__main__":
    robot = SocialRobot()
    for k in range(30):
        state, x, presence, u = robot.step()
        print(f"k={k:2d} state={state.name:9s} x={x:5.2f} "
              f"presence={presence} u={u:5.2f}")
      

This example combines: (i) a linear engagement model, (ii) threshold-based FSM transitions, and (iii) a simple proportional controller. It can be extended in ROS by mapping BehaviorState to specific messages, such as “play greeting audio file” or “move to user”.

The following C++ snippet illustrates the same FSM structure. In a full robotics stack, this logic could run inside a control loop or a ROS/ROS2 node (e.g., using rclcpp in ROS2).

#include <iostream>

enum class BehaviorState {
    IDLE,
    GREETING,
    SMALLTALK,
    ASSIST,
    GOODBYE
};

BehaviorState step_fsm(BehaviorState s,
                       double x,
                       bool presence,
                       double theta_low,
                       double theta_high)
{
    switch (s) {
    case BehaviorState::IDLE:
        if (presence && x < theta_high)
            return BehaviorState::GREETING;
        return s;
    case BehaviorState::GREETING:
        return BehaviorState::SMALLTALK;
    case BehaviorState::SMALLTALK:
        if (x < theta_low)
            return BehaviorState::GOODBYE;
        if (x > theta_high)
            return BehaviorState::ASSIST;
        return s;
    case BehaviorState::ASSIST:
        if (!presence || x < theta_low)
            return BehaviorState::GOODBYE;
        return s;
    case BehaviorState::GOODBYE:
        if (!presence)
            return BehaviorState::IDLE;
        return s;
    default:
        return BehaviorState::IDLE;
    }
}

const char* to_string(BehaviorState s)
{
    switch (s) {
    case BehaviorState::IDLE: return "IDLE";
    case BehaviorState::GREETING: return "GREETING";
    case BehaviorState::SMALLTALK: return "SMALLTALK";
    case BehaviorState::ASSIST: return "ASSIST";
    case BehaviorState::GOODBYE: return "GOODBYE";
    }
    return "UNKNOWN";
}

int main()
{
    BehaviorState s = BehaviorState::IDLE;
    double x = 0.5;
    double theta_low = 0.3, theta_high = 0.8;

    for (int k = 0; k < 10; ++k) {
        bool presence = (k % 2 == 0); // toy example
        s = step_fsm(s, x, presence, theta_low, theta_high);
        std::cout << "k=" << k
                  << " state=" << to_string(s)
                  << " presence=" << presence
                  << " x=" << x
                  << std::endl;
        // here one would update x according to engagement dynamics
    }
    return 0;
}
      

To integrate with ROS/ROS2, replace the main loop with a timed callback (e.g., using rclcpp::TimerBase) and retrieve x and presence from subscribed topics.

Java is often used in larger service robot software stacks or Android front-ends. The following Java class mimics the FSM logic, assuming that engagement and presence estimates are provided from elsewhere.

public class SocialBehaviorController {

    public enum BehaviorState {
        IDLE,
        GREETING,
        SMALLTALK,
        ASSIST,
        GOODBYE
    }

    private BehaviorState state = BehaviorState.IDLE;
    private final double thetaLow;
    private final double thetaHigh;

    public SocialBehaviorController(double thetaLow, double thetaHigh) {
        this.thetaLow = thetaLow;
        this.thetaHigh = thetaHigh;
    }

    public BehaviorState getState() {
        return state;
    }

    public void step(double engagement, boolean presence) {
        switch (state) {
            case IDLE:
                if (presence && engagement < thetaHigh) {
                    state = BehaviorState.GREETING;
                }
                break;
            case GREETING:
                state = BehaviorState.SMALLTALK;
                break;
            case SMALLTALK:
                if (engagement < thetaLow) {
                    state = BehaviorState.GOODBYE;
                } else if (engagement > thetaHigh) {
                    state = BehaviorState.ASSIST;
                }
                break;
            case ASSIST:
                if (!presence || engagement < thetaLow) {
                    state = BehaviorState.GOODBYE;
                }
                break;
            case GOODBYE:
                if (!presence) {
                    state = BehaviorState.IDLE;
                }
                break;
            default:
                state = BehaviorState.IDLE;
        }
    }

    public static void main(String[] args) {
        SocialBehaviorController ctrl =
            new SocialBehaviorController(0.3, 0.8);
        double x = 0.5;
        boolean presence = true;
        for (int k = 0; k < 10; ++k) {
            ctrl.step(x, presence);
            System.out.println("k=" + k +
                               " state=" + ctrl.getState() +
                               " x=" + x +
                               " presence=" + presence);
            // here: update x and presence from sensors
        }
    }
}
      

In a larger system, the step method would be called from a periodic control loop or an event handler, and the resulting BehaviorState would drive dialogue or motion modules.

MATLAB can be used to simulate the discrete-time engagement dynamics and evaluate simple controllers before implementing them in real robots. Consider again

\[ x_{k+1} = a x_k + b u_k, \qquad u_k = -K(x_k - x_{\mathrm{ref}}). \]

A basic MATLAB script is:

a = 0.9;
b = 0.3;
K = 0.8;
x_ref = 0.7;

N = 40;
x = zeros(1, N+1);
u = zeros(1, N);
x(1) = 0.1;

for k = 1:N
    u(k) = -K * (x(k) - x_ref);
    x(k+1) = a * x(k) + b * u(k);
end

k = 0:N;
figure;
subplot(2,1,1);
stairs(k, x, "LineWidth", 1.5);
xlabel("k");
ylabel("engagement x_k");
grid on;

subplot(2,1,2);
stairs(0:N-1, u, "LineWidth", 1.5);
xlabel("k");
ylabel("control u_k");
grid on;
      

To implement the same model in Simulink:

1. Create a new model and set a discrete sample time T_s.
2. Use a Unit Delay block to represent the state update from x_k to x_{k+1}.
3. Implement the update equation using Gain blocks for a, b, and K, plus a Sum block to compute x_{k+1} = a*x_k + b*u_k.
4. Use a Constant block for x_ref and a Scope to visualize x_k over time.

This simulation lets students explore how different values of \( K \) affect convergence and overshoot of engagement, mirroring the reasoning in Section 2.

Social robots can be viewed as control systems that regulate latent human states such as engagement via expressive actions and interaction structure. We introduced simple discrete-time models for engagement, derived stability conditions for linear feedback, and described finite-state and reward-based formulations of behavioral design. Small Python, C++, Java, and MATLAB/Simulink examples illustrated how these models can be turned into executable controllers, preparing the ground for more advanced HRI and autonomy techniques in follow-up courses.