I was aiming for a smooth transition for one of my Arduino projects, the first tool for that is the ramp library. While the library itself is quite nice, I miss some more comprehensive documentation of it.
Working principle
Ramp is meant to be used with motors, like servos, to ease up the start and stop, and having less stress on the parts, make more pleasant movements.
With ramp, you specify a target value to reach, and the time should take to get there. Ramp will calculate the actual value you should be in while the time is passing by.
Problems
The first problem in my reading, that ramp should not know the time on it’s own, it would be better if it was passed to it, e.g. “calculate the current position to me, if the current time is 120ms!”. Or maybe just send ramp the current percentage of the journey, as we might not use the calculation on time basis. This would give a more clear way of the job. Finally I found the “no-automation” mode, that I will explain later.
The second problem is, that all motors (contraptions) has their acceleration limit. The motor might not be able to keep up with the expected (calculated) values.
Bug
I have created a test program for that, it goes from 0 to 255 within 5000 milliseconds in 100ms steps and repeat this with LOOPFORWARD. Thus, we should have 50 steps.
The first interesting observation was just here, as we made 50 steps for the first loop, but 49 steps any further iterations. After some digging, I figured out, that this is a bug with LOOPFORWARD and I have created an issue with that: https://github.com/siteswapjuggler/RAMP/issues/26
Interpolation modes
The first question starting on ramps might be, which interpolation mode to use. I have generated a visualization with a test program and utilizing LibreOffice Calc. The graph below shows one raising session for all interpolation modes.
Here you can see another graph, this time both IN and OUT are interpolated with one full cycle of FORTHANDBACK.
Note, that some interpolations do overshoot, this is intended to be so, but you must take care on that, if you want to use them. E.g. if you are using 8 bit unsigned integer (aka. char) to store the value, it will overflow.
Grain
Now, grain is a phrase not very well described. Grain is a time span in milliseconds. The idea behind it (in automated mode) is to spare calculating the value if “grain time” was not passed since last call.
While grain itself is proper, it has drawbacks. As you can also see in the graphs, sometime the change of the value is quite fine, it would require smaller grain-time to achieve a nicer curve. But that would require the grain to be altered dynamically. Further more the grain should be altered by the interpolation, that would complicate things.
Non-Automated mode
Again, This mode is not very well documented. The idea here is to not let Ramp to figure out the time difference, but Ramp will assume “grain time” was passed since last update() call.
This is very useful if you already utilized some time-keeping in your project.
There is only one thing to keep in mind using non-automated mode: go() is already step no.0 and further update() calls will always assume grain time was passed since the last step. (Meaning first update() call will assume grain time was passed since go() was called.)