Live simulation

IQCR: Inspection and Quality Control Robots

Can a six-axis inspection robot actually reach where it needs to?

IQCR proposes putting a camera, depth sensor, and laser probe on one robot arm instead of running parts between separate inspection stations. Before any of that sensor fusion gets built, the arm has to physically reach the poses the idea requires. This page runs the same ABB IRB 120 kinematics and the same inverse-kinematics solver as the paper, live in your browser, in 3D.

01. The arm, live

ABB IRB 120, built from its actual Denavit–Hartenberg parameters

Every link length, twist, and joint limit below is pulled straight from iqcr_kinematics.m, not a generic robot model. Drag to orbit, scroll to zoom.

auto-demo · drag or click to take over

Manipulability (beyond the paper): how far the current pose is from a kinematic singularity, computed live from the same numerical Jacobian the IK solver uses (Craig ch. 8), shown relative to the home pose above. It drops toward 0x near singular configurations, where the arm loses a degree of freedom; many poses are more manipulable than home, so values above 1x are expected, not an error.

02. Does the solver actually work?

Convergence, live vs. the paper's MATLAB run

The paper ran this exact damped-least-squares solver protocol (λ = 10⁻³, numerical Jacobian, tolerance 10⁻⁹) on seeded random poses. The revised camera-ready converges on all 8 feasible reference poses in 21–37 iterations, and its failure study shows what a stuck solve at the 1500-iteration cap actually means: every reproducible failure traced to a target with no joint-limit-feasible solution, certified by a closed-form solver. Generate and solve a few targets above; each run lands in the chart and table below.

The MATLAB Robotics-Toolbox cross-check below (rst_verification.m) already used random restarts (AllowRandomRestart) and still hit the same stuck pose, evidence that particular target sits somewhere the arm genuinely struggles to reach cleanly, not just a tuning artifact. This live solver didn't have that safety net; it now does. When an attempt stalls it jumps to a fresh random joint configuration and retries, up to 5 times, keeping the closest result. Across 30,000 randomized offline trials spanning the full starting-guess-error slider range (±7.5° to ±45°), that took the stall rate from as high as ~0.5% down to 0%, with zero previously-successful cases made worse. A result badge below will say how many restarts a run needed.

Position error vs. iteration (your browser)

Semilog. Each solved run overlays a new curve.

Your solved poses

Same columns as the paper's Table (case, position error, orientation error, iterations, converged).

CasePos err (mm)Ori err (°)ItersOK?
Paper's reference results The hand-coded MATLAB run, plus the revised paper's Robotics System Toolbox verification, compared against your live runs above.

The paper's actual MATLAB run

Hand-coded numerical IK (iqcr_kinematics.m): 8 fixed test poses, seeded RNG.

CasePos err (mm)ItersOK?

Cross-checked with a MATLAB add-in

The revised paper's Table IV: 8 feasible poses (seed rng(7), MATLAB R2026a), solved by MATLAB's Robotics System Toolbox using ABB's own loadrobot('abbIrb120') model and its built-in inverseKinematics solver (rst_verification_v2.m), so the hand-coded solver isn't grading its own homework.

CasePos err (mm)ItersOK?

All 8 converge under the corrected sampling in the revised paper; the original submission's stuck case was root-caused there to a joint-limit-infeasible target, not a solver defect. Cross-solver agreement is the actual evidence the hand-coded solver is implemented correctly, not just self-consistent.

03. Where can it even reach?

Reachable workspace envelope

With the base joint locked at 0°, sweeping the shoulder and elbow across their full range traces the region the hand can physically enter. Computed live over a 60×60 grid, same as the paper's fig_workspace.png.

Envelope in the X–Z plane (base joint = 0°)