← Back to projects

Automated Dimensional Inspection System

A vision-guided measurement system for industrial quality assurance

2024robotics, computer-vision, embedded-systems, mechanical-design

View on GitHub


The Problem

In manufacturing environments, dimensional inspection is a critical quality assurance step. Traditional methods require human operators to manually measure parts with calipers—a process that's slow, inconsistent, and prone to human error. For high-volume production lines, this becomes a bottleneck.

The challenge: Design an automated system that can measure arbitrary objects with minimal human intervention, suitable for integration into an existing production line.


System Architecture

After evaluating several approaches (coordinate measuring machines, laser scanners, structured light), we settled on a hybrid mechanical-vision system. The key insight was that combining rotary encoder precision with computer vision for orientation would give us the accuracy of contact measurement with the flexibility of vision-based systems.

High-Level Design

The system consists of three subsystems:

  • Linear Motion System — A rack-and-pinion driven carriage that contacts the object
  • Rotational Platform — A servo-driven turntable that orients objects for measurement
  • Vision System — An overhead camera that determines object orientation

This architecture was chosen over alternatives for several reasons:

ApproachProsConsDecision
Laser triangulationNon-contact, fastExpensive, reflective surface issuesRejected
CMM-style probingVery accurateSlow, complex kinematicsRejected
Vision-onlyFast, flexibleAccuracy limited by resolutionPartial use
Encoder + VisionAccurate, simple mechanicsRequires contactSelected

Mechanical Design

Linear Motion System

The linear motion system uses a single rail on one side and a rack-and-pinion on the other. This asymmetric design was intentional—it minimizes complexity while leaving clearance for the rotating platform.

Design trade-off: A dual-rail system would provide better rigidity and reduce deflection under load. However, it would interfere with the turntable mechanism. Given our expected loads (LEGO blocks, small parts), the single-rail approach provides sufficient rigidity while enabling the rotation feature.

Materials choice: All custom parts were 3D printed in PLA. For a production system, aluminum or steel would be preferred—PLA's flexibility introduces measurement error under load. However, for prototyping, PLA allowed us to iterate quickly (2 days from CAD to assembly).

Tolerance considerations: We designed for tight press-fits between components to minimize backlash. This required several iterations—initial prints were too tight, causing binding. Final clearances were 0.1mm for sliding fits and 0.05mm for press fits.

Rotational Platform

The turntable uses a 55:90 tooth spur gear reduction driven by a servo. The gear system was hidden within the end plate for a cleaner design.

Why gears instead of direct drive? Initially, we planned to mount the motor directly below the platform. This caused clearance issues with the linear carriage. The offset gear system moves the motor outside the carriage path while providing a 1.64:1 reduction ratio for finer positioning.

Custom gear design: Commercial gears didn't match our space constraints, so we designed custom spur gears using an involute gear generator. The 55-tooth pinion and 90-tooth gear were optimized for our 3D printer's resolution (0.4mm nozzle, 0.2mm layer height).

Camera Mount

The camera mount height was calculated using basic trigonometry:

height = (platform_diameter / 2) / tan(FOV / 2)

For our camera's 60° FOV and 100mm platform diameter, this gave us a minimum height of 87mm. We added 30% margin for safety, resulting in a 115mm mount height.


Embedded Systems

The VEX V5 Challenge

We used the VEX V5 ecosystem for actuation, which presented a significant constraint: the V5 brain has no standard communication protocols. No UART, I2C, SPI—only digital I/O.

This meant we couldn't simply connect a computer to the brain. We needed a workaround.

Custom Communication Protocol

We developed a custom serial protocol inspired by I2C, using just two wires: a clock line and a data line.

Protocol specification:

  • Clock frequency: 100Hz (limited by V5 brain polling rate)
  • Data format: 8-bit angle value (0-180°)
  • Bit encoding: Clock high = bit valid, read data line
  • Frame format: START (clock low 50ms) + 8 data bits + STOP (clock low 50ms)

Implementation: An ESP32 acts as a bridge between the PC (running computer vision) and the V5 brain. The ESP32 hosts a WiFi access point, receives angle data via HTTP, converts it to our protocol, and transmits to the brain.

Why not just use the ESP32 for everything? The VEX motors and sensors integrate seamlessly with the V5 brain. Trying to control them directly from an ESP32 would require reverse-engineering proprietary protocols. Using the brain as the motor controller and the ESP32 as a communication bridge was the pragmatic choice.

Collision Detection Without Limit Switches

A key insight: we could detect object contact by monitoring motor current, eliminating the need for limit switches.

The problem with limit switches:

  • Add mechanical complexity
  • Introduce variability (switch travel, mounting tolerance)
  • Limit the size of measurable objects

Current-based detection: When the motor carriage contacts an object, the motor draws more current to overcome the sudden resistance. By monitoring current and detecting spikes above a threshold, we can determine the exact moment of contact.

Calibration: We ran 45 trials to determine the detection threshold. The threshold was set at 3 standard deviations above the mean running current, achieving 100% detection accuracy in testing.

This same technique is used for "homing"—the carriage moves until it contacts the back plate, establishing a zero reference.


Computer Vision

Orientation Detection Pipeline

The vision system determines how to rotate the object so its longest axis aligns with the measurement direction. This maximizes measurement accuracy (measuring along the longest dimension).

Pipeline stages:

  • Capture — Grab frame from overhead camera
  • Preprocessing — Grayscale conversion, Gaussian blur (5x5 kernel)
  • Thresholding — Adaptive threshold to handle varying lighting
  • Contour detection — Find object boundaries
  • Filtering — Remove contours that are too small (noise) or too large (background)
  • PCA analysis — Determine principal axes of the object
  • Angle calculation — Compute rotation needed to align longest axis horizontally

Principal Component Analysis

PCA finds the directions of maximum variance in the contour points. The eigenvector with the largest eigenvalue points along the object's longest axis.

angle = atan2(eigenvector[1], eigenvector[0])

This angle is then transmitted to the ESP32, which forwards it to the V5 brain to rotate the turntable.

Edge case handling: For square objects, the two principal eigenvalues are nearly equal. We detect this condition (eigenvalue ratio < 1.1) and skip rotation, since orientation doesn't matter for symmetric objects.


Calibration and Error Analysis

Calibration Procedure

  • Home the system (carriage contacts back plate)
  • Move to a known reference distance (108mm, verified with calibrated calipers)
  • Record encoder counts at this position
  • Calculate mm-per-count conversion factor

Measurement Accuracy

We collected 20 calibration points comparing encoder output to caliper readings:

Results:

  • R² = 0.999 (excellent linearity)
  • Maximum deviation: ±1.84mm
  • Systematic offset: 8.49mm

The systematic offset indicates a calibration error—likely in our "zero" position. This is correctable with better homing precision or a calibration offset in software.

Error Sources

SourceTypeMagnitudeMitigation
PLA flexibilitySystematic~0.5mmUse metal parts
Backlash in gearsRandom~0.3mmAnti-backlash design
Current detection latencySystematic~0.2mmReduce motor speed near contact
Encoder resolutionRandom~0.08mmHigher resolution encoder
Camera calibrationSystematic~2°Better calibration procedure

Lessons Learned

What Worked Well

  • Current-based collision detection eliminated mechanical complexity and worked reliably
  • The ESP32 bridge architecture solved the VEX communication problem elegantly
  • PCA for orientation is robust and handles arbitrary convex shapes
  • Rapid prototyping with 3D printing enabled fast iteration (3 design revisions in 2 days)

What I'd Do Differently

  • Use aluminum extrusion for the frame instead of 3D printed brackets—rigidity matters for precision
  • Add a proper limit switch for homing—current detection works but adds latency
  • Implement closed-loop positioning on the turntable—currently open-loop servo control
  • Better lighting control for the vision system—we were sensitive to ambient light changes

Production Readiness

For a production implementation, I would:

  • Replace PLA with machined aluminum or steel
  • Add dual linear rails for better rigidity
  • Implement proper cable management and enclosure
  • Add environmental controls (lighting, vibration isolation)
  • Integrate with PLC for production line communication
  • Add statistical process control (SPC) data logging

Technical Specifications

ParameterValue
Measurement range10-100mm
Resolution0.08mm
Accuracy±1.84mm
Repeatability±0.5mm
Measurement time~5 seconds
Rotation range0-180°
Rotation resolution
CommunicationWiFi (ESP32) + Custom serial
Power12V DC (VEX battery)

Conclusion

This project demonstrated that a hybrid mechanical-vision approach can provide accurate automated measurement at low cost. The key engineering decisions—current-based collision detection, the ESP32 communication bridge, and PCA-based orientation—solved real constraints we faced with the VEX platform.

The system achieves ±1.84mm accuracy, which is sufficient for many quality assurance applications. With the improvements outlined above, production-grade accuracy (±0.1mm) is achievable.

More importantly, this project taught me how to navigate constraints creatively. When standard communication protocols weren't available, we invented our own. When limit switches added complexity, we found an alternative. Engineering is often about finding pragmatic solutions within real-world limitations.