# Classical Robotics: MASTER Guide for Autonomous Systems Classical robotics gives you the mathematical language for answering questions such as: * Where is the robot? * Where is its end effector? * How do coordinate systems relate? * What joint angles place the gripper at a desired position? * How fast should each joint move? * What happens near a singular configuration? * How does a wheeled robot move? * What forces and torques are required to produce motion? * How should a robot move smoothly from one state to another? * How do motors and actuators convert commands into physical movement? Modern robotics may include: ```text cameras LiDAR deep learning vision-language models reinforcement learning foundation models autonomous agents ``` but underneath all of those lies something much older: ```text geometry kinematics dynamics control mechanics ``` A neural network can recognize a cup. But if a robot arm must reach that cup, it still needs to understand: ```text Where is the cup relative to the robot? What pose should the gripper reach? What joint angles produce that pose? Are those joint angles physically possible? Is the robot near a singularity? What trajectory should the arm follow? What torques will the motors need? ``` That is classical robotics. The goal of this chapter is to build a working mental model connecting: ```text coordinate frames → transformations → configuration space → kinematics → Jacobians → mobile robot motion → dynamics → trajectory generation → actuators ``` * * * # 1\. The Robotics Pipeline A useful high-level picture is: ```text World ↓ Perception ↓ Estimate robot/environment state ↓ Geometric reasoning ↓ Plan desired motion ↓ Compute joint/wheel commands ↓ Controller ↓ Actuators ↓ Physical robot ↓ Sensors └──────────────→ feedback ``` Classical robotics mostly lives in the middle: ```text State ↓ Geometry ↓ Kinematics ↓ Dynamics ↓ Trajectory ↓ Control ``` Before discussing movement, however, we must define **where things are**. * * * # 2\. Coordinate Frames Almost everything in robotics is expressed relative to some coordinate frame. Imagine a mobile robot with a camera and robotic arm. There may be frames such as: ```text world map odom base_link camera_link arm_base shoulder elbow wrist gripper ``` A frame defines: ```text origin + orientation ``` For a 3D Cartesian frame: ```text z ↑ | | O────→ x / / y ``` A point might have coordinates: ```text p = [2, 1, 0.5] ``` But those numbers are meaningless without specifying: > Relative to which frame? For example: ```text camera frame: cup = [0.3, 0.1, 1.2] ``` means: ```text 30 cm along camera x 10 cm along camera y 1.2 m along camera z ``` The same physical cup has different coordinates in the world frame. * * * # 3\. A Point Is Not Its Coordinates This distinction is fundamental. The physical point exists independently. Its numerical representation depends on the frame. Suppose: ```text World frame coordinates: p = [5, 2] ``` The exact same point might be: ```text Robot frame coordinates: p = [1, -0.5] ``` Nothing moved. Only the coordinate system changed. This idea appears everywhere in robotics. * * * # 4\. Frame Notation A common notation is: ```text ^A p ``` meaning: > coordinates of point `p` expressed in frame A. Similarly: ```text ^B p ``` means the same physical point represented in frame B. Transformations allow us to convert: ```text ^B p → ^A p ``` * * * # 5\. Translation Suppose two coordinate frames have the same orientation but different origins. ```text World origin Robot origin O----------------O translation ``` If the robot origin is at: ```text t = [3, 2] ``` then a point: ```text p_robot = [1, 1] ``` becomes: ```text p_world = t + p_robot ``` so: ```text p_world = [4, 3] ``` Translation changes position but not orientation. * * * # 6\. Rotation Frames can also be rotated. In 2D, a rotation by angle θ is: ```text R(θ) = [ cosθ -sinθ sinθ cosθ ] ``` If: ```text p_B ``` is expressed in frame B and B is rotated relative to A: ```text p_A = R p_B ``` A rotation matrix changes the coordinate representation while preserving: ```text lengths angles rigid geometry ``` * * * # 7\. Properties of Rotation Matrices For a valid rotation matrix: ```text RᵀR = I ``` Therefore: ```text R⁻¹ = Rᵀ ``` Also: ```text det(R) = 1 ``` These are useful computational properties. Rotation matrices belong to a mathematical group called: ```text SO(3) ``` for 3D rotations. SO means: ```text Special Orthogonal ``` You do not need abstract group theory to use them, but SO(3) appears constantly in robotics literature. * * * # 8\. 3D Rotation In 3D, we rotate around: ```text x-axis y-axis z-axis ``` For example, rotation around z: ```text Rz(θ) = [ cosθ -sinθ 0 sinθ cosθ 0 0 0 1 ] ``` Rotations can be composed: ```text R = Rz Ry Rx ``` But multiplication order matters. In general: ```text R1 R2 ≠ R2 R1 ``` 3D rotations are **noncommutative**. That is one reason orientation is more subtle than position. * * * # 9\. Euler Angles Orientation can also be represented using three angles. Common forms include: ```text roll pitch yaw ``` often abbreviated: ```text RPY ``` For example: ```text roll = rotation about x pitch = rotation about y yaw = rotation about z ``` Euler angles are intuitive. But they have weaknesses. One major problem is: ```text gimbal lock ``` where certain orientations cause degrees of rotational freedom to become indistinguishable. * * * # 10\. Quaternions Robotics systems frequently represent 3D orientation using quaternions. A quaternion may be written: ```text q = [x, y, z, w] ``` or sometimes: ```text q = [w, x, y, z] ``` depending on the library. A unit quaternion satisfies: ```text ||q|| = 1 ``` Advantages include: ```text compact representation no gimbal lock efficient composition smooth interpolation ``` ROS commonly uses quaternions for orientation. For example: ```text geometry_msgs/Pose ``` contains: ```text position: x y z orientation: x y z w ``` * * * # 11\. Pose A **pose** consists of: ```text position + orientation ``` For a rigid body in 3D: ```text position = 3 values orientation = 3 independent rotational DOF ``` Therefore a free rigid body has: ```text 6 degrees of freedom ``` usually: ```text x y z roll pitch yaw ``` * * * # 12\. Homogeneous Transformation Matrices Robotics often combines translation and rotation into a single matrix. A 3D rigid transformation is: ```text T = [ R t 0 1 ] ``` where: ```text R = 3×3 rotation matrix t = 3×1 translation vector ``` So T is: ```text 4×4 ``` A point becomes homogeneous: ```text p = [x y z 1] ``` Then: ```text p_A = T_A_B p_B ``` This means: > transform coordinates from frame B into frame A. * * * # 13\. Why Homogeneous Transformations Matter Without homogeneous coordinates: ```text p_A = R p_B + t ``` With them: ```text p_A = T_A_B p_B ``` Now multiple transformations can be composed using matrix multiplication. Example: ```text world ↓ robot ↓ camera ↓ object ``` Then: ```text T_world_object = T_world_robot T_robot_camera T_camera_object ``` This is one of the most important equations in practical robotics. * * * # 14\. Transformation Chains Imagine a robotic arm: ```text World ↓ Base ↓ Shoulder ↓ Elbow ↓ Wrist ↓ Gripper ``` Each joint contributes a transformation. Then: ```text T_world_gripper = T_world_base T_base_shoulder T_shoulder_elbow T_elbow_wrist T_wrist_gripper ``` Robot kinematics is largely the systematic construction of these transformation chains. * * * # 15\. Inverse Transformations If: ```text T_A_B ``` converts from frame B to A, then: ```text T_B_A = T_A_B⁻¹ ``` For: ```text T = [R t 0 1] ``` the inverse has the convenient structure: ```text T⁻¹ = [Rᵀ -Rᵀt 0 1 ] ``` * * * # 16\. ROS TF Mental Model In ROS/ROS 2, transforms form a tree. Example: ```text map ↓ odom ↓ base_link ├── lidar_link ├── camera_link └── arm_base ↓ ... ``` If TF knows the transformations between connected frames, it can calculate: ```text camera → map gripper → base_link lidar → world ``` by composing transforms. The mathematics is exactly what we have just discussed. * * * # 17\. Degrees of Freedom Degrees of freedom, or DOF, describe the number of independent variables needed to specify a system's configuration. A point moving along a line: ```text 1 DOF ``` A point moving on a plane: ```text x y 2 DOF ``` A planar rigid robot: ```text x y θ 3 DOF ``` A free rigid body in space: ```text x y z roll pitch yaw 6 DOF ``` * * * # 18\. Robot Joints Robot manipulators commonly use: ```text revolute joints prismatic joints ``` A revolute joint rotates: ```text ───○─── ↻ ``` Its joint variable is usually: ```text θ ``` A prismatic joint translates: ```text ────[ ]────→ ``` Its joint variable is usually: ```text d ``` Each simple revolute or prismatic joint contributes approximately one DOF. * * * # 19\. Joint Space Suppose a robot arm has three revolute joints. Its configuration may be: ```text q = [θ1 θ2 θ3] ``` This vector is called the **joint configuration** or generalized coordinate vector. The space of possible q values is the robot's configuration space. * * * # 20\. Configuration Space Configuration space is usually written: ```text C ``` or: ```text C-space ``` Instead of thinking about the physical robot's entire geometry, we represent its state using configuration variables. Example planar robot: ```text q = [x, y, θ] ``` Its configuration space is three-dimensional. A 6-joint manipulator may have: ```text q = [θ1 θ2 θ3 θ4 θ5 θ6] ``` so its joint configuration space is six-dimensional. * * * # 21\. Configuration Space vs Workspace These are different concepts. ## Configuration space Contains robot configurations: ```text q ``` Example: ```text [θ1, θ2, θ3] ``` ## Workspace Contains positions or poses reachable by the robot's physical body or end effector. Example: ```text [x, y, z] ``` A six-joint robot may have a six-dimensional configuration space while its end-effector workspace occupies some subset of 3D physical space. * * * # 22\. Obstacles in Configuration Space Suppose a robot arm must avoid a table. Rather than representing collision geometry directly, motion planning often asks: ```text Which joint configurations cause collision? ``` Those configurations form: ```text C_obstacle ``` Collision-free configurations form: ```text C_free ``` Then motion planning becomes: > Find a path through configuration space from start q to goal q without entering C\_obstacle. Conceptually: ```text q_start ↓ C_free ↓ q_goal ``` This idea becomes important later for algorithms such as: ```text RRT RRT* PRM A* trajectory optimization ``` * * * # 23\. Forward Kinematics Forward kinematics asks: > Given the robot's joint variables, where is the end effector? Input: ```text q ``` Output: ```text end-effector pose ``` Mathematically: ```text x = f(q) ``` where: ```text q = joint configuration x = task-space pose ``` * * * # 24\. Simple 2-Link Planar Arm Imagine: ```text end effector ● / L2/ / ● elbow / L1/ / ● base ``` Joint angles: ```text θ1 θ2 ``` Link lengths: ```text L1 L2 ``` Then the end-effector position is: ```text x = L1 cosθ1 + L2 cos(θ1 + θ2) y = L1 sinθ1 + L2 sin(θ1 + θ2) ``` This is forward kinematics. Given: ```text θ1 θ2 ``` the position can be calculated directly. * * * # 25\. Forward Kinematics Through Transformations For larger robots: ```text T_0_n(q) = T_0_1(q1) T_1_2(q2) ... T_(n-1)_n(qn) ``` The final transformation contains: ```text end-effector position + end-effector orientation ``` This formulation works for complex manipulators. * * * # 26\. Denavit-Hartenberg Parameters A classical method for describing manipulator geometry is the Denavit-Hartenberg convention. Each link transformation is described by four parameters: ```text θ joint angle d link offset a link length α link twist ``` This allows robot geometry to be represented systematically. A DH table may look like: ```text Joint θ d a α 1 θ1 d1 a1 α1 2 θ2 d2 a2 α2 3 θ3 d3 a3 α3 ``` From these parameters, homogeneous transformations are constructed. Modern robotics libraries may use alternative conventions internally, but DH remains valuable for understanding manipulator kinematics. * * * # 27\. Inverse Kinematics Inverse kinematics asks the reverse question: > Given the desired end-effector pose, what joint configuration should the robot use? Forward: ```text q → x ``` Inverse: ```text x_desired → q ``` So we want: ```text f(q) = x_desired ``` * * * # 28\. Why Inverse Kinematics Is Harder Forward kinematics usually has one direct answer. Inverse kinematics can have: ```text no solution one solution multiple solutions infinitely many solutions ``` For a 2-link arm reaching one point: ```text elbow up ● / ---target or ---target \ ● elbow down ``` Both configurations may reach the same point. * * * # 29\. Reachability Not every desired pose is physically reachable. For a two-link planar arm: ```text maximum reach = L1 + L2 ``` If the target lies farther away: ```text distance > L1 + L2 ``` no inverse-kinematics solution exists. Similarly, joint limits may make an otherwise geometrically reachable pose impossible. * * * # 30\. Analytical Inverse Kinematics For simple robot geometries, IK can sometimes be solved using closed-form equations. For the 2-link arm: ```text cosθ2 = (x² + y² - L1² - L2²) / (2 L1 L2) ``` Then: ```text θ2 = ±acos(...) ``` The ± corresponds to multiple configurations. After θ2 is selected, θ1 can be computed. Analytical IK is: ```text fast precise ``` but often difficult or impossible to derive for arbitrary mechanisms. * * * # 31\. Numerical Inverse Kinematics General robots often use iterative numerical methods. Start with an initial guess: ```text q0 ``` Compute the current pose: ```text x = f(q) ``` Find error: ```text e = x_desired - x ``` Then update q: ```text q ← q + Δq ``` until: ```text ||e|| < tolerance ``` The Jacobian tells us how to choose Δq. * * * # 32\. The Jacobian The Jacobian is one of the central objects in robotics. Recall: ```text x = f(q) ``` Differentiate: ```text ẋ = J(q) q̇ ``` where: ```text q̇ = joint velocities ẋ = end-effector velocity J = Jacobian ``` The Jacobian maps: ```text joint velocity → task-space velocity ``` * * * # 33\. Jacobian of a 2-Link Arm For: ```text x = L1 cosθ1 + L2 cos(θ1+θ2) y = L1 sinθ1 + L2 sin(θ1+θ2) ``` the Jacobian is: ```text J = [ ∂x/∂θ1 ∂x/∂θ2 ∂y/∂θ1 ∂y/∂θ2 ] ``` giving: ```text J = [ -L1 sinθ1 - L2 sin(θ1+θ2) -L2 sin(θ1+θ2) L1 cosθ1 + L2 cos(θ1+θ2) L2 cos(θ1+θ2) ] ``` Then: ```text [ẋ ẏ] = J [θ̇1 θ̇2] ``` * * * # 34\. Velocity Kinematics Suppose the robot should move its gripper horizontally at: ```text ẋ = 0.1 m/s ẏ = 0 ``` We want joint velocities satisfying: ```text ẋ = J q̇ ``` If J is square and invertible: ```text q̇ = J⁻¹ ẋ ``` This is inverse velocity kinematics. Instead of asking: ```text What joint angles reach this pose? ``` we ask: ```text What joint velocities produce this Cartesian velocity? ``` * * * # 35\. Redundant Manipulators Suppose the task needs six DOF but the robot has seven joints. Then: ```text number of joint variables > number of task variables ``` The robot is redundant. There may be infinitely many q̇ values producing the same ẋ. This is actually useful. Extra freedom can be used to: ```text avoid obstacles avoid joint limits stay away from singularities minimize energy keep comfortable posture ``` * * * # 36\. Jacobian Pseudoinverse If J is not square, we commonly use the Moore-Penrose pseudoinverse: ```text J⁺ ``` Then: ```text q̇ = J⁺ ẋ ``` provides one useful solution. For redundant robots, additional null-space motion can be added: ```text q̇ = J⁺ẋ + (I - J⁺J) z ``` The first term performs the primary task. The second term moves within directions that do not affect the end-effector task. That second term can optimize secondary objectives. * * * # 37\. Null Space Suppose: ```text J q̇_null = 0 ``` Then q̇\_null moves the joints without producing end-effector motion. This motion lies in the Jacobian's null space. A 7-DOF arm might hold its gripper fixed while changing elbow posture. ```text gripper: unchanged elbow: moves ``` This is extremely useful in advanced manipulation. * * * # 38\. Singularities A singularity occurs when the Jacobian loses rank. Informally: > The robot loses the ability to move in some Cartesian direction. For a 2-link arm fully stretched: ```text base ───── link1 ───── link2 ───── end ``` the links align. Certain movement directions become impossible instantaneously. Mathematically: ```text det(J) = 0 ``` for a square Jacobian. More generally: ```text rank(J) drops ``` * * * # 39\. Why Singularities Are Dangerous Near a singularity: ```text J⁻¹ ``` becomes numerically unstable. A small desired Cartesian velocity can require enormous joint velocities. Example: ```text desired gripper motion: 0.01 m/s required joint speed: 100 rad/s ``` which the robot cannot physically produce. Near singularities you may see: ```text large joint velocities poor numerical behavior loss of control authority unstable IK ``` * * * # 40\. Damped Least Squares A common numerical technique near singularities is damped least squares. Instead of directly using: ```text J⁺ ``` one computes something conceptually like: ```text q̇ = Jᵀ (J Jᵀ + λ²I)⁻¹ ẋ ``` where λ adds damping. This sacrifices some tracking precision to avoid extremely large joint commands. * * * # 41\. Manipulability The Jacobian can also tell us how easily the robot can move in different directions. Some configurations provide good freedom: ```text / / base ●──── ``` Others are poorly conditioned: ```text base ●──────────── ``` Manipulability measures quantify this. One classical measure is: ```text w = sqrt(det(J Jᵀ)) ``` Near singularity: ```text w → 0 ``` This can be used to keep the robot away from difficult configurations. * * * # 42\. Position Kinematics vs Velocity Kinematics Keep these layers separate. ## Position kinematics ```text q → x ``` Forward kinematics. ## Inverse position kinematics ```text x → q ``` Inverse kinematics. ## Velocity kinematics ```text q̇ → ẋ ``` Jacobian. ## Inverse velocity kinematics ```text ẋ → q̇ ``` Jacobian inverse or pseudoinverse. These relationships form the geometric heart of manipulation. * * * # 43\. Manipulator Kinematics A serial manipulator can be thought of as: ```text Base ↓ Joint 1 ↓ Link 1 ↓ Joint 2 ↓ Link 2 ↓ ... ↓ End Effector ``` Each joint contributes one transformation. The configuration: ```text q = [q1 ... qn] ``` determines every link's pose. This allows us to calculate not just the end effector but also: ```text elbow position wrist position link orientations collision geometry center of mass locations ``` These become necessary for planning and dynamics. * * * # 44\. Serial vs Parallel Manipulators Most common robot arms are serial: ```text base → link → link → link → tool ``` Examples include six-axis industrial manipulators. Parallel robots use several kinematic chains simultaneously. Conceptually: ```text platform / | \ / | \ actuator actuator actuator ``` Parallel systems can provide: ```text high stiffness high precision high acceleration ``` but their kinematics can be significantly more complex. * * * # 45\. Mobile Robot Kinematics Manipulators are not the only robot type. Mobile robots include: ```text differential drive car-like / Ackermann omnidirectional mecanum swerve legged systems ``` Each has different movement constraints. * * * # 46\. Differential Drive A differential-drive robot has two independently driven wheels. ```text front ↑ L wheel R wheel O──────O ``` Let: ```text r = wheel radius L = distance between wheels ωL = left wheel angular velocity ωR = right wheel angular velocity ``` Linear velocity: ```text v = r/2 (ωR + ωL) ``` Angular velocity: ```text ω = r/L (ωR - ωL) ``` * * * # 47\. Differential Drive Behaviors If: ```text ωL = ωR ``` then: ```text ω = 0 ``` and the robot drives straight. If: ```text ωL = -ωR ``` then: ```text v = 0 ``` and the robot rotates approximately in place. If: ```text ωR > ωL ``` the robot turns. This is the kinematic basis of many indoor robots, including TurtleBot-like platforms. * * * # 48\. Differential Drive State Model A planar robot pose: ```text q = [x, y, θ] ``` Given linear velocity v and angular velocity ω: ```text ẋ = v cosθ ẏ = v sinθ θ̇ = ω ``` This simple model is everywhere in mobile robotics. * * * # 49\. Nonholonomic Constraints A differential-drive robot cannot instantaneously move sideways. A car has the same issue. Even though the robot's pose has: ```text x y θ ``` it cannot arbitrarily command: ```text ẋ ẏ θ̇ ``` independently. For an ideal wheeled robot: ```text sideways velocity = 0 ``` This is a **nonholonomic constraint**. It strongly influences path planning. * * * # 50\. Why a Car Needs Maneuvering Suppose a car wants to move sideways into a parking space. It cannot simply command: ```text velocity = left ``` Instead it performs a sequence: ```text forward turn reverse turn ``` The final displacement contains sideways movement even though instantaneous sideways velocity was impossible. That is a classic consequence of nonholonomic constraints. * * * # 51\. Ackermann Steering Cars typically use Ackermann steering. ```text front wheels / \ O O O O rear wheels ``` During a turn, the inner and outer front wheels require different steering angles. Why? Because they follow circles with different radii. Ideally all wheel axes intersect at one instantaneous center of rotation. ```text ICC ● /| / | / | robot/car ``` * * * # 52\. Bicycle Model A simplified car model replaces the four wheels with two effective wheels: ```text front O / / O rear ``` This is called the bicycle model. Let: ```text L = wheelbase δ = steering angle v = speed ``` Then approximately: ```text ẋ = v cosθ ẏ = v sinθ θ̇ = (v/L) tanδ ``` This model is widely used in: ```text autonomous cars mobile robot planning MPC trajectory tracking ``` * * * # 53\. Turning Radius From the bicycle model: ```text θ̇ = v/L tanδ ``` the turning radius R approximately satisfies: ```text R = L / tanδ ``` Large steering angle: ```text smaller turning radius ``` Small steering angle: ```text larger turning radius ``` This creates constraints for autonomous vehicle path planners. * * * # 54\. Omnidirectional Robots An omnidirectional robot can move sideways without first rotating. Conceptually: ```text ↑ forward ← robot → ↓ backward ``` It may command: ```text vx vy ω ``` independently within actuator limits. Examples include robots using: ```text omni wheels mecanum wheels certain swerve-drive systems ``` * * * # 55\. Mecanum Wheels Mecanum wheels contain angled rollers. ```text //// wheel ``` By combining wheel speeds appropriately, the robot can generate forces in multiple planar directions. A four-wheel mecanum platform can approximately control: ```text vx vy ω ``` This makes maneuvering easier but introduces: ```text slip lower mechanical efficiency more complex wheel kinematics ``` * * * # 56\. Instantaneous Center of Rotation Many wheeled robot motions can be understood using the instantaneous center of rotation, or ICR. At a given instant, the robot behaves as though it is rotating around some point. Straight motion corresponds roughly to: ```text ICR infinitely far away ``` Pure rotation corresponds to: ```text ICR near robot center ``` This geometric viewpoint helps understand both differential-drive and Ackermann motion. * * * # 57\. Kinematics vs Dynamics Kinematics describes motion without asking what causes it. Questions such as: ```text Where is the robot? How fast is it moving? What joint velocity produces this tool velocity? ``` are kinematic. Dynamics asks: > What forces and torques produce that motion? For example: ```text How much torque is required at the shoulder? How does gravity affect the arm? What acceleration will a motor torque produce? ``` That is dynamics. * * * # 58\. Rigid Bodies Classical robot models often treat links as rigid bodies. A rigid body preserves distances between its points. If points A and B belong to one rigid link: ```text ||A - B|| = constant ``` regardless of robot motion. Real robots flex slightly. But rigid-body assumptions work extremely well for many systems. * * * # 59\. Mass Mass tells us how strongly a body resists linear acceleration. Newton's law: ```text F = ma ``` More precisely: ```text F = m a ``` where: ```text F = force m = mass a = acceleration ``` * * * # 60\. Rotational Inertia Rotational motion has an analogous quantity: ```text moment of inertia ``` For simple rotation: ```text τ = I α ``` where: ```text τ = torque I = rotational inertia α = angular acceleration ``` A mass farther from the rotation axis contributes more rotational inertia. That is why a long extended robot arm can require large shoulder torque. * * * # 61\. Center of Mass Every rigid body has a center of mass. For dynamics, the link's mass can often be considered concentrated at this effective location for translational calculations. A robotic link therefore has important inertial properties: ```text mass center of mass inertia tensor ``` These are typically specified in robot models such as URDF. * * * # 62\. Inertia Tensor In 3D, rotational inertia cannot generally be represented by one scalar. Instead we use a matrix: ```text I = [Ixx Ixy Ixz Iyx Iyy Iyz Izx Izy Izz] ``` called the inertia tensor. It describes resistance to angular acceleration about different axes. * * * # 63\. Gravity Robot actuators often spend significant effort simply counteracting gravity. Imagine a horizontal arm: ```text base ●──────── link ─────── mass ``` Gravity pulls downward. The shoulder must generate torque. Approximately: ```text τ = r × F ``` The farther mass is from the joint, the larger the torque. That is why robot posture strongly affects actuator load. * * * # 64\. General Robot Dynamics Equation Manipulator dynamics are commonly written: ```text M(q) q̈ + C(q, q̇) q̇ + g(q) + friction = τ ``` Sometimes written simply: ```text M(q)q̈ + C(q,q̇)q̇ + g(q) = τ ``` This is one of the most important equations in classical robotics. * * * # 65\. What the Dynamics Terms Mean ## M(q) ```text mass / inertia matrix ``` describes how difficult it is to accelerate the robot from configuration q. ## C(q,q̇)q̇ contains velocity-dependent effects such as: ```text Coriolis forces centrifugal forces ``` ## g(q) contains: ```text gravity effects ``` ## τ contains: ```text joint torques / generalized forces ``` * * * # 66\. Why M Depends on Configuration Imagine a two-link arm. When folded: ```text mass closer to base ``` When extended: ```text mass farther from base ``` The rotational inertia seen by the base joint changes. Therefore: ```text M = M(q) ``` Robot dynamics are nonlinear partly because geometry changes as the robot moves. * * * # 67\. Coriolis and Centrifugal Effects When multiple rotating joints move simultaneously, motion in one joint affects forces experienced by another. These velocity-dependent effects appear inside: ```text C(q,q̇) q̇ ``` At slow speeds they may be small. At high-speed manipulation they become significant. * * * # 68\. Static Gravity Compensation Suppose: ```text q̇ = 0 q̈ = 0 ``` The robot is holding still. Then the dynamic equation approximately becomes: ```text τ = g(q) ``` The motors must produce torques counteracting gravity. This is gravity compensation. A well-compensated arm can feel nearly weightless to a human moving it manually. * * * # 69\. Lagrangian Mechanics One elegant way to derive robot dynamics is through energy. Define: ```text T = kinetic energy V = potential energy ``` The Lagrangian is: ```text L = T - V ``` For generalized coordinate qi: ```text d/dt (∂L/∂q̇i) - ∂L/∂qi = τi ``` These are the Euler-Lagrange equations. * * * # 70\. Why Lagrangian Mechanics Is Useful Instead of individually tracking every internal force, we describe: ```text energy + generalized coordinates ``` For complicated manipulators, this can make derivation conceptually clean. Workflow: ```text Choose q ↓ Calculate kinetic energy T ↓ Calculate potential energy V ↓ Build L = T - V ↓ Apply Euler-Lagrange ↓ Obtain equations of motion ``` * * * # 71\. Simple Pendulum Example A pendulum can be described by: ```text q = θ ``` Kinetic energy: ```text T = 1/2 m l² θ̇² ``` Potential energy: ```text V = mgl(1 - cosθ) ``` Then: ```text L = T - V ``` Applying the Euler-Lagrange equation gives something equivalent to: ```text ml² θ̈ + mgl sinθ = τ ``` This is already a nonlinear robotic-style dynamic equation. * * * # 72\. Newton-Euler Dynamics Another approach derives robot dynamics from forces and moments directly. Newton: ```text F = ma ``` Euler rotational dynamics: ```text τ = Iα + ... ``` For a robot arm, computations proceed recursively through links. Conceptually: ```text forward pass: calculate velocities and accelerations backward pass: calculate forces and torques ``` This is called the recursive Newton-Euler method. * * * # 73\. Lagrange vs Newton-Euler Both describe the same physical robot. ## Lagrangian approach Focus: ```text energy generalized coordinates ``` Advantages: ```text beautiful analytical formulation good for deriving equations ``` ## Newton-Euler approach Focus: ```text forces moments recursive link calculations ``` Advantages: ```text computational efficiency natural recursive implementation ``` You should understand both conceptually. * * * # 74\. Forward Dynamics Given: ```text q q̇ τ ``` forward dynamics asks: > What acceleration q̈ will result? From: ```text M(q)q̈ + C(q,q̇)q̇ + g(q) = τ ``` solve: ```text q̈ = M(q)⁻¹ [ τ - C(q,q̇)q̇ - g(q) ] ``` A physics simulator repeatedly performs this kind of computation. * * * # 75\. Inverse Dynamics Given: ```text q q̇ q̈_desired ``` inverse dynamics asks: > What torque τ is required? Using: ```text τ = M(q)q̈ + C(q,q̇)q̇ + g(q) ``` This is useful for model-based robot control. * * * # 76\. From Dynamics to Control Suppose a trajectory specifies: ```text q_desired(t) q̇_desired(t) q̈_desired(t) ``` The controller computes actuator commands so the robot follows it. One simple controller might use: ```text position error + velocity error ``` while advanced controllers also compensate robot dynamics. Conceptually: ```text Desired Trajectory ↓ Controller ↓ Torque Command ↓ Robot Dynamics ↓ Actual Motion ↓ Sensors └────→ Controller ``` * * * # 77\. PID as a Robotics Baseline A common controller is PID. Error: ```text e = q_desired - q ``` Command: ```text u = Kp e + Kd ė + Ki ∫e dt ``` In robot joints, often: ```text PD + gravity compensation ``` is already useful: ```text τ = Kp(qd - q) + Kd(q̇d - q̇) + g(q) ``` This makes the controller responsible for tracking errors while g(q) compensates gravity. * * * # 78\. Computed Torque Control Using the dynamics model more explicitly: ```text τ = M(q) v + C(q,q̇)q̇ + g(q) ``` where v is chosen using tracking errors. If the model is accurate, this can approximately cancel nonlinear robot dynamics and make the closed-loop system behave more simply. This illustrates why understanding dynamics helps control. * * * # 79\. Joint Space vs Task Space Control A robot can be controlled in: ```text joint space ``` or: ```text task / Cartesian space ``` Joint-space goal: ```text θ1 = ... θ2 = ... θ3 = ... ``` Task-space goal: ```text gripper at: x = ... y = ... z = ... orientation = ... ``` Task-space control uses the Jacobian to relate Cartesian forces/velocities to joint variables. * * * # 80\. Force and the Jacobian The Jacobian also relates forces. Velocity relation: ```text ẋ = J q̇ ``` Force relation: ```text τ = Jᵀ F ``` where: ```text F = end-effector wrench τ = joint torques ``` A wrench combines: ```text forces + moments ``` This relationship is enormously important for: ```text force control contact manipulation impedance control grasping ``` * * * # 81\. Trajectory Generation A path tells the robot where to go. A trajectory tells it: ```text where + when ``` Path: ```text q(s) ``` Trajectory: ```text q(t) ``` A trajectory includes timing. Therefore it determines: ```text position velocity acceleration ``` and sometimes: ```text jerk ``` * * * # 82\. Why Smooth Trajectories Matter Suppose you command: ```text position: 0 → 1 meter instantly ``` That would imply: ```text infinite velocity ``` which is impossible. Similarly, instantaneous velocity changes imply very large acceleration. Physical robots have limits: ```text joint position limits velocity limits acceleration limits jerk limits torque limits motor current limits ``` Trajectory generators produce physically reasonable commands. * * * # 83\. Polynomial Trajectories A common approach uses polynomials. For example: ```text q(t) = a0 + a1t + a2t² + a3t³ ``` A cubic polynomial has four coefficients. We can specify four boundary conditions such as: ```text q(0) = q0 q(T) = qf q̇(0) = 0 q̇(T) = 0 ``` and solve for: ```text a0 a1 a2 a3 ``` * * * # 84\. Quintic Trajectories A fifth-order polynomial: ```text q(t) = a0 + a1t + a2t² + a3t³ + a4t⁴ + a5t⁵ ``` allows six boundary conditions. Typical conditions: ```text initial position initial velocity initial acceleration final position final velocity final acceleration ``` This gives smoother motion. * * * # 85\. Trapezoidal Velocity Profile Another standard motion profile: ```text velocity _________ / \ / \ _____/ \_____ time ``` Phases: ```text accelerate constant velocity decelerate ``` Position follows an S-like piecewise curve. This is common in industrial motion systems. * * * # 86\. Jerk Jerk is the derivative of acceleration: ```text j = da/dt ``` Large jerk can cause: ```text vibration mechanical stress uncomfortable motion poor payload stability ``` High-performance robots may use jerk-limited trajectories such as S-curve profiles. * * * # 87\. Cartesian Trajectories Sometimes we want the end effector to move along a specific path. Example: ```text gripper should move straight from A to B ``` Interpolating joint angles directly does not necessarily create a straight Cartesian path. Instead we may interpolate: ```text position orientation ``` in Cartesian space and repeatedly solve IK. * * * # 88\. Orientation Interpolation Linearly interpolating quaternion components is generally not ideal. A common method is: ```text SLERP ``` Spherical Linear Interpolation. It smoothly interpolates orientations along the unit quaternion sphere. This matters when planning smooth gripper rotations. * * * # 89\. Path vs Trajectory vs Motion Plan Useful distinction: ## Path ```text geometric route ``` ## Trajectory ```text path + timing ``` ## Motion plan May additionally consider: ```text collisions joint limits velocity limits acceleration limits kinematic constraints dynamic feasibility ``` * * * # 90\. Actuators Everything so far eventually produces a physical command. Actuators create motion. Common robotic actuators include: ```text DC motors brushless DC motors servo motors stepper motors hydraulic actuators pneumatic actuators series elastic actuators linear actuators ``` Electric motors dominate many modern robots. * * * # 91\. Motor Torque For many electric motors, torque is approximately related to current: ```text τ = Kt I ``` where: ```text Kt = torque constant I = motor current ``` This is extremely important. A position command eventually becomes something like: ```text position error → controller → desired torque → desired current → motor driver → motor torque ``` * * * # 92\. Motor Back EMF As a motor spins, it generates voltage opposing the applied voltage. Approximately: ```text V_back = Ke ω ``` where: ```text Ke = back-EMF constant ω = motor speed ``` At high speed, back EMF limits how much current can flow. Therefore motors cannot simultaneously provide arbitrary: ```text speed and torque ``` * * * # 93\. Motor Electrical Dynamics A simplified motor electrical equation is: ```text V = L di/dt + Ri + Keω ``` where: ```text V = applied voltage L = winding inductance R = winding resistance i = current Keω = back EMF ``` The mechanical equation might look like: ```text Jω̇ = Kt i - bω - τ_load ``` Now you can see actuator dynamics joining robot dynamics. * * * # 94\. Gearboxes Robot joints often use gear reduction. Suppose: ```text gear ratio = N ``` Conceptually, gearing can trade: ```text speed for torque ``` A high reduction ratio gives larger output torque but lower output speed. Approximate relationship: ```text τ_output ≈ N τ_motor ``` while: ```text ω_output ≈ ω_motor / N ``` minus efficiency losses. * * * # 95\. Why Gearboxes Matter A small high-speed motor may not directly generate enough joint torque. A gearbox allows: ```text fast motor ↓ gear reduction ↓ slow powerful joint ``` But gearing introduces complications: ```text backlash friction efficiency loss compliance reflected inertia ``` * * * # 96\. Reflected Inertia A gearbox can make the motor's inertia appear larger at the output. Roughly, inertia can scale with the square of gear ratio. That means: ```text high reduction ``` can make a robot joint harder to backdrive. This influences: ```text safety force control human-robot interaction ``` * * * # 97\. Backdrivability A backdrivable actuator can be moved externally relatively easily. Example: ```text human pushes robot arm → joint moves ``` Highly geared actuators may resist external motion strongly. Backdrivability matters for: ```text collaborative robots legged robots force control physical interaction ``` * * * # 98\. Series Elastic Actuators A series elastic actuator intentionally places a spring between motor transmission and output. ```text motor ↓ spring ↓ joint/load ``` By measuring spring deflection, force or torque can be estimated: ```text F = kx ``` or: ```text τ = kθ ``` Benefits include: ```text force sensing shock tolerance safer interaction compliance ``` These appear in many advanced robots. * * * # 99\. Position, Velocity, and Torque Control Actuators may expose different command modes. ## Position control ```text go to angle θ ``` ## Velocity control ```text rotate at ω ``` ## Torque/current control ```text produce torque τ ``` Higher-level robotics controllers may eventually depend on low-level current loops operating much faster. * * * # 100\. Cascaded Control Loops A motor controller may contain nested loops: ```text Position Loop ↓ Velocity Loop ↓ Current/Torque Loop ↓ Motor ``` Typical relative frequencies might be: ```text position: slower velocity: faster current: fastest ``` Each inner loop makes the outer layer easier to control. * * * # 101\. Saturation Real actuators have limits. For example: ```text |τ| ≤ τ_max ``` or: ```text |ω| ≤ ω_max ``` A controller might request: ```text τ = 100 Nm ``` while the actuator can provide: ```text 20 Nm ``` The physical system receives only: ```text 20 Nm ``` This is actuator saturation. Ignoring saturation can make theoretical controllers behave poorly in reality. * * * # 102\. Friction Robot joints experience friction. Simple models include: ## Viscous friction ```text τ_f = b q̇ ``` ## Coulomb friction approximately constant magnitude opposing motion. Real friction includes more complicated phenomena such as: ```text stiction Stribeck effects gear friction seal friction ``` These matter especially for precise low-speed motion. * * * # 103\. Backlash Gear systems may have small mechanical gaps. When direction reverses: ```text motor turns slightly but output does not immediately move ``` This is backlash. It introduces: ```text position error hysteresis control difficulty ``` High-precision robotics tries to minimize or compensate it. * * * # 104\. Compliance Real robots are not perfectly rigid. Compliance can come from: ```text links joints gears belts springs tires soft materials ``` Sometimes compliance is undesirable. Sometimes it is deliberately introduced. For robots interacting with humans or uncertain environments, controlled compliance can make behavior safer and more robust. * * * # 105\. From Command to Motion A useful full-stack mental model is: ```text Desired End-Effector Pose ↓ Inverse Kinematics ↓ Desired Joint State ↓ Trajectory Generator ↓ Desired q, q̇, q̈ ↓ Controller ↓ Desired Torque ↓ Motor Current ↓ Actuator ↓ Joint Motion ↓ Forward Kinematics ↓ Actual End-Effector Pose ``` Sensors close the loop: ```text encoders IMU force sensors vision ``` * * * # 106\. Manipulation Example Suppose a camera detects a cup. Camera estimates: ```text cup pose in camera frame ``` First convert it: ```text T_world_cup = T_world_camera T_camera_cup ``` Now choose desired gripper pose: ```text T_world_gripper_desired ``` Solve IK: ```text q_desired = IK(T_world_gripper_desired) ``` Check: ```text joint limits collision singularity ``` Then generate a trajectory: ```text q(t) ``` Controller follows: ```text q(t) q̇(t) q̈(t) ``` Dynamics determines required torques: ```text τ(t) ``` Actuators execute them. This single task uses almost everything in this chapter. * * * # 107\. Mobile Robot Example Suppose Nav2 gives a desired velocity: ```text linear.x = 0.5 m/s angular.z = 0.3 rad/s ``` For differential drive: ```text v = r/2(ωR + ωL) ω = r/L(ωR - ωL) ``` Solve for wheel speeds: ```text ωR = (v + ωL/2) / r ωL = (v - ωL/2) / r ``` More clearly, using wheelbase width `b`: ```text ωR = (v + ωb/2)/r ωL = (v - ωb/2)/r ``` The wheel controller then converts desired wheel velocity into motor commands. So: ```text /cmd_vel ↓ mobile-base kinematics ↓ wheel velocity targets ↓ motor controllers ↓ robot movement ``` * * * # 108\. Where Odometry Comes From Wheel encoders measure wheel rotation. From: ```text ΔφL ΔφR ``` we estimate wheel travel: ```text ΔsL = r ΔφL ΔsR = r ΔφR ``` Then approximate robot motion: ```text Δs = (ΔsR + ΔsL)/2 Δθ = (ΔsR - ΔsL)/b ``` This updates: ```text x y θ ``` forming wheel odometry. This explains the physical meaning behind ROS: ```text /odom ``` * * * # 109\. Why Odometry Drifts Wheel odometry integrates motion over time. Small errors accumulate. Sources include: ```text wheel slip unequal wheel radii encoder error floor irregularities incorrect wheelbase numerical integration ``` Therefore: ```text odom ``` is locally smooth but globally drifts. Localization systems combine it with: ```text LiDAR camera GPS IMU map information ``` to correct long-term error. * * * # 110\. The Map → Odom → Base Chain A common ROS frame hierarchy is: ```text map ↓ odom ↓ base_link ``` Interpretation: ## odom → base\_link comes from local motion estimation. It should be: ```text smooth continuous ``` but may drift. ## map → odom comes from global localization. It corrects accumulated drift. Therefore: ```text map → base_link ``` provides globally referenced robot pose. This frame architecture directly reflects classical coordinate transformations. * * * # 111\. Kinematic Feasibility A planner cannot simply draw any path through space. It must ask whether the robot can physically follow it. Differential drive: ```text cannot instantaneously move sideways ``` Ackermann: ```text minimum turning radius ``` Manipulator: ```text joint limits workspace limits singularities ``` Omnidirectional base: ```text more freedom but wheel velocity constraints ``` Planning and classical robot kinematics are therefore tightly connected. * * * # 112\. Dynamic Feasibility A kinematically valid trajectory might still be impossible dynamically. Suppose the planner requests: ```text 0 → 5 m/s in 0.01 sec ``` Required acceleration: ```text 500 m/s² ``` which may exceed: ```text motor torque wheel friction mechanical strength ``` Therefore a physically executable trajectory must satisfy both: ```text kinematic constraints + dynamic constraints ``` * * * # 113\. Differential Flatness Some robotic systems have special mathematical structure allowing trajectories to be designed using a smaller set of variables known as flat outputs. You will encounter this in: ```text quadrotors mobile robots trajectory optimization ``` You do not need it as a first principle, but recognize the term when moving toward advanced trajectory generation. * * * # 114\. Constraint Hierarchy in Robotics When planning a robot motion, think through constraints in layers: ```text Geometric: Does it collide? Kinematic: Can its joints/wheels create the motion? Differential: Are velocity constraints satisfied? Dynamic: Can available forces/torques produce it? Actuator: Are motor limits respected? Safety: Is the motion acceptable around humans/environment? ``` This hierarchy is extremely useful when debugging autonomous behavior. * * * # 115\. State A configuration q alone does not always fully describe a moving robot. For a dynamic system, state may include: ```text q q̇ ``` For example: ```text state = [position velocity] ``` Two robots at the same position but moving at different velocities have the same configuration but different dynamic states. * * * # 116\. State-Space Representation A dynamical system may be written: ```text ẋ = f(x, u) ``` where: ```text x = state u = control input ``` For a mobile robot: ```text x = [x, y, θ] u = [v, ω] ``` Then: ```text ẋ = [v cosθ v sinθ ω] ``` This state-space viewpoint becomes fundamental for: ```text control Kalman filters MPC trajectory optimization reinforcement learning ``` * * * # 117\. Holonomic vs Nonholonomic Robots A holonomic robot can independently control all dimensions of its configuration velocity, subject to actuator limits. Example ideal omnidirectional platform: ```text vx vy ω ``` A differential-drive robot cannot. Therefore it is nonholonomic. This distinction matters because: ```text configuration DOF ≠ instantaneously controllable DOF ``` * * * # 118\. Underactuated Robots Some robots have fewer independent actuators than configuration variables. Examples can include: ```text pendulum systems quadrotors under certain formulations legged robots during free flight passive-joint mechanisms ``` These are underactuated systems. They require exploiting dynamics rather than commanding every coordinate independently. * * * # 119\. Fully Actuated Systems A fully actuated manipulator roughly has an independent actuator corresponding to each generalized coordinate. For: ```text q = [θ1 ... θ6] ``` there may be: ```text τ = [τ1 ... τ6] ``` This simplifies control relative to strongly underactuated systems. * * * # 120\. Contact Changes Everything A free robot arm follows: ```text M(q)q̈ + C(q,q̇)q̇ + g(q) = τ ``` But when the robot contacts the environment, additional forces appear: ```text M(q)q̈ + C(q,q̇)q̇ + g(q) = τ + Jᵀ F_contact ``` Contact introduces: ```text constraints friction impact force exchange ``` This becomes central in: ```text grasping legged locomotion pushing assembly manipulation ``` * * * # 121\. Friction Cones A contact cannot provide arbitrary tangential force. Coulomb friction approximately requires: ```text |F_tangent| ≤ μ F_normal ``` In 3D this forms a friction cone. If demanded tangential force exceeds this limit: ```text slip occurs ``` This matters for: ```text robot feet grippers tires pushing tasks ``` * * * # 122\. Static vs Dynamic Models Sometimes detailed dynamics are unnecessary. For slow manipulation: ```text inertia effects small ``` and one may mainly care about: ```text gravity quasi-static forces ``` For high-speed robots: ```text acceleration Coriolis inertia actuator dynamics ``` become essential. Choose model complexity based on the problem. * * * # 123\. Model Fidelity A real robot contains effects such as: ```text flexibility temperature gear deformation electrical delays sensor noise communication latency friction backlash battery voltage variation ``` A model ignores many of them. Therefore: > A robot model is not reality. It is a useful approximation of reality. The art of robotics is choosing a model simple enough to work with but accurate enough to support the task. * * * # 124\. Classical Robotics and Simulation Simulators such as Gazebo conceptually use: ```text robot geometry mass inertia joint constraints actuator inputs contacts gravity friction ``` to numerically integrate the equations of motion. Simulation therefore rests directly on rigid-body dynamics. When your simulated robot behaves strangely, inspect: ```text mass inertia tensor joint axes joint limits collision geometry friction controller gains ``` not only your AI code. * * * # 125\. Classical Robotics and URDF A URDF model describes things such as: ```text links joints joint axes joint limits visual geometry collision geometry mass inertia transforms ``` Example conceptual structure: ```text base_link ↓ joint link_1 ↓ joint link_2 ↓ joint gripper ``` This file is essentially a machine-readable representation of classical robot structure. * * * # 126\. From URDF to Kinematics The joint/link tree lets software compute: ```text forward kinematics TF transformations collision geometry Jacobian ``` Each joint defines how one link moves relative to another. Robot-state software updates transforms based on q. So when you see a TF tree being generated from joint states, you are observing forward kinematics in real time. * * * # 127\. Encoders Joint encoders measure joint position. For revolute joints: ```text θ ``` For wheels they measure: ```text wheel angle ``` Differentiating gives approximate velocity: ```text θ̇ ``` Encoders are the core proprioceptive sensors for most electromechanical robots. * * * # 128\. Absolute vs Incremental Encoders ## Incremental encoder Measures changes in rotation. May require homing after startup. ## Absolute encoder Reports physical position directly. Retains unique position information across power cycles depending on design. This matters for systems where startup configuration must be known reliably. * * * # 129\. Joint Limits Every physical joint has limits. For example: ```text -170° ≤ θ ≤ 170° ``` or: ```text 0 m ≤ d ≤ 0.5 m ``` Also: ```text velocity limits acceleration limits effort limits ``` IK and trajectory generation must respect all of them. A mathematically valid solution violating joint limits is physically invalid. * * * # 130\. Self-Collision A configuration may satisfy all joint limits yet cause: ```text robot link A collides with robot link B ``` Therefore feasible configuration space excludes both: ```text environment collisions + self-collisions ``` * * * # 131\. Workspace Shape The reachable workspace of a manipulator depends on: ```text link lengths joint types joint limits mechanical interference orientation requirements ``` For a two-link planar arm, the workspace resembles an annular region. Outer radius roughly: ```text L1 + L2 ``` Inner unreachable region may exist depending on link geometry. For 6-DOF manipulators, workspace geometry becomes much more complex. * * * # 132\. Reachability vs Dexterity A point may be reachable but only with limited end-effector orientations. For example: ```text gripper can reach point P ``` but cannot point downward there. Therefore we distinguish: ```text reachable workspace ``` from: ```text dexterous workspace ``` where a wider set of orientations is possible. * * * # 133\. Multiple IK Solutions A six-axis robot may reach one end-effector pose using different configurations: ```text shoulder left/right elbow up/down wrist flipped/non-flipped ``` A controller or planner must choose among them based on: ```text current configuration collision joint limits singularity distance motion cost ``` Selecting IK solutions is itself a planning problem. * * * # 134\. Continuity in IK Suppose the desired end-effector pose changes smoothly. A poor IK solver might jump: ```text solution A → solution B ``` even though both reach nearly identical poses. The robot could suddenly move several joints dramatically. Therefore real systems often prefer the IK solution near: ```text current q ``` to maintain continuity. * * * # 135\. Differential IK Loop A common Cartesian controller works like: ```text desired pose ↓ pose error ↓ desired Cartesian velocity ↓ Jacobian pseudoinverse ↓ joint velocity ↓ integrate/update ``` Repeated rapidly: ```text q̇ = J⁺ ẋ_desired ``` This is differential inverse kinematics. * * * # 136\. Pose Error Position error is straightforward: ```text e_p = p_desired - p_current ``` Orientation error is more subtle because rotation does not live in ordinary Euclidean vector space. Robotics software may use: ```text rotation matrices axis-angle quaternion error Lie algebra representations ``` to calculate orientation difference. * * * # 137\. SO(3) and SE(3) Important notation to recognize: ```text SO(3) ``` represents 3D rotations. ```text SE(3) ``` represents 3D rigid-body poses: ```text rotation + translation ``` Transformation matrices belong to SE(3). You will repeatedly encounter: ```text SO(2) SE(2) SO(3) SE(3) ``` in robotics, SLAM, state estimation, and control. * * * # 138\. SE(2) for Mobile Robots Planar robots often live in: ```text SE(2) ``` with configuration: ```text [x, y, θ] ``` This describes: ```text 2D translation + 1D orientation ``` 3D rigid bodies live in: ```text SE(3) ``` with six independent pose variables. * * * # 139\. Why Lie Groups Appear Rigid-body transformations have special structure. Simply adding rotation matrices: ```text R1 + R2 ``` does not generally produce another valid rotation. Likewise, orientations wrap around. Lie-group mathematics gives a clean framework for: ```text composing poses interpolating motion calculating pose errors optimization SLAM state estimation ``` For a classical robotics foundation, recognize the idea even if you postpone the deeper mathematics. * * * # 140\. Twist A rigid body's instantaneous velocity in 3D can be represented as a **twist**: ```text V = [linear velocity angular velocity] ``` typically six components. Example: ```text V = [vx vy vz ωx ωy ωz] ``` The manipulator Jacobian maps: ```text q̇ → end-effector twist ``` This is the proper 3D version of velocity kinematics. * * * # 141\. Wrench The dual concept is a **wrench**: ```text W = [force torque] ``` typically: ```text Fx Fy Fz τx τy τz ``` Then: ```text joint torque = Jᵀ wrench ``` Twists describe motion. Wrenches describe force. * * * # 142\. Virtual Work The relationship: ```text τ = JᵀF ``` can be understood through virtual work. Small joint displacement: ```text δq ``` causes Cartesian displacement: ```text δx = J δq ``` Energy/work consistency requires: ```text τᵀδq = Fᵀδx ``` Substituting: ```text τᵀδq = FᵀJδq ``` therefore: ```text τ = JᵀF ``` This beautifully connects geometry with forces. * * * # 143\. Singularities Revisited Through Force Near singularities, motion and force capabilities become distorted. A robot may be: ```text very weak in one Cartesian direction ``` while mechanically strong in another. The Jacobian determines both: ```text velocity transmission and force transmission ``` This is why singularity awareness matters beyond numerical IK. * * * # 144\. Robot Design and DOF Why do industrial arms often have six joints? Because arbitrary rigid-body pose requires six independent DOF: ```text 3 position + 3 orientation ``` Why do some arms have seven? The seventh creates redundancy. Why do simple pick-and-place robots sometimes have four? Their task may not require arbitrary orientation. Robot morphology reflects task requirements. * * * # 145\. Autonomous Manipulation Architecture A modern autonomous manipulation stack may look like: ```text RGB-D Camera ↓ Object Detection / Segmentation ↓ Pose Estimation ↓ Transform to Robot Frame ↓ Grasp Planning ↓ Desired End-Effector Pose ↓ Inverse Kinematics ↓ Motion Planning ↓ Trajectory Generation ↓ Joint Controller ↓ Robot Arm ``` The AI portions may occupy the first several boxes. The physical execution still depends heavily on classical robotics. * * * # 146\. AI Does Not Replace Geometry Suppose a vision-language model says: ```text "Pick up the red cup." ``` It still needs some mechanism to convert that semantic goal into: ```text cup pose gripper pose collision-free path joint trajectory motor commands ``` A learned end-to-end policy may implicitly approximate those mappings. But the physical relationships still exist. Understanding classical robotics lets you: ```text debug learned policies impose constraints build hybrid systems verify safety interpret failures ``` * * * # 147\. Hybrid Classical + Learned Robotics Modern robots often combine both worlds. Example: ```text Neural network: detect grasp point Classical geometry: transform grasp into robot frame IK: find joint configuration Motion planner: avoid obstacles Trajectory controller: execute motion Force controller: handle contact ``` This hybrid architecture is likely to remain important even as robotics foundation models improve. * * * # 148\. Mobile Robot + AI Example Suppose YOLO detects a person: ```text camera image ↓ person bounding box ``` Depth estimation provides: ```text person position in camera frame ``` TF transforms: ```text camera frame → base_link → map ``` Navigation planner generates a target path. Differential-drive kinematics convert desired: ```text v ω ``` into wheel speeds. Controllers convert wheel speeds into motor commands. Thus: ```text AI perception + classical geometry + kinematics + control = autonomous following robot ``` * * * # 149\. Why Classical Robotics Is Still Foundational Even with powerful learned control policies, engineers need to understand: ```text coordinate-frame mistakes quaternion mistakes singularities incorrect joint axes velocity limits kinematic infeasibility torque saturation contact forces odometry wheel slip trajectory smoothness ``` A neural policy may fail because the model is bad. Or because: ```text camera transform is rotated 90° ``` Those are very different failures. Without classical robotics, debugging becomes guesswork. * * * # 150\. Common Coordinate-Frame Bug Suppose a camera detects: ```text object = [1, 0, 0] ``` You interpret it as: ```text 1 meter forward ``` But the camera convention says: ```text x = right y = down z = forward ``` Then you just commanded the robot toward the wrong direction. Always know: ```text axis convention frame handedness units ``` * * * # 151\. Right-Hand Rule Most robotics systems use right-handed coordinate systems. For rotation: ```text curl fingers around positive axis ``` Your thumb points along the positive axis. Your curled fingers indicate positive rotational direction. Understanding the right-hand rule prevents many sign mistakes. * * * # 152\. Units Matter Classical robotics equations are useless if units are mixed. Common units: ```text distance: meters angle: radians velocity: m/s angular velocity: rad/s force: newtons torque: N·m mass: kg ``` Radians are especially important. Many mathematical functions assume: ```text radians ``` not degrees. * * * # 153\. Radians One full revolution: ```text 2π rad = 360° ``` Therefore: ```text π rad = 180° π/2 rad = 90° ``` Angular velocity: ```text rad/s ``` appears throughout kinematics and actuator models. * * * # 154\. Numerical Integration Given velocity: ```text q̇ ``` we update position approximately: ```text q(t+Δt) ≈ q(t) + q̇ Δt ``` Given acceleration: ```text q̈ ``` we update velocity: ```text q̇(t+Δt) ≈ q̇(t) + q̈ Δt ``` Simulators and controllers continuously perform numerical integration. More advanced integration methods improve accuracy and stability. * * * # 155\. Sampling Time Digital robot controllers operate at discrete intervals. For example: ```text 100 Hz 500 Hz 1 kHz ``` At 1 kHz: ```text Δt = 0.001 sec ``` Controller frequency strongly influences: ```text stability tracking quality force control reaction time ``` Fast inner motor loops may run much faster than high-level planning. * * * # 156\. Multi-Rate Robotics A realistic autonomous robot may have: ```text motor current loop: 10 kHz joint control: 1 kHz state estimation: 100 Hz local planning: 20 Hz vision model: 10 Hz global planning: 1 Hz LLM reasoning: slower/asynchronous ``` Different layers operate at different timescales. This is crucial for AI robotics: > Slow intelligence should not replace fast stabilization loops. * * * # 157\. Classical Control Beneath AI An AI planner might decide: ```text walk to kitchen ``` A learned locomotion model might decide: ```text desired body velocity ``` But beneath that may still run: ```text joint PD controllers motor current controllers state estimators safety loops ``` at hundreds or thousands of Hertz. Autonomous intelligence is hierarchical. * * * # 158\. Model-Based vs Model-Free Classical robotics is heavily model-based. We explicitly write: ```text x = f(q) ẋ = J(q)q̇ M(q)q̈ + C(q,q̇)q̇ + g(q) = τ ``` Model-free methods attempt to learn behavior without explicitly using all of these equations. Modern robotics often combines the two. Examples: ```text learn residual dynamics learn friction model learn perception learn policy use model-based safety constraints use classical low-level control ``` * * * # 159\. Sim-to-Real Simulation uses approximate robot dynamics. Reality differs because of: ```text friction latency flexibility mass uncertainty contact uncertainty sensor noise motor behavior ``` This mismatch is known as: ```text reality gap ``` Understanding classical mechanics helps identify which simulation parameters matter when transferring learned policies to physical robots. * * * # 160\. Parameter Identification Sometimes robot parameters are not accurately known. Unknown quantities might include: ```text mass inertia friction coefficient motor constants center of mass ``` Parameter identification estimates them from experiments. Conceptually: ```text apply known input ↓ measure robot response ↓ fit model parameters ``` This bridges physical systems and data-driven estimation. * * * # 161\. Actuator Bandwidth Actuators cannot change output infinitely fast. Bandwidth describes roughly how quickly the actuator/control loop can respond. A high-level trajectory requesting motion beyond actuator bandwidth will not be followed accurately. Therefore: ```text trajectory frequency content ``` must match physical hardware capability. * * * # 162\. Torque-Speed Curve Motors typically provide different available torque at different speeds. Conceptually: ```text torque ↑ |\ | \ | \ | \ |____\______→ speed ``` High torque is available near low speed. Maximum speed occurs near low torque. Robot planners/controllers must respect this physical envelope. * * * # 163\. Thermal Limits Motor capability is also limited by heat. A motor might produce: ```text high peak torque ``` for a short period but only: ```text lower continuous torque ``` indefinitely. Why? Current generates heat: ```text P_loss ≈ I²R ``` Therefore long-duration robot behavior must respect thermal constraints. * * * # 164\. Battery and Voltage Effects Mobile robots operate from batteries. As battery voltage changes, available motor performance may change. Power: ```text P = VI ``` Mechanical power: ```text P = τω ``` Robot performance therefore connects: ```text electrical power → actuator power → mechanical motion ``` This becomes important in mobile and field robots. * * * # 165\. Mechanical Power For rotational motion: ```text P = τω ``` High torque at high speed requires substantial power. For linear motion: ```text P = Fv ``` This simple relationship helps sanity-check robot requirements. * * * # 166\. Energy Battery-powered robots care not only about instantaneous power but total energy: ```text E = ∫P dt ``` Motion planning may therefore optimize: ```text time energy distance risk ``` depending on application. * * * # 167\. Classical Robotics Mental Stack When analyzing robot motion, think in this order: ```text 1. Frames Where are quantities expressed? 2. Configuration What variables describe the robot? 3. Kinematics How does configuration map to pose? 4. Differential kinematics How do velocities map? 5. Constraints What motions are impossible? 6. Dynamics What forces/torques cause acceleration? 7. Trajectory What motion should happen over time? 8. Control How do we track that trajectory? 9. Actuators Can the hardware actually produce it? ``` If something fails, work downward through the stack. * * * # 168\. Debugging Manipulator Motion Suppose a gripper moves incorrectly. Check: ```text 1. Is target expressed in correct frame? 2. Are transforms correct? 3. Is quaternion normalized/correct? 4. Is FK correct? 5. Is IK solving intended pose? 6. Did solver choose strange IK branch? 7. Is robot near singularity? 8. Are joint limits respected? 9. Is trajectory smooth? 10. Is controller tracking? 11. Are actuators saturated? ``` This approach separates geometry problems from dynamics/control problems. * * * # 169\. Debugging Mobile Robot Motion Suppose a differential-drive robot curves while commanded straight. Possible causes: ```text left/right wheel radii differ wheel speed calibration differs wheel slip encoder scaling error incorrect wheel separation motor controller mismatch ``` Classical kinematics lets you reason about the failure instead of treating it as arbitrary behavior. * * * # 170\. What You Should Be Able to Derive For strong working knowledge, you should eventually be comfortable deriving: ```text 2D rotation matrix homogeneous transformation composition 2-link forward kinematics 2-link Jacobian differential-drive equations bicycle-model equations basic Euler-Lagrange equation basic motor model ``` You do not need to memorize every final equation. You should understand where they come from. * * * # 171\. What You Should Recognize Immediately When you see: ```text T_A_B ``` think: ```text coordinate transformation ``` When you see: ```text q ``` think: ```text configuration / generalized coordinates ``` When you see: ```text x = f(q) ``` think: ```text forward kinematics ``` When you see: ```text ẋ = Jq̇ ``` think: ```text velocity kinematics ``` When you see: ```text rank(J) drops ``` think: ```text singularity ``` When you see: ```text M(q)q̈ + C(q,q̇)q̇ + g(q) = τ ``` think: ```text robot dynamics ``` When you see: ```text τ = JᵀF ``` think: ```text Cartesian force → joint torque ``` * * * # 172\. Complete Manipulator Equation Chain For a robot arm: ```text Joint Configuration q ↓ Forward Kinematics x = f(q) ↓ Differentiate ẋ = J(q)q̇ ↓ Differentiate again / model dynamics M(q)q̈ + C(q,q̇)q̇ + g(q) = τ ↓ Actuator Model τ ≈ Kt I ↓ Motor Current I ``` Going backward: ```text Desired Pose x_d ↓ Inverse Kinematics q_d ↓ Trajectory Generation q_d(t), q̇_d(t), q̈_d(t) ↓ Inverse Dynamics / Controller τ_d ↓ Motor Current I_d ``` That is classical manipulator robotics in one chain. * * * # 173\. Complete Mobile Robot Equation Chain For differential drive: ```text Desired path ↓ Local planner ↓ desired: v, ω ↓ Differential-drive kinematics ↓ ω_left, ω_right ↓ Wheel controllers ↓ motor torque/current ↓ wheel rotation ↓ robot motion ↓ encoders ↓ odometry ↓ pose estimate ``` Again: ```text planning → kinematics → actuation → sensing → feedback ``` * * * # 174\. Classical Robotics Topic Map Use this map when revisiting the subject later. ```text CLASSICAL ROBOTICS │ ├── GEOMETRY │ ├── coordinate frames │ ├── rotation matrices │ ├── Euler angles │ ├── quaternions │ ├── homogeneous transforms │ ├── SO(3) │ └── SE(3) │ ├── CONFIGURATION │ ├── degrees of freedom │ ├── generalized coordinates │ ├── joint space │ ├── configuration space │ ├── workspace │ └── constraints │ ├── MANIPULATOR KINEMATICS │ ├── forward kinematics │ ├── DH parameters │ ├── inverse kinematics │ ├── Jacobians │ ├── differential kinematics │ ├── pseudoinverse │ ├── redundancy │ ├── null space │ └── singularities │ ├── MOBILE ROBOT KINEMATICS │ ├── differential drive │ ├── nonholonomic constraints │ ├── Ackermann steering │ ├── bicycle model │ ├── omnidirectional motion │ └── odometry │ ├── DYNAMICS │ ├── rigid bodies │ ├── mass │ ├── inertia │ ├── center of mass │ ├── forces │ ├── torques │ ├── gravity │ ├── Coriolis effects │ ├── Lagrangian mechanics │ ├── Newton-Euler dynamics │ ├── forward dynamics │ └── inverse dynamics │ ├── TRAJECTORIES │ ├── paths │ ├── time parameterization │ ├── cubic trajectories │ ├── quintic trajectories │ ├── trapezoidal profiles │ ├── S-curves │ ├── Cartesian interpolation │ └── orientation interpolation │ ├── ACTUATION │ ├── motors │ ├── torque constants │ ├── back EMF │ ├── motor dynamics │ ├── gearboxes │ ├── friction │ ├── backlash │ ├── compliance │ ├── series elastic actuators │ └── saturation │ └── CONTROL CONNECTION ├── position control ├── velocity control ├── torque control ├── PID ├── gravity compensation ├── computed torque ├── Cartesian control └── force control ``` * * * # 175\. What a Robotics Software Engineer Should Actually Master You do not need to memorize every derivation. But you should become comfortable enough that the following statements feel natural: ```text Every pose is relative to a frame. Transforms compose coordinate relationships. A robot's configuration is represented by generalized coordinates q. DOF tells you how many independent configuration variables exist. Forward kinematics maps joints to end-effector pose. Inverse kinematics maps desired pose back to possible joints. The Jacobian maps joint velocity to task-space velocity. The Jacobian transpose maps task-space forces to joint torques. Singularities occur when the Jacobian loses rank. Redundant robots have extra joint freedom. Differential-drive robots cannot move sideways instantaneously. Ackermann vehicles have curvature and steering constraints. Omnidirectional robots can control more planar velocity directions. Kinematics describes motion without forces. Dynamics explains motion using forces and torques. Robot dynamics have the structure: M(q)q̈ + C(q,q̇)q̇ + g(q) = τ. Lagrangian mechanics derives dynamics through energy. Newton-Euler derives them through forces and moments. Trajectories add timing to geometric paths. Actuators have finite torque, speed, bandwidth, and power. Motor torque is closely related to motor current. The controller cannot command physics to violate hardware limits. ``` If those are deeply understood, you possess a strong classical robotics foundation. * * * # 176\. The Most Important Conceptual Separation One of the best habits you can develop is distinguishing: ```text perception problem geometry problem kinematics problem planning problem dynamics problem control problem actuator problem ``` Suppose an autonomous robot misses an object. Possible reasons: ```text AI detected wrong location ``` or: ```text camera transform wrong ``` or: ```text IK found bad solution ``` or: ```text trajectory collided ``` or: ```text joint controller lagged ``` or: ```text motor saturated ``` All produce a similar visible failure. But they belong to completely different layers. Robotics engineering is largely about identifying **which layer violated its assumptions**. * * * # 177\. The Deeper Mathematical Chain At an abstract level: ```text Geometry ↓ Configuration manifold ↓ Kinematic mapping x = f(q) ↓ Differential mapping ẋ = J(q)q̇ ↓ Dynamics M(q)q̈ + C(q,q̇)q̇ + g(q) = τ ↓ Control τ = π(state, target) ↓ Actuation current → torque ↓ Physical motion ``` AI can enter this stack at many locations. It can learn: ```text f(q) dynamics control policy grasp selection trajectory state representation ``` But the physical relationships remain underneath. * * * # 178\. Classical Robotics for Future AI Robots Future autonomous robots may contain extremely powerful AI systems. A humanoid could receive: ```text "Clean the kitchen." ``` The AI may reason about: ```text what objects exist what actions are required what sequence should be performed ``` But executing: ```text reach grasp walk push turn place balance ``` still occurs in physical space. The robot must respect: ```text geometry joint limits contact friction gravity torque limits actuator bandwidth stability ``` Language models do not repeal Newtonian mechanics. * * * # 179\. AI + Classical Robotics Architecture A powerful future architecture may look like: ```text Language / Vision Foundation Model ↓ Semantic Task Plan ↓ Skill Selection ↓ Learned / Classical Motion Planner ↓ Desired Trajectory ↓ Model-Based / Learned Controller ↓ Joint Commands ↓ Low-Level Motor Control ↓ Physical Robot ``` With feedback: ```text camera LiDAR IMU encoders force sensors tactile sensors ``` feeding back at different layers. The intelligence may be modern. The physical substrate remains classical. * * * # 180\. Final Mental Model When looking at any robot, imagine four representations simultaneously. ### 1\. Physical robot ```text motors links wheels mass friction gravity ``` ### 2\. Configuration ```text q ``` the coordinates describing the robot. ### 3\. Task space ```text x ``` what you care about physically: ```text gripper pose robot position tool velocity ``` ### 4\. Forces and commands ```text τ F motor current ``` The major classical relationships are: ```text x = f(q) ẋ = J(q) q̇ τ = JᵀF M(q)q̈ + C(q,q̇)q̇ + g(q) = τ ``` These four equations contain an enormous portion of manipulator robotics. For mobile robots, add: ```text ẋ = v cosθ ẏ = v sinθ θ̇ = ω ``` and the wheel/steering constraints defining how `v` and `ω` can be generated. * * * # 181\. The Five Questions to Carry With You Whenever you study or build a robot, ask: > **Relative to which coordinate frame?** > **What variables completely describe the robot configuration?** > **What kinematic constraints limit possible motion?** > **What forces and torques are required to create that motion?** > **Can the real actuators actually produce those forces, speeds, and accelerations?** Those five questions connect mathematical robotics to physical robotics. * * * # 182\. Final Perspective Classical robotics can initially look like a disconnected collection of: ```text matrix multiplication trigonometry Jacobians differential equations mechanics motor equations ``` But they are all solving one continuous problem: > **How do we represent, predict, and control the motion of a physical machine?** Coordinate frames tell you: ```text where things are. ``` Transformations tell you: ```text how different descriptions of space relate. ``` Configuration space tells you: ```text what states the robot can occupy. ``` Forward kinematics tells you: ```text where the robot goes when joints move. ``` Inverse kinematics tells you: ```text which joints are needed to reach a goal. ``` Jacobians tell you: ```text how local velocities and forces transform. ``` Singularities tell you: ```text where motion capability degenerates. ``` Mobile robot kinematics tells you: ```text which planar motions wheels can physically create. ``` Dynamics tells you: ```text what forces and torques create acceleration. ``` Trajectory generation tells you: ```text how motion should unfold through time. ``` Actuator dynamics tells you: ```text whether the physical hardware can execute the command. ``` Once these pieces connect, a robot stops looking like a mysterious intelligent machine. You begin to see: ```text frames transform chains states constraints kinematic maps Jacobians forces torques trajectories feedback loops actuators ``` And that is the classical foundation underneath modern autonomous robotics.