Just thinking out loud here…
You have a speed of 800 steps/sec (incorrectly displayed on the web app as mm/sec).
So that’s 4 revolutions/sec, or one revolution every 250ms.
The encoder is 360 lines per revolution, so that’s one pulse every 694us. But it’s a quadrature encoder so that’s one edge every 175us. The tolerance is +/-45 degrees so two edges could occur within 86us.
A quick glance at the Arduino code and you’re sampling the encoders every 200us? Something must be wrong with my maths (quite likely)… or you’re having some challenges with the encoders
All initial development for the encoders was done with encoders with a much lower resolution. Full positioning using encoders only works with only 100 steps/sec. Too slow. Because of that, we’ve switched now to stall detection using the encoders, not positioning. This is sufficient for homing, calibration and error detection. You can still switch on full positioning for full accuracy and low speed.
Considering FarmBot is most likely to become an unattended piece of equipment fairly soon (after you’ve been staring at it in amazement the first two weeks), would speed really be that much of an issue?
In all honesty, I wouldn’t mind FarmBot taking its sweet time doing its sequences while I’m away at work during the day. As long as I come home to a well tended garden and a FarmBot that didn’t wreck itself on its tracks.
I know. It’s essentially a 24/7 machine so it can take it’s time until fields get much bigger.
But the option is not on the screen yet. We’re all still pretty much in the ‘first two weeks’ stage and unwilling to admit defeat on the encoder/speed issue.
Understood, I’d bite down into the issue as much as you are doing, really. But I have the feeling that there are other areas which can still improve a lot. Encoders will come in due time, more as a “nice to have” feature.
Understood about more important things. I might have a play with the software over the weekend if I have time, I’ve looked up some old software from 8 years ago where I was controlling steppers with a sample rate of 25kHz (using a mega64), so it’s certainly do-able. I suspect you may be trying to do too much in the interrupt subroutine; only the encoder pins need sampling at high speed, the processing of them can be polled at a much slower rate. Same goes for the stepper drive, only the output frequency needs a high sampling rate, the calculation of the speed (frequency) can be done much more slowly in the background.
No GPS. Typical accuracy of that is 5 meter. You get centimeter accuracy for high-end models. You need millimeter accuracy for handling planting, tool bay, weeding…
