On Sat, Sep 28, 2013 at 10:31 PM, Robert Ellenberg <[email protected]> wrote:
> Hi All, > I'm a grad student working on trajectory planning for robots. While > doing some fine-detail work using LinuxCNC on a mini-mill, I've bumped up > against the feed rate limitations due to small G-Code segments. Since this > kind of thing is my area, I wrote up a proposal to improve speed through a > longer queue and lookahead, linked here as a PDF: > > > https://www.dropbox.com/s/p1g1zbwmviv5cn7/LinuxCNC%20Lookahead%20Proposal.pdf > Hi Robert, Thanks for the proposal, I'll try to read this with some thought later. I did some initial work on documenting the current motion planner on a wiki page you might have seen: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_Tp_Notes there is no good documentation on the blending algorithm used AFAIK. Historically there was another motion planner developed for EMC, but for some reason it was not adopted. http://emc.cvs.sourceforge.net/viewvc/emc/emc/doc/segmentqueue.pdf this may be more or less closely related to this thesis: https://circle.ubc.ca/handle/2429/11855 There is also much more recent work on a NURBS planner: https://github.com/araisrobo/linuxcnc Writing some trajectory planner tests to actually say something quantitative about the different implementations would be a good thing. I'm not an expert on motion planning, and whenever I read papers in the area there are a few questions that puzzle me: - mapping between joints/axes, i.e. kinematics. In LinuxCNC-terminology joints are actuators (i.e. length of a leg on a hexapod). Trajectory planning for trivial kinematics (one joint == one axis, axes=XYZ) is fairly straightforward. But do we want any new trajectory planner to work on hexapods etc. with funky kinematics? - Feed override. In the current implementation feed-override (a percentage between 0-200%, upper limit might be something else also) gets applied almost immediately. For example if we are in the middle of a long G1 segment and the user dials down the feed override to 50% the machine will decelerate to 50% of programmed speed in the middle of a move. How is this going to be implemented when we have a lookahead queue 100-segments deep? The current speed and acceleration we want to use then depends on all the segments in the queue. What happens when the user changes feed-override? Can we allow >100% feed override? I'd like to emphasize that (IMO) the hard part of this problem is really the motion blending, i.e. when we decide to deviate (by given tolerance) from the G-code programmed path in order to keep up the speed of the machine. Writing an "exact stop" trajectory planner, or one where only C2-continuous (continuous tangents and curvature) segments are blended together using any of the mentioned strategies (NURBS, 'bang-bang' jerk or double-jerk, sine-pulses, etc, etc) is fairly straightforward. Anders ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
