Update intake to use Hall effect sensor inputs rather than potentiometers to read angle

[gerth2]

We're using two of the Bosch seat motor for the intake. We are going to switch to reading the position using the built in hall effect sensor, rather than the potentiometers. (Due to testing Monday night showing an inability to get good readings from the potentiometers).

The hall effect sensor just outputs digital pulses for rotation - it doesn't matter the direction, you just get pulses. See the datasheet for more info. Each "pulse" has two edges (one "rising", one "falling"). There are 174.9 pulses per rotation of the output shaft. However, there is no direction information encoded inside this signal. We will need to assume direction of travel.

Since the motor is connected to the output via a worm gear, for software purposes, we can largely assume that external forces on the arm will not move it. Therefor, we will use motor command to assume direction. Any pulses read while motor command is in the positive direction will be assumed to indicate forward (extend) motion. Any pulses read while motor command is in the negative direction will be assumed to indicate reverse (retract) motion. Any pulses read while zero is commanded to the motor should be assumed to be noise, and discarded.

We will use the WPI Counter API to track the number of edges read from the sensor. See this CD post for some background info on setting it up. A few additions: 1) We should only have an up-count source, no down-count source. 2) To increase resolution, we should count edges, not pulses. setSemiPeriodMode() will insure we get two edges (both rising and falling) per pulse. 3) Use setSamplesToAverage() to ensure we debounce each edge a bit. I'll say let's start with 4 and go from there.

Use the following algorithm to calculate position:

Per each side of the intake:

Have a class-global variable double curPosDeg indicating the current position, in degrees. This may already exist under a different name.

Once per loop, in a sampleSensors() or similar routine: 1) Read the difference between the current edge count (.get() from Counter) and the previous edge count. This will indicate the distance traveled during the time between the previous loop and the current one. 2) Multiply the edge count by the proper conversion factor to get a value for deltaDegrees - the magnitude of the angle change from the previous loop to the current one.. 3) If the motor command was positive during that period of time, add deltaDegrees to curPosDeg. If the motor command was negative, subtract deltaDegrees. If the motor command was zero, assume deltaDegrees was just noise and don't change curPosDeg.

Replace all the instances of using analog inputs for position measurement with this new strategy. Ensure the old variables for indicating position are populated the same way.

Like all encoders measuring an absolute position, we will still need a zeroing-strategy. Here is my initial proposal:

1) Each individual side of the intake should provide a method public void resetPosition() that sets curPosDeg to zero immediately. 2) Intake & Robot.java should be updated to call resetPosition() at the following times: a) In robotInit(), so the power-on assumption is intake-fully-retracted. b) Whenever the USER button on the roboRIO is pressed, and the robot is in Test mode or Disabled.

The thought here is that the robot should always power-on with the intake in the zeroed position. This will be the case for all competition matches. It must be a pit checklist item, as robots cannot be enabled on the field.

If during practice or at the warehouse the arm is not started in this position, the alternate method is to use Test mode to manually put it back, then press the USER button to indicate it has been aligned.

Additional notes: Update the arm PID to have a "on-target" degree range reflective of the fact that over 180 degrees of motion, we will only see ~170 edges (so less that 1 degree of resolution). I think if we're within 5 degrees, we can say "good enough" and turn off the motors.

Confirm the arm motor controllers are both running brake mode (maybe software configurable?). This will make sure when we command zero to the motor, they actually stop as quickly as possible.

[imdunne8]

Since we may need to build these, another student should find the required resistors to build the circuit. We'll need two of each of the following. If you can't find an exact match, see if we have something close. Anything within 10-15% is almost certain to work correctly. 180 Ohm 220 Ohm 5.6 KOhm These can be found in small bags in the electrical component box (green/tan tackle box). This link can be used to calculate resistor values if they aren't labelled. We'll eventually need to build this circuit, so if a couple small proto boards can be found it would also be helpful.

I also did get two adapters for the better quality potentiometers printed and test fit. I would guess we can have those mounted in the first half hour tonight - I think it's fair to say now that it takes priority over most other things going on with the robot.

[gerth2]

Speaking of priorities, I talked briefly with Asit this morning about "what still needs to be done". I'm going to consolidate the on-robot test into one issue and list out the order of things. There are largely 3 "buckets" of tasks that we have to complete. Each bucket must be emptied before we can move on to the next one.

[gerth2]

Updated #67 to have the full list.

[Treecko120]

Think I finished this. Needs testing. Also probably not needed... :(