Right now, the ramp generation algorithm can only start and end at a speed of zero, which limits the use cases to movements that are completely pre-planned. It should be possible to abort a movement mid-ramp and switch to a different speed, or target a different position.

I currently don't know how to best approach this. Supporting this capability would definitely require a redesign of the AccelerationProfile trait.

In addition to the iterator over delay values, add new iterators over velocity and acceleration values. This is mostly useful for debugging and testing, and makes some utility code used by the tests publicly available.

Updates and extends the MotionProfile trait, making it more powerful and flexible. This is a step towards addressing #5.

This pull request leaves Trapezoidal in a bit of a weird state, as it now has a more powerful interface without actually being able to support that. It's no worse than before though, so the previous usage patterns will keep working with the new API. I am going to make Trapezoidal more flexible (and address #5 fully) in a follow-up PR.

This uses a more expensive computation, but I think that's the best trade-off for now. I'm currently working on making the motion profiles more flexible, and I'm running into accuracy problems with the trapezoidal ramp. I think it's better for now to just make it accurate and deal with optimization later (if necessary).

Close #3

What if we want to immediately stop while on motion, and respect the acceleration constraint?

Calling enter_position_mode(0,0) won't work. It will stop the motor abruptly.

The current MotionProfile trait only supports moving to a specified position. There should be an additional interface that allows moving at a specific velocity, without a target position:

pub trait MotionProfile {
    // ...
    fn enter_velocity_mode(&mut self, target_velocity: Self::Velocity);
}

The trapezoidal ramp generation algorithm should already be able to support this, with some minor prodding. In fact, I think velocity mode can be simulated using position mode, by setting a far-away target step:

profile.enter_position_mode(target_velocity, 100_000);

And then making sure to repeat that call often enough, so the target step is never actually reached.

The unit tests use f32, for the sake of convenience (and because it works pretty well on the platforms these unit tests run on). This is fine, but it makes it pretty easy to accidentally introduce trait bounds that are not supported by the fixed-point types, and manual testing is required to catch this.

#4 proposes a testing approach that would address this, but as an intermediate step, it would be fine to have some code that just tries to instantiate the motion profile implementations with each supported type, so we'll at least know at compile time if something breaks.

Currently, the CI build only builds using the default features (i.e. no features, since all are optional). There should be additional builds to make sure the std and libm features build correctly.

The example (which requires the std feature) is also not built.

The current approach Trapezoidal uses is rather naive. It uses the same numeric type for all parts of the computation. This works well enough for floating-point numbers, but requires incredibly large fixed-point numbers to get the required accuracy. There probably are ways to handle this much better. stepgen, for example, uses different fixed-point numbers for different parts of the computation.

The question is how to best implement this in a way that users can still override according to their needs. Especially since choosing the correct fixed-point types can be difficult to get right. So far, this is the best I've come up with:

• Instead of adding multiple type parameters, one for each number type used, add a single type parameter that is bound on a trait that defines the type parameters as associated types.
• Document that trait extensively, explaining how each type is used, and how to choose the right one.
• Provide some pre-built implementations of the type: One optimized for using seconds as the unit of time, another optimized for using timer ticks as the unit of time, one using f32, etc.

The test suite should be run for each provided type bundle. It would probably be best to move the test code to a separate public module under trapezoidal, so anyone defining their own types can re-use the test code.