Some useful features

Here are some features that we had to implement on the external microcomputer and would be great to have in the RoboteQ instead.

1. Do you have plans for adding exp() function? When you've added basic trigonometry it allowed us to get rid of external microcomputers in several projects. We still have couple projects left where the absence of exp() is the only reason we have microcomputer in the system.

2. Analog input filtering. This is big issue for us. Several of the projects have to work with extremely noisy analog data. No amount of shielding did a thing. So, we implemented several software filters that should not be hard to add to RoboteQ firmware, for example:

- Low pass filter combines a fraction of previous reading with a fraction of current one. If done frequently the delay introduced by this filter is negligible;
- Hysteresis filter recognizes the "trend" of input changes and does not allow value to go in opposite direction until it is confirmed by subsequent readings;
- Limit filter does not introduce any delay, but also does not allow value to change for more than predefined step at a time. With fast polling and small step it works even better than low pass;
- Over-sample filter remembers several past readings and returns average of them. Again, similar to low pass, but much faster reacting to a change and past readings do not linger in the output after several iterations.

BTW, I am no electrical engineer but it seems to me that adding a capacitor on analog input as suggested in the documentation will only help if power is stable AND input is configured for absolute mode. Since you suggesting switching to relative mode to make it less susceptible to power fluctuations the capacitor will amplify the noise in this case. I think.

3. Position cross-coupling for multi-joint trajectory.
I am really impressed by your implementation of the Speed Position and Relative Position modes. In the past I did something like that, except the expected trajectory points were calculated in advance on a computer to take into account physical characteristics of the system, so the microcontroller only took care of PID part. Another big difference was that there were 3 joints in the system that had to work synchronously.

It would be really great if you could implement another mixing mode specifically for closed-loop position configurations. The idea is that commands like NXTPOS, NXTVEL etc. will define multi-dimensional point that all motors have to reach simultaneously. You already have algorithm for calculating incremental positions for each motor. All you have to do is take the longest trajectory and then re-calculate the other one to slow it down to the same travel time.

Also, if you can do this to support more than 2(3) motors by passing synchronization data over CAN you will make many people happy!