[ayeckley]

Originally Posted by wt200999

I'm curious to learn a little more about your application from past years. I also was reading what you had posted in the Cypress thread. Do you have any pictures or examples of how you used this previously?

I'm searching for pictures of last year's DS now. I'll update if I'm able to track them down. Last year we used it for fine-tuning of our shooter angles, as well as for gross movements of the shooter when the desired position didn't correspond to the five presets we had established. When the target angle was achieved, an LED adjacent to the corresponding preset button would illuminate in case the operator didn't have a clear view of the robot. We used almost all of the discrete inputs and outputs of the Cypress PSoC. People complained about the reliability of it, but it never gave us a lick of trouble.

On the robot side, the shooter angle control was implemented via a closed-loop system using a Bournes pot for feedback. Since we only had a ~180 degree range of motion we didn't have to deal with the rollover issue I described in the other thread.

For your application, what encoder did you use? The LaunchPad is certainly capable of interfacing with an encoder, it just needs to be able to do that and send the USB packets out.

We use FANUC pulse generators recycled from CNC equipment which have gone to That Great Pile of Chips in the Sky. They have a knob that is very human-factor friendly -- about the size of the average palm and with micro-detents that provide an intuitive feedback to the operator -- and are very robust since they are designed for industrial use. The drawback this year (aside from what we've already discussed) is that are intended to operate at 5V; I'm going to be running a test later this morning to see if 3.3V is sufficient. If not then we'll have to build some simple level-translation circuitry since the LaunchPad is [so I'm told] not 5V tolerant on the inputs.

An interrupt based solution would probably work well for you. We are happy to help support your team with this.

Thanks for your support. Happily, I've been using MSP430 (off and on) for about 13 years now so I'm pretty comfortable with the hardware side of things. We may get into trouble with the software side but we were able to get the default code to compile using CCS last night which is a very positive first step. I see that the polling interval is 10ms, so I think we'll approach it from that angle first and then may fall back on an interrupt approach if need be. The kids are going to get a lot more exposure to embedded microcontrollers than we were anticipating.

Originally Posted by wt200999

Also have you considered using an absolute encoder, something that maybe uses I2C or SPI?

I guess we've lightly considered it, but haven't encountered a situation yet where we felt we couldn't achieve what we wanted using a relative encoder. Another one of our lessons-learned over the years is that the Drive Team will sometimes forget to put the DS in its required starting configuration. For that reason, one of our standard design practices is to have the robot only have relative control response. In other words, if nobody turns the knob at the start of Teleop then the robot stays in whatever state it was in at the end of Autonomous. If we used an absolute encoder and accidentally set it to the "wrong" position going into Teleop, then it could/would do something unintended at the start of the match and we'd have to spend time and energy recovering from it. It's a minor point, obviously, but we do try to squeeze as much performance out of things as we can.