VisualGuard | Two Views. One Next Step.

OpenCV 5 checks two equipment-panel views and recommends REVIEW, STOP, or REQUEST_VIEW—turning an uncertain signal into a clear next step for a human operator.

Comment

One alarm, two views, one next step

On an equipment line, a red indicator in one camera view may be a real warning—or a sticker, reflection, or poor image. Treating uncertainty as an automatic stop can create needless downtime; treating an untrustworthy view as clear can hide missing evidence. VisualGuard explores a safer middle step: compare two views, explain what the images support, and give a human operator a bounded next action.

From pixels to a review decision

The prototype accepts front and side images, measures sharpness, exposure, and occlusion, detects red regions with HSV masks and morphology, checks contour geometry, and fuses the two views with freshness and replay checks. It returns REVIEW, STOP, or REQUEST_VIEW. When a view is requested, an operator can supply a replacement pair and run the inspection again. The system returns a plan only: action_executed=false, with no PLC or equipment actuator connected.

One inspection core, local and AWS paths

Try the live AWS application without an account. Choose a synthetic pair or upload front and side photos, preview both views, then select Inspect on AWS. The English interface sends the images to the same-origin Lambda API and returns an annotated decision, image-quality findings, and a human-readable next step. REQUEST_VIEW guides the operator to replace an unclear view and explicitly inspect again.

The shared Python/OpenCV 5 core runs in an ECR container on AWS Lambda. GitHub OIDC supplies short-lived deployment credentials, CloudWatch records executions, and the evidence panel exposes the real Lambda invocation ID separately from the application request ID. DynamoDB enforces a global allowance of five inspection attempts per Asia/Taipei calendar day, shared by all visitors. Loading samples and checking the connection do not consume an inspection.

Real equipment footage and AI visuals, clearly separated

The film includes archived machinery footage from the October 4 trade show as real-world context, plus AI-generated illustrative operator scenes. The interface demonstration and the four AWS invocations use synthetic or empty inputs; the video does not show live-camera inference. A separate local check processed 15 archived exhibition frames and photos and found no red candidates. Those images have no verified alarm labels, so this is not an accuracy result.

Evidence, including failure cases

On 540 held-out synthetic image pairs, exact-decision agreement was 94.26%, compared with 50% for a simple red-count baseline. None of 210 synthetic alarm cases was routed to REVIEW; that result is not a real-world recall claim. A known failure remains: all 30 round red-sticker cases returned a false STOP, and one motion-blur case returned REVIEW instead of REQUEST_VIEW. These cases show why the prototype needs broader, independently labeled data before operational use.

The deployed source is 0030066. Hosted CI and the public deployment workflow both passed. Anonymous readback returned HTTP 200 for the application and health route, and the served HTML hash matched the committed UI. Initial public AWS synthetic checks returned REVIEW for a clear pair and STOP for a side-view alarm. The attached report and architecture diagram distinguish the public rollout from the earlier private AWS film evidence.

What comes next

Collect consented, labeled camera data, evaluate new conditions without tuning on the held-out set, and get operator feedback. Live-camera accuracy, field acceptance, and physical control remain unverified.

Created by YOUNG-FU (solo entry).

Built With

Share this project:

Updates

Submission history