Hi Anders, Thanks for your feedback! I'll try to address your comments here:
*NURBS Planner:* I took a quick look at their code. It looks like have have both a NURBS implementation and a limited-jerk planner. I just sent them an email to see what their status is. Maybe they can give this effort a boost! * * *Kinematics / Mapping*: For now I'm just looking at trivial kinematics (i.e. assume all axes are linear and orthogonal), since it covers most use cases. The variety of machine configurations out there probably makes a one-size-fits-all IK implementation tough. I have some experience with closed-form IK for robots with up to 6DOF, so this is one avenue we could go down in the future. One possibility is ikfast, which makes closed-form IK solvers in C++ for an arbitrary robot configuration: http://www.openrave.org/docs/latest_stable/openravepy/ikfast/ *Feed Override*: this is a great insight, and definitely needs more thought. While the simplest choice is to just wait until the current queue of moves is done, it sounds like we need almost instant reaction time. I've seen ideas on how to do this, such as multiple parallel queues of moves, but it seems like it should be simpler than that. My gut feeling is that it's easy to go slower, but going faster than planned would be very disruptive. The obvious answer is to always plan for maximum speed (i.e. at 200% feed override), then execute it slower as needed. If we can avoid having to re-do the optimization, then the response could be pretty fast. *Blending: *I agree about your blending insight. The good news is, if my math is correct, we can use the same linear velocity blend being used now. Thanks! Rob On Sun, Sep 29, 2013 at 3:16 AM, Anders Wallin <[email protected]>wrote: > 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 > ------------------------------------------------------------------------------ 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
