PaperlayerView exact revision on arXiv

Source-linked AI summary

Reproducible Vision-Guided 6-DoF Robotic Manipulator with a Mixed Stepper-Driver Architecture and Browser-Native Control

Lasan Perera, Deneth Priyadarshana, Dulana Pitiwaduge, Isitha Dinujaya, Mokshan Colambage

arXiv:2608.22799v1cs.ROcs.CVeess.SY

TL;DR

Low-cost robotic arms trade affordability against torque, repeatability, and payload, while reproducible mixed-driver designs remain underdocumented. The paper presents the open NeuralNexus Arm, combining a single-controller mixed stepper architecture with browser-native control and vision-guided operation. The platform actuates all six axes at a 2 kHz update rate and executes manual and pre-recorded motions from the browser.

  • Problem

    Low-cost robotic arms face tradeoffs in torque, repeatability, and payload, motivating reproducible alternatives beyond hobby-grade designs.

  • Method

    The paper presents an open 6-DOF arm using one STM32H743 controller, mixed onboard and external stepper drivers, and browser-native motion control.

  • Results

    The platform actuates all six axes and executes manual jog commands and pre-recorded sequences from the browser interface at a 2 kHz update rate.

  • Takeaways & Limitations

    The documented open design and bring-up failures support reproduction of a capable 6-DOF stepper arm without proprietary host software.

Abstract

from arXiv · show

We present the NeuralNexus Arm, an open, low-cost 6-DOF robotic manipulator built by an undergraduate engineering team, together with the design decisions and debugging experience needed to reproduce it. The arm is driven by a single STM32H743 microcontroller on a custom printed circuit board (PCB) and combines two stepper-driver strategies on one controller: push-pull 3.3 V step/direction outputs for onboard TMC2209 drivers on the three wrist joints, and open-drain outputs for external CL57T and DM542 drivers on the three high-torque proximal joints. We describe the mechanical design, mixed-driver electronics, interrupt-driven firmware, a MATLAB/Simscape-based inverse-kinematics pipeline, a browser-native control interface using the Web Serial API, and a lightweight vision pipeline for object localisation and autonomous pick-and-place tasks. We also document non-obvious hardware and firmware failure modes encountered during the transition from a development board to the custom PCB as reproducibility guidance. All design files and firmware are released openly. The platform actuates all six axes under coordinated control at a 2 kHz update rate and executes both manual and pre-recorded motions from the browser interface.

I. INTRODUCTION … B. Shoulder Joint (J2)

The paper presents the open, low-cost NeuralNexus Arm as a reproducible six-axis platform that addresses the gap between hobby-grade and costly, difficult-to-reproduce manipulators. It combines a mixed-driver STM32H743 controller, browser-native control, documented bring-up lessons, and joint-specific mechanical reductions.

  • I. INTRODUCTION: The NeuralNexus Arm is an open, low-cost 6-DOF manipulator documented across its mechanics, electronics, firmware, and reproducibility lessons.The authors emphasize the development-board-to-custom-PCB migration and the hardware and firmware failures exposed during bring-up.
  • I. INTRODUCTION: Its single STM32H743 controller mixes onboard TMC2209 push–pull 3.3 V outputs with external closed-loop open-drain drivers using common-anode wiring.The architecture is designed to match different joint torque requirements while addressing polarity and logic subtleties.
  • I. INTRODUCTION: The browser-native Web Serial interface enables jogging and pre-recorded motion without host-side software.This removes a host-side software dependency from the control workflow.
  • II. RELATED WORK: Compared with related open-source manipulators, NeuralNexus emphasizes controller-level design and reproducibility rather than mechanical novelty.Its documentation covers PCB design, firmware, system integration, and bring-up procedures for replication by researchers and student teams.
  • III. MECHANICAL DESIGN: The manipulator uses hierarchical actuation, pairing high-torque proximal NEMA 23/24 motors with gearboxes and belt reductions and compact NEMA 17 wrist motors.The arrangement addresses varying torque and speed requirements while reducing distal moving inertia.
  • A. Base Rotation (J1): The base rotation joint uses a NEMA 23 motor and a 1:7 spur-gear reduction to increase output torque, positioning resolution, and reduce motor torque demand.The base supports the manipulator and rotates it about the vertical axis.
  • B. Shoulder Joint (J2): The shoulder joint uses a NEMA 24 motor, a 1:10 planetary gearbox, and a belt stage with 30-tooth and 75-tooth pulleys for an additional 1:2.5 reduction.The shoulder carries a significant portion of the manipulator mass and uses an HTD3M 15 mm belt selected for high torque capacity.

C. Elbow Joint (J3) … A. Actuator and Driver Selection

The NeuralNexus Arm combines geared and belt-driven actuation for its elbow and wrist, a servo-actuated parallel-jaw gripper, and a single STM32H743-based PCB coordinating all six joints. Proximal joints use external closed-loop drivers for high-torque support, while lighter wrist joints use onboard TMC2209 drivers.

  • C. Elbow Joint (J3): J3 uses a NEMA 24 stepper motor with a 1:10 planetary gearbox and three HTD3M timing-belt reduction stages.The final stage uses a 30-tooth driving pulley and a 75-tooth driven pulley.
  • D. Wrist Pitch (J4): J4 uses a compact NEMA 17 stepper motor combined with a 1:4 planetary gearbox for wrist actuation.The gearbox provides sufficient output torque while retaining a compact wrist design.
  • E. Wrist Roll (J5): J5 uses a NEMA 17 motor and GT2 belt transmission with a 20-tooth driving pulley, 60-tooth driven pulley, and 1:3 reduction.A 6 mm wide belt supports compact packaging and torque transmission for the lightweight wrist mechanism.
  • F. Gripper Rotation (J6): J6 uses a pancake NEMA 17 motor mounted directly in the wrist to provide end-effector rotation with reduced size and inertia.The motor provides sufficient torque for orienting the gripper.
  • G. Gripper: The gripper uses a digital-servo-actuated parallel-jaw mechanism with closed-loop position control and independent orientation and grasping-force control.Separating gripping from wrist rotation simplifies the mechanical design.
  • IV. ELECTRONICS, CONTROLLER & FIRMWARE ARCHITECTURE: A custom PCB built around the 480 MHz STM32H743VIT6 generates step and direction signals, reads encoders, and communicates serially for all six joints.The board integrates wrist drivers, external-driver interfaces, power conditioning, and motor and signal connectors.
  • A. Actuator and Driver Selection: The three proximal joints use high-torque motors with external closed-loop DM542 and CL57T drivers, while lighter wrist joints use NEMA-17 motors with onboard TMC2209 drivers.Closed-loop drive addresses consequential step loss under gravitational load; TMC2209 drivers are compact, quiet, and adequate for the wrist.

B. Mixed Driver Interfacing … F. Power Architecture

The controller integrates two stepper-driver interface strategies on one STM32H743, matching push–pull 3.3 V signaling to onboard TMC2209 wrist drivers and open-drain 5 V signaling to opto-isolated external drivers. Separate enable handling, hardware-configured motion parameters, and partitioned power rails support the mixed architecture.

  • B. Mixed Driver Interfacing: The PCB accommodates different electrical interfaces for the two driver families.The architecture uses one STM32H743 controller for both interfaces.
  • B. Mixed Driver Interfacing: The STM32 uses push–pull 3.3 V outputs for onboard TMC2209 drivers and open-drain common-anode 5 V signaling for external CL57T and DM542 inputs.The microcontroller sinks current through the opto-isolated drivers’ negative terminals, avoiding external level shifters.
  • C. Enable-Signal Polarity: Enable polarity differs across driver families and external models, so firmware uses separate routines and maps motor channels M1–M6 to joints through jointToMotor.Onboard channels M1–M3 correspond to wrist joints J4–J6, while external channels M4–M6 correspond to proximal joints J1–J3.
  • D. Microstepping and Step Timing: Microstep resolution and phase current are configured in hardware rather than changed at run time.External drivers use DIP switches, while onboard TMC2209 settings use configuration pins; firmware stores per-joint pulses per full revolution.
  • D. Microstepping and Step Timing: Step pulses are generated by a single TIM6 interrupt at 2 kHz, with each pulse held high for approximately 500 µs.The 2 kHz interrupt corresponds to a 500 µs control tick and the firmware timebase dt = 0.5 ms.
  • E. TMC2209 Configuration: The TMC2209 drivers select SpreadCycle by tying SPREAD to VIO to retain torque during motion.They operate in standalone step/direction mode, with phase-current limits set through VREF and onboard 0.11 Ω sense resistors.
  • F. Power Architecture: Motor power is separated from logic power: motors and drivers use the main motor rail, while the microcontroller and logic circuitry use 3.3 V.The 3.3 V logic supply is generated by an onboard ST1L05CPU33R low-dropout regulator.
  • F. Power Architecture: The external drivers’ opto-isolated 5 V input rail is derived from the 12 V wrist rail through a TPS56637RPAR synchronous buck converter.Motor and logic grounds are joined at a single point to limit switching noise on the logic rail.

V. KINEMATICS AND MOTION PLANNING · A. Kinematic Model · B. Inverse Kinematics

The NeuralNexus Arm is modelled as a six-joint MATLAB rigidBodyTree using CAD-derived transformations, providing the numerical basis for forward and inverse kinematics. Desired poses are converted to joint angles through numerically optimized, limit-constrained inverse kinematics initialized from the current configuration.

  • A. Kinematic Model: The MATLAB rigidBodyTree represents six rigid bodies connected by six revolute joints, with fixed transformations extracted from the validated Simscape model.This model supports forward kinematics and inverse kinematics while preserving the manipulator’s validated geometry.
  • A. Kinematic Model: Unlike Denavit–Hartenberg modelling, rigidBodyTree stores adjacent joint-frame transformations directly and preserves CAD geometry without intermediate DH parameters.
  • A. Kinematic Model: Each joint-frame transformation comprises a rotation matrix Ri ∈SO(3) and translation vector pi ∈R3 between parent and child frames.
  • A. Kinematic Model: Forward kinematics is computed by the ordered product of individual link transformations to obtain the end-effector pose relative to the base frame.
  • A. Kinematic Model: The exported fixed translations and joint axes completely define the kinematic chain used by the numerical inverse kinematics solver.Mechanical joint limits are incorporated into the rigidBodyTree so optimization produces physically achievable configurations.
  • B. Inverse Kinematics: Desired end-effector poses are converted to joint angles by MATLAB’s inverseKinematics solver, which numerically minimizes Cartesian pose error instead of using a closed-form solution.
  • B. Inverse Kinematics: Initialization from the current joint configuration enables rapid convergence and configuration continuity between successive target poses.Translation and rotation receive equal weighting, giving position and orientation equal importance during optimization.
  • B. Inverse Kinematics: Joint limits are enforced throughout inverse-kinematics optimization to prevent solutions outside the manipulator’s mechanical operating range.A reference joint configuration was used as a nominal pose for forward- and inverse-kinematic model validation.

C. Motion Execution · VI. CONTROL INTERFACE · VII. VISION PIPELINE

The system transmits inverse-kinematics joint angles from MATLAB to an STM32H743 controller, which generates synchronized six-motor step commands. Browser control supports manual and prerecorded motions, while vision estimates planar object coordinates for inverse-kinematics-based positioning under a fixed-height assumption.

  • C. Motion Execution: MATLAB transmits inverse-kinematics joint angles to the STM32H743 controller, whose interrupt-driven firmware converts them into synchronized step commands for six stepper motors.This workflow connects the inverse-kinematics solver, serial communication interface, and embedded pulse-generation algorithm.
  • C. Motion Execution: Long trajectories are split into smaller motion segments to prevent communication-latency pauses while maintaining coordinated motion across all six joints.The chunked-motion strategy is applied before transmission.
  • VI. CONTROL INTERFACE: A Chromium-based browser connects directly to the controller through the Web Serial API without requiring a vendor IDE or native host driver.The browser-native panel provides the primary host-side connection to the arm.
  • VI. CONTROL INTERFACE: The control panel supports per-joint manual jogging, prerecorded sequences, gripper commands, and a Stop control.Gripper commands are G,1 to open and G,0 to close.
  • VI. CONTROL INTERFACE: Cartesian moves remain MATLAB-dependent: the solver computes joint angles and streams them over the same serial link, while browser-side solver porting is future work.This separates browser-based manual and prerecorded control from Cartesian motion execution.
  • VII. VISION PIPELINE: The vision implementation uses a Raspberry Pi 5 with 4 GB RAM and a Pi Camera 3 to detect objects, form bounding boxes, transform centre pixels into real-world coordinates, and invoke inverse kinematics.The resulting coordinates direct the arm toward the detected object.
  • VII. VISION PIPELINE: Because the Pi Camera 3 provides only x and y image coordinates, the arm uses a fixed position with known height z = 41 cm to determine complete target coordinates.The arm moves to the fixed position, captures the pixel value, transforms it into x and y, and supplies the known z coordinate.
  • VII. VISION PIPELINE: The complete vision pipeline captures and calibrates images, undistorts them, segments objects by colour, estimates image centres, transforms planar coordinates, and generates robot targets.Target points are valid only when they lie within the calibrated workspace plane.

A. Camera Calibration and Image Undistortion

The camera was calibrated geometrically with a fixed Pi Camera and a 32 mm-square chessboard using 20 images captured at varied angles and distances. The resulting intrinsic and distortion parameters were stored and applied to undistort frames before object localisation.

  • Calibration procedure: Geometric calibration estimated the camera intrinsics and lens-distortion parameters before object localisation.Planar chessboard points were matched to observed image coordinates for calibration.
  • Calibration procedure: 20 chessboard images with 32 mm squares were captured at different angles and distances while the Pi Camera remained stationary.The calibration set included detected 8×5 inner-corner patterns from nine images.
  • Camera model: The intrinsic camera matrix represents pixel focal lengths fx and fy together with the principal point (cx, cy).These parameters describe the camera’s intrinsic geometry.
  • Camera model: The OpenCV distortion model estimates three radial coefficients, k1, k2, and k3, and two tangential coefficients, p1 and p2.Radial distortion increases with distance from the optical centre, while tangential distortion reflects lens–imaging-plane misalignment.
  • Runtime correction: Calibration outputs were stored as camera_matrix.npy and dist_coeffs.npy, then used to undistort every captured frame before object localisation.The stored parameters were applied during operation rather than only during calibration.

B. Colour-Based Target Segmentation · C. Contour Detection and Centroid Estimation

The vision pipeline uses HSV colour segmentation to detect red objects without object-specific training, then extracts and filters contours to estimate a target centroid. The resulting pixel coordinates must be transformed into the robotic workspace coordinate system.

  • B. Colour-Based Target Segmentation: Colour-based segmentation was selected over YOLO because it offers higher FPS and detects objects of any shape sharing the target colour without separate training.Initial tests considered yolo26n.pt, yolo11n.pt, and custom-trained YOLO models primarily detecting cardboard boxes.
  • B. Colour-Based Target Segmentation: The pipeline converts OpenCV’s BGR images to HSV, where hue represents colour type and saturation and value describe purity and brightness.HSV supports colour-based segmentation by separating colour type from colour purity and brightness.
  • B. Colour-Based Target Segmentation: Red targets are segmented by combining two HSV hue intervals because red lies across the cyclic hue boundary.The selected intervals are 0 ≤H ≤10 and 170 ≤H ≤179.
  • C. Contour Detection and Centroid Estimation: Contours are extracted from the binary mask to identify candidate connected regions, while small noise or unwanted red regions are rejected by area.Contour area is compared with the expected target size to select a valid target contour.
  • C. Contour Detection and Centroid Estimation: The valid target contour is selected according to its calculated area and the expected target size.This filtering step separates the target region from other segmented regions.
  • C. Contour Detection and Centroid Estimation: Spatial image moments determine the centre of the selected target and provide region-area and centroid quantities.The centroid is computed from the binary region’s spatial moments.
  • C. Contour Detection and Centroid Estimation: The detected object location is represented by centroid coordinates in image pixels before workspace-coordinate transformation.Pixel coordinates require conversion into the robotic workspace’s physical coordinate system.

D. Planar Workspace Calibration

Planar workspace calibration maps camera pixels to real-world (x, y) coordinates using a homography estimated from corresponding physical and image points. The resulting transformation is reused during real-time operation while camera–workspace geometry remains fixed.

  • D. Planar Workspace Calibration: A 3×3 planar homography matrix maps image pixels to real-world (x, y) coordinates through a projective transformation.The method performs the projective transformation between the image and workspace planes.
  • D. Planar Workspace Calibration: Calibration pairs known physical workspace locations with their corresponding image coordinates to estimate the homography matrix.For planar scenes, the image-to-plane mapping is estimated directly from corresponding points.
  • D. Planar Workspace Calibration: The target centroid (uc, vc) is converted into physical coordinates through homogeneous normalisation.This provides the real-world coordinates used after detecting the target centroid.
  • D. Planar Workspace Calibration: The calibrated transformation is stored as homography_matrix.npy and reused during real-time operation.The same transformation remains applicable provided the fixed camera and workspace retain unchanged relative geometry.

E. Generation of Robot Target Coordinates · VIII. BILL OF MATERIALS

The target-coordinate pipeline maps image observations onto the calibrated workspace plane, assigns height from the known workspace, and supplies the resulting coordinates to the robot controller. The bill of materials reports subsystem-level costs and a revised total of $1,512.33, with full itemisation in Appendix A.

  • E. Generation of Robot Target Coordinates: The homography transformation determines the target’s planar workspace location.The calibration visualisation uses a 32 mm chessboard to map detected image-plane corners into a top-down calibrated-workspace representation.
  • E. Generation of Robot Target Coordinates: The target’s vertical coordinate is defined from the corresponding workspace height because the object lies on a known workspace plane.
  • E. Generation of Robot Target Coordinates: The resulting target coordinate is supplied to the robot controller.
  • VIII. BILL OF MATERIALS: Table V summarises component and fabrication-service costs by subsystem.The table provides a subsystem-level bill-of-materials summary, while the full itemised breakdown appears in Appendix A.
  • E. Generation of Robot Target Coordinates: The target-generation formulation uses θ to denote the set of robot joint variables.
  • VIII. BILL OF MATERIALS: $1,512.33 is the revised total bill-of-materials cost, superseding the approximate figure in Table I.

IX. ENGINEERING METHODOLOGY AND LESSONS LEARNED … XII. CONCLUSION

The paper documents migration failures and fixes encountered when porting the arm from a development board to a custom PCB, then validates six-axis browser control and outlines future applications. It concludes that a capable, reproducible 6-DOF stepper arm can be built with one microcontroller, mixed drivers, and an open browser interface.

  • IX. ENGINEERING METHODOLOGY AND LESSONS LEARNED: Porting from the development board to the custom PCB exposed a cascade of reproducibility-relevant hardware and firmware issues.The authors record these root causes because reproducing teams are likely to encounter similar problems.
  • X. RESULTS AND VALIDATION: The platform was demonstrated in a full pick-and-place sequence, with selected frames reported in Fig. 10 and the complete demonstration in Video 2.Table VI is identified as the experimental performance summary.
  • A. Phantom Encoder Wander: ±72◦ encoder wander was caused by averaging −1 error sentinels, and excluding them removed the artefact.Slowing the SPI clock worsened the effect, ruling out analogue or timing causes and pointing to the data path.
  • B. CubeMX Regeneration Trap: CubeMX regeneration reintroduced SDMMC1 and FATFS initialisers that trapped without an SD card.Commenting them out after regeneration is an immediate workaround; disabling SDMMC1 and FATFS in the .ioc is the durable fix.
  • X. RESULTS AND VALIDATION: All six axes actuated through browser-based manual jog commands and pre-recorded sequences during validation.Motion timing matched the step-rate model, including approximately 4 s for a 60◦ move at 400 steps/s.
  • XI. FUTURE WORK: Future work targets reconfigurable manufacturing and automation uses, including additive manufacturing, multi-axis 3D printing, laser engraving, and low-power laser cutting.The proposed adaptations include mounting extrusion-based or laser end effectors on the wrist.
  • XI. FUTURE WORK: Additional applications include adhesive dispensing, component sorting, surface inspection, laboratory automation, machining, polishing, and painting using interchangeable end effectors.These possibilities extend the same platform to light-duty robotic process-automation tasks.
  • XII. CONCLUSION: The NeuralNexus Arm demonstrates reproducible 6-DOF stepper manipulation using one microcontroller, mixed onboard and external drivers, and browser-native control without proprietary host software.Documenting the finished design alongside bring-up failures and root causes is intended to make the platform genuinely reproducible.

APPENDIX DETAILED BILL OF MATERIALS

The appendix presents a detailed bill of materials and states that its costs were converted from LKR using a specified exchange rate in August 2026.

  • Bill of materials: The appendix includes a detailed bill of materials.The passage identifies this content as Table VII.
  • Cost conversion: Costs are converted from LKR at 1 LKR = $0.00298.The stated conversion rate is associated with the bill of materials.
  • Cost conversion: The cost conversion is dated August 2026.The passage specifies the timing of the exchange-rate conversion.
Loading 2608.22799v1…