This is as much a programming problem as it is a mechanical issue I guess. A few of us are working with quad encoders at the moment and I'm just wondering about ideas how to overcome a problem I've encountered using some. I'm using interrupt on change to count encoder ticks and also reading a 16 bit timer for the interval between ticks on each motor. The problem I've assumed that can occur and proven in the simulator is you have no control? over how close together the encoder ticks on each side fire in relation to eachother and so under those circumstances your code can never be fast enough to update one side when it must attend to the other, leading to errors. Say for instance your encoders tick at a rate of 250 microseconds, that's plenty of time to do heaps in this amount of time with a micro running at 16 mhz or more but if the second motor/encoder ticks only a few microseconds after the first then your going to be pushed to increment your counter and read the timer in only a few microseconds.
So I believe for reliability it will be necesary to dedicate one processor per motor/encoder so no clashes can occur. Although I'm not excited at the idea. I see Protowrx has used 2 pro mini's with Lexanne using one pro mini per motor/encoder setup. I'm not sure if that was the reason he chose to use 2 but I'm guessing it is.
I probably worry too much, I’ve found that the whole update loop takes about 6-7 microseconds. So if a tick event happens faster than that then the information is lost and I noticed that just below this amount of time the odometer readings are first to fail in that they do not update evenly and then as the time gets shorter the speed readings are wrong.
What I forget I guess is that even if the ticks are close together for a time unless you run a straight line for a long time then the gap will change as you turn? For spot readings of speed it shouldn’t matter but it could have an effect on odometry readings. How big I don’t know yet.
Proto I started using the pololu encoders(the older version) and was frustrated at their accuracy. Channel b, it could have fit 5 times inside the period of channel a. Hardly quadrature. I switched to some faulhaber motor/encoders I have and the signal is much steadier and reliable plus I’ve gone from 96 counts per second to 4000 counts per second at full speed.
Bajdi, that’s what I can’t understand with 4 quad encoders run on one processor there must be a lot of times that ticks happen before the last reading can be updated. Have you done any odometry tests yet?
You should be computing your speed/distance at a much slower rate than the encoder tick rate. If you’re running PID, normally you want to run the PID loop at a fixed rate, say 10 Hz (that’s the rate the Arduino PID library enforces). Given that, it is pointless to compute speed/distance at any rate higher than that. Even if you aren’t running PID, and are just computing distance and/or speed, calculating it any faster than 10-50 Hz isn’t going to help, unless your build quality rivals NASA’s.
Yes, I’m changing that. Not the first time I’ve ran an update loop too fast. My first attempts with steppers failed because I was updating them too fast, lol. Anway nows a good time for me to say welcome to lmr, I like what you’ve done. Checked out your blog and what you posted here and your build quality is pretty high up there Jon.
