New direction on RepolaRap firmware

I'm running a series of timing/space tests on my Arduino Mega to get an idea of speed / performance. On the Arduino Mega:

0.3 ms to perform forward kinematics for the X+Y RepolaRap platforms.
1.1 ms to perform inverse kinematics for the X+Y RepolaRap platforms.

I'm pleasantly surprised; all numbers and calculations used double precision floating point; forward kinematics requires standard arithmetic, cos, and sin. Inverse required additional atan, acos, sqrt, and lots of messing ifs and thens.

I'm rethinking the architecture based on these measurements. I may push the polar calculatinos right into the firmware, and use the existing GCode protocol firmware.

I can't get an exact measure on code size, with serial comms, my test program, and the kinematics, the code consumes 7K code space.

I'm going to play around for another week or two and see what I can come up with - I'm going to test the performance of integer step splines and see how that compares.

How repeatable are your timings over a range of values ??

Some software floating point algorithms take different amounts of time depending on the value they are presented with ??

Given that Gcode is essentially Cartesian is it work considering some form of lookup table arrangement or hybrid lookup table arrangement, generated to match a target Cartesian resolution ?? Must admit I have'nt properly thought this one through and dong so might answer the question in advance.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> How repeatable are your timings over a range of
> values ??

I hadn't spent much more time on this. I'd guess there could be some variation. I ran it thru the same coordinates, rather than stepping.. Still, that is quite a bit of overhead if I want to get to 8cm/s; using full stepping, I need to achieve ~400 steps per second to get this with current setup. That doesn't leave much margin of error if I have to compute forward or inverse kinematics for every step.

I'm going to spend a little more time coding and timing the spline curves; it is a much more elligant solution, as it allows all motor accelleration, delay, timings, etc. to be built into the splines itself; almost everything can be precomputed on the host; the firmware would only need execute the spline (4 long additions per axis, plus a compare to decide whether to step or not.) For spline computation, I have the code already in C#; it's just a simple matter of porting the step portion to C/C++, and adding a module to the C# to generate data that I can feed to the spline firmware.

I think I want to get the platform to the point where I can measure precise positions, either via feedback, or careful measuring and just ignoring (minor) belt slip. Then create code to draw a large 100x100 grid of squares 1mm to the side, drawing each square (rather than drawing the grid lines directly, I want to increase the amount of data to process to every mm of movement.) I'll stop writing code when I can compute faster than I can print, whether computations done in firmware or on host.

I think it's going to look really cool drawing that grid on this machine, BTW. I'm looking forward to making that video.

Okay. I've run the timing tests for stepped splines.

I originally tested using int64_t computations for position and velocity; It added ~2K in code, and the overhead, compared to a 48 bit hand coded addition algorithm, was ~10x slower; I suspect gcc uses function calls rather than inlining the instructions (8 adc instructions seems more than adequate, but I did not take a look at the assembly to see what GCC was doing.)

My next steps on firmware front:
1. add protocol to allow transmitting splines to firmware.
- I've talked about making this a 'forth' like syntax. I think I'm going to back off of this for the time being; KISS, and all that.

2. Add protocol to reset and home all motors.

3. Hook stepper drive to step spline output.


Main loop on firmware will be extremely simple; I'm guestimating an overall loop rate of 2000-5000 per second, which should be adequate to drive all steppers at at 100-150 RPM or higher. Hopefully, this translates into a fast enough print speed for the majority of area on my RepolaRap...


For those interested, here's the data structure for the stepped spline:

struct CubicStepSpline
{
uint32_t positionFrac;
uint32_t velocityFrac;
int32_t accelerationFrac;
int32_t jerkFrac;
int16_t velocityUnit;
int16_t positionUnit;

CubicStepSpline( int64_t position, int64_t velocity, int32_t acceleration, int32_t jerk );
int16_t get_Position() const { return positionUnit; }
void Step();
};

The Step function simply does:

position += velocity;
velocity += acceleration;
acceleration += jerk;

The numbers use 32 bit fixed point representation; which means, to return the position value, you return the top 16 bits of the 48 bit number.

To translate this to stepper motion, I'll just record the current position of each stepper, the target position in the stepped spline, and incrementally step until the two numbers match. Once all steppers match, I'll advance all splines to the next position.

I find this appealing because computing the next spline takes time. That time translates to delay between motor steps. The splines may need to step several times to translate to a single step on a motor. The host can compute a specific position/velocity/acceleration/jerk profile. Knowing the average 'main loop' time, hardware capabilities, etc. should allow the profiles to approach hardware limitations without crossing them, I.E, accelerating thru corners (acute angles would slow down more than obtuse angles, for example). I'll look forward to see if this actually becomes a reality.