Arbitrary Quadrature Encoder

[Bneufeld235]

Team 585, the Cyber Penguins have launched a new Kickstarter project, the Arbitrary Quadrature Encoder (http://kck.st/147OyqI). We designed this circuit out of frustration with the high precision encoders that are currently available. For our uses, we were looking for a source of feedback that didn't have to be so precise but can plug straight into the Jaguar. We wanted to be able to control a window motor or a linear actuator with some ability to measure, but not so much that it was a burden to calibrate or keep from getting damaged.

After two years of development, we are now at the point where we are ready to create a printed and assembled circuit for our encoder so that more than just our team can benefit from our research and design. We explain how it works and have a demonstration video on the Kickstarter page. Please let me know what you think.

http://kck.st/147OyqI

[Levansic]

Brooke was able to gather some feedback at CMP, and should be posting some of that relatively soon.

In the meantime, we got some helpful feedback, both public and private, from some Kickstarter commenters. One was a FIRST alum from our team, who graciously offered some help with producing the prototype SMD boards much faster than we were able to get quoted elsewhere.

As a quick update, here (http://tehachapi-stem.org/images/Encoder_Schematic_Rev_0.png) is our current schematic. The schematic matches out wire-wrap prototype. We will be adding reverse-polarity and short-to-ground protection, very soon.

This is the current board design:
http://tehachapi-stem.org/images/Encoder_PCB_Rev_0.png

It looks big on the screen, but it is quite small when printed at actual size.

-- Len

[Bneufeld235]

We received a lot of great feed-back from talking to teams at Championships. Most questions fell under two categories: maximum performances and testing.

We have done testing at relatively low speeds so we are unable at this time to give a maximum speed. That being said, we calculated theoretical maximums based on the slew rate of our op-amps and are convinced we will never be able to test the maximum rate.

We realize that is a bold claim so here are some numbers. We have designed this to trigger at TTL levels but our worst case scenario is making every max voltage go from zero to maximum supply voltage to zero 111,000 transitions or 55,500 cycles per second. The default striped resolution is 0.2" (5mm) has 20 stripes around a 2.5" diameter hub. This would correspond to a speed of 166,000 rpm.

Absolute max performance is a signal that just trips the hysteresis with a much higher 500,000 transitions which is an approximate 750,000 rpm. This is theoretical in a perfect world and will not be any where close to that.

It should be noted that this is at default low resolution. The arbitrary part of the encoder is the resolution as well as the count per revolution. Higher resolution can be achieved by skewing the encoder. We will produce a table of stripe size to skew angle and post this once we verify performance.

We have posted this to receive feed-back from other FIRST teams so if you have any questions please ask.

[Joe Ross]

We have done testing at relatively low speeds so we are unable at this time to give a maximum speed. That being said, we calculated theoretical maximums based on the slew rate of our op-amps and are convinced we will never be able to test the maximum rate.


I suspect your limiting factor will be the phototransistors, rather then the op-amp.

[cgmv123]

I suspect your limiting factor will be the phototransistors, rather then the op-amp.

Based on those numbers, I think the FPGA's limit of 39,000 pulses per second could be the limiting factor, a limit which hopefully NI will increase in the new controller.

[Bneufeld235]

Yes, the limiting factor would be the phototransistors. It is about three times slower compared to the op-amp. The phototransistor only needs to trigger the hysteresis, which can be slightly reduced. The theoretical peak of the phototransistor would then match the capabilities of the op-amp.

Theoretically, the encoder can go faster than the cRIO can handle but it does not even come close to what the jaguar can handle. For the Jaguar case the op-amp and the phototransistor are the limiting components.

[Ether]

Theoretically, the encoder can go faster than the cRIO can handle but it does not even come close to what the jaguar can handle.

What can the Jaguar handle?

[FrankJ]

A 166,000 rpm shooter wheel? I think you are going to need a guard on that. ::safety::

Amazing stuff.

[Hjelstrom]

Team 585, the Cyber Penguins have launched a new Kickstarter project, the Arbitrary Quadrature Encoder (http://kck.st/147OyqI). We designed this circuit out of frustration with the high precision encoders that are currently available. For our uses, we were looking for a source of feedback that didn't have to be so precise but can plug straight into the Jaguar. We wanted to be able to control a window motor or a linear actuator with some ability to measure, but not so much that it was a burden to calibrate or keep from getting damaged.

After two years of development, we are now at the point where we are ready to create a printed and assembled circuit for our encoder so that more than just our team can benefit from our research and design. We explain how it works and have a demonstration video on the Kickstarter page. Please let me know what you think.

http://kck.st/147OyqI

This is really cool! I remember talking to you during the Las Vegas regional and you had a demonstration unit on the table. I'm going to back it, good luck!

[Bneufeld235]

What can the Jaguar handle?




The Jaguar can handle one million transitions a second.

[Bneufeld235]

This is really cool! I remember talking to you during the Las Vegas regional and you had a demonstration unit on the table. I'm going to back it, good luck!

Thank you for your support. If you have any feedback or questions just let me know.

[Ether]

The Jaguar can handle one million transitions a second.

For the record, would you please give your source for that information.

[Gdeaver]

The jag does have a hardware quadrature block that is fast but you have to service that hardware in a timely manor and handle many other time critical events. That may be a little high.

[Joe Ross]

For the record, would you please give your source for that information.




http://www.chiefdelphi.com/forums/showpost.php?p=1114857&postcount=8 ;-)

[Bneufeld235]

For the record, would you please give your source for that information.




Texas Instruments, Board Data Sheet (page 6)
Stellaris Brushes DC Motor Control Module with CAN (MDL-BDC24)
It was downloaded last year when Texas Intruments still made the Jaguars and assuming they haven't changed.

[Ether]

http://www.chiefdelphi.com/forums/showpost.php?p=1114857&postcount=8 ;-)

Facepalm.

[PayneTrain]

Facepalm.




Well folks, I think the internet is over now.

[Ether]

Well folks, I think the internet is over now.

Age is catching up with me :-(

[Bneufeld235]

We have now ordered the first round of circuit boards. Everything should arrive around May 14. These are for test and verification of the design, before we commit to making a bunch. I and several other students will be soldering the boards.

With the circuits we have ordered resistors with different values so we can do some testing and fine tune our encoder.The resistors that will most likely need fiddled with are involved with the voltage divider feeding into the first op-amp. We just don't know how sensitive the SMT phototransistors will be, compared to the through-hole version on the wire-wrapped prototype.

[Levansic]

For illustrative purposes, this is the current schematic (http://tehachapi-stem.org/images/Encoder_Schematic_Rev_0.1.png) of the encoder. The voltage dividers Brooke is referring to are R1/R3 and R5/R7, on the left side of the schematic. These dividers set the threshold for a high or low value.

Maybe now would be a good time to expand our in-team discussion to the wider CD community.

Initially, we had intended to offer this encoder as a completely assembled component, and as a kit. Our thinking was that the kit could be used for skill building, while a commercially assembled board should be more reliable for competition use.

Going to the Kickstarter forced us to be more pragmatic. I used to memorize Heathkit (http://en.wikipedia.org/wiki/Heathkit) catalogs in my youth, but couldn't see the volumes for kits being worth the headache of confused parts or damaged components. The truth is, we just don't know if it is better to keep on the road that we are on, or re-think the option of offering kits. Any thoughts?

[Levansic]

:(
I didn't expect crickets.

Well, we have some new news. Our SMT components arrived today, and my tracking info on the boards says that they should arrive tomorrow. This is ahead of our original schedule. We will post pictures when the boards arrive.

Unfortunately, this doesn't advance our schedule any sooner than assembling on Monday, With college placement tests, Special Olympics, and Mother's Day all happening this weekend, we have no confluence of students and time.

Looking at the size of the components we used to fit everything on the board, while not an absolute position, I've moved decidedly against offering kits. I can now see why Heathkit had trouble being reborn recently. It looks like successful assembly will take the skills of a dentist or a damond cutter.

That being said, if there is interest, we may add a lower award tier for a kit of parts, with one extra component of every type. I'm sure there are a few masochists like me around that would love the challenge.

[calvin909090]

Why are you guys using op-amps instead of comparators? Comparators output a direct digital signal. Response times will be better, since you don't need to worry about slew rate (not as if that was a concern in the first place)—something like the LM339 instead of the LM324.

[nuttle]

This isn't a good fit for the Jag, but for teams wanting another way to interface an encoder, this (http://www.lsicsi.com/pdfs/Data_Sheets/LS7366R.pdf) part is a good choice and sets up an interesting software project.

This project is very good to see as-is, just wanted to offer another avenue in case it is helpful to anyone. Also, studying the data sheet enough to understand it can be a good way to learn -- possibly with some mentor or student discussion mixed in.

[Levansic]

Why are you guys using op-amps instead of comparators? Comparators output a direct digital signal...

That's a good question!

There are several reasons that are tied together, but I'll start with the easiest first. Comparators are specialized op-amps. Our original circuit was attempted with comparators, and didn't "work". Switching to more general-purpose LM741 op-amps, which were available at the local Radio Shack, made it work, and the LM324 is a quad version of this op-amp.

In reality, the first phase probably worked fine, but we couldn't sink or source enough current to drive the second phase LED's for feedback. That's the problem with using comparators for this circuit. They are typically connected to high-impedance logic inputs and not driving current consumers. Using the LM339 for example, it sources nil current at high signal, and only sinks 15 mA at low signal. While this will light our indicator LED's, it would be at a much lower intensity. In our circuit, we source the current for the LED's from the op-amp, rather than sinking or switching a transistor.

There are comparators that can sink or source comparable current to what the LM324 can supply, but they are much more expensive than the LM324. We could have split the phases apart and used a dual comparator for the first phase and a dual op-amp for the second, but we wanted to reduce component count.

[Levansic]

This isn't a good fit for the Jag, but for teams wanting another way to interface an encoder, this (http://www.lsicsi.com/pdfs/Data_Sheets/LS7366R.pdf) part is a good choice and sets up an interesting software project.

Last Fall, we had a few discussions about adding a chip like this to this project. Looked at an Arduino-compatible chip, thinking we could find a scope to meet the creep. With the current control system, the only way we could see this as adding value would be if we also included a CAN transceiver. At that point, you're probably already using Jaguars, which have everything you need for a simple encoder without needing to have a counter chip.

If you use a chip like this, you would have to use I2C to make it practical. It would also need an easy way to change the address, so it does not conflict with the existing accelerometers that can use I2C. If you used SPI or RS-232, then you would only have one encoder per robot. You could hang more off of an onboard laptop or Raspberry PI, but that would probably violate current rules.

In the end, we figured we could expand in this direction if it made more sense in the future. I guess we'll find out in August if it would just be cool to play with, or more useful for the next system.

This is the engineer's conundrum of doing it because you can versus canning it because you should.

[Levansic]

The prototype boards have arrived!

http://tehachapi-stem.org/images/Board_Quarter.png

Boy are these things small. If all goes well, we should have the first one assembled tomorrow.

[nuttle]

Looks nice -- have fun!

BTW, I think you could connect up to 8 of the encoder chips I mentioned over SPI, using something like a 74LS138 (http://www.ti.com/lit/ds/symlink/sn74ls138.pdf) (and even more using a similar scheme with more/different parts to select which chip to enable). The datasheet for the encoder chip (http://www.lsicsi.com/pdfs/Data_Sheets/LS7366R.pdf) shows this in Fig 15. You'd hook the SS* line from each chip to one of the outputs from the 74LS138, and inputs to the 74LS138 would be three digital output lines, plus the original chip select line from the digital side car. You would use the three digital output lines to choose which encoder chip to interact with, one at a time. Other than this, the rest of the SPI usage should be unchanged. If someone out there is looking to try something like this, I just wanted to follow up.

Good luck with the project, it will be very useful I'm sure and to others as well. Thanks for sharing!

[Levansic]

BTW, I think you could connect up to 8 of the encoder chips I mentioned over SPI, using something like a 74LS138 (http://www.ti.com/lit/ds/symlink/sn74ls138.pdf) (and even more using a similar scheme with more/different parts to select which chip to enable).

:D
That sounds like a lot of work. It also sounds like a central interface for a bunch of encoders, rather than individual encoders. Nothing wrong with that, but that would be a bit more specialized than our plain encoders.

We kind of ignore SPI existing on the digital sidecar, as we've never got it to work correctly. This contrasts with our experience with I2C, which just works. Perhaps it is the programming environment and libraries that we use (LabView), or perhaps the implementation of SPI on the accelerometer. Sometimes should work and does work aren't in the same ballpark.

[Bneufeld235]

First round of hand-soldered printed circuit boards work! For actual production we do plan on soldering the boards with a machine but for the prototype boards it will easier and cheaper to do it by hand. We have done minor testing; there needs to be a few adjustments to the values of some resistors but other than that it is successful.
http://tehachapi-stem.org/images/First_born.jpg

[nuttle]

You have to pay attention to signal integrity when working with anything even slightly high-speed on the digital side car. We've had good success with SPI, but I don't want to take things off topic. Your project is great!

FWIW, here's a photo of a 6-encoder board we used for Lunacy, before it was legal to use CAN. This worked really well, it used the digital I/O lines as a bus to interface a similar (but non-SPI) encoder chip. At first, the digital I/O lines had enough bounce to cause occasional problems, one major source was the long round cable used to connect the cRIO to the DSC that year, at least if you went with the KoP solution. The ribbon cable connected to the digital I/O on the DSC and the other connectors were to encoders and coast/brake inputs (I think we decided this wasn't legal and left these off).

This type of thing is a good off-season project, it does normally take a while to get everything working well, including the software! Again, it is great that this is being done; thanks for sharing and good luck!

[Mike Bortfeldt]

We will produce a table of stripe size to skew angle and post this once we verify performance.

Do you have an estimate of when this may be complete?

Thanks,
Mike

[Levansic]

We've calculated the table of stripe sizes, and are testing to find the practical limit. We don't have an estimate yet on when we will finish that testing, as we are still making adjustments on the boards (four complete, so far).

One of the things that we were less prepared for was the relative difficulty of the testing of the SMT board. It is really easy to attach probes to just about anything on our wire-wrapped board, so we can "see" what is happening. We didn't have the foresight to add a bunch of through-hole locations to add probe points to the back side of the board, so we could test input voltage levels to the first stage op-amps.

With the move from 5mm through-hole LED's and phototransistors to surface mount equivalents, there are physical changes that we are still adjusting for. Specifically, the 5mm LED's had a 20° beam, while the 0603 package has a 120° beam. Likewise, the 5mm phototransistor had a 20° cone of high-sensitivity, while the 0603 package phototransistor has a 120° cone of sensitivity. The SMT components are better suited for a transmissive/interruptor application than the reflective one that we are doing. In practical terms, this greatly reduces the distance between the encoder strip and the encoder. Our original goal was and still is to make an encoder that has a lot of tolerance for the distance between the encoder strip or disk, and the encoder.

There are domed surface mount components that can improve our range, but they are much larger than what we can easily place on the board. Likewise, there are reflective paired sensors that have a longer range, but these are also much larger than the components we are currently using.

The easiest adjustment is to change the threshold voltage, which is what we are testing now. The next step for us is doubling our illumination, which may expand our range by ~40%. This will need a new board design, so we are applying the lessons we learned so far to a new board.

[Levansic]

Testing is ongoing, but is throttled by student availability. The end of the school year is always chaotic.

We refined the design a little, based on our experience with the SMT boards we made. As mentioned in my last post, we are going to double the illumination, and adjust the spacing between our detectors. We also moved the detection portion to the center of the board, to make the encoder ambidextrous.

Our board shop says we should have them next week, which is after the close of our Kickstarter project (http://www.kickstarter.com/projects/951897038/a-quadrature-encoder-for-the-real-world).

http://tehachapi-stem.org/images/Encoder_PCB_Rev_0.2.png

Speaking of Kickstarter, it has been an illuminating experience. We want this to become a COTS part that any team can use, and we do not have the funds to make this happen ourselves. We have four days left, but our funding pledges have flat-lined over the last week. Thus far, our video has been watched about 1,100 times. Of our supporters, only three have come from Chief Delphi, while half have come from people browsing through Kickstarter projects. There may be more overlap, but that's what is being reported to us.

Of course, we would like our project to be successfully funded by the crowd, but if it isn't, we will still plug away at refining and developing the device. If we repost, we will have a much better project, and a much more polished video

[Levansic]

Well, the Kickstarter is over. Although we didn't make our goal, we're framing this experience not as a failure, but a learning opportunity on the path to a delayed success. In hindsight, it is clear that we should have been further advanced on our SMT boards before starting, and we should have looked at a smaller first run, accepting that the unit costs would be higher.

Right now, we intend to keep the development burners going all summer, until we feel that we have an adequate encoder that meets our original goals. For us, that is essentially matching the sensing we got from our wire-wrapped prototype, but on the much more compact SMT board. Even with some setbacks, we have not fallen behind our original schedule.

Where are we now? Well, we've done a lot of testing that has shown us that the encoder can sense encoder strips of several different resolutions, but we have found a lower limit that is a little too coarse for our comfort. Specifically, as the stripe size decreases, the sensing range also decreases. The encoder becomes really picky on the clearance distance between the strip and the detectors, until a point is reached where the encoder strip only registers gray, no matter what the clearance is. There is no problem with a "native" resolution strip, other than requiring it to be a bit closer than we like. It still has a bit of flexibility on the clearance distance.

This encoder was never supposed to be high resolution, as the point was to be more flexible and forgiving than the commercial encoders. We still want to be able to use the encoder for higher-resolution detection, as it would expand the envelope of uses.

We should be getting the boards for the first slight re-design (Rev. 0.2) this week, and have already gotten a second redesign (Rev. 0.3) prepared with some different components to try to address the resolution issue. Ironically, to get to higher resolution with smaller stripe sizes, we may have to go to significantly larger components on the board, that have integrated optic features. Testing will determine our course of action, as the components for the Rev. 0.3 board will add significant cost, compared to Rev. 0.1 and 0.2.

[Levansic]

The world has changed so much over the last quarter of a century. I look at the FIRST program, like most mentors, and ponder what it would have been like to have this kind of competition when I was in high school. That usually leads me to consider other technical advances that I can't seem to live without today, like cell phones, laptop computers and e-mail. I realize that even those are old-tech now, replaced by smartphones, tablets, and the myriad of social interaction and language destruction technologies like texting, twitter, and FaceBook. I digress.

When I was in high school, I had no problem sending an order through the mail, and waiting weeks to receive whatever it was that I had ordered. Usually, I would wait a week, and then eagerly check the mailbox every day, to see when my goodies would show up. Usually this was an act of ritualistic disappointment, until the fateful day that my package would arrive, but I was blissfully unaware that package delivery could be done any faster.

Things took longer. I had a high-speed 1200 baud modem, and I liked it. Yes I loved it! Compared to the 110 and 300 baud modems of the time, it was blazing. I used that modem and it's successors into college, and remember when the internet was not so easy. Now I'm one of those old codgers that surfed the World Wide Web with lynx (in all of it's text-based glory) in mainframe sessions, before any of my current students were born.

I remember my first experience with FedEx, getting a letter overnight. I can't even vaguely remember one of my first e-commerce sessions, when I ordered something online, and it showed up a few days later. In the past year, I've used rapid prototype services like Protolabs (http://protolabs.com) to get simple parts in two days, by only sending in a STEP file.

Why I bring all of this up, is a prelude to discussing the prototype board shop that we are using for this project, OshPark (http://oshpark.com).

We submitted our Cadsoft Eagle files to their online system, and their software produced the gerber and drill files for the board, and gave us immediate renderings of what the finished boards would look like. Our designs were combined with the designs of other customers, to make a full panel, and those panels were manufactured here in the U.S. Our last batch of boards was shipped to us by them on Saturday, which is about a 5-day turn-around.

We couldn't be happier with them.

In this day and age, though, it seems that the U.S. Post Office has gotten me nostalgic. I realize that this is a slightly off-week, with Memorial day on Monday, but their online tracking service has taken me back to the days of indeterminate mail delivery of my youth. We know that our boards were transferred into the custody of the USPS on Saturday, at precisely 10:07 a.m., and that they expected to deliver our boards on Tuesday (two days ago). We re-check the tracking status page hourly, a symptom of the impatience caused by the technology that we take for granted today. Nothing has arrived yet. The ritual will repeat tomorrow...

[Levansic]

The Post Office has delivered our boards. Unfortunately, we don't know where they have delivered them. All I know is that there are reportedly somewhere in our town, but not at any address of anyone on the team.:mad:

On the positive side, we now have all of the other components for the next revisions of our design. Rev 0.2, posted above will double the illumination and move the detectors closer together. We will actually be testing two different sets of emitters and detectors on our third board revision (Rev. 0.3). That board has been getting minor tweaks to make it more amenable to reflow soldering, rather than wave soldering. That doesn't affect our hand-work now, but will make it easier when we do move into production.

[Levansic]

We had a fortunate break today when a neighbor discovered our package in his mail today.

We mentioned the changes we made for this board in an earlier post. Here, you can see the differences from the first set of boards. The position of most components were adjusted in some way. Additional labeling and keying of the JP1 connector was also added. JP2 was also labeled for its function.

Board front - Rev 0.2 on left Rev 0.1 on right
http://tehachapi-stem.org/images/1-2_front.jpg

Board rear - Rev 0.2 on left Rev 0.1 on right
http://tehachapi-stem.org/images/1-2_back.jpg
We got some branding on this set :D

This week is graduation for much of our team. We will most likely be assembling the new boards this weekend, and testing soon afterwards.