# Difference between revisions of "Mathematics"

(→Current (lacking) Solution) |
(→Current (lacking) Solution) |
||

Line 14: | Line 14: | ||

Currently the controller accepts commands of tuples of jerk values for each axis along with a duration. Velocity and acceleration initially start at zero and are maintained between commands. This is good for straight lines with s-curve motion profiles, but to follow a curve tightly many control commands would be necessary, overwhelming the host and the communication interface. | Currently the controller accepts commands of tuples of jerk values for each axis along with a duration. Velocity and acceleration initially start at zero and are maintained between commands. This is good for straight lines with s-curve motion profiles, but to follow a curve tightly many control commands would be necessary, overwhelming the host and the communication interface. | ||

− | Commands are queued to | + | Commands are queued so that they can be executed back-to-back. |

== Possible Solution == | == Possible Solution == |

## Latest revision as of 08:49, 3 September 2018

## Requirements for the Controller

- The head has to be moved along a given curve. Currently the curve consists of segments of lines, clothoids and arcs. Later on they may also be described by Bezier-Splines/B-Splines/NURBS.
- The movement speed is independent from the parameterization of the curve. Most of the time the head is required to move at constant |v|, but it also accelerates/decelerates.
- Head movement has to be continuous in position, speed and acceleration and bounded in jerk. The source curves are at least
**Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle C^2}**. - The path the head is moved along should not deviate from the given curve by more than 0.01mm, total range is 300mm. So an accuracy of
**Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle 10^{-5}}**is striven for. - The velocity of the head should not deviate by more than
**Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle 10^{-4}}**, the acceleration has to be continuous and bounded, the jerk only has to be bounded. - The motor controller is implemented in an FPGA and communicates with the host via UART.
- Required step frequency up to 6 MHz, FPGA running at 20MHz.
- The solution should accommodate multiple kinematics, like cartesian, corexy, delta and polar.

## Current (lacking) Solution

Currently the controller accepts commands of tuples of jerk values for each axis along with a duration. Velocity and acceleration initially start at zero and are maintained between commands. This is good for straight lines with s-curve motion profiles, but to follow a curve tightly many control commands would be necessary, overwhelming the host and the communication interface.

Commands are queued so that they can be executed back-to-back.

## Possible Solution

If the controller would implement a 5th order polynomial, each control command would consist of a tuple of (jerk, snap, crackle) per axis and a duration, while again velocity and acceleration start at zero and are maintained between commands. This would allow the controller to control the movement of the head up to jerk, while approximating the curve with a 2nd order path. The resulting motion would be continuous up to acceleration, while between segment jerk, snap and crackle can jump.

To derive the parameters one would partition the curve into segments, calculating position, velocity and acceleration on start and end point. These 6 values determine exactly all parameters and ensure that the resulting path is **Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "https://en.wikipedia.org/api/rest_v1/":): {\displaystyle C^2}**
.

The segments could be evenly spaced in terms of arc length or varied depending on the sharpness (change of curvature) of the curve. This is very easy for lines, arcs and clothoids as they are already parameterized in arc length, whereas for splines it would be necessary to approximate the arc length numerically.

Note that the source curve is two dimensional, while the controller commands are per axis. Velocity and acceleration information are provided seperatly.

One advantage of this solution is that there is no curve fitting necessary, because at the end of each segments the exact values of position, direction, velocity and acceleration are met.