CauldronDevelopmentLLC / CAMotics

Open-Source Simulation & Computer Aided Machining - A 3-axis CNC GCode simulator
Other
602 stars 138 forks source link

Shank and Rapid Collision Detection #358

Open amunchet opened 2 years ago

amunchet commented 2 years ago

I'm a newcomer to this project - excellent work.

I am very interested in having shank and rapid move collision detection. Since this is of interest to our company, we would gladly sponsor development on it.

I'd also be willing to give it a crack myself. Many moons ago, myself and a graduate student created something similar on a much smaller scale (there was a specific problem we were trying to solve).

Could a kind soul point me in the right direction as to which files I should be looking at? In our crude system, we had a 3 dimensional array that represented the block's current state which we checked against if any portion of the shank was presently intersecting with. For rapids, I think we polled it every tolerance amount to see if there was a collision.

I would imagine that any cutting move (or motion move) updates the state of the "block" and any collision detection could be done at that point.

Any pointers are greatly appreciated - and any developer interested in being sponsored for this feature, please email me at my github username AT gmail DOT com.

Thanks!

jcoffland commented 2 years ago

Rapid collision detection is fairly easy. The simulation is the same except you ignore all but the rapid moves. I've also considered shank collision. As long at the shank can be modeled as a combination of a few primitive shapes (sphere, cylinder, cone, cuboid, oblong) the simulation is already well supported by existing CAMotics code. The other part of collision detection is what move collided with a point in the workpiece first. If a cutting surface collides first then there's no problem. This could be solved by ensuring the tool path segments are ordered in time. Note, that we don't compute collisions with every tool path segment and every point in the workpiece. That would be too expensive. We only look at tool path segments which are close enough to possibly collide with the point in question.

Are you also interested in modeling fixtures and/or the spindle and collet and detecting collisions with these?

The work would involve:

  1. Adding support for defining the shape and position of shank relative to the tool in the user interface.
  2. Reading and writing the description of the shank to/from CAMotics configuration files.
  3. Modifying the code to also run collision detection with the shank and rapids.

I'd be happy to do this work if the funding was sufficient. Feel free to email me directly to discuss this possibility. joseph@cauldrondevelopment.com

amunchet commented 2 years ago

(Thank you for taking the time to reply).

I believe simulation of rapid moves would need to take into account the current part's machined state (so if material had already been removed from an area, that area would be safe to rapid into).

I recall combining the spindle and tool holder/collet into the "shank" assembly for ease of collision detection (as you said, those can all be primitive shapes without issue). Fixture modelling isn't as much of a concern for me at the moment, but it would be neat to have.

With the issue of when the collision occurred, I recall letting the shank assembly acting as a cutting surface and simply changing the colour of the block in the areas where it cut - I also think I set a flag to let the user know a collision occurred. I think this made is much easier to determine if a lateral collision occurred, as well as axial. With the colour change it was easy to diagnose (and used existing code) instead of having that very expensive calculation - setting the flag ensured that the collision point wasn't cut by a later part of the toolpath and missed.

I'll leave the technical discussion here and email you about the sponsorship privately if that's okay?