Advanced Search

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.

Then you should not need any python code use just rules

there is no 3 states only on off because you only have on and off hal output and this can only use a single hal reader

That's a StatusLabel connected to the status channel, not a hal bit pin.  And the logic is in the user_button.py file.

just an fyi why are you destroying the format and look of the ui.. your better than that!

I thought I was keeping the look quite true to your original.  Same background colors, container shapes, borders, padding, etc for everything but the DRO.  I wanted a bigger display for the main DRO and had the real estate.  I even used the exact same halbar color scheme for the axis load indicators as you did on the spindle load bar.

As for format, I've mentioned a number of times (in other threads) I don't want/like any controls in the user interface that can cause physical machine movement.  If I could get rid of the cycle start/stop buttons, jog panel, go-to-home/zero buttons I would... but those are in the base probe_basic.ui files I cant touch without going way off the reservation.

I understand having on-screen control buttons for the ATC and probing - those are just too convenient and would take up a massive number of physical inputs to replicate.

My physical control panel has all the 'standard' controls I need for routine machine operations: start/stop/feed-hold, jog, FRO/SRO/JRO/RRO, spindle control, flood/mist/blast/wash, plus man/mdi/auto mode and a home-all button plus a few undesignated spares.  I like tactile controls and think touchscreens are dangerous... same opinion about modern cars, in fact.

So my compromise is to accept what's in the base ui, but change everything I can to indicators vs. buttons/controls. And get rid of the 'danger' buttons (DRO auto-zero HAD to go).  Your somewhat-recent modification to permit keyboard jog disable was a huge win in my book!

I just pushed the changes to qtpyvcp for the halbutton flash option property in qtdesigner

You rock.  I'll have a go at it tomorrow evening and report back.

here is the flashing stylesheet code:

I just pushed the changes to qtpyvcp for the halbutton flash option property in qtdesigner. it will take it about 20 minutes to build and be available via apt, once you see it pop up in sudo apt update you will have the functionality you can adjust the stylesheet to give you whatever colors you want for the checked state flash primary and secondary colors!

just an fyi why are you destroying the format and look of the ui.. your better than that!

there is no 3 states only on off because you only have on and off hal output and this can only use a single hal reader

and i am adding a flashing property to button widgets because thats a good idea..

 

That's really slick!

Any thoughts on the three-state label I mentioned?

PAUSED state is blinking.

ok yeah this is what you want to do it is much cleaner with no code changes to hack it up, this is existing hal code and the button itself is none functional in the ui essentially becomes a label, you cannot click it or select it or do anything bu observe it physically.

you then just add your net in postgui.hal file and your off to the races!

here is the stylesheet used:

doesn't have to be, you can give it no focus, im tinklering with it now just about have it and it is pretty easy with no code changes and making more of them would be way faster and not require code changes for each instance

Lcvette wrote:

Ok I see now, did you try just using a halbutton? If you just wanted color change I think that would work and be simple. Have to check, but I believe they are bidirectional.
 

No, it didn't occur to me to use a button as an indicator.  And I didn't want an on-screen button or control widget.

Ok I see now, did you try just using a halbutton? If you just wanted color change I think that would work and be simple. Have to check, but I believe they are bidirectional.

As I said earlier, the LED was just a first attempt.  When that didn't work out, I realized a label that acted like an LED could do double-duty and save screen space.

Just so we're on the same page, here are two screenshots of what I've got after Claude created new .py and .qss files



The red one is actually blinking, but you get the idea.

I'm not completely sure about the architecture, but it looks like that python file creates two hal pins per Qlabel instance.  And links the label to a .qss setting via the standard Qt Qlabel's dynamic settings.  Screenshot of the dynamic properties:



The rest of the indicators follow the same process.  Two hal pins are created per label, I link one of the pins in post-gui, set the dynamic properties to a color, and they all work.

I've attached the files in case you're interested in what's backstage.  And I think the status_tab.py was also modified - and is what I'm not supposed to touch (auto-updated when probe_basic.ui is open).

The above is what I was trying to do with HalLabel widget rules, but couldn't.

I agree with Tommy. Pointless adding additional failure points!

I would try and arrange the drives horizontallly as there is a risk the top drives overheat with the heat from the ones below. I have had this happen but at a lot more than 24 volts (which I think is too low, velocity and acceleration are king with plasma and you are limiting yours by the low voltage)