AOI Inspection Time Optimization — Practical Guide
4th Koh Young AI Contest — ICCAS 2026
📘 This is a supplementary document. For official contest rules, see Contest Rules ★
⚡ Quick Start — Get Started in 5 Minutes
It may look complicated, but what you actually need to do is simple. Write your code in the
solver/ folder.① Environment Setup (1 min)
# Install required packages
pip install -r requirements.txt
② Generate Data & Run Baseline (2 min)
# Generate simulation data (8 scenarios x 12 = 96 datasets)
python 1_generate_data.py
# Run baseline solver on all data -> check CT
python 2_run.py --solver greedy
PCB | FOVs | Cover | Order | CT (s)
--------------------------------------------------
PCB0000 | 42 | True | True | 28.53
PCB0001 | 38 | True | True | 25.17
... | ... | ... | ... | ...
--------------------------------------------------
PCB0000 | 42 | True | True | 28.53
PCB0001 | 38 | True | True | 25.17
... | ... | ... | ... | ...
③ Write Your Own Code in solver/ (This Is the Core of the Contest!)
Create files freely inside the solver/ folder. Just export a solve function from solver/__init__.py.
# solver/__init__.py
from .my_solver import solve
# solver/my_solver.py (filename is up to you)
def solve(data_folder: str) -> int:
# 1. Read input_component.csv, input_size.csv, input_parameter.csv
# 2. Determine FOV placement (position, count)
# 3. Assign components to FOVs
# 4. Determine inspection order (Fiducial -> Barcode -> Normal)
# 5. Save output_fov.csv
# 6. return FOV count
💡
Start simple: Assigning one FOV per component is a valid result. From there, merge FOVs and improve the ordering.
📊 FOV Placement Optimization — Before vs After
FOV size is determined by the camera field of view — all FOVs are the same size. The key is deciding where and how many same-sized FOVs to place.
Key: FOV size is fixed — optimize placement to cover all components with fewer FOVs and minimize travel distance
④ Verify Results (1 min)
# Run my solver -> constraint verification + automatic CT calculation
python 2_run.py --solver greedy
# Scoring only (evaluate existing output without running solver)
python 2_run.py --solver greedy --eval
# View result interactively in browser
python 3_view.py --solver greedy --dataset S00_sparse_fast_001 --open
✅
Cover = True: All components are included in FOVs
✅
Order = True: Inspection order constraints satisfied
⚠
If Cover or Order is False, a constraint is violated → penalty_solver is automatically applied.
checker.py will log which constraints were violated.
⚠ Penalty Solver — Automatically Applied on Constraint Violation
If a constraint (cover_all_components or fov_inspection_order) is violated, the Checker automatically runs the penalty_solver.
Your existing valid FOVs are kept intact, and additional FOVs are placed only for the uncovered (violating) components to recalculate CT.
1. Detect Uncovered Components
Components not covered by the participant's
output_fov.csv, or those violating inspection order, are identified.
Properly covered components and their FOVs are retained as-is.
2. Additional FOV Placement (Greedy)
Additional FOVs are placed via greedy method for uncovered components.
These extra FOVs are appended to the existing path in nearest neighbor order.
Existing FOVs kept + extra FOVs for uncovered
⚠ Penalty Effect
• Your existing FOV placement is preserved, but additional FOVs increase total FOV count and travel distance.
• The greedy placement of extra FOVs is far from optimal, so CT will be higher than a well-tuned solver.
• Finding better FOV placements while satisfying all constraints is the core challenge of this contest.
• The greedy placement of extra FOVs is far from optimal, so CT will be higher than a well-tuned solver.
• Finding better FOV placements while satisfying all constraints is the core challenge of this contest.
🔥
Make sure to cover all components! When penalty_solver is applied, extra FOVs are inserted, increasing CT.
Always verify that
cover_all_components() = True and fov_inspection_order() = True.
🔍 result.html Viewer — Normal vs Constraint Violation
After running 3_view.py --solver <name>, a result.html file is generated in each <dataset>/<solver>/ folder. Open it in a browser to interactively inspect the PCB layout and timing.
✅ Normal Output (2_run.py --solver greedy)
PCB | FOVs | Core | Cover | Order | CT (s)
----------------------------------------------------------
PCB_01 | 6 | 10 | True | True | 45.20
PCB_02 | 8 | 12 | True | True | 52.80
❌ Constraint Violation → penalty_solver Auto-applied
PCB | FOVs | Core | Cover | Order | CT (s)
----------------------------------------------------------
PCB_01 | 6 | 10 | True | True | 45.20
PCB_02 | 5 | 12 | False | True | 78.50*
----------------------------------------------------------
AVG | | | | | 61.85
* = penalty_solver applied (1/2 datasets)
When Cover=False or Order=False, penalty_solver places additional FOVs for uncovered components.
The
The
* next to CT indicates penalty was applied. Check error.log for violation details.
💡
Viewer tips: Run
python 3_view.py --solver greedy --open to generate and open result.html. Click a FOV to highlight its components and timing. Drag to zoom in, double-click to reset zoom. Use Step filters (Step=0/Step=1) to view by height level.
STEP 1
Generate Data
generator.py
❯
STEP 2
Write solver/
FOV placement + ordering
❯
STEP 3
Verify & Improve
checker.py → check CT
❯
STEP 4
Submit
Submit solver/ folder
🔍 result.html Viewer Usage
Run
3_view.py --solver <name> to generate result.html in each <dataset>/<solver>/ folder. Open it in any browser to access the interactive PCB inspection viewer.💻 Opening the Viewer
After 2_run.py has been run for a solver, use 3_view.py to render result pages. Each solver's output is in its own subfolder (e.g., simulation_data/S00_sparse_fast_001/greedy/result.html).
# Generate result.html for a specific solver
python 3_view.py --solver greedy
# View a single dataset and open in browser
python 3_view.py --solver greedy --dataset S00_sparse_fast_001 --open
# e.g., simulation_data/S00_sparse_fast_001/greedy/result.html
🗺 Viewer Layout
Header Bar
FOVs: Total FOV count
CT: Calculated Cycle Time (seconds)
Cover: PASS
Order: PASS
Cover: FAIL — uncovered components exist
Step Filters:
All
Step=0
Step=1
— click to show only that step's FOVs/components; others are dimmed
Left Panel — PCB Layout
- FOV rectangles: Each FOV is shown as a rectangle on the PCB board
- Components: Individual components inside their FOVs (gray=normal, green=fiducial, purple=barcode)
- Side FOV: FOVs containing side components show a blue dashed inner region
- Error FOV: Components outside FOV bounds are highlighted with a red border
- Trajectory: Inspection path connecting FOV centers as a polyline
- Step region: Step=1 areas shown with ochre dashed outline
Right Panel — Timing Gantt Chart
- Core 3+ (Inspect): Inspection time (orange)
- Core 1~2 (3D Recon): 3D Reconstruction time (red)
- Core 0 (Camera): Move (blue) + Capture (green) alternating
- CT: Total pipeline completion = last core finish time
🖱 Interaction Controls
🖱
Click a FOV
Highlights its components on the PCB and corresponding timing bars on the Gantt chart
🔍
Drag to Zoom
Click and drag on either panel to zoom into a region for detailed inspection
↺
Double-Click to Reset
Double-click anywhere to reset the zoom level back to the full view
🎨 Color Coding Reference
| Color | Element | Meaning |
|---|---|---|
| Green | Component | Fiducial mark (type=2) |
| Purple | Component | Barcode (type=1) — or error component (filled red with X mark) |
| Gray | Component | Normal component (type=0) |
| Blue | Component | Side component |
| Orange | FOV | Currently selected / highlighted FOV |
| Red border | FOV | Error FOV — contains components that violate coverage constraints |
| × Red + X | Component | Error component — extends outside its assigned FOV boundary or is unassigned |
📊 Understanding the Gantt Chart
The right panel displays a pipeline timing diagram showing how inspection tasks are distributed across CPU cores:
Move (stage repositioning)
Capture (camera image acquisition)
Reconstruction (3D height map)
Inspection (defect detection)
Core Assignment
- Core 3+ (C3, C4, ...): Handle inspection of reconstructed data
- Core 1–2 (C1, C2): Handle reconstruction of captured images
- Core 0 (C0): Dedicated to camera — alternates between Move and Capture
Pipeline Behavior
- Tasks execute in a pipelined fashion across cores
- More cores = more parallel inspection, reducing CT
- The bottleneck determines overall CT — balance is key
- CT is measured from the first Move to the last Inspection completion
💡
Pro tip: Use the viewer to identify bottlenecks in your solution. If the Gantt chart shows long idle gaps between bars, your FOV ordering or placement may benefit from optimization. Comparing result.html across different solver iterations helps you visualize improvements.
2 Contest Format & Scoring
The problem is published first, then participants are recruited. Write your code in the
solver/ folder.🏆 Scoring Method
Score = AVGi=all ( Cycle Timei + Computation Timei ) (lower is better)
Each dataset has a fixed max_core (random 4–16). The Checker uses it directly — no core sweep. Cycle Time is the inspection time; Computation Time is the solver's execution time. For the full formula, examples, and detailed explanation, see Problem Description §2 “Contest Format & Scoring”.
💡
Key insight: Core count is a given constraint. Focus on minimizing FOV count and optimizing visit order while keeping computation time low.
⛔ Important Notes
⚠
Prohibited: It is forbidden to call the provided ky_solver/ (Koh Young baseline) to generate or update solutions.
Participants must generate
However, using it for purposes that do not directly contribute to the solution output, such as generating training data, is permitted.
Participants must generate
output_fov.csv using their own algorithm. Directly or indirectly calling functions from ky_solver/ to produce results is grounds for disqualification.However, using it for purposes that do not directly contribute to the solution output, such as generating training data, is permitted.
✅
Permitted: External libraries (numpy, scipy, OR-Tools, etc.) may be used freely. Using AI tools (ChatGPT, Claude, Copilot, etc.) for code writing is also allowed.
🖥 Evaluation Environment
- All teams' code runs on the same evaluation server
- CPU Only — GPU not available
- Time limit applied per dataset (results up to that point are used if exceeded)
- Participants develop freely on their own PC; final submission is the
solver/folder
⚠
Eliminating hardware differences: Since all teams run on the same server, there is no advantage or disadvantage based on hardware. The contest is purely about algorithm efficiency.
📦 Provided Materials
| File / Folder | Purpose |
|---|---|
ky_solver/ | Koh Young baseline solver (compiled binary, source not provided) |
solver/ | Participant code folder — write your code here freely |
utils/checker.py | Constraint verification + automatic CT calculation |
utils/generator.py | Simulation data generator (unlimited training data) |
1_generate_data.py | Simulation data generator |
2_run.py | Run solver & score (per solver) |
3_view.py | Render result.html viewer (per solver) |
simulation_data/ | 96 datasets (8 scenarios × 12) |
# solver/__init__.py
from .my_solver import solve
# solver/my_solver.py (filename is up to you)
def solve(data_path: str) -> int:
# Input: data folder path
# Process: FOV placement + component assignment + order determination
# Save: output_fov.csv
# Return: FOV count (int)
...
✅
With the generator + checker open-sourced, RL/ML-based approaches are possible. Traditional optimization, AI, hybrid — any method is welcome.
📖 Glossary
| Term | Description |
|---|---|
| AOI | Automated Optical Inspection — equipment that automatically inspects electronic components on PCBs using cameras |
| PCB | Printed Circuit Board — the board on which electronic components are mounted |
| FOV | Field of View — the rectangular area captured in a single camera shot |
| CT | Cycle Time — total inspection time for one PCB (seconds) |
| Computation Time | Solver computation time (seconds) |
| Core | Parallel processing unit in the inspection pipeline. C0=Capture/Move, C1~C2=3D Reconstruction, C3+=Inspection |
| Pipeline | Parallel structure where Capture → 3D Reconstruction → Inspection run concurrently across multiple Cores |
| Fiducial | Reference point defining the PCB coordinate origin (type=2). Must be placed exclusively in the first FOV |
| Barcode | PCB model identifier (type=1). Inspected right after Fiducial |
| Side Camera | Camera capturing solder fillet from an angled view. Side FOV = 1/2 of Top FOV size |
| Step | Height regions on PCB (step=0, 1). Transitioning between steps adds +5s penalty |
| Penalty Solver | Greedy correction auto-applied on constraint violations. Significantly increases CT |