• Welcome to Redshift Project Depot.

How the intake will work

Started by Louis L, January 11, 2018, 12:37:16 PM

Previous topic - Next topic

Louis L

This thread will document how the arm will operate from a software point of view. The goal is to describe in as much detail as possible, the operation of the arm as it relates to game play, software states, state machines,  etc. There will be some cross-pollination with the related arm (http://www.team4048.org/smf/index.php?topic=255.0) thread.

Louis L

Thought: have at least 2 sensors.

  • limit switch to identify when a Cube is properly seated flush against the rear of the holding area (whatever that is)
  • optical sensor across the gripper so we know we have a something in our grasp. This is sensor for the software state machine.

Louis L

Following the HW team meeting on 1/23/18, here is how the intake will work.

Theory of operation.
The intake ingests a Cube and presses it against the frame of the robot. There is no notch in the frame to recess the Cube. When not in use, the intake should always be raised safely out of the way to prevent potential damage from field and robot collisions. The intake's job is only to retrieve a Cube. It does not deliver the Cube to its final destination; that's the job of the arm.

Mechanical and Electrical Details.
There are 2 arms on the intake, each mounted to a carriage plate that allows the arm to swivel by some amount on the horizontal plane. The amount of movement is limited such that when the 2 arms pinch the Cube, they hold it firmly. Each arm has some tension (from unknown material - spring, rubber band, tubing, etc) to put pressure on the Cube; but not so much pressure that it the arm can not be separated by lateral forces from a Cube's presence in the intake.

Each intake motor will turn at the same speed with 4 inch high grip wheels. The carriage is deployed up and down by a 3rd motor. In the Up (initial) position, the entire assembly is inside the robot perimeter. In the Down position, it is ready for use. There are no intermediate positions. Two limit switches protect the motor that moves the carriage up and down.

Two limit switches are mounted near the rear of the arms. When deployed in the Down position, these switches detect the presence of a Cube in the holding position. The 2 switches will be wired in series and will be connected to the RoboRio. They can also be connected to the intake motors to stop them.

Both intake motors  are wired to their own motor controllers and have their own power connection on the PDP. Should we need to free up a connection on the PDP, we will drive both motors from one motor controller - this is legal for PG motors per FRC rules.

Optional feature - In the event that a Cube is ingested at a 45 degree angle, the 2 intake motors may not be capable of handling the Cube. This can be solved by either moving the robot laterally and re-engaging at a different angle, or by changing the speed on one of the intake motors to rotate the Cube into a different alignment.

Louis L

We finally got to test the Intake mechanism over the weekend. Both motors were driven at varying voltages and the tension on the arms (the amount that it is pulled together) was also adjusted.

Voltages used included 6, 8, all the way up to the max of 12 V. With the initial tension of one loop of surgical tubing, a Cube can be brought into the holding area fairly reliably. Sometimes, the Cube would fail to fully touch chassis. The Intake wheels would continue to spin after the Cube settled into its resting place - this would cause wear on both the wheel and the nylon Cube covering.

As the voltages is cranked up, the speed at which the Cube is ingested goes up. But its accuracy - the ability to get Cubes that are no lined up perfectly, did not get much better. Ways in which Cubes go bad include

  • getting partially ingested, sitting at an angle where the corner of a Cube presses against an arm and prevents the wheel on that side from contacting the Cube. This can happen at different angles.
  • getting partially ingested, sitting at an angle close to 45 degrees and having two Cube corners resting on both arms. This is the worse case and there's really no good way around it with the current design. It's best to simply avoid picking up a Cube at 45 degrees. Just move the robot!
We then adjusted the tension by stretching the one loop of surgical tubing. We didn't see a noticeable difference in performance. Thinking that the tension difference wasn't large enough, we restored the tension as originally built with 2 loops of surgical tubing.
In this configuration and again starting at 6V, the extra tension seems to do a better job of preventing Cubes from jamming in-between the arms especially at high wheel speeds. We settled on using 8V to give sufficient intake speed. The Intake wheels now press against the Cube hard enough that they stall out once the Cube as been ingested. Cube seem to consistently end up flat against the robot frame. Tension on the arm measured about 2000 grams using the scale in A006. This needs to be better quantified.

Executive summary:

  • Run the Intake wheels at 8V. One wheel will be of opposite polarity relative to the other one (exact polarity TBD when we do the actual wiring)
  • Maintain 2 loops of surgical tubing. A better metric is to have about 2000 grams of force.
  • Limit switches that detect the Cube need to act quickly to shut off power to the Intake motors when they stall. Electrical needs to remember that one motor will be moving forward and one backward so make sure the correct limit switch pins are used.
  • Software should also monitor current draw on the motors to detect stalling.
  • Electrical needs to update the PDP connection numbers on the master doc so Software knows what ports to monitor.

Louis L

Replaced TBD on previous post with 2000 grams of force.