Most robot projects that disappoint do not fail at the robot.They fail because the upstream process was never stable enough to automate. Because the gripper was designed around the nominal part, and the real parts arrive with flash on the parting line. Because a safety distance was calculated from a stopping time nobody had measured, and the fence had to move after the concrete was poured. Because the acceptance criteria were written after the contract was signed, and the two parties then discovered they had different ideas about what finished meant.
None of these are robotics problems in the sense a textbook would recognize. All of them are implementation problems, and all of them are avoidable.
A great deal of published material treats the manipulator as the interesting object: its kinematics, its dynamics, its control. That material is valuable, and it is not what decides whether a cell reaches production. This handbook treats the robot as a component to be selected rather than a machine to be designed, and concentrates on the engineering that surrounds the selection.
It is organized around the sequence in which decisions actually arrive. Money is not committed before technical feasibility is established. Requirements are written before vendors are approached, not after. Safety enters as a design constraint while layout and speed are still negotiable, rather than as an inspection performed on a cell that has already been built.
What this handbook helps you do- Screen an application for feasibility before capital is committed, and record what would disqualify it
- Build a capital request that survives a finance review, with the cash-flow convention stated rather than assumed
- Write requirements and acceptance criteria before award, so acceptance is a measurement instead of a negotiation
- Size payload, inertia, reach and duty cycle, and recognize when inertia becomes the limiting criterion before payload does
- Assemble a stopping-time budget and place safeguards from it, keeping design-stage evidence separate from validation evidence
- Lay out the cell, guarding and utilities, and see which provisional numbers the layout still depends on
- Commission against agreed criteria, run the capability and rate trials honestly, and close the project at the right gates
One project runs through all sixteen chapters: a guarded six-axis cell tending a CNC turning center on a medium-volume machined-component line. Every chapter ends by producing one completed deliverable for that project, and the deliverables accumulate into a full implementation file.
Every method is presented with its assumptions visible, because a method whose assumptions are hidden will eventually be applied outside its range. Every number that matters is derived rather than asserted. Where the honest answer is that a quantity depends on the controller, the vendor or the plant, the book says so.
Who it is forThe manufacturing or automation engineer specifying a first cell. The integrator engineering a system against someone else’s requirements. The maintenance engineer who inherits the result. The engineering manager who has to defend the capital request. Advanced students will find the treatment accessible, but it is written for people who will have to live with their decisions.
Open the book at the stage your project has reached, and start building the file that will carry it to production.
