Monitoring Manual Assembly on an Engine Crankcase Station
An overhead camera watches the crankcase: timing chain, right-case close, oil-pump gear, locating pin, then oil-pump confirmation — each step must finish before the next; skipped or missed steps show up on the spot.
Author LeoField video + platform UI
K E Y P O I N T S
The core problem. Once the case is closed, internal work is hidden. A missed timing chain, oil-pump gear or locating pin — or a wrong order — often surfaces only in later tests or tear-down rework, costing far more than one extra look at the station.
Order is the constraint. These steps depend on each other — the right case closes off access, and pin / pump checks sit at fixed nodes. The system must judge not only “is it there”, but whether it belongs at this step.
Few-shot start. Five classes — timing chain, right case, oil-pump gear, locating pin, oil pump — each settled with 1–10 on-site images in the labelling tool, configured in minutes.
A state machine enforces the hand sequence. S0–S5 advance through the five-step SOP; unexpected events self-loop — skips do not advance, and a miss never reaches release.
Edge-local inference. Video is analysed on a shop-floor GPU in real time and does not leave the plant; one agent can cover multiple stations and lines.
00
Brief: five steps on the crankcase
Background
A manual engine-crankcase station. Operators complete, in order, timing-chain fit, right-case close, oil-pump gear fit, locating-pin fit, oil-pump confirmation. After close-up, internals are covered; misses and wrong order are hard to re-check at this station.
Work pattern
Overhead view, both hands in frame, trays beside the case; glove colour changes and motion is large, but the shape of each critical part when seated can still be captured by a segmentation model.
Goal
Judge each step on the spot; skips and misses must be visible at the station, not deferred to downstream test or tear-down.
System
Overhead video stream + one edge agent. Inference stays on the shop floor; video does not leave the plant.
The pipeline is five operators — the spine of this article:
01
Video camera
Overhead station feed
02
Preprocess
Denoise, enhance, normalise
03
Segmentation
Five assembly classes
04
Event detect
“Is this step done?”
05
State machine
Release only when complete
01
Why missed steps are hard to catch
Three difficulties are each manageable alone; together they shut out “sample after the fact”.
1. After close-up you cannot see; the cost lands downstream
Once the chain, gear and pin are inside and the right case closes, internals disappear. Misses and wrong order often surface only in later tests — or tear-down rework — costing far more than one second of confirmation here. Value is knowing on the spot, not being able to audit later.
2. Steps are ordered; “all five appeared” is not enough
Any order does not work: closing the right case blocks access, and pump confirmation sits at a fixed node. Counting “five objects showed up” lets skips through — “which step should run now” must live in the state machine.
3. Hands, gloves and tools keep occluding
Gloves and tools dominate the frame; pins and gears only show fully for a short window. Fixed boxes or geometry metrology cannot ride out occlusion; few-shot segmentation must recognise “which class is being fitted”, then events decide seated.
Together, the shape of the solution is: recognise the class being fitted, express “this step holds” as an event, and lock order in a state machine — skips self-loop, misses never reach release.
02
Tensor flow: one stream, three jobs
Configuration starts on this canvas. Drag operators from the left library, wire them on the right — the stream does three jobs only: see, decide, order.
📹 Video camera
Overhead feed in
→
🎨 Preprocess
Denoise / enhance
→
🧠 Segmentation
Five assembly classes
→
🔍 Event detect
“Done or not?”
→
🎯 State machine
Hold until release
The split pays off later: classes live in segmentation, verdicts in events, order in the state machine. Change one without retraining the model.
Fig. 1 Tensor-flow editor. Nodes wrap when needed; wires enter and leave ports horizontally — the platform’s native style, no arrowheads.
03
Semantic segmentation: see what is being fitted
This section answers “which class is in play” — events and the state machine both rest on that table.
Glove colour and tools change; the objects that must be confirmed do not. Matching the five steps already running in the video, the classes are:
Class
What it covers in the frame
Timing chain
Chain and related action region during timing-chain fit
Right case
The case half being lifted and seated at close-up
Oil-pump gear
The gear body as it enters the cavity
Locating pin
The pin and its seating region
Oil pump
Pump body / install form checked at confirmation
Swatches are platform mask colours for class separation — not the glove colours on the line.
Setup stays light: cut 1–10 frames per class, outline them, hit “migrate” to train from labelled samples — a model in minutes; hit “detect” to re-check the same set. Glove changes or small angle shifts take a few more samples to iterate — no long on-site retraining residency.
Fig. 2 Semantic segmentation UI from this station’s field video. Left: detection result — mask and step label painted by the platform; right: the same frame outlined with a solid contour, no fill.
04
Event detection: turn “seen” into “done”
Segmentation says what is in the frame; events say which step happened. This layer does not touch the model — only judgement logic.
Each of the five steps has one event, usually an “object exists” primitive on that class in the critical region; stricter area or AND gates can be added without retraining:
Event
Meaning
Primary class
E0
Timing-chain fit done
Timing chain
E1
Right-case close done
Right case
E2
Oil-pump gear fit done
Oil-pump gear
E3
Locating-pin fit done
Locating pin
E4
Oil-pump confirmation done
Oil pump
Events only answer whether a step’s conditions hold; they do not track progress — order belongs to the state machine next. Insert a process step later with one new event and one transition; the segmentation model can stay put.
Fig. 3 GPU event orchestrator, configuring E1 right-case close: “object exists” on the right-case class; horizontal port wiring, no arrowheads.
05
State machine: miss one step, no release
Events say whether a step holds; the state machine says where this unit is. This station advances in SOP order — a single chain.
S0
Await timing chain
On E0 → next; other events self-loop
↓
S1
Await right-case close
On E1 → next
↓
S2
Await oil-pump gear
On E2 → next
↓
S3
Await locating pin
On E3 → next
↓
S4
Await oil-pump confirm
On E4 → release; otherwise stay here
↓
S5
Unit complete
Part leaves / reset → back to S0
The force is in the self-loop: in S2, fitting the pin first will not advance even if E3 fires — only the expected event moves the machine. Miss any step and S5 is unreachable; the station shows progress stuck on the missing link.
For a model change or a small sequence tweak, edit the graph and event list; the segmentation model can stay — rename classes or add a few samples.
Fig. 4 State-diagram editor. Right-hand tensors list events and the state–action set.
Fig. 5 The same config as a grid. Only the expected event advances; everything else self-loops — that is how hand-sequence enforcement lands.
06
Live run: 35 seconds of field video
The clip below is the live station (portrait, overhead). Coloured masks track the active step region and overlay the step name.
00:05Timing chain
00:13Right-case close
00:23Oil-pump gear
00:27Locating pin
00:32Oil-pump confirm
One detail: mask colour switches with the step — no need to read a report; the highlighted class is what the system believes is running. Wherever progress stops is the missing step.
5 classes
Segmentation
1–10 imgs
Per-class start
5 evt / 6 st
Events & states
On-prem
Video stays local
07
Retrospective: where this approach stops
Ordered stations need more than kit counting
Kit counting fits order-free connector work; for crankcase internals, order itself is a quality constraint. Pin expected events in the state machine and skips are blocked by design.
Split class, event and state so changeovers stay light
“What is being fitted”, “does that count as done”, and “where are we” stay independent. Insert a step or tweak sequence — often config only, no model retrain. Field feedback can keep iterating the same few-shot loop.
One agent, many stations
Compute sits on the edge agent; stations keep camera and HMI. One box can run many stations and lines, each with its own classes, events and state machine.
Say the boundary clearly
Fits overhead-visible work with a short clear window: chain, case close, gear, pin, pump confirm. Not for steps fully hidden by fixtures with no visible outline — add a close-up camera or leave a process window.
Cross-domain reuse
The same base moves to another scene with 1–10 sample images and minutes of setup. Directions already run:
Four questions run through the project: what the system watches, what counts as done, which order is legal, and how results are kept. Answer them in the config UI and the station runs.
LEO
Leo
Vision architect · industrial process monitoring
PhD in computer vision (few-shot segmentation and video action understanding); 12 years on industrial lines across 30+ lines and 100+ stations.
Moves process monitoring from one dedicated model per station to few-shot segmentation + event wiring + SOP state machines, so judgement logic stays decoupled from the perception model.
Focuses on edge-GPU inference, cross-domain generalisation and closed-loop field data — so the same configuration style can copy across plants and processes. This piece records the actual setup, judgement logic and field result.