No closed form solution. The develop a cost function and use numeric optimization to find lowest cost. This is what Boston Dynamics does now and they do it in real time.
The idea was first used for process control in oil refineries but it works in any case where the forward comutions is "easy" but the backward one is very hard. Sy you have an "n" dimensional problem, you first write a simulation and then put some guessed values for all n parameters and compute the state at some small "t", typically milliseconds ahead. Then do it again and again for all reasonablevalies ofparameters for several seconds out. You are searching a HUGE space using the forward equations. and doing a MANY step look ahead. The goal is minimum cost at some distant time (like a few seconds. YOu recompute this every cycle. Yes it requires a trillion computations per second, but so what, multi teraflop machines cost only a few hundred dollars today. The magic Google search term is "MPC" In you case the parameters are the speed of the motors and the cost is has close the cut is to the desired shape + how long it takes to cut the metal. "jerk" will just take care if itself. All the smarts is in (1) youe cost funtion and (2) your forward kinetics model. This was developed by chemical plants by today we see Boston Dynamics using it to make robots molve like animalsand we see SpaceX use it to mke falling rockets hit the landing pad. It basicallyturns a very hard inverse problem into a very big search and numerical otimization. It works because optimization is well understood. Tht said, I'd expect machinists would be afraid of this because it does not give an exact solution but only the "best that can be found, given the time limit and compute power available". This is very good if you are a rocket falling from the sky, It does no good to be "perfect" if you are a millisecond late. So a machinest might take some inperation from MPC and turn a a hard inverse case into a large but "easy" search. https://en.wikipedia.org/wiki/Model_predictive_control On Sun, Aug 22, 2021 at 11:51 AM Curtis Dutton <curtd...@gmail.com> wrote: > I have a desire to implement this. > > My business is in need of another cnc router and I will be building as > high speed of a machine as I can afford. It is going to be a dual table but > a horizontal spindle. 1m x 1m working envelope. I plan on using linear > motors. > > It will require jerk limiting to really get the value out of the machine. > > I have been working on bits and pieces in my spare time but I have very > little time right now. > > > My main approach so far is.... > > > The realtime motion component will be enhanced so as to interpolate nurbs > curves. Those curves need be in a specific form of parameterization. (coord > length parameterized) > > > The other part is in user space and it is the hard part. To perform > blending of line segments it converts segments to nurbs curves, and blends > them together by fitting a segment of a clothoid (euler spirals) in between > them. It must do all of this while fitting within all of the velocity, > accel, jerk and limit constraints. Then it reparameterizes these curves for > consumption by the motion component. > > This is essentially plotting a reasonable driving path on an N dimensional > race track. > > From some of the papers that I have read it looks like it will involve > numerical integration and/or linear programming. Adding jerk equations into > standard physics makes it very much harder to solve. Closed form equations > don't really seem to exist. (If you have experience with this I could > sorely use pointers, links, papers) > > > Ultimately this is a very difficult task. Building a stripped down version > of a jerk controlled motion planner is what many people have done to earn a > PHD. > > > I would be happy to join up with anyone else that is interested in working > on this. Even ideas, papers, demos is very helpful. Timeline for this... > sadly a few years at best before completion. > > > Thanks, > Curt > > On Tue, Aug 17, 2021, 10:10 PM andrew beck <andrewbeck0...@gmail.com> > wrote: > > > Here is the text from your link sam > > > > > > Ramped velocity in this case just means constant acceleration over the > > whole segment. This is less optimal than a trapezoidal velocity profile, > > since the acceleration is not maximized. However, if the segment is short > > enough, there isn’t enough time to accelerate much before we hit the next > > segment. Recall the short line segments from the previous example. Since > > they’re lines, there’s no cornering acceleration, so we’re free to > > accelerate up to the requested speed. However, if this line is between > two > > arcs, then it will have to quickly decelerate again to be within the > > maximum speed of the next segment. This means that we have a spike of > > acceleration, then a spike of deceleration, causing a large jerk, for > very > > little performance gain. This setting is a way to eliminate this jerk for > > short segments. > > > > Basically, if a segment will complete in less time than 1 / > > ARC_BLEND_RAMP_FREQ, we don’t bother with a trapezoidal velocity profile > on > > that segment, and use constant acceleration. (Setting > ARC_BLEND_RAMP_FREQ = > > 1000 is equivalent to always using trapezoidal acceleration, if the servo > > loop is 1kHz). > > > > You can characterize the worst-case loss of performance by comparing the > > velocity that a trapezoidal profile reaches vs. the ramp: > > > > # v_ripple = a_max / (4.0 * f) # where: # v_ripple = average velocity > > "loss" due to ramping # a_max = max axis acceleration # f = cutoff > > frequency from INI > > > > For the aforementioned machine, the ripple for a 20Hz cutoff frequency is > > 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is > > only a worst-case estimate. In reality , the trapezoidal motion profile > is > > limited by other factors, such as normal acceleration or requested > > velocity, and so the actual performance loss should be much smaller. > > Increasing the cutoff frequency can squeeze out more performance, but > make > > the motion rougher due to acceleration discontinuities. A value in the > > range 20Hz to 200Hz should be reasonable to start. > > > > Finally, no amount of tweaking will speed up a toolpath with lots of > small, > > tight corners, since you’re limited by cornering acceleration. > > > > On Wed, Aug 18, 2021, 2:06 PM John Dammeyer <jo...@autoartisans.com> > > wrote: > > > > > This is what we're talking about right? > > > Ramping acceleration? > > > https://www.mmsonline.com/articles/understanding-jerk-control > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: Feral Engineer [mailto:theferalengin...@gmail.com] > > > > Sent: August-17-21 6:46 PM > > > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > I'm curious what the current level of block lookahead is on lcnc > > compared > > > > to commercial controls. Anyone know the amount of data buffering that > > it > > > > can handle? > > > > > > > > Phil T. > > > > The Feral Engineer > > > > > > > > Check out my LinuxCNC tutorials, machine builds and other antics at > > > > www.youtube.com/c/theferalengineer > > > > > > > > Help support my channel efforts and coffee addiction: > > > > www.patreon.com/theferalengineer > > > > > > > > On Tue, Aug 17, 2021, 9:36 PM Sam Sokolik <samco...@gmail.com> > wrote: > > > > > > > > > It would be the same setup... Just using servo amps.. Velocity > out > > > of > > > > > the pid - position back from the encoders. > > > > > > > > > > On Tue, Aug 17, 2021, 8:14 PM andrew beck < > andrewbeck0...@gmail.com> > > > > > wrote: > > > > > > > > > > > Not sure Sam. > > > > > > > > > > > > I have a 7i77 on this mill though also. So analog control > > > > > > > > > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik <samco...@gmail.com> > > > wrote: > > > > > > > > > > > > > I am going to ask a stuid question.. If you have a velocity > run > > > step > > > > > gen > > > > > > > with pid. Couldn't you hook a limit3 between the pid and > > steghen. > > > > > > > Because the input is velocity instead of position - wouldn't > the > > > > > > > acceleration limit in the limit3 be jerk instead of > acceleration? > > > I > > > > > am > > > > > > > sure it doesn't work that way.. I was just thinking you have > > moved > > > the > > > > > > > derivatives up one.. > > > > > > > > > > > > > > (I can tell you it doesn't seem to work in practice - probably > > > because > > > > > > the > > > > > > > pid will always try to correct the error. Like maybe you would > > > need to > > > > > > > negate the limit3 amount on the feedback side..) > > > > > > > > > > > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > > > > > > emc-users@lists.sourceforge.net> wrote: > > > > > > > > > > > > > > > I haven't tried it yet, but this looks promising. > > > > > > > > LinuxCNC S-Curve Accelerations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scott H > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph > > Stirling > > > < > > > > > > > > ralph.stirl...@wallawalla.edu> wrote: > > > > > > > > > > > > > > > > I've also been hoping to see this appear in a Linuxcnc > update, > > > > > > > > as it has been worked on by a number of people for years. > > > > > > > > Here are the most recent threads about jerk-limited > trajectory > > > > > > planning: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > > > > > > > > > > > > > -- Ralph > > > > > > > > ________________________________________ > > > > > > > > From: David Berndt [ber...@uberwin.com] > > > > > > > > Sent: Tuesday, August 17, 2021 9:01 AM > > > > > > > > To: Enhanced Machine Controller (EMC); andrew beck > > > > > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > > > > > > > > > CAUTION: This email originated from outside the Walla Walla > > > > > University > > > > > > > > email system. > > > > > > > > > > > > > > > > > > > > > > > > I don't have a great need for it with my machines, or the > > > time/brains > > > > > > to > > > > > > > > implement it. It just seems like a feature we really should > > have. > > > > > > > > > > > > > > > > I'd be willing to participate monetarily in some sort of > > > system to > > > > > > > > incentivize the inclusion of jerk control. Perhaps an > > open-source > > > > > > feature > > > > > > > > bounty? Does the community want to consider that sort of > thing? > > > > > > > > > > > > > > > > -Dave > > > > > > > > > > > > > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > > > > > > > andrewbeck0...@gmail.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > hey guys > > > > > > > > > > > > > > > > > > I am sitting here watching my cnc mill atm its shaking > quite > > a > > > bit > > > > > > > > > acceleration is 600mm/sec2 which is not that high i think. > > > > > compared > > > > > > > to > > > > > > > > > every other cnc mill i have used with a commercial > > controller. > > > > > they > > > > > > > have > > > > > > > > > jerk control and work much better. so looking forward to > > when > > > we > > > > > get > > > > > > > > > jerk > > > > > > > > > control here on linuxcnc! > > > > > > > > > > > > > > > > > > but in the mean time i need a poor mans jerk control and > > > thinking > > > > > of > > > > > > a > > > > > > > > > limit on the pid output to chop down the initial > acceleration > > > for > > > > > the > > > > > > > > > first > > > > > > > > > moment in time just so little moves don't shake it to death > > > > > > > > > > > > > > > > > > andy mentioned that I could maybe use a limit component to > > > limit > > > > > the > > > > > > > > > initial acceleration for the first tiny moment in time to > cut > > > down > > > > > on > > > > > > > the > > > > > > > > > vibrations. > > > > > > > > > > > > > > > > > > how do you guys think that could work? > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Emc-users mailing list > > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc- > > > > users&data=04%7C01%7Cralph.stirling%40wallawalla.edu > > > %7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8de > > > > > > > > > > bfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > > > > > > > > > > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Emc-users mailing list > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc- > > > > users&data=04%7C01%7Cralph.stirling%40wallawalla.edu > > > %7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8de > > > > > > > > > > bfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > > > > > > > > > > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Emc-users mailing list > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Emc-users mailing list > > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Emc-users mailing list > > > > > > > Emc-users@lists.sourceforge.net > > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Emc-users mailing list > > > > > > Emc-users@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Emc-users mailing list > > > > > Emc-users@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > > _______________________________________________ > > > > Emc-users mailing list > > > > Emc-users@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > > > > > _______________________________________________ > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
