A follow-up on **FabScan**, the LinuxCNC camera tracing/digitizing project I posted about earlier.
FabScan has now reached:
**v0.6.0-alpha.1**
Project:
github.com/FabLabRacing/FabScan
I am definitely not calling it finished, but I think it has crossed an important enough milestone to call it an alpha and, more importantly, to start asking the open-source community for help improving it.
## What Changed
The biggest change since my original post is the tracing architecture.
The earlier versions were basically:
detect local line
→ calculate correction
→ move
→ repeat
That worked surprisingly well on simple geometry, but corners eventually exposed the limits of that approach. I spent quite a while developing various versions of "Corner Assist", but eventually concluded that I was trying to solve an architectural problem with more special-case logic.
The current v0.6 approach is closer to:
Camera / perception
↓
Persistent world-space path belief
↓
Connected-path prediction / look-ahead
↓
Planner
↓
Controller / safety
↓
LinuxCNC motion
The design principle that came out of that work is:
**Detectors observe. The model remembers. The planner decides. Motion executes.**
FabScan now tries to understand and follow the connected continuation of the profile rather than simply reacting to the latest local line fit.
## Record/Replay and Simulator
A fairly substantial development framework grew out of trying to debug the follower.
FabScan can now record complete physical tracing runs, including camera frames, calibration, planner state, motion, and diagnostics, then replay those runs deterministically.
Replay was extremely useful, but it has one unavoidable limitation: once a new planner chooses a different path than the old one, there are no recorded camera frames from that new location.
That led to an SVG ground-truth simulator using the exact A-G test geometry.
The simulator runs the real FabScan perception, estimator, and planner against a virtual camera that can move wherever the planner chooses. It also includes measured camera appearance, observation delay, and the actual configured motion limits from my LinuxCNC table.
That has become one of the most useful development tools in the project.
## Latest Real-Machine Result
The current hardest test geometry is shape **G**, which contains straight sections, tabs, a 45-degree corner, a radius, and several sharp direction changes.
The latest physical run completed:
**800 / 800 planner steps with no HOLD**
It stopped only because Count was set to 800, about **0.738" short of completing the loop**.
Some comparison numbers:
M5.6 simulator full path: 21.5182"
M6.2 physical implied path: 21.5091"
Physical RMS error vs SVG: ~0.00446"
87.6% of path within: 0.005"
96.4% of path within: 0.010"
LinuxCNC itself followed the requested coordinated XY endpoints very closely, with an average endpoint miss of about **0.00045"**.
The remaining larger errors are concentrated around a few sharp vertices where the planner begins turning slightly early.
That is encouraging because the problem is becoming very specific rather than looking like general path instability.
## Where Help Would Be Useful
The biggest current planner question is how best to distinguish:
**continuous curvature / a radius**
from:
**a true sharp connected-path vertex**
For a radius, normal look-ahead following should continue.
For a true corner, I think the planner needs to recognize it, commit to the actual vertex, finish the incoming leg, then latch onto the outgoing leg.
Other areas where ideas or contributions would be welcome include:
* state estimation / Kalman-style approaches
* connected-path association and branch scoring
* confidence models
* machine vision
* diagnostics
* eventual continuous/velocity-based following
* LinuxCNC integration
## HISTORY.md
I added a `HISTORY.md` file to the repository specifically for anyone interested in the development side of the project.
It is a bit longer than the normal documentation, but I think it is worthwhile reading before digging into the planner because it explains **why the current architecture exists**.
It covers:
* the original local follower
* the Corner Assist experiments and why that approach was abandoned
* the move to persistent path state
* why record/replay was added
* why replay eventually led to the simulator
* what the simulator is intended to prove
* what the first physical tests exposed
* the A-G test geometry
* simulation vs real-machine results
* the major open design questions
There is also a condensed decision tree showing how one development problem led to the next.
I am hoping that gives potential contributors enough context to avoid having to reverse-engineer months of experiments from the commit history.
## Alpha Status
The safety philosophy has not changed.
FabScan only commands controlled X/Y tracing motion. It does not control Z, the torch, spindle, THC, Cycle Start, or any cutting process.
The real-machine follower is still deliberately conservative and uses bounded coordinated moves with independent safety checks and HOLD behavior when it cannot identify a continuation it trusts.
I am calling this **alpha** because I think the basic architecture has now been validated well enough in simulation and on the real machine that outside review would be genuinely useful.
If anyone has experience with LinuxCNC, machine vision, robotics, controls, state estimation, path planning, OpenCV, or simply sees a better way to approach part of the problem, I would appreciate comments, criticism, testing, ideas, or pull requests.
The goal is still pretty simple:
**A practical open-source LinuxCNC camera tracing tool that can capture real shop-floor geometry and produce useful DXF without trying to become a CAD system or machine controller.**
It is not finished yet, but I think it is getting close enough to be interesting.
