uploads.json

{
  "d5177146-dcab-4240-8995-012c30f7111b": " Alexandria University Faculty of Engineering Communication and Electronics Department    ROBOTICS  Laboratory Report  Lab 3    Kinematics and Jacobian Matrix Analysis of a 2-DOF Robotic Arm in MATLAB/Simulink      1.  Introduction Robot kinematics is the mathematical discipline that relates the geometric structure of a manipulator to its motion in three-dimensional space, entirely independently of the forces that produce such motion. For any robotic system, two complementary problems must be solved: forward kinematics, which determines the end-effector pose given a set of joint variables, and inverse kinematics, which determines the joint variables required to achieve a prescribed end-effector pose. Bridging these two mappings in the velocity domain is the Jacobian matrix, a fundamental quantity in robot control that linearly relates joint-space velocities to task-space velocities. This laboratory investigation employs a two-degrees-of-freedom (2-DOF) planar robotic arm modelled within the MATLAB Robotics System Toolbox and simulated in Simulink. The arm executes a multi-segment Cartesian path defined by six waypoints, following a trapezoidal velocity profile. The simulation integrates an inverse kinematics solver to compute joint configurations online, a Simscape Multibody mechanical model to replicate physical joint dynamics, a forward kinematics block to verify end-effector position, and a Jacobian computation block whose output is used to map joint-space velocity into Cartesian space. The primary objectives of this experiment are: (i) to implement and validate a closed-loop kinematic chain in Simulink, (ii) to examine the role of the Jacobian matrix in relating joint and task-space velocities, and (iii) to interpret simulation results in terms of end-effector trajectory tracking accuracy and joint configuration profiles. 2.  Theoretical Background 2.1  Forward and Inverse Kinematics Forward kinematics (FK) maps a set of joint angles q = (θ₁, θ₂) to the end-effector pose in Cartesian space via a chain of homogeneous transformation matrices: T₀ₙ = T₀¹ · T¹² · ⋯ · Tⁿ⁻¹ⁿ For the planar 2-DOF arm this reduces to: x = L₁cosθ₁ + L₂cos(θ₁+θ₂) and y = L₁sinθ₁ + L₂sin(θ₁+θ₂). Inverse kinematics (IK) solves the reverse: given a desired pose xᵈ, find q such that f(q) = xᵈ. MATLAB’s inverseKinematics solver uses a damped least-squares iterative method, minimising: min  ‖ f(q) − xᵈ ‖²  +  λ² ‖ q − q₀ ‖² where λ is a damping coefficient and q₀ is the initial guess. Convergence is controlled by four tolerance thresholds — gradient, solution, step, and error-change — each set to 1×10⁻¹⁰ in the present model, with a maximum of 1,500 iterations permitted per timestep. 2.2  The Jacobian Matrix The Jacobian J(q) ∈ ℝᵏˣⁿ linearly relates joint-space velocities to end-effector Cartesian velocities: ẋ_EE = J(q) · q̇ where q̇ is the joint velocity vector. For revolute joints, each column of the geometric Jacobian is Jᵥᵢ = zᵢ₋₁ × (pₙ − pᵢ₋₁). In this experiment, the MatrixMultiply block evaluates this product using Simscape-measured joint velocities, providing a real-time verification of the kinematic chain. Configurations where det(J) ≈ 0 are singular and must be avoided, as they cause unbounded joint velocities for finite Cartesian motion. 3.  Experimental Setup 3.1  Robot Model The 2-DOF robotic arm was imported into MATLAB using importrobot('lab_1'), which loads a rigid body tree object DOF2_Arm along with the associated ArmInfo structure. The arm comprises two revolute joints (J1 and J2) and three rigid bodies (Base, Link1, Link2), with the end-effector defined at Body3. The Simscape Multibody model provides physical simulation of joint dynamics, including position and velocity measurements that are fed back into the Simulink diagram.   Figure 1. Mechanics Explorer view of the 2-DOF arm at simulation time t ≈ 5.92 s. The workspace variables confirm successful loading of DOF2_Arm (rigidBodyTree), ArmInfo, and the waypoint matrix wp. 3.2  Waypoints and Trajectory The desired end-effector path is defined by six Cartesian waypoints specified in the lab_1_load.m initialisation script: wp = [0.35, 0, 0.1;\n      0.25, 0.01, 0.1;\n      0.25, 0.11, 0.1;\n      0.15, 0.11, 0.1;\n      0.15, 0.01, 0.1;\n      0.25, 0.01, 0.1]' These waypoints, expressed in metres in the base frame (x, y, z), trace a rectangular profile in the horizontal plane at a constant height of z = 0.1 m. Interpolation between waypoints is handled by the Trapezoidal Velocity Profile Trajectory block, which generates smooth position, velocity, and acceleration profiles (q, q̇, q̈) over a 10-second simulation horizon.  Table 1. End-effector Cartesian waypoints defining the desired trajectory. 3.3  Simulink Block Diagram The Simulink model, shown in Figure 2, implements the following signal flow: a Clock block provides the simulation time signal to the Trapezoidal Velocity Profile Trajectory block, which outputs the instantaneous desired position q, velocity q̇, and acceleration q̈. The position signal enters the Inverse Kinematics subsystem to compute joint angles (θ₁, θ₂), which are then fed to both the Robot (Simscape) subsystem and the Forward Kinematics block. Measured joint positions and velocities from the Simscape model are routed to the Get Jacobian block and the MatrixMultiply block to compute the Cartesian velocity.   Figure 2. Simulink top-level block diagram showing the kinematic chain: trajectory generator → inverse kinematics → Simscape robot → forward kinematics → Jacobian velocity mapping. 3.4  Inverse Kinematics Subsystem Inside the Inverse Kinematics subsystem (Figure 3), the trajectory position vector is first converted from a translation vector to a homogeneous transformation matrix using the Coordinate Transformation Conversion block (translation vector → rigid body transform). This transformation is passed to the Inverse Kinematics block, which references DOF2_Arm and targets Body3 as the end-effector. An initial guess of [0, 0] is provided, with a weight vector of [1 × 6] applied uniformly to all pose components.   Figure 3. Internal structure of the Inverse Kinematics subsystem, illustrating the coordinate transformation and IK solver configuration. 4.  Simulation Results and Analysis 4.1  Scope Output — Position and Velocity Signals Figure 4 presents the four-panel scope output recorded at the end of the 10-second simulation. The upper-left panel displays the FK-computed end-effector Cartesian positions (x, y, z) against time, confirming that the arm successfully traverses all six waypoints. The z-coordinate remains constant at 0.1 m throughout, consistent with the planar nature of the task. The x and y coordinates exhibit smooth trapezoidal transitions between waypoints with no discontinuities, validating the trajectory generator and IK solver.   Figure 4. Scope output over the full 10-second simulation. Upper-left: FK end-effector positions (x, y, z). Upper-right: desired Cartesian velocity components from trajectory generator. Lower panels: Jacobian-mapped velocity signals showing the effect of IK convergence behaviour in the second half of the trajectory. 4.2  Effect of IK Solver Tolerances The IK solver was configured with uniformly tight tolerances: GradientTolerance, SolutionTolerance, StepTolerance, and ErrorChangeTolerance all set to 1×10⁻¹⁰ — an order of magnitude tighter than typical defaults. This single configuration choice has three observable consequences on the simulation. Effect on simulation time.  Tight tolerances force the damped least-squares solver to iterate until the residual pose error falls below near-machine-precision thresholds at every timestep. With up to 1,500 iterations permitted and 10,000 steps in the 10-second run, the total solver workload is substantial. This is the principal reason the simulation ran significantly slower than a colleague’s instance using looser tolerances (1×10⁻⁶): fewer iterations per step translate directly into lower wall-clock time with no meaningful loss in trajectory accuracy for this workspace. Effect on the upper-right scope graph (desired Cartesian velocity).  Precise IK convergence at each step means the velocity command fed to the Simscape model carries no residual positional error. Consequently, the upper-right panel shows clean, sharp trapezoidal velocity transitions with no inter-step correction artefacts. Relaxing tolerances to 1×10⁻⁴ would allow small residual errors to propagate forward, introducing a low-amplitude ripple at the ramp transitions of the velocity profile, as the solver corrects accumulated offsets over successive steps. Effect on robot motion smoothness.  High-precision IK solutions ensure that joint-angle commands delivered to the Simscape model are geometrically accurate at every step, so the arm traces the rectangular Cartesian path without visible positional drift or corner undershoot. Loosening tolerances to 1×10⁻³ or coarser would cause the arm to miss waypoint corners by a few millimetres — acceptable for coarse path following but problematic in precision tasks. The appropriate tolerance is therefore task-dependent and should be chosen deliberately rather than defaulted to the tightest possible value. 4.3  Trajectory Tracking Assessment The upper-left scope panel (desired vs. achieved position) confirms close agreement between the commanded trajectory and the FK-verified end-effector position throughout the first five seconds of motion. The smooth, wave-like profiles of the x and y signals are characteristic of the trapezoidal velocity profile: constant-velocity segments are flanked by smooth acceleration and deceleration ramps, minimising jerk. The upper-right panel shows the desired Cartesian velocity (ẋ_x, ẋ_y), which exhibits the expected trapezoidal shape: ramp-up, constant plateau, and ramp-down at each waypoint transition. Peak velocities of approximately ±0.15 m/s are observed, consistent with the waypoint spacings and the 10-second total duration. 4.4  Jacobian-Mapped Velocity Analysis The lower-right scope panel displays the Cartesian velocity reconstructed via the Jacobian matrix product J(q) · q̇. During approximately 0–5 seconds, the Jacobian velocity closely tracks the desired velocity, confirming kinematic consistency. After t ≈ 5 s, noticeable high-frequency oscillations appear in the Jacobian-velocity signal. This behaviour arises from numerical noise in the joint velocity measurements q̇ produced by the Simscape PS-Simulink converters when the arm’s motion slows near waypoints, where the signal-to-noise ratio in the velocity channel decreases. A secondary contributing factor is the variable-step solver (VariableStepAuto) used in this simulation, which adjusts its step size based on local error estimates. Near trajectory inflection points, where higher derivatives are non-negligible, the solver takes smaller steps, amplifying the apparent noise in differentiated quantities such as joint velocity. Employing a fixed-step solver at the control sample time T_s = 0.001 s would mitigate this effect. 4.5  Simulation Performance Observations Examination of the model configuration revealed that three critical blocks — Trapezoidal Velocity Profile Trajectory, Inverse Kinematics, and Get Jacobian — were set to Interpreted execution rather than Code generation. Interpreted execution re-evaluates the block’s underlying MATLAB code at every simulation timestep, incurring a substantial per-step overhead. Switching these blocks to Code generation is expected to reduce simulation time by an order of magnitude, as was observed when comparing execution times between student instances.   Figure 5. Full four-panel scope view at T = 10 s. The lower-right panel highlights the increasing Jacobian velocity noise after t ≈ 5 s, attributable to the variable-step solver and interpreted block execution. 5.  Discussion 5.1  Accuracy of Forward and Inverse Kinematics The FK results confirm that the Simulink model correctly maps joint angles to Cartesian end-effector positions for all waypoints in the trajectory. The agreement between the trajectory generator output and the FK-verified position — visible in the overlapping scope traces — demonstrates that the IK solver converges reliably within the 1,500-iteration budget and that the Simscape model accurately enforces the joint-angle commands. The IK solver convergence is sensitive to the initial guess and the solver tolerances. In this experiment, a zero initial guess q₀ = [0, 0] was used throughout. While adequate for the small workspace covered by the six waypoints, a warm-start strategy — in which the previous solution is used as the initial guess for the next timestep — would improve convergence speed and robustness, particularly near singular configurations. 5.2  Role and Limitations of the Jacobian The Jacobian matrix serves as the local linearisation of the FK map and is central to velocity-level robot control. Its utility was demonstrated in this experiment by the MatrixMultiply block, which reconstructed Cartesian velocity from measured joint velocities. The close agreement observed in the first half of the trajectory confirms that the Jacobian is correctly computed and that the Simscape model’s joint velocity outputs are accurate. The degradation in Jacobian-velocity accuracy observed after t ≈ 5 s illustrates a practical limitation: the Jacobian is a first-order approximation that amplifies measurement noise in q̇. In real robotic systems, this is addressed through joint velocity filtering (e.g., a first-order low-pass filter with an appropriate cut-off frequency) or by computing velocity analytically from the trajectory generator rather than differentiating noisy encoder signals. 5.3  Singularity Considerations For the 2-DOF arm, a kinematic singularity occurs when θ₂ = 0 (fully extended configuration) or θ₂ = ±π (fully folded). At these configurations, det(J) = 0, and the damped least-squares IK solver introduces artificial damping to prevent infinite joint velocities, at the cost of a small position error. The rectangular trajectory defined by the six waypoints avoids the immediate vicinity of these singular configurations, as all target poses lie well within the interior of the arm’s reachable workspace. 6.  Conclusion This laboratory demonstrated the full kinematic pipeline of a 2-DOF robotic arm in MATLAB/Simulink, encompassing trajectory generation, inverse kinematics, Simscape-based physical simulation, forward kinematics verification, and Jacobian-based velocity mapping. The key findings are summarised as follows: The IK solver successfully computed joint angles for all six waypoints, enabling the end-effector to follow the prescribed rectangular Cartesian path without loss of track. Forward kinematics results agreed with the desired trajectory, validating the consistency of the Simscape physical model and the Robotics System Toolbox FK implementation. The Jacobian matrix faithfully mapped joint-space velocities to Cartesian velocities during the first half of the trajectory, with increasing noise in the second half attributable to variable-step solver behaviour and interpreted block execution overhead. Simulation performance was significantly degraded by the use of Interpreted execution mode in three RST blocks; switching to Code generation is strongly recommended for future work. The damped least-squares IK solver with a zero initial guess proved sufficient for this workspace, though a warm-start strategy would improve robustness at higher speeds or in proximity to singular configurations.  Overall, the experiment provided a comprehensive hands-on understanding of the interplay between forward kinematics, inverse kinematics, and the Jacobian matrix in practical robotic motion, and highlighted the importance of numerical solver choices and simulation configuration on both accuracy and computational efficiency. References [1]  B. Siciliano, L. Sciavicco, L. Villani, and G. Oriolo, Robotics: Modelling, Planning and Control, Springer, London, 2009. [2]  MathWorks, “Robotics System Toolbox User’s Guide,” The MathWorks, Inc., Natick, MA, 2024. [Online]. Available: https://www.mathworks.com/help/robotics/ [3]  MathWorks, “Simscape Multibody User’s Guide,” The MathWorks, Inc., Natick, MA, 2024. [4]  R. Murray, Z. Li, and S. Sastry, A Mathematical Introduction to Robotic Manipulation, CRC Press, Boca Raton, FL, 1994.",
  "152b4ea7-5515-4eea-b93d-e675e3f32247": "بحث حول العلاقة بين المساءلة والشفافية وحالات التحيز في الذكاء الاصطناعي جامعة الإمام محمد بن سعود الإسلامية\nكلية علوم الحاسب والمعلومات\nمقرر: التفاعل بين الإنسان والذكاء الاصطناعي أولاً: العلاقة بين المساءلة والشفافية تعتبر الشفافية (Transparency) والمساءلة (Accountability) وجهين لعملة واحدة في أخلاقيات الذكاء الاصطناعي. الشفافية تعني القدرة على فهم النظام وتفسير أسباب اتخاذه لقرار معين، بينما المساءلة هي القدرة على تحديد الطرف المسؤول عن تلك القرارات ونتائجها ي أنظمة الذكاء الاصطناعي، لا يمكن فصل المساءلة عن الشفافية للأسباب التالية: القدرة على التفسير (Explainability): الشفافية تضمن أن النظام ليس \"صندوقاً أسود\". عندما نفهم كيف اتخذ النظام قراره، يمكننا تحديد ما إذا كان الخطأ ناتجاً عن البيانات، أو الخوارزمية، أو سوء الاستخدام البشري. تحديد المسؤولية: تنص مبادئ \"سدايا\" على أن الإنسان يجب أن يظل مسؤولاً. الشفافية هي الأداة التي تمكن الإنسان من مراقبة مخرجات النظام والتدخل عند الضرورة، مما يحقق مبدأ المساءلة. بناء الثقة: الشفافية في عرض حدود النظام ومخاطره (كما ورد في ص 15 من الدرس الرابع) هي ما يسمح للمستخدمين والمجتمع بمساءلة الجهات المطورة. \n\nوفقاً لمحتوى الدرس، يمثل غياب الشفافية تحدياً جوهرياً للمساءلة؛ فالأشخاص الذين يطورون أو يستخدمون الأنظمة قد يعجزون عن شرح قرار محدد، مما يضعف قدرتهم على تحمل المسؤولية. لذا، الشفافية هي المتطلب السابق والضروري لتحقيق مساءلة حقيقية وعادلة. ثانياً: حالات تحيز الذكاء الاصطناعي ومخالفتها لمبدأ عدم التمييز الحالة الأولى: تحيز خوارزميات التوظيف (Amazon Recruiter Case) الوصف: استخدمت شركة أمازون أداة ذكاء اصطناعي للمساعدة في التوظيف، لكنها أظهرت تحيزاً ضد النساء لأن البيانات التاريخية التي تدربت عليها كانت من سير ذاتية يسيطر عليها الرجال.\nمخالفة المبدأ: خالفت هذه الحالة مبدأ \"عدم التسبب في ضرر تمييزي\" من خلال استبعاد كفاءات بناءً على الجنس، مما أدى لعدم تكافؤ الفرص.\nالمصدر:  https://www.reuters.com/article/us-amazon-com-jobs-automation-insight-idUSKCN1MK08G الحالة الثانية: تحيز الرعاية الصحية (Optum Health Algorithm) الوصف: خوارزمية تستخدم للتنبؤ بالمرضى الذين يحتاجون رعاية إضافية أعطت أولوية للمرضى البيض على السود، لأنها اعتمدت على تكلفة الرعاية السابقة كمعيار للحاجة، وحيث أن السود تاريخياً ينفقون أقل على الرعاية، استنتج النظام أنهم أقل حاجة.\nمخالفة المبدأ: تمييز عرقي غير مباشر ناتج عن بيانات تعكس عدم مساواة اجتماعية سابقة.\nالمصدر:  https://www.science.org/doi/10.1126/science.aax2342  الحالة الثالثة: تحيز التعرف على الوجوه (Face Recognition Bias) الوصف: أظهرت دراسات أن أنظمة التعرف على الوجوه لديها معدلات خطأ أعلى بكثير عند تحليل وجوه النساء والملونين مقارنة بالرجال البيض.\nمخالفة المبدأ: تسبب ضرر تمييزي في سياقات أمنية وقانونية، مما قد يؤدي لاتهامات خاطئة لفئات معينة.\nالمصدر: https://mitsloan.mit.edu/ideas-made-to-matter/unmasking-bias-facial-recognition-algorithms  الخلاصة إن تحقيق الشفافية ليس مجرد مطلب تقني، بل هو ضرورة أخلاقية لضمان عدم تسبب الأنظمة في أضرار تمييزية ولتمكين الإنسان من تفسير وتحمل مسؤولية المخرجات الآلية."
}