encoder for cam-driven kicker?
 

As part of a feasibility study, our team has just prototyped a cam-driven kicker.

A motor-driven cam pushes a cam follower at the end of a lever arm which forces the kicking arm back, stretching the latex tubing. When the cam reaches its largest radius, we want to motor to stop. Then to fire, the motor continues rotating in the same direction, and the cam-follower falls off the edge of the cam (down to the lowest cam radius, that is), allowing the kicking arm to kick, and the cycle repeats.

I'm seeking suggestions as to what type of sensor to use. I'm thinking an absolute encoder would be what I need, but the one in the kit of parts is a relative encoder (as far as I can tell). Is there a way to make that work for this application?


~

Re: encoder for cam-driven kicker?
 

What about the magnetic encoder that was supplied in the kit? It measures a full rotation and, since it needs no contact, that's one less thing dragging down your mechanism when it is unwinding.

Re: encoder for cam-driven kicker?
 

What about a simple limit switch? We have a cam-driven spring kicker. It is programmed so that when the trigger is pulled, the limit switch is ignored and the cam motors are run until the limit switch deactivates and then reactivates. It works great for us.

Re: encoder for cam-driven kicker?
 

limit switch is what we are using for ours too.

Re: encoder for cam-driven kicker?
 

Yes, that would work as well and would probably better for this application. I'm a bit biased because in our kicker, three limit switches would actually be more complex than the magnetic sensor. ;)

We do have the exact same setup as yours to release the kicker's dog gear.

Re: encoder for cam-driven kicker?
 

We are using a continuous rotation potentiometer for a similar purpose. We wired it up like you would wire up any other pot, and it works well. And it is a lot cheaper than an absolute encoder or something like that.

Re: encoder for cam-driven kicker?
 

A "free" component from the Kit of Parts (e.g. the magnetic encoder) is cheaper than any potentiometer. :p

Re: encoder for cam-driven kicker?
 

We are also using a limit switch on our cam, and it usually works quite well.

One problem we ran into is that our kicker is adjustable and at high energy the whole robot shakes enough that the limit switch vibrates and can give a false reading that has to be programmed around.

Re: encoder for cam-driven kicker?
 

Hmm... We haven't had that problem. Our limit switch triggers off of the kicker itself -- if it's 'ready to fire', the motor stops the cam until the trigger is pulled, and then runs it until the switch is triggered again.

Thus far, it's been super-solid.

Re: encoder for cam-driven kicker?
 

You've piqued my curiosity. Would you mind giving a bit more detail how the switch is mounted?

I can't picture how this might happen; certainly no amount of vibration of the switch itself (that could occur on the robot) could cause the switch to give a false reading... unless the vibration is causing the switch lever to bump against something?


~

Re: encoder for cam-driven kicker?
 

We also use a cam driven kicker. We put a simple 1 turn pot on the shaft for the kicker (not the cam where you need continuous turns). This works well for us because we have multiple positions we want the kicker to be in: one position (middle of travel) for ball collection to stop balls from going under the frame, the other to give us clearance (close to kicking) to go over the bump. It is also easier to detect a pot failure than a limit switch failure.

Re: encoder for cam-driven kicker?
 

Continuous pots work pretty well, but there are two "gotcha's::

1) The pot can shift over time due to shaft slippage. Usually not that big of a deal, but keep an eye on it.

2) (Potentially BIG) There is a gap in the pot at the wrap-around point where the voltage will float. That will give you false position readings in the gap. The gap may seem insignificant at first, but it grows over time as the pot mechanically wears.

There are two ways to cure #2. The first is to wire in a pull-down resistor so the voltage doesn't float. The second method is to put the gap at an angle that you don't need to stop the motor, stop reading the pot near the gap, do a timed motor command to get through the gap, then start reading the pot again. You may consider doing both. We were using a continuous pot at Kettering and we somehow lost the pull-down resistor. We had trouble kicking for a few matches until we figured out what happened.

If you want to use a relative encoder, your cam actually makes that quite easy. Start each match by driving the kicker motor backward with a small enough PWM so you don't damage anything. Montior the rate of the encoder. Once the encoder stops moving, you know you hit the edge of your cam. Reset the encoder position and then start using the kicker as you normally would. By doing this, you will get a very accurate zero point of the encoder every match.

Re: encoder for cam-driven kicker?
 

Great suggestion, but may not be robust for our configuration. We'd have to thread the needle between going slow enough not to damage the motor/cam, and going fast enough not to get a penalty for having the end of the kicker outside the frame perimeter for more than two seconds. Also, it would chew up valuable time in autonomous.

What I envisioned doing instead was to pre-configure the cam in the "armed" ready-to-kick position when the robot is placed on the field. Then at the start of autonomous, zero the encoder counter.

What is the data type of the encoder counter in the FPGA? Is it large enough to just let it run free without overflowing during a match ?


~

Re: encoder for cam-driven kicker?
 

The data type is double, at least in LabVIEW.

You can always convert the encoder output into degrees and do:

or the LabVIEW equivalent so you don't have to worry about overflow. Then you can always stop the motor at the same angle.

Re: encoder for cam-driven kicker?
 

Yeah, but I doubt that the counter in the FPGA is floating-point.

I want to know if the FPGA counter will not overflow during a match.


Does the above code actually write a new value to the FPGA counter itself? Or just zero the associated RAM variable in cRIO?


~