LinuxCNC S-Curve Accelerations
19 Jun 2021 21:41 #212442
by arvidb
Replied by arvidb on topic LinuxCNC S-Curve Accelerations
I've done a preliminary integration of my code into LinuxCNC now. It's published
here
, in the branch "smooth1d".
Anyone interested in testing it, please read below!
Some safety notes
Bugs in the planner code can make your machine run away in ways that will neither produce a following error nor trigger soft limits! Make sure your machine has hardwired limit switches, or can tolerate running full speed into its end of travel!
For the same reason, please don't insert any part of yourself into the machine while running this code in its current state.
Things to test:
Known bugs:
Anyone interested in testing it, please read below!
Some safety notes
Bugs in the planner code can make your machine run away in ways that will neither produce a following error nor trigger soft limits! Make sure your machine has hardwired limit switches, or can tolerate running full speed into its end of travel!
For the same reason, please don't insert any part of yourself into the machine while running this code in its current state.
Things to test:
- Does the code compile and run? -- You must install a Rust compiler - see instructions for your distro. (This usually involves downloading and running the rustup script.)
- Does the new planner make a noticeable difference?
Note that I've only replaced the joint jogging planner, so you should get jerk-limited jogging while the machine is unhomed, and the usual constant-acceleration jogging after the machine is homed. (I think this is how it works?) - Does homing work as expected?
Due to the way simple_tp (the constant-acceleration planner) is entangled into the LinuxCNC code, I had to do some rather brusque code cutting in relation to homing, and this needs to be tested.
-- If you are using a joint.N.jog-accel-fraction HAL pin, you need to comment that out since "acceleration fractions" are no longer needed for jogs, so this pin has been removed.
-- At the moment this code will only compile on PREEMPT systems, not on RTAI.
-- Don't forget to checkout the smooth1d branch before compiling.
-- Please run linuxcnc from the terminal so that you can catch debug printouts if you run into any bugs.
Known bugs:
- In some situations, the planner fails to find a solution and stops before reaching the intended position. (So some jogs might be shorter than expected.) I'm working on figuring out why. If this happens very often for you, I'd like to know about it.
- The build integration needs a lot of work. (E.g. 'make clean' doesn't work, RTAPI doesn't work, dependency checking doesn't work... and more)
- You will see a lot of debug printouts on the terminal (one long line each time a new target position is requested).
Please Log in or Create an account to join the conversation.
21 Jun 2021 11:26 - 21 Jun 2021 14:35 #212549
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi Arvidb,
Nice work. I will study your code soon !
I found the in-accuracy of the displacement value's.
I was calculating the (total) lenght's and (total) time of acc and dcc path's wrong for the scurve.
After a code modification all output value's seems correct now. The output is double checked with various formula's.
When studying the (new) attached document (paper), i came to the conclusion the used formula's are identical to the paper i first used.
Then i thought, the displacement in-acurracy problem has to have a different origin.
A sample:
a video : user-images.githubusercontent.com/448801...954-a2350cc98fdf.mp4
For download:
1. hal component code with s-curve library as header only lib
2. qt c++ project
github.com/grotius-cnc/S-curve-motion-planning/releases
Nice work. I will study your code soon !
I found the in-accuracy of the displacement value's.
I was calculating the (total) lenght's and (total) time of acc and dcc path's wrong for the scurve.
After a code modification all output value's seems correct now. The output is double checked with various formula's.
When studying the (new) attached document (paper), i came to the conclusion the used formula's are identical to the paper i first used.
Then i thought, the displacement in-acurracy problem has to have a different origin.
A sample:
a video : user-images.githubusercontent.com/448801...954-a2350cc98fdf.mp4
For download:
1. hal component code with s-curve library as header only lib
2. qt c++ project
github.com/grotius-cnc/S-curve-motion-planning/releases
Last edit: 21 Jun 2021 14:35 by Grotius.
Please Log in or Create an account to join the conversation.
21 Jun 2021 16:32 #212560
by BesPav
Replied by BesPav on topic LinuxCNC S-Curve Accelerations
Hi, folks!
Dreaming about smoother movement with LCNC i have found and sucessfully try on Arduino Due this code:
github.com/synthetos/g2
with well-described jerk-controlled motion:
github.com/synthetos/g2/wiki/Jerk-Controlled-Motion-Explained
Are there any chance to recompile and intregrate this math to LCLC?
Dreaming about smoother movement with LCNC i have found and sucessfully try on Arduino Due this code:
github.com/synthetos/g2
with well-described jerk-controlled motion:
github.com/synthetos/g2/wiki/Jerk-Controlled-Motion-Explained
Are there any chance to recompile and intregrate this math to LCLC?
Please Log in or Create an account to join the conversation.
21 Jun 2021 18:57 #212581
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi BesPav,
Do you have a direct link to the math please?
Do you have a direct link to the math please?
Please Log in or Create an account to join the conversation.
22 Jun 2021 09:01 #212657
by BesPav
Hi, Grotius!
I have zipped some planner sources with all those crazy discrete time and differential math, fortunately they have good comments, please check if this is what you wanted.
Replied by BesPav on topic LinuxCNC S-Curve Accelerations
Do you have a direct link to the math please?
Hi, Grotius!
I have zipped some planner sources with all those crazy discrete time and differential math, fortunately they have good comments, please check if this is what you wanted.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
22 Jun 2021 11:40 - 22 Jun 2021 11:44 #212665
by rmu
Replied by rmu on topic LinuxCNC S-Curve Accelerations
you can look at this github.com/rmu75/linuxcnc/tree/rs_6otp for an implementation of the 6th order bezier curve. the discrete diff math is not needed in linuxcnc, cpus powerful enough to run linuxcnc are powerful enough to use floating point and "direct evaluation".
I included a ipython notebook for those who want to play around with the bezier curves. , rename extension to .ipynb
I included a ipython notebook for those who want to play around with the bezier curves. , rename extension to .ipynb
Last edit: 22 Jun 2021 11:44 by rmu. Reason: add ipython notebook with math
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
22 Jun 2021 22:14 - 22 Jun 2021 22:26 #212703
by Grotius
Replied by Grotius on topic LinuxCNC S-Curve Accelerations
Hi,
@ Rmu,
If this linuxcnc repro is working out of the box, wich i don't know at the moment, would be helpfull.
Then a diff to master will tell us what has to be modified for the scurve implemenation.
@BesPav,
There is no real scurve math inside. It looks like they hide it somewhere else.
I am working on a hal component that includes the scurve implemenation.
The user can request values for a certain timestamp. And it also gives other important values.
It is in fact a complete implementation of the first paper i posted before.
I think it will also be usefull to soft start spindles etc.
velocity start=1
velocity end=0
acceleration start=2
de-acceleration end=3 (machine can stop quicker)
A output example with halscope : user-images.githubusercontent.com/448801...a56-f8b83324c0b9.mp4
@ Rmu,
If this linuxcnc repro is working out of the box, wich i don't know at the moment, would be helpfull.
Then a diff to master will tell us what has to be modified for the scurve implemenation.
@BesPav,
There is no real scurve math inside. It looks like they hide it somewhere else.
I am working on a hal component that includes the scurve implemenation.
The user can request values for a certain timestamp. And it also gives other important values.
It is in fact a complete implementation of the first paper i posted before.
I think it will also be usefull to soft start spindles etc.
velocity start=1
velocity end=0
acceleration start=2
de-acceleration end=3 (machine can stop quicker)
A output example with halscope : user-images.githubusercontent.com/448801...a56-f8b83324c0b9.mp4
Last edit: 22 Jun 2021 22:26 by Grotius.
Please Log in or Create an account to join the conversation.
- TheRoslyak
- Offline
- Elite Member
Less
More
- Posts: 238
- Thank you received: 37
23 Jun 2021 08:57 #212724
by TheRoslyak
Replied by TheRoslyak on topic LinuxCNC S-Curve Accelerations
hi arvidb
I start testing your branch "smooth1d".
I seem to have compiled everything correctly. maybe )
But I didn't notice the difference. Can you explain How to configure your function? for Dummies
I start testing your branch "smooth1d".
I seem to have compiled everything correctly. maybe )
But I didn't notice the difference. Can you explain How to configure your function? for Dummies
The following user(s) said Thank You: arvidb
Please Log in or Create an account to join the conversation.
23 Jun 2021 09:18 #212725
by rmu
It is just a few commits, and last I tried it rebased relatively cleanly on master. The math is in the ipython notebook, and there is another thread in this forum discussing the whole thing. github.com/rmu75/linuxcnc/blob/rs_6otp/src/emc/tp/tp.c#L2436 contains a description of the approach. Some familiarity with Bezier curves is expected, wikipedia should do it for starters. In principle it is the same what the tinyG thingy does, transplanted into the "execution" stage of the linuxcnc trajectory planner.
Caveat emptor, this thing is not finished and may explode your machine and/or computer, esp. if you use feed override (which will have very unpredictable effects).
Replied by rmu on topic LinuxCNC S-Curve Accelerations
Hi,
@ Rmu,
If this linuxcnc repro is working out of the box, wich i don't know at the moment, would be helpfull.
Then a diff to master will tell us what has to be modified for the scurve implemenation.
It is just a few commits, and last I tried it rebased relatively cleanly on master. The math is in the ipython notebook, and there is another thread in this forum discussing the whole thing. github.com/rmu75/linuxcnc/blob/rs_6otp/src/emc/tp/tp.c#L2436 contains a description of the approach. Some familiarity with Bezier curves is expected, wikipedia should do it for starters. In principle it is the same what the tinyG thingy does, transplanted into the "execution" stage of the linuxcnc trajectory planner.
Caveat emptor, this thing is not finished and may explode your machine and/or computer, esp. if you use feed override (which will have very unpredictable effects).
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
23 Jun 2021 13:04 - 23 Jun 2021 13:04 #212734
by arvidb
It's quite possible that most people won't notice much of a difference with jerk-limited planning. I think it will have the most effect on heavy machines with a very tight servo loop and where an MPG is used for jogging. How did you test it?
There should be no configuration needed. If the jerk-limited planner is active, you will see debug printouts such as these on the terminal each time a new move is planned:Did you see such printouts? If not, make sure you are jogging in joint mode, since the joint planner is the only planner that I replaced. Once the machine is homed and in axis jog mode, the old planner is still used.
Replied by arvidb on topic LinuxCNC S-Curve Accelerations
Thanks for testing!hi arvidb
I start testing your branch "smooth1d".
I seem to have compiled everything correctly. maybe )
But I didn't notice the difference. Can you explain How to configure your function? for Dummies
It's quite possible that most people won't notice much of a difference with jerk-limited planning. I think it will have the most effect on heavy machines with a very tight servo loop and where an MPG is used for jogging. How did you test it?
There should be no configuration needed. If the jerk-limited planner is active, you will see debug printouts such as these on the terminal each time a new move is planned:
Smooth1d::replan(), state [0.0, 0.0, 0.0, 9.44062555275579], s_target -498.5593744472442, v_limit 30.383333333333333, a_limit 502
Smooth1d::stop(), state [0.0, 0.0, -30.383333333333333, -0.4787863109007038]
Last edit: 23 Jun 2021 13:04 by arvidb. Reason: Spelling...
Please Log in or Create an account to join the conversation.
Time to create page: 0.129 seconds