Encoders direct driven by mini cim? Is it bad?

[aphelps231]

A mentor said we can't put an encoder on our shooter, driven by mini CIMs, because it would overload the code or something. Being the one who designed and built the shooter, I've been kicking myself in the butt trying to figure out how to get some type of low res encoder on it. So far we've tried a Hall effect sensor and a metal proximity detector, with magnets on the shaft and bolt heads on a hex hub, respectively. Both didn't work.

There is a 20 tick encoder on andymark that mounts directly to a mini cim. At this point, I'm willing to try it despite what our main technical mentor said in week three. My question: would an encoder reading downwards of 2,000 cps (counts per second, 5,800 RPM @ 20 ticks/rotation = ~2,000 cps) overload the code/RoboRIO? I'd like to say no since the RoboRIO operates in the MHz (I think) and that should be plenty but id love it if you would share your experiences.

It has been tossed around that we use an algorithm based on battery voltage to decide how much voltage to give the shooter. I really don't like this option, I'd rather run it open loop since battery voltage is constantly fluctuating.

[Knufire]

Originally Posted by aphelps231

Our main technical mentor said we can't put an encoder on our shooter, driven by mini CIMs, because it would overload the code or something. Being the one who designed and built the shooter, I've been kicking myself in the butt trying to figure out how to get some type of low res encoder on it. So far we've tried a Hall effect sensor and a metal proximity detector, with magnets on the shaft and bolt heads on a hex hub, respectively. Both didn't work.

There is a 20 tick encoder on andymark that mounts directly to a mini cim. At this point, I'm willing to try it despite what our main technical mentor said in week three. My question: would an encoder reading downwards of 2,000 cps (counts per second, 5,800 RPM @ 20 ticks/rotation = ~2,000 cps) overload the code/RoboRIO? I'd like to say no since the RoboRIO operates in the MHz (I think) and that should be plenty but id love it if you would share your experiences.

The same mentor suggested we use an algorithm based on battery voltage to decide how much voltage to give the shooter. I really don't like this option, I'd rather run it open loop since battery voltage is constantly fluctuating.

The encoder AM sells is fine. Most other encoders would be as well. This is a limit you had to be mindful of on the cRio but the roboRio's limit is much higher.

A common trick in the past was to put a colored white/black pattern on the side of the wheel and point a IR sensor at it.

[Owen Busler]

Im not a main programmer, but my team is running 1024 CPR encoders spinning at 6000 rpm and the rio is having no trouble reading these at all. We use labView if it matters. Just sharing my experience, no idea what will work for you.

[aphelps231]

Thanks for the quick replies. I think I'll have an AndyMark CIMcoder ordered and see what happens.

[rod@3711]

Originally Posted by aphelps231

Thanks for the quick replies. I think I'll have an AndyMark CIMcoder ordered and see what happens.

We are using Andy Mark encoders on our miniCim shooter wheels. No problem.

[Ether]

Originally Posted by aphelps231

Our main technical mentor said we can't put an encoder on our shooter, driven by mini CIMs, because it would overload the code or something.

Encoder signal detection and processing is handled by the FPGA in the roboRIO. Your code runs in the CPU. So using an encoder will not steal resources from your code.

Being the one who designed and built the shooter, I've been kicking myself in the butt trying to figure out how to get some type of low res encoder on it. So far we've tried a Hall effect sensor and a metal proximity detector, with magnets on the shaft and bolt heads on a hex hub, respectively. Both didn't work.

I wish you had posted here when you were trying to get it to work. Many many teams have successfully used Hall sensors for shooter wheel speed control.

would an encoder reading downwards of 2,000 cps (counts per second, 5,800 RPM @ 20 ticks/rotation = ~2,000 cps) overload the code/RoboRIO?

No. See previous comment about FPGA vs CPU.

I'd like to say no since the RoboRIO operates in the MHz (I think) and that should be plenty but id love it if you would share your experiences.

The FPGA samples the DIO for edges at 40MHz. This is completely separate from the roboRIO's CPU, which has 2 cores each running at 667 MHz. Your code runs in the CPU.

The same mentor suggested we use an algorithm based on battery voltage to decide how much voltage to give the shooter.

This can help, but it's not as effective as using speed feedback.

I really don't like this option, I'd rather run it open loop since battery voltage is constantly fluctuating.

The whole point of using a voltage-based algorithm is to compensate for the fluctuating voltage. But it's not the best way to control speed.

There is a 20 tick encoder on andymark that mounts directly to a mini cim.

What is the part number of that encoder?

[snoman]

we are using a magnetic encoder with the talon srx and java seems to be working well for us. i am not the programmer but may be able to get and post code. pm me if you are interested

[aphelps231]

Originally Posted by Ether

What is the part number of that encoder?

http://www.andymark.com/encoder-p/am-3314.htm

am-3314

[de_]

We have used both a $5 IR light sensor of ebay pointed at a black and white disk attached to a shooter. Also used an industrial IR light sensor. Both seemed to work.

We have also used a grayhill encoder in the past but you would be operating it slightly above its rated RPM of 5000.

http://www.grayhill.com/assets/1/7/Opt_Encoder_63R.pdf

[JesseK]

We had the VP encoders in 'Quadrature' mode hooked up to the Talon SRX's in 'Speed' mode, running at 8k RPM. Was pretty nice to not have to worry about the RIO running the sensing for 2 shooter wheels, the tilt potentiometer and turret absolute encoder - the SRX's do it all individually.

We're switching to the CIMcoder and a CIM-ile setup for non-sensor reasons though.