Offloading intterupts to a counter

[TedP]

Originally Posted by KenWittlief

I know that most PIC processors have internal counters that can count transistions on input pins - I dont know if they are available on the one in the RC - if so it would be much easier to use than an external device - and the counters dont need interrupts for each count - only when they have reached their terminal count.

Digital inputs 1 through 6 are already tied to the low priority interrupt handler in the default IFI code. Transitions from 0 to 1 are detected. This is actually how we're doing our encoding -- we just detect beam breaks. At every break, the interrupt triggers and increments a counter.

Everyone seems to love talking about quadrature encoders, but in this particular type of application where you usually have some gear reduction between the motors and the wheels, it just seems silly. If I'm driving the motors forward and the wheels are moving backwards despite the gearing connecting the motors to the wheels, I have a BIG PROBLEM. Thus, just use one bit for encoding and keep track of what direction you're driving your motor to tell you which direction you're going in.

And because I gazed ahead and noticed a question about terminal count... When the external counter reaches the highest number it can count to, it will have to raise a flag indicating it has reached it's "terminal count." This can be done internally in the PIC to keep track of time. If counters external raise a terminal count every, for example, 1024 ticks, then the PIC will be able to increment a counter internally indicating that the counter has moved another 1024 ticks.

[KenWittlief]

Ted has a good point - if you end up hitting something, or another bot is pushing you backwards, you wheels will either be slipping (spinning) or turning backwards or both

but either way, you are already lost - so you might as well assume you are going in the direction you set your motors to. once your wheels slip your position based on wheel turns is useless.

and if you are using wheel rotation to close the loop on motor speed, buy the time your wheels end up being pushed backwards your PID loop would have them at full power forwards anyway

[TedP]

Originally Posted by KenWittlief

Ted has a good point - if you end up hitting something, or another bot is pushing you backwards, you wheels will either be slipping (spinning) or turning backwards or both

Well, and what I was trying to also say was that depending on your robot's gearing, it's probably very difficult to push the robots backwards any significant amount, ESPECIALLY if their motors are driving. I'd be more willing to believe wheels slip or spin rather than run backwards. When a motor wants to drive forwards and you drive it backwards instead, it's not good for the motor nor the source of power to the motor.

Originally Posted by KenWittlief

but either way, you are already lost - so you might as well assume you are going in the direction you set your motors to. once your wheels slip your position based on wheel turns is useless.

Well, even if your position is useless, the rate of change is still useful. In fact, sometimes the thing to do when your wheels slip is to reduce your speed until you start catching on carpet again. Sometimes having some feedback control controlling your speed is a good way to do that.

Originally Posted by KenWittlief

and if you are using wheel rotation to close the loop on motor speed, buy the time your wheels end up being pushed backwards your PID loop would have them at full power forwards anyway

And again, motors in full power forward while wheels are going backwards is no good for anyone. "back EMF" becomes "forward EMF"... or something.

So, yeah, to reiterate, I don't think quadrature encoders really provide much advantage. Get your ticks, fudge your direction, and you'll do just as good as any.

Now, if you have other mechanisms besides drive train that might be driven backwards (perhaps you're using something as input that is fairly free to rotate... etc.) then the quadrature makes a lot of sense. But for drive train for most of these robots, it's probably not all that helpful.

[Max Lobovsky]

The drive train should be just barely traction limited so slipping will be rare. There are many cases where the drive trains will backdrive in my application, often the motors will not be on and the wheels will spin, it is not always that they will be spinning in the opposite direction. I defenitley do need a direction sensor. Regardless, it isn't too hard at all to check direction with the quadrature encoders, every counter i have looked at has the capability to, and it probably doesnt add too much time to my interrupt code to do a single if on a digital i/o pin. One possible solution might be to use current sensors to see if the motors are being backdriven, but if im going to be counting encoder clicks, i might as well count them up and down.