pic: Team 830's electronic box

[TedP]

Now, the modularity is mighty nice. That's definitely the case. Nice job there.

However, do you really need the external encoder circuitry? With last year's Stamp, I could see that, but with this year's PIC, it's really easy to do that in software with very little processing burden (just be sure you're using interrupts; don't poll!!).

For example, on our robot we're using the Banner sensors (yes, I know it's a waste, but they're nice to use an have NO and NC outputs) as a reflective shaft encoder. Connecting the NO output to digital 1 allows you to use a simple interrupt handler to do whatever magic you need at every 0-to-1 transition. Likewise, if you connect the NC output to digital 2, you can trigger on the other edge (thus, as long as you have your spacing correct, doubling your resolution). (note that digital inputs 1-6 generate interrupts on 0-to-1 transitions)

You can tune your handler to provide enough information to calculate speed as well.

Then, in your fast code somewhere, setup a constant sampling interval. You can do this with another interrupt that triggers every 100th of a second, for example. You can then "sample" the speed and position being generated by your interrupt handler and build a pretty decent speed controller.

We're using a simple PIID controller for our left and right wheels as well as the two joints of an articulated arm we used. Our code is listed here:

http://www.osufirst.org/twiki/bin/vi...04RegionalCode

No additional encoder hardware was needed; this worked really well. Now, to simplify things, we did add in some floating point operations (our PIID coefficients) while at the regional (rather than dealing with integer math), and we haven't timed it to make sure that it is keeping up and still sampling at 100 times a second, but things still work pretty well.

In the code we put on-line, we have some arbitrary proportional and integral constants set. That ended up being all we needed to function very well (without any open loop filtering), but we did some system identification on the side to generate a much more optimized compensator.

Our students knowledge of PID technology is one of the major reasons we won the engineering inspiration award, and we shared this code as well as some insights to some of the other teams who were using more naive ways to respond to their feedback. The PIID controllers we built worked pretty well to the first order on even our very non-linear articulated arm. I highly recommend this architecture on these sorts of robots; it's very similar to the ones we use on robots we use in other projects outside of FIRST.

Anyway, my main comment was that the board looks great, I just don't think that much additional hardware is really necessary. This year's controller is very powerful and needs little extra help to work well.

[Don Wright]

Yes...I agree with you...now. But, in Jan, when we got the new RC I wasn't sure of our programming resources or how difficult it would be to just do simple things with the new controller. So, I asked one of our engineers to come up with an encoder solution with some of the kids that just gave us a simple voltage output and a direction bit. That, I knew we could do something with. He did come up with a very nice, precise, solution...but at a cost. It's very delicate, time and space consuming.

I can't wait to check out your code when I have some spare time. I really appreciate your help and suggestions. The new RC is proving to be a very nice piece of work...

Thanks again.

Good luck!!