Computer vision workspace / 2024 to present

Eidos

Why it matters Eidos requires a performance change to preserve exact marker IDs and corner coordinates, not merely return a similar detection count.

Eidos asks how much vision work can stay format-aware and predictable on embedded hardware.

Request a demo

StatusPrivate · pre-1.0 R&D

Role in the architectureReusable vision algorithms / separate workspace

My roleFounder & Lead Engineer

DisciplinesRobotics + embedded / Runtime + media

01 / Processing evidence

Trace a result back to its source.

These are inspection views from one detector path. Comparing the camera frame with the candidate mask and contour geometry shows where a missed or false marker entered the pipeline.

Original source frame processed by Eidos — **Camera input**The field frame before detector filtering

Eidos mask output — **Candidate mask**Pixels retained for connected geometry

Eidos contour output — **Contour geometry**Candidate boundaries before marker decoding

02 / The work

Challenge

Embedded vision libraries often convert every source into one convenient format and optimize isolated kernels without proving that detector output stayed identical.

Product nodes then mix math, scheduling, calibration conventions, and tuning evidence in one boundary.

Approach

I split shared frames, geometry, masks, contours, calibration, motion, temporal logic, fixtures, and benchmarks into focused crates.

Native-format kernels choose scalar, SIMD, NEON, or Rayon implementations behind one facade, while hashed expected payloads and checked image/video cases gate detector experiments.

03 / Architecture model Inspectable vision path

Every intermediate stage can explain the result.

Fiducial markers are coded squares whose IDs and image-space corners let a robot estimate its position. Eidos keeps the source, candidate mask, contours, and complete marker output visible so a missed or shifted result can be traced to the stage that introduced it.

InputCamera input

Styx frame · native pixel layout · optional calibration

01Pixel domain

Color · mask · sampling · motion

02Topology

Contours · features · candidates

03Geometry

Coordinates · calibration · pose

04Detector

Scoring · filtering · temporal state

System outputChecked output

Marker family + ID · corner geometry · temporal result

Evidence loopCorrectness before timing

Exact saved outputs
Intermediate images
CM5 workload benchmarks

04 / Implementation

The decisions beneath the summary.

Format-native image operations

Avoid paying a universal color or layout conversion tax before useful work begins.

The image-operation layer keeps the source layout visible and routes supported work through scalar, SIMD, NEON, or Rayon implementations behind one facade. Shared frame, mask, geometry, drawing, filtering, motion, and sampling contracts let detector code compose those operations without depending on a product graph or UI.

Input boundary: Eidos accepts the same Styx FrameLease produced by capture instead of copying into a product-only image container
Hardware boundary: backend selection remains below the operation API so an algorithm does not fork into separate CM5 and desktop versions
Scope note: calibration shares geometry types with the detector, but the current calibration implementation is not presented as release-ready

Exact detector evidence

Treat a faster but different detection payload as a regression until the difference is understood.

A fiducial detector returns more than whether it saw a square. Its payload includes the marker family and ID plus the image-space corners used for pose estimation. Checked still and video fixtures preserve those complete outputs, so a candidate cannot appear faster by dropping a difficult marker or shifting its geometry.

Still workload: 78 difficult field captures preserve 1,368 complete marker outputs; the count describes regression coverage, not accuracy
Video workload: 2,042 consecutive 1280 by 800 robot frames preserve 3,149 outputs across 1,795 frames, with zero to three markers per frame
Target result: in every recorded CM5 trial, at least 95% of detector calls finish within 2 ms on these fixtures; camera capture, pose estimation, and robot output are outside that timing

Algorithms below orchestration

Make each mathematical domain testable without starting the HeliOS runtime.

Frames, masks, contours, geometry, calibration, fiducials, motion, temporal behavior, fixtures, and benchmarks live in focused crates behind a convenient facade. A detector can share coordinate conventions and evidence while remaining separate from scheduling, browser configuration, and robot output.

Product boundary: Eidos is separate R&D and is not presented as a detector currently shipped inside HeliOS
Failure localization: source, mask, contour, and final output views show which stage admitted or lost a candidate
Repeatable comparison: fixture and benchmark crates feed identical inputs to candidate implementations

Recorded experiments and gates

Keep rejected optimization routes as evidence rather than erasing the tradeoff that rejected them.

Candidate sparse-edge, mask, contour, and backend changes are compared for output equality and slow-frame behavior. Accepted and rejected work stays tied to its fixture and machine context, with CM5 validation complementing desktop checks. This makes the R&D path reviewable without converting local measurements into universal claims.

Acceptance order: exact output hashes pass before timing is considered, and small timing changes require repeated interleaved runs
Target relevance: CM5 measurements verify the embedded architecture instead of assuming desktop results transfer
Release status: facade and configuration unification, marker-family independence, image-edge correctness, calibration, and packaging remain blockers

05 / Tradeoffs + limits

What this work does not claim.

Eidos is private, pre-1.0 research. The reviewed detector configuration is not yet the public facade default, so the measured path is not presented as a drop-in library release.

The saved payloads are regression oracles from known field inputs, not a universally labelled dataset or a precision and recall claim.

Performance figures apply to the documented CM5 builds and fixtures. They measure detector time, not camera-to-robot latency or every image format.

Marker-family independence, calibration math, some image-edge contracts, and packaging remain explicit release blockers.

06 / Engineering review

Architecture, evidence, and limits.

Request a demo ↗

Architecture

01
Algorithms separated from orchestration
calibration, geometry, detection, masks, and temporal operations can be tested without the HeliOS runtime
02
Shared mathematical vocabulary
frame and geometry types prevent each detector from inventing incompatible coordinate and image conventions
03
Styx at the input boundary
vision code consumes the same FrameLease used by capture instead of introducing a second product-specific image container
04
Small domain crates behind a facade
consumers can choose a narrow algorithm surface while the full workspace keeps integration convenient

Validation

01
Still-image gate
78 difficult camera captures preserve 1,368 saved marker outputs, including IDs and corners; the count describes regression coverage, not detector accuracy
02
Video gate
a 2,042-frame, 1280 by 800 robot recording preserves 3,149 saved outputs across 1,795 frames; candidates must match the complete payload, not merely the count
03
Target timing
in repeated CM5 trials, at least 95% of detector calls finish within 2 ms on both saved workloads; this measures the detector stage, not camera-to-robot latency
04

Visual fixtures expose the source, candidate mask, and contour geometry so a missed or false marker can be traced to the stage that introduced it

07 / Project consequence

Why it matters in practice.

01Prevents false speed wins by requiring every candidate to preserve the saved marker IDs and corner coordinates before its timing is considered
02In repeated CM5 runs on 1280 by 800 field stills and robot video, at least 95% of detector calls finished within 2 ms, leaving compute time for the rest of the vision pipeline
03Records rejected optimization paths with their correctness and timing evidence, so later work does not repeat attractive changes that fail on the target workload
04Lets image operations choose scalar, SIMD, NEON, or parallel kernels without changing the detector-facing API

My ownership

Workspace architecture
Detector modules
Geometry primitives
Calibration and temporal tools

Built with

Rust
Computer vision
ArUco
Calibration
Image processing