Closed lromor closed 2 years ago
Very nice, the hard deceleration now is completely gone just looking at the make test-html
output.
It does seem to accumulate some slight rounding errors along the way, most noticeable in this spiral cut example, in which the new machine path (colored) slightly deviates from the gcode path (solid thin line) at the end of the travel.
Old | New |
---|---|
![]() |
![]() |
Slightly easier to see in this direct comparison
I think we need some unit test that test this with
(Axis-X, Axis-Y)
we have a segment sequence of (2,1), (1,2), (2,1), (1,2)...
and possibly also a test with just one step like in the previous test case (1,0), (0,1), (1,0), (0,1)...
You might now need to re-base this pull request to incorporate the planner test changes.
Merging #44 (9485d25) into master (6b2d27a) will increase coverage by
0.86%
. The diff coverage is98.24%
.
@@ Coverage Diff @@
## master #44 +/- ##
==========================================
+ Coverage 44.34% 45.20% +0.86%
==========================================
Files 38 38
Lines 4122 4174 +52
==========================================
+ Hits 1828 1887 +59
+ Misses 2294 2287 -7
Impacted Files | Coverage Δ | |
---|---|---|
src/planner.cc | 81.87% <98.23%> (+5.80%) |
:arrow_up: |
src/machine-control-config.cc | 77.46% <100.00%> (+0.32%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 6b2d27a...9485d25. Read the comment docs.
Has you suggested, let's add another test checking the behavior for different planning buffer capacities.
With this change, the test with the square that is compared with single-segment lines vs. multi segment lint
Is now properly accelerating and starting to decelerate in the middle. However, wouldn't we expect the speed profile now be exactly the same ? From the visualization it looks like that the small-segment version accelerates and decelerates quicker, leaving a longer stretch of fast movement ("yellow") in the middle. It looks like the postscript output has the same color/speed legend, so what is different ?
With this change, the test with the square that is compared with single-segment lines vs. multi segment lint
- One-segment lines square-moves-direct.gcode
- Multi segment lines square-moves-small-segments.gcode
Is now properly accelerating and starting to decelerate in the middle. However, wouldn't we expect the speed profile now be exactly the same ? From the visualization it looks like that the small-segment version accelerates and decelerates quicker, leaving a longer stretch of fast movement ("yellow") in the middle. It looks like the postscript output has the same color/speed legend, so what is different ?
I made a small python utility to compare the speed/steps plots of two gcode strings, these are the results for the two ways of doing a straight line:
They seem to nicely overlap. I guess gcode2ps doesn't really interpolate the colors based on the speed. It must be doing some linear interpolation if a single segment is provided (instead of using the sqrt function). This is not true for the simulation backend.
Hi Leonardo,
I have been busy redesigning our larger motion control system and have not been able to actively follow your acceleration stuff.
Is this ready for testing on actual hardware or are you still working on the test code? I can give it a spin on my hardware when it’s ready and give you feedback on how it physically looks.
Regards, Hartley
From: Leonardo Romor @.> Sent: Saturday, April 2, 2022 4:28 AM To: hzeller/beagleg @.> Cc: Subscribed @.***> Subject: Re: [hzeller/beagleg] Added simple test that ensures accelerations constraints are met. (#44)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
With this change, the test with the square that is compared with single-segment lines vs. multi segment lint
Is now properly accelerating and starting to decelerate in the middle. However, wouldn't we expect the speed profile now be exactly the same ? From the visualization it looks like that the small-segment version accelerates and decelerates quicker, leaving a longer stretch of fast movement ("yellow") in the middle. It looks like the postscript output has the same color/speed legend, so what is different ?
[square-moves]https://user-images.githubusercontent.com/140937/155919856-bd69dbe5-71b8-475f-8ce8-84e362b1cd50.gif
I made a small python utility to compare the speed/steps plots of two gcode strings, these are the results for the two ways of doing a straight line:
[image]https://user-images.githubusercontent.com/1597330/161380891-eb960636-6ab0-49bd-aefa-d5e4a46d8eb9.png
They seem to nicely overlap. I'll try to dig deeper.
— Reply to this email directly, view it on GitHubhttps://github.com/hzeller/beagleg/pull/44#issuecomment-1086619853, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAMSUIN47QY2OTHHK7EPXMLVDAVM3ANCNFSM44BUV6QA. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>
Is this ready for testing on actual hardware or are you still working on the test code? I can give it a spin on my hardware when it’s ready and give you feedback on how it physically looks.
Yes, the improved acceleration/deceleration code should be ready now.
Lines with many small segments (such as circles or arcs) that previously would result in an abrupt deceleration at the last segment, are now starting to decelerate early enough to meet deceleration constraints. I've run it on an actual machine and its moves and deceleration are smooth.
Code is slightly slower than before because of more calculations, but that only really shows in direct performance comparisons without a physical machine attached and shouldn't impact real-world speed (though we have it on the TODO list to see what can be improved).
The install document also has been updated to describe how to install BeagleG on a current Beaglebone Debian image.
Looks like there is a conflict in one of the files; the last change in the file was in #47 - maybe things got messed up in working in two branches ?