[suggestion] Collision detection

[ES-Alexander]

This could be varying degrees of difficult depending on how it's approached, but it seems like a valuable feature for any kind of tool-path generation software.

My personal preference would be the codebase being refactored such that everything stems from a base Machine class, which has 3D Printer as a sub-class, and 3D printer types can have specified frame and bed geometries, and get initialised with a particular nozzle. The tool-path generation and plotting could both be handled by the selected machine, which should simplify plotting different types of machines (and animations once that's relevant) and should also simplify the logic for when a collision could occur (because e.g. a cartesian printer will have some different collision opportunities compared to a delta or polar printer).

That said, I'm sure it's also possible by adding a more general collision detection module into the existing functionality-focused abstraction.

[AndyGlx]

This is definitely a good addition! It might be good to implement it in gradually increasing complexity:

1. Checking for intersections between the toolpath and cuboid blocks - maybe one representing the whole printhead and one or two representing everying above the print head (rails, etc.)
   • useful for printing multiple parts
   • it's simple maths (if any point of toolpath has xyz values between the min/max xyz values of these cuboids)
   • cuboids defined by simple user input
2. The above plus a simple model of the nozzle (e.g. truncated cone + cylinder)
   • useful to check if the nozzle or printhead collides with the current part (for nonplanar printing mostly)
   • still simple maths but a little more complicated and more info required from user (alleviated if we make assumptions for them)
3. Increasingly complex versions where a CAD model of system components (e.g. STL files) could be imported and intersections between toolpath points and CAD data are checked
   • required a fair bit of set-up potentially
   • could be slow (fine initially)
   • logically worth encorperating this into animation previews of the overall procedure (robot pose, etc.)

The code-base refactor is kinda waiting to see how flexible it seems FullControl should be (based on what people are using it for). If its most valuable for toolpath generation of new and unique systems, then the structure needs to be simpler and more accessible to people who will change it (e.g. new axes, new tool concepts, new stuff we can't predict...) - ideally even if they don't have much python expertise or software engineering experience. Whereas if it's really focused on extrusion 3D printing, or more generally path-based 3D printing, or path-based stuff like plotting, then it may be more acceptable to somewhat focus on enabling those applications at the expense of simplicity. But overall your suggestion doesn't contradict anything we're currently considering. And importantly, any code developed for the collision stuff will easily translate regardless of the refactoring.

[ES-Alexander]

A couple of ideas that may be relevant to implementing this efficiently:

1. Signed distance functions
   • Potentially (significantly) more efficient than checking the mesh triangles, assuming the design path is known
   • For an existing mesh it may be possible to approximate with some easily queryable geometry, but efficient (arbitrary) shape-fitting is hard, especially in 3D
2. Bounding volume hierarchy
   • Useful for reducing the parts of the design/mesh that need to be checked in detail
   • Layer based designs could also be split along the layer axis, which definitely simplifies the progressive tracking side of such designs
   • I'm yet to think of a performant mechanism for adding a sequence of many extrudates to an existing hierarchy (like for an extrusion-based 3D lattice or similar), although adding them as new volume hierarchy leaf nodes or by expanding the nearest one to enclose the extra volume, with occasional re-determination of the hierarchy (like re-balancing a tree with amortised cost), may be a sufficient compromise

[fullcontrol-xyz]

FYI I've been working a lot with 6-axis robot arms over the last year and will be getting them into FullControl at some point. Collision detection will be even more important for them, so it would really to bee to give this as generic functions. You are implying in your comment, I'm just reiterating for clarity. We've been thinking about simple collision detection stuff there too and also thought distance functions would be good as a simple first-check. The centres of all 6 robot joints are known for each point in the toolpath and their approximate size. So this can be checked against the current toolpath. The scales are such that there's no need to consider a meshed previous of the toolpath. A simple distance check between all lines in the toolpath to a given point, and the robot joint positions at that point is already extremely valuable.

My thinking is to get an as-simple-as-possible solution up and running for the most basic checks, which are still extremely valuable, and then go from there.