Robots and AI for Manufacturing

A case report on a $600 arm, twenty thousand magnets, and the course I am building from an automation project that isn't finished.

Framing

Automation education in most institutions is departmentally sorted. Robotics programs teach control and kinematics. Manufacturing programs teach process and fixturing. Computer science teaches the software. Each produces competent graduates, and industry performs the integration afterward, slowly and at cost.

What follows is a case report on a single automation project I developed inside a digital manufacturing program at a small private university, and on the course I am building from it. The project is unfinished. I am reporting it in that state deliberately, because the most transferable findings emerged from the failures rather than from the working system.

The case

The problem was a real production requirement, not a constructed exercise. An injection molded clip requires a small magnet glued into a recess in its base. A production run of ten thousand two piece sets left me with twenty thousand magnets to glue in. I initially staffed this with paid student labor. That approach worked in the narrow sense that the parts were assembled, and failed in every other sense: the task carried no instructional content, and quality consistency degraded predictably with operator fatigue and disengagement.

The automation target was therefore well specified. Pick a clip, dispense a magnet, apply glue, seat the magnet, verify. Five operations, tight tolerance, high repetition.

The hardware was a $600 robotic arm, selected on budget rather than capability. Vision was added later via two webcams. Inference runs locally on a Raspberry Pi.

Development began in 2024, before I had a working understanding of what current AI systems could contribute to a project of this kind. That timing shaped the initial architecture in ways worth documenting.

Finding one: the limiting factor was mechanical, and so was the solution

Iteration concentrated first on the end effectors, which is where my own expertise lies. The magnet dispenser passed through multiple revisions, beginning with a rotary design. Ferrous part handling introduces failure modes absent from general purpose feeding: magnets attract each other and any ferrous fixture element, so mechanisms that function reliably in single part testing jam under stacked conditions. The gluing station introduced separate constraints around dose consistency and cure timing.

The binding constraint, however, was arm accuracy. A $600 arm does not deliver the positional repeatability required to seat a small magnet in a small pocket. It approaches the target. Approach is not tolerance.

The resolution was mechanical rather than computational. Registration features designed into the gripper allow the arm to arrive approximately positioned and be physically corrected into exact position at the moment of contact.

I regard this as the project's most instructionally significant result. A robotics trained approach to a repeatability deficit reaches first for control refinement. A fabrication trained approach makes the physical environment tolerant so that precision need not originate in the machine. The second approach was cheaper, faster, and more robust. The knowledge required to reach it is conventional shop practice: self locating features, tapers, lead ins, hard stops. It is widely held among people who work with their hands and largely absent from robotics curricula.

The pedagogical implication is direct. Compliance and fixturing should be taught as first order solutions to automation problems, not as remedial measures after control strategies fail.

Finding two: the role of AI inverted during development

The initial architecture assigned AI a single bounded function: quality control at the terminal station, verifying magnet seating. All coordination was conventional.

That is not the current architecture. As the project progressed, AI absorbed successive functions until a locally hosted model became the coordinating layer for the system, with the hardware serving as its means of perception and action.

This inversion was not designed. It occurred incrementally, one problem at a time, and I only recognized it retrospectively. I note it because the pattern is likely general: practitioners entering these projects with a component level mental model of AI may find that model unstable under contact with the actual work. If that is common, curricula that introduce AI as one module among several may be teaching an architecture that dissolves in practice.

Finding three: local inference is a pedagogical constraint worth keeping

Inference runs on a Raspberry Pi rather than a cloud endpoint. The operational arguments are conventional: no network dependency, no latency across an external link, no recurring cost, no exposure to upstream API changes on a production floor.

The instructional argument is stronger. The entire compute stack costs less than a single quality end mill. Every student in a course can own the full system rather than sharing access to it, and the constraint of running within local resources forces explicit reasoning about model size and inference cost that hosted access conceals.

Course design

The course under development, Robots and AI for Manufacturing, is structured to draw from three programs: digital manufacturing, robotics, and programming.

The blending is not primarily an enrollment strategy, though it does substantially widen the eligible population. It is a response to Finding One. Each cohort predictably fails in a direction the others can see. Manufacturing students underestimate the software problem. Programming students underestimate the fixturing problem. Robotics students reach for control solutions where a mechanical feature would suffice. The corrective is not additional instruction from me. It is proximity to peers whose default reflexes differ.

The project basis is the production problem described above, retained in its unsolved state.

Limitations

Several constraints on the generality of this report should be stated.

The system is incomplete. I am not claiming a validated production cell, and no throughput or quality data against the human baseline is available yet.

The case is n of one, conducted by a practitioner with substantial prior fabrication expertise. My own learning trajectory was shaped by capabilities I brought in, and is not a model for a student's.

The course has not yet run. Everything in the course design section is hypothesis.

Most significantly, the conditions that produced my own learning may not be reproducible in a classroom. The project's instructional value to me derived substantially from a real and unavoidable obligation sustained over many months. A semester is fifteen weeks and carries no comparable consequence for nonperformance. Whether the learning survives the removal of that pressure is unresolved, and I would treat any claim to the contrary with suspicion.

Three questions seem worth pursuing beyond this case.

Whether mechanical compliance can be taught as a general automation heuristic, or whether it transfers only through hands on fabrication experience.

Whether the component to coordinator inversion described in Finding Two recurs across other practitioners and problem types, or is an artifact of my starting assumptions in 2024.

Whether authentic unsolved problems retain instructional value when the consequence of failure is a grade rather than an obligation. This is the question I have the least confidence about and the most interest in.