Unit 5: Control and Programming Elements

I. Orientation — From Commands to Autonomous Behaviour

Robot control and programming connect sensing, computation, and actuation. A robot receives information about itself or its environment, decides what action is required, and sends commands to actuators such as motors, grippers, or valves.

• Governing principle: A robotic system repeatedly performs a sense–plan–act cycle:
  1. Sensors measure variables such as position, velocity, distance, or force.
  2. A controller compares measurements with desired values.
  3. Software selects an action.
  4. Actuators produce physical motion.
• Core elements:
  • Plant: The physical system being controlled, such as a robotic arm.
  • Controller: The algorithm or device that generates control signals.
  • Reference or setpoint: The desired state, denoted (r(t)).
  • Output: The measured system state, denoted (y(t)).
  • Control input: The actuator command, denoted (u(t)).
• Main objectives: Stability, accuracy, fast response, smooth motion, safety, and robustness against disturbances.
• Implementation levels: High-level planning may select a destination, while low-level embedded software regulates motor current, speed, or position.

II. Robot Control Systems — Regulating Physical Behaviour

A. Open-loop and closed-loop control

Open-loop control acts without checking the result, whereas closed-loop control continuously uses measured output to correct its action.

1. Open-loop control:

   • Structure: The controller sends (u(t)) to the plant without receiving output information.
   • Example: A mobile robot powers both wheels for five seconds to estimate a travelled distance.
   • Advantages: Simple, inexpensive, fast to implement, and unaffected by sensor noise.
   • Limitations: Wheel slip, battery variation, or an obstacle can create errors that the controller cannot detect.
   • Suitable use: Predictable operations such as running a conveyor for a fixed time.

2. Closed-loop control:

   • Structure: A sensor measures (y(t)), which is compared with the desired value (r(t)).
   • Error equation:

e(t) = r(t) - y(t)

Here, (e(t)) is control error, (r(t)) is the reference, and (y(t)) is measured output.

• Example: A wheel encoder measures angular position until a motor reaches the commanded angle.
• Advantages: Greater accuracy, disturbance rejection, and adaptation to changing loads.
• Limitations: Requires sensors, tuning, computation, and careful stability analysis.

B. Feedback systems

A feedback system returns information about actual performance to the controller so that deviations can be reduced.

• Negative feedback: Subtracts measured output from the reference; most robot regulation uses negative feedback because it reduces error.
• Positive feedback: Reinforces a change and can cause oscillation or instability; it is generally avoided in motion control.
• Feedback path: Includes a sensor, signal conditioning, communication, and sometimes an estimator such as a Kalman filter.
• Disturbance response: If an external force slows a motor, encoder feedback reveals the speed drop and the controller increases motor voltage.
• Stability: A stable system returns toward equilibrium after a small disturbance; excessive gain or delay may create sustained oscillations.
• Practical limitations: Sensor noise, sampling delay, mechanical backlash, actuator saturation, and incorrect calibration reduce performance.
• Performance measures:
  • Rise time: Time required for output to approach the setpoint.
  • Overshoot: Amount by which output exceeds the setpoint.
  • Steady-state error: Error remaining after transient behaviour has ended.

C. PID control (Introduction)

A proportional–integral–derivative controller combines present, accumulated, and predicted error to generate a corrective input.

• Control law:

u(t) = Kp e(t) + Ki ∫e(t)dt + Kd de(t)/dt

Here, (u(t)) is controller output; (e(t)) is error; and (K_p), (K_i), and (K_d) are proportional, integral, and derivative gains.

• Proportional term: (K_p e(t)) reacts to present error; increasing (K_p) usually speeds response but may increase overshoot.
• Integral term: (K_i\int e(t)dt) accumulates past error and removes steady-state offset; excessive integral action can cause slow oscillation or integral windup.
• Derivative term: (K_d\,de(t)/dt) responds to the error’s rate of change and adds damping; measurement noise can produce large derivative fluctuations.
• Digital implementation: At sampling interval (T_s), software updates the controller from sampled errors.

integral = integral + e × Ts
derivative = (e - previous_error) / Ts
u = Kp × e + Ki × integral + Kd × derivative

(T_s) is sampling time, and previous_error is the error from the preceding update.

• Tuning: Gains may be selected experimentally, through system modelling, or by methods such as Ziegler–Nichols tuning.
• Safeguards: Output limiting, integral clamping, and derivative filtering help accommodate real actuators and noisy sensors.

III. Motion Generation — Moving Safely from Start to Goal

A. Motion planning basics

Motion planning determines a collision-free and feasible path or trajectory between an initial robot configuration and a goal configuration.

• Configuration space: Represents a robot state by joint variables (q=[q_1,q_2,\ldots,q_n]); an (n)-joint manipulator generally has an (n)-dimensional configuration space.
• Path and trajectory:
  • Path: Geometric sequence of configurations without timing information.
  • Trajectory: Time-parameterized motion specifying position, velocity, and possibly acceleration.
• Constraints: Plans must respect obstacles, joint limits, maximum velocity, acceleration, torque, and stability requirements.
• Basic procedure:

read start and goal
construct or search free configuration space
find a collision-free path
smooth the path
assign velocity and time
send trajectory points to the controller

• Common methods: Grid search uses algorithms such as A*; sampling-based planners include probabilistic roadmaps and rapidly exploring random trees.
• Local planning: Reacts to nearby obstacles using current sensor data, while global planning uses a larger map to select an overall route.
• Limitations: High-dimensional spaces, moving obstacles, uncertain maps, and non-holonomic motion constraints increase computational difficulty.

IV. Robot Software — Expressing Tasks and Decisions

A. Robot programming concepts

Robot programming converts task requirements into executable sequences of perception, decision, motion, and control operations.

• Programming levels:
  • Joint level: Commands individual joint angles or velocities.
  • Motion level: Requests operations such as “move to pose.”
  • Task level: Specifies goals such as “pick the red block.”
• Program structures: Variables, functions, conditions, loops, events, and state machines organize robot behaviour.
• Coordinate frames: Positions must be identified relative to frames such as world, base, tool, or camera coordinates.
• Teaching methods: Teach pendants and lead-through programming record waypoints directly; offline programming develops and simulates programs on a computer.
• Concurrency: Robots often monitor sensors, control motion, and communicate simultaneously using threads, processes, or event-driven callbacks.
• Safety logic: Emergency-stop states, speed limits, workspace checks, and fault handling must override ordinary task execution.

B. Programming languages used in robotics

Robotics uses multiple languages because real-time control, artificial intelligence, simulation, and hardware access have different requirements.

• C and C++: Provide speed, memory control, and hardware access; they are common in firmware, real-time control, and ROS components.
• Python: Supports rapid development, readable syntax, computer vision, machine learning, and ROS scripting.
• MATLAB/Simulink: Used for modelling, control design, simulation, and automatic code generation.
• Java and C#: Used in interfaces, networked systems, simulations, and application-level software.
• Vendor languages: Industrial robots may use manufacturer-specific languages for motion instructions, input/output, and process control.
• Language selection: Depends on timing deadlines, processor resources, library availability, maintainability, and safety requirements.

V. Embedded Robot Computing — Interfacing Software with Hardware

A. Embedded programming basics

Embedded programming develops software for dedicated processors that directly monitor sensors and control actuators under resource and timing constraints.

• Microcontroller resources: CPU, flash memory, RAM, timers, analogue-to-digital converters, pulse-width modulation channels, and communication peripherals.
• Digital input/output: GPIO pins read switches or drive logic signals; external driver circuits are required for motors drawing substantial current.
• Analogue sensing: An ADC converts sensor voltage into a number; a 10-bit ADC provides (2^{10}=1024) possible levels.
• PWM control: Pulse-width modulation varies average power by changing duty cycle; a 75% duty cycle keeps the signal high for 75% of each period.
• Communication protocols: UART supports serial links, I²C connects addressed peripheral devices, and SPI provides fast synchronous communication.
• Timing: Interrupts respond to urgent events, while timers schedule periodic control loops.
• Reliability: Debouncing, watchdog timers, bounds checking, and fail-safe outputs help prevent unsafe behaviour.

B. Arduino and Raspberry Pi overview

Arduino boards emphasize direct microcontroller control, while Raspberry Pi boards provide general-purpose computing with an operating system.

1. Arduino:

   • Platform: Common boards use a microcontroller and execute one uploaded firmware program.
   • Strengths: Predictable timing, low power consumption, ADC inputs, PWM outputs, and straightforward sensor interfacing.
   • Program model: Arduino sketches commonly contain setup() for initialization and loop() for repeated operation.
   • Limitations: Restricted memory and processing power make complex vision or machine-learning tasks difficult.

2. Raspberry Pi:

   • Platform: A single-board computer that normally runs Linux from removable storage.
   • Strengths: Supports Python, C++, networking, cameras, graphical interfaces, databases, and ROS.
   • Limitations: Linux is not inherently hard real-time, and GPIO pins require electrical protection and motor-driver hardware.
   • Combined use: A Raspberry Pi can perform vision and planning while an Arduino executes precise motor and sensor control.

VI. Robotics Middleware — Integrating Distributed Components

A. Introduction to ROS (Robot Operating System)

ROS is an open-source robotics middleware ecosystem that provides communication tools, reusable software packages, and development utilities rather than a complete operating system.

• Nodes: Independent processes perform functions such as camera acquisition, localization, planning, or motor control.
• Topics: Support asynchronous publish–subscribe communication; for example, a camera node publishes images for vision nodes.
• Services: Provide request–response communication for short operations.
• Actions: Handle longer, cancellable tasks such as navigating to a goal while reporting progress.
• Messages: Typed data structures define exchanged information, such as velocity commands or sensor readings.
• Packages: Organize source code, configuration, launch files, and dependencies.
• Core tools: RViz visualizes robot data, rosbag records and replays messages, and Gazebo-compatible interfaces support simulation.
• ROS generations: ROS 2 improves distributed communication, security options, and real-time support through DDS-based middleware.
• Limitation: ROS integration still requires correct hardware drivers, coordinate transforms, timing, and safety mechanisms.

VII. Interaction and Supervision — Connecting People with Robots

A. Human–Robot Interface basics

A human–robot interface enables people to command, monitor, understand, or collaborate with a robotic system.

• Input methods: Buttons, joysticks, teach pendants, touchscreens, gestures, speech, and virtual-reality controllers can convey commands.
• Output methods: Displays, indicator lights, sounds, haptic feedback, maps, and robot motion communicate status and intent.
• Interaction modes:
  • Teleoperation: A human directly controls robot motion.
  • Supervisory control: A human assigns goals while the robot handles execution.
  • Shared control: Human commands and robot autonomy jointly determine action.
• Usability: Controls should be consistent, readable, responsive, and matched to operator skill and workload.
• Situation awareness: Interfaces should show robot pose, planned path, battery state, sensor condition, and active faults.
• Safety: Emergency stops, command confirmation, access control, speed reduction, and clear warnings reduce risk.
• Trust and transparency: The robot should indicate what it is doing, why it stopped, and whether it requires human intervention.