Rotary Optical encoders

[Bob]

I'm not yet an IOIO user - only discovered it on friday.

I posted a couple of questions in the comments section of Ytai's pages and Yati suggested that I post here.

I've done some play with Arduino and optical Rotary encoders, primarily with an interest in tracking the position of  telescopes (although I have an ArgoNavis which does that very well). Interesting learning and hoping one day that I get enough bit's of learning together to make some useful real world application with this (using a phone or tablet as a telescope control handpiece with fairly simple electronics at the telescope). Ability to read encoders and control steppers has a raft of potential uses for DIY projects.

The encoders I'm using are the predecessors to these http://www.usdigital.com/assets/general/82_s6_datasheet_3.pdf
Detecting all state changes on the two channels of a 2.5k encoder can give a 10k resolution.

I put some notes on what I was doing with the Arduino onto a Sparkfun forum http://forum.sparkfun.com/viewtopic.php?f=8&t=20137&view=print for those who want to see how I did that.
I'm trying to work out if it would be viable to add encoder interfacing into the IOIO firmware so that the IOIO kept track of the position and the phone polled position as needed. In practice it would also need to be able to set current position, notify the phone when it got to a specified position etc. Great to be able to deal with multiple encoders as well although that potentially makes the speed issue much worse).

I've not been able to determine what sort of real clock speeds the IOIO runs at, the Arduino missed some state changes when I upped the rotation speed (trying to mimic a fast hand slew of a telescope). From memory I was working with a 16MHz 328 board. I've not yet worked with PIC's so I don't have any idea if they might handle some of that stuff differently to the Arduino.

Any thoughts on what would be involved on adding in encoder functionality to the firmware?

What's the speed of the board and does the way the firmware is implemented alter performance compared to tools such as the Arduino and Picaxe?
Please excuse the vagueness of that question, not an issue I understand well but I'm hoping that there are some ballpark figures that would help me understand what sort of performance to expect compared to what I'm already used to (eg 16MHz Arduino).

Bob

[Ytai Ben-Tsvi]

Hi,

Sorry for the delay in response, I was on vacation and then took some time to think about your question.

Short answer: I'm planning to implement encoder (including quadrature) support. It'll probably take weeks / months, not because it's so complicated, but because I have so much other stuff on my plate.

Long answer:

Some PICs have a dedicated hardware peripheral called QEI that handles quadrature encoders. It is basically a counter that increments / decrements according to two phase inputs, as well as a programmable digital filter for optional cleaning of the inputs.

The PIC on the IOIO doesn't have such a peripheral, thus one would have to implement such functionality in software. The CPU runs at 16MIPS and can interrupt on any pin change. There's only a single issue I can think of that might make such software implementation limited in its rate: there's only a single interrupt handler for every pin with interrupt change enabled and no way of knowing which pin actually changed except saving the previous state, XORing and finding the "1" bits. Even if implemented in assembly, it might take a few tens of cycle to process such an interrupt (just guessing). So you can possibly get to a few hundred KHz if you spend some time optimizing.

You can see an example of how I'm handling input changes in https://github.com/ytai/ioio/blob/master/firmware/app_layer_v1/digital.c. In this case, I haven't bothered optimizing too much and instead of counting changes I'm merely sending change notifications to the Android (that's how DigitalInput is implemented under the hood).

If you want to get into the IOIO code and work on implementing such a feature support yourself, I will be more than happy to guide you and support you.

Ytai.

[RobotFreak]

Hi,
A tip for evaluating rotary encoders. Use a timer interrupt and sample the pin states instead of using a pin change interrupt. I'm doing this for many of my Arduino robot projects. It works very well for the Pololu 42mm wheel encoders and the Dagu Rover5 chassis.
An Arduino code example can be found here.
Greatings Peter

[Gordon Tao]

Hi, Bob

we have the same issue. Do you find some solutions now?  Any insights greatly appreciated!

Gordon

[Nick Jonas]

Did anyone figure out a solution to this, having the same issue currently...