The nice part is that if the motion is in a continous NURBS form, you only have one continous motion, and NURBS can be patched togeter, so a big part can be done in the motion planning stage, ie. precalculated.
think of two straight lines represented by NURBS, the corner can be patched to a radii consistent with the tolerance settings specified, also the speed along the NURB can be included i the representation, so you don't have a separate velocity component. For stuff like trochoidal machining this is NICE ! For a longer run if you want realtime calculations, you can patch together NURBS of different degrees , as long as your motion NURB is atleast of the highest degree of the component NURBS, I am not 100% on this one but I do think so. Also you get consistent handling of lines/arcs/circles/conics and so on .... in an analytical form. It does however get complicated :-D / Lars Segerlund. 2013/7/8 Anders Wallin <[email protected]>: > It is fairly straightforward to plan a trajectory for a *single* segment > (line, arc, nurbs-curve) with limited acceleration/jerk/double-jerk etc. > > It is much harder to come up with an algorithm that blends together *many* > lines/arcs/nurbs-curves and plans a smooth trajectory. Note that it is > always necessary to deviate from the programmed path at the corners between > segments (unless your CAM-program produces c2/c3/c4 continuous toolpaths!). > So there is always a tolerance to be specified for blending. > > Better trajectory control for linuxcnc is a fairly hard problem to tackle. > It's especially hard if we want to support arbitrary kinematics and > feed-override settings. > I think it would be wise to start with only trivial kinematics and no >100% > feed-override allowed. > > Are there software tests for the trajectory controller? If so, has anyone > run them on the araisrobo nurbs-branch (github)? Good tests would make it > easier to develop something new and increase the confidence in new code > before starting to move heavy metal. > > Anders > > > > On Mon, Jul 8, 2013 at 12:11 PM, EBo <[email protected]> wrote: > >> I never ment to imply that NURBS were necessary -- I like them for >> other reasons (like exact representation of conics, splaying the control >> polygon gives you a helix in closed form (read threading in any >> arbitrary axis), is a natural representation produced from 3D models and >> CAD systems, and of course the ability to smooth and analyze them. I >> will take a look at the TinyG firmware for reference, and I am aware >> that there are a number of ways to get to achieve jerk minimization. >> >> Thanks for the TinyG pointer BTW, >> >> EBo -- >> >> On Jul 8 2013 12:51 AM, Alexey Starikovskiy wrote: >> > There is an quite simple algorithm, which is used in TinyG firmware. >> > There >> > is a link to the paper from their github. No NURBS involved. >> > >> > >> > On Mon, Jul 8, 2013 at 1:23 AM, EBo <[email protected]> >> > wrote: >> > >> >> Since I do not have my references handy I thought I would review >> >> some >> >> of the properties necessary to geometrically minimize jerk. I found >> >> a >> >> couple of references online that might make for a good read: >> >> >> >> >> >> Smooth trajectory generation for five-axis machine tools: >> >> >> >> >> >> >> >> >> http://academia.edu/3862221/Smooth_trajectory_generation_for_ve-axis_machine_tools >> >> >> >> So it looks like they are requiring C3 continuity, and uses NURBS. >> >> This might comtinue the interesting debate... >> >> >> >> EBo -- >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> This SF.net email is sponsored by Windows: >> >> >> >> Build for Windows Store. >> >> >> >> http://p.sf.net/sfu/windows-dev2dev >> >> _______________________________________________ >> >> Emc-developers mailing list >> >> [email protected] >> >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by Windows: >> > >> > Build for Windows Store. >> > >> > http://p.sf.net/sfu/windows-dev2dev >> > _______________________________________________ >> > Emc-developers mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
