### Sunday, February 28, 2010

## Repola Computations

[Updated: Attached new images to show more accurately the curve scales. Previous images lacked an accurate 'zero' frame. Also added a 'zoom' image to show spline error up close]

I have made some progress working thru the conversion of linear segments into an N dimensional spline path.

I've created a simulated environment for the RepolaRap XY platform to test some of my ideas out. I created an algorithm curve consisting of line segments of various lengths, and fractally segment it so I get a few quiet areas with long straight segments, as well as some noisy areas with lots of tiny segments.

My goal will be to produce an complete description of every control that must change at each precise moment, and approximate this with spline segments to within as much accuracy as is needed to get an accurate build.

This first image shows the general shape that I've been testing with. The blue segments are simple euclidean line segments, and would represent the output of a G-Code interpreter of all three axes, as well as extruder rate (integrated to get an extruder 'position'), temperature control, fans, and any other special devices that would need to be controlled. Although I assume these are straight linear segments for my simulation, the conversion to splines does not actually require they be linear, only that some function be described that can give its position at some time t.

The red segments in this image represent the spline approximation for the X and Y axis converted into two angles for a two link arm. The simulation allows for distinct pivot arm lengths, but I have assumed they are the same in this image, E.G, that the extruder will be able to reach the exact center point of the build platform.

Mapping the angle positions across time results in the following chart. I have chopped it into the modular domain, rather than extend it beyond the 360 degree motion that actually defines model space. I point out those cases where the apparent branch cuts actually do not exist in the simulated revolutions. As I have mentioned previously, only one axis actually needs 360 degree freedom (the build platform); the radial arm only requires 180 degrees, so no it does not require welding, and no special logic for handling the branch cut is needed.

My next goal is to figure out a way to dilate or compress the time component such that one axis will always move at maximal jerk, acceleration, or velocity. I think this will happen by cutting each spline segment into as many as six segments as different limits are hit. I've included the stock graphs for the equations that will need to be dilated, consisting simply of the first, second, and third derivatives of the angular motions.

I fully expect during extrusion that the extruder will actually arbitrate the majority of time, with the exception of very noisy, very short segments. As I've not yet gotten this logic in yet, it's hard for me to judge yet.

One last image here shows what the spline error tends to look like. This image was generated by finding a region with some error, and zooming into it 100x. This is the first angle area on the right near the top of the path.

I have made some progress working thru the conversion of linear segments into an N dimensional spline path.

I've created a simulated environment for the RepolaRap XY platform to test some of my ideas out. I created an algorithm curve consisting of line segments of various lengths, and fractally segment it so I get a few quiet areas with long straight segments, as well as some noisy areas with lots of tiny segments.

My goal will be to produce an complete description of every control that must change at each precise moment, and approximate this with spline segments to within as much accuracy as is needed to get an accurate build.

This first image shows the general shape that I've been testing with. The blue segments are simple euclidean line segments, and would represent the output of a G-Code interpreter of all three axes, as well as extruder rate (integrated to get an extruder 'position'), temperature control, fans, and any other special devices that would need to be controlled. Although I assume these are straight linear segments for my simulation, the conversion to splines does not actually require they be linear, only that some function be described that can give its position at some time t.

The red segments in this image represent the spline approximation for the X and Y axis converted into two angles for a two link arm. The simulation allows for distinct pivot arm lengths, but I have assumed they are the same in this image, E.G, that the extruder will be able to reach the exact center point of the build platform.

Mapping the angle positions across time results in the following chart. I have chopped it into the modular domain, rather than extend it beyond the 360 degree motion that actually defines model space. I point out those cases where the apparent branch cuts actually do not exist in the simulated revolutions. As I have mentioned previously, only one axis actually needs 360 degree freedom (the build platform); the radial arm only requires 180 degrees, so no it does not require welding, and no special logic for handling the branch cut is needed.

My next goal is to figure out a way to dilate or compress the time component such that one axis will always move at maximal jerk, acceleration, or velocity. I think this will happen by cutting each spline segment into as many as six segments as different limits are hit. I've included the stock graphs for the equations that will need to be dilated, consisting simply of the first, second, and third derivatives of the angular motions.

I fully expect during extrusion that the extruder will actually arbitrate the majority of time, with the exception of very noisy, very short segments. As I've not yet gotten this logic in yet, it's hard for me to judge yet.

One last image here shows what the spline error tends to look like. This image was generated by finding a region with some error, and zooming into it 100x. This is the first angle area on the right near the top of the path.

Comments:

Links to this post:

<< Home

I love these posts!

I have trouble interpreting the acceleration graph though, it seems the green line is off.

I first noticed that the green line is mostly off the zero axis, which would indicate continuous acceleration (in the negative direction) during most of the 'build' which sounds plain wrong. Then I looked closer at the beginnig of the green velocity graph and noticed that it starts with two distinct sawtooth patterns. The derivative of sawteeth would be horizontal line segments, instead the acceleration graph shows triangualr patterns. Is this a bug or do I completey misunderstand?

I have trouble interpreting the acceleration graph though, it seems the green line is off.

I first noticed that the green line is mostly off the zero axis, which would indicate continuous acceleration (in the negative direction) during most of the 'build' which sounds plain wrong. Then I looked closer at the beginnig of the green velocity graph and noticed that it starts with two distinct sawtooth patterns. The derivative of sawteeth would be horizontal line segments, instead the acceleration graph shows triangualr patterns. Is this a bug or do I completey misunderstand?

It's a bug. I normalized each curve individually to the min and max value, which skews the data when you compare the two lines together.

I'll try to get the more accurate 'zero' based graphs (I fixed this yesterday because it was just plain hard to get a feeling for how to do minmax evaluation for each of the graphs without understanding where zero was.) This also allows you to compare the relative scales between the two motors, and make more obvious the position of one motor excludes an entire 180 degrees from it's domain.

I'll try to get the more accurate 'zero' based graphs (I fixed this yesterday because it was just plain hard to get a feeling for how to do minmax evaluation for each of the graphs without understanding where zero was.) This also allows you to compare the relative scales between the two motors, and make more obvious the position of one motor excludes an entire 180 degrees from it's domain.

Okay, added updated images. I changed the fractal model used for testing by making it a bit larger, making one half less busy and the other half more busy.

I also added a zoomed in look to show what spline error looks up close and personal.

I also added a zoomed in look to show what spline error looks up close and personal.

This is really exciting. Respect for blazing a trail in to new territory. You do the community a service.

Post a Comment
Links to this post:

<< Home