ad a). larger gear surely will help but most important is to make in atmegas slowing down ramp. piece of cake
ad b). encoder's positions after move, few errors which I programmed in atmegas, so still in separate thread RasPi "is talking" with atmegas trough i2c
ad c). goog question, and moreover: reproducibility. Because it is made from wood I do not expect rigidity like from steel but it should be +/- small difference for a some time of work. The most important is reading encoders correctly. That's point
Thanks for your replies. Yes, if you get feedback or are carefully calibrated you can tune on/off to be a curve instead of abrupt.
Probably our robot will be aluminium. and I'll probably using dspice33's (using C or, less likely Mikropascal).If I need more, they'll probably be linked over CAN, with a W5500 ethernet chip to communicate with PC (or RPI for the mobile, demonstration setup)
These (dspic33epxxxMU806/810/814) are the standard chips we use, and they are very suitable for this, with 14 two pin motor peripherals and 16 single pin and two encoders and DSP functionality to do realtime analysis (like FFT), though I have no experience with the DSP part yet. Till now I just use the single pin peripherals as a signal generation for external motor drivers like yours. But till this project most of our motorcontrol was ad-hoc and not design-in, so this will be different.
The robot will be an vertical axis that can turn 90 degrees and on top of this something that can extend (linear actuator?) and some gripping device on the point of that. So it can pick up a bottle from some store area, rotate 90 degrees, extend in the machine, and drop it. Precision is course, 5mm or so. Reliability is more important.