Hardware interface map

[Louis L]

This thread will always reflect what the hardware looks like from a software point of view. The top-most posting will be updated as necessary.

See the corresponding document in the hardware section that contains the a summary of all hardware subsystems. Link http://www.team4048.org/smf/index.php?topic=279.0

Overall Table
This is the master table. It contains all the important stuff that needs to be wired between the RoboRio and the external hardware. However, it does not contain all wiring. For example connections between limit switches and controllers are not listed. See the respective section below for more details.

Index	CAN (PDP#)	DIO	PWM (PDP#)	AIN
0	PDP	unused	unused  (Talon SR @ #8)	absolute encoder FR
1	Steering FR (SRX @ #11)	unused	unused  (Talon SR @ #9)	absolute encoder FL
2	Steering FL (SRX @ #4)	unused	unused  (Spark @ #6)	absolute encoder RL
3	Steering RL (SRX @ #5)	unused	unused	absolute encoder RR
4	Steering RR (SRX @ #10)	unused	unused  (Spark @ #2)	Sonar Right (WPIlib)
5	Drivetrain CIM FR (SRX @ #15)	Distance quad A	unused	Sonar Left (WPIlib)
6	Drivetrain CIM FL (SRX @ #0)	Distance quad B	unused	unused (WPIlib)
7	Drivetrain CIM RL (SRX @ #1)	unused	unused	unused (WPIlib)
8	Drivetrain CIM RR (SRX @ #14)	unused	unused	N/A
9	Pigeon IMU (chassis)	unused	unused	N/A
10	Elbow (SRX @ #13)	N/A	N/A	N/A
11	Arm (SRX @ #12)	N/A	N/A	N/A
12	Pincher (SRX @ #7)	N/A	N/A	N/A
MXP0	unused	N/A	N/A	Sonar Right (LabVIEW)
MXP1	unused	N/A	N/A	Sonar Left (LabVIEW)
MXP2	unused	N/A	N/A	unused
MXP3	unused	N/A	N/A	unused

Joystick and Control
USB0 is left joystick (X/Y control)
USB1 is right joystick (rotate)
USB2 is gamepad

IMPORTANT

• Numbering will go FR, FL, RL, RR, in that order. As long as we are consistent, we'll be fine!
• To protect motors and the robot as a whole, software should, whenever possible, check all motors for stall condition (current draw) and have a timeout for each operation.

Drivetrain and Chassis
Four AndyMark AM3009 Swerve drive modules. Each consists of a CIM drive motor and RS775/PG71 steering motor. The digital signal from the PG71 encoder is fed to the Talon SRX. Absolute analog encoders output is fed to the RoboRIO.

Motor Controller (CIM) - 4 x TalonSRX
Motor Controller (RS775/PG71) - 4 x TalonSRX + breakout board
CIM FR - CAN 5
CIM FL - CAN 6
CIM RL - CAN 7
CIM RR - CAN 8
Steering FR - CAN 1
Steering FL - CAN 2
Steering RL - CAN 3
Steering RR - CAN 4
Absolute encoder FR - AIN1
Absolute encoder FL - AIN2
Absolute encoder RL - AIN3
Absolute encoder RR - AIN4

Distance CIM encoder, quadrature output A - DIN5
Distance CIM encoder, quadrature output B - DIN6

Intake
Two RS775-5 motors with CIM-SPORT 4:1 gearbox, one on the left and one on the right will suck in the Cube. Each has its own motor controller but they run off one PWM cable since they run in tandem. A pair of limit switches mounted at the rear of the cube storage area will be series wired and report back to the RoboRio that a Cube is present. These can optionally be wired to the controller's limit switch to stop the intake motors.

Motor Controller - Left Talon SR @ PWM0, Right Talon SR @ PWM1
Intake limit switch - two wired in series @ DIO7

One Bosch seat motor is used to deploy (raise and lower) the intake assembly. Two limit switches will define the up and down limits of travel. The limit switch signals will also be sent to the RoboRio for software detection. The Bosch has an output encoder that we may use. For now, just rely on the limit switches since its only ever used fully up or fully down.

Motor Controller - Spark @ PWM2
Limit switches @ DIO1 and DIO2

Arm
One mini-CIM with a 64:1 CIM-SPORT gearbox is used to move the arm up and down. This is controller by a Talon SRX with a optional local PID. Two limit switches prevent the arm from moving outside its expected range of motion.

Motor Controller - Talon SRX @ CAN 11

One PG27 gearmotor drives a lead screws for 12 inches of travel to extend and retract the arm to keep it within the 16 inch boundary. There is one rotation per inch of travel. Two limit switches will limit the travel of the extension. A multi-turn potentiometer reads the rotation and returns a voltage value to the RoboRio to report distance (it does not go to an SRX because the extension to height curve is complex and better off controlled by the cpu).

Motor Controller - Spark @ PWM 3

Arm rotation potentiometer, continuous, 5K linear, 0.25W, plastic, 10% 
Extension potentiometer. 10 turn, 1K linear, 2W wirewound 5% - MXP AIN3 (also AIN7)

Claw
There are several sensors on this subsystems; some are local loops and some go to the RoboRio.

One snowblower motor open and closes the claw to release and grip the Cube respectively. There is no backdrive so once we grip the Cube, we can turn off the motor. Two limit switches define the absolute min and max positions of the opening.

Motor Controller - Talon SRX @ CAN 12

Another snowblower (?) motor pitches the gripper up and down. Two more limit switches limit the motion of this rotation. It would be advantageous to keep the Cube level during transit. An Analog Devices ADXL362 MEMS accelerometer can be mounted on the claw. A 10 wire cable carrying SPI signals to the RoboRio will allow the software to level the gripper. Note that this leveling should be done when the robot is still as motion will likely throw off the sensors.

Motor Controller - Talon SRX @ CAN 13

A switch mounted on the gripper will sense the top of the crate when it makes contact with the gripper. Since crates can be either 11 or 13 inches off the ground, we need to know when to stop lowering the arm. This sensor will be wired directly to the RoboRio

Limit Switch - DIO 0

An optional pressure sensor will tell software how much force is exerted on the Cube. Software can also monitor the current draw on the motor to determine when to stop driving the motor.

Pressure sensor - MXP AIN2

Climber
One Mini-CIM with a 64:1 Banebot P80 gearbox is used to pull the robot up. This is controlled by a Talon SRX and can be monitored over the CAN bus for current sensing (if needed). Alternatively we can use any other motor controller; or even a Spike relay.
Motor Controller - Talon SRX @ CAN 10

? One sonar mounted at an angle such that when the robot is hanging, it is pointing down. This is used to display a rough height on the console during the climb.
Sonar @ MXP AIN1

A limit switch is located on the climber such that when it is properly latched onto the Rung, the switch will inform the RoboRio that it is safe to start climbing.
Limit Switch @ DIO3

Pincher
This device replaces the old Claw/Gripper. It consists of 2 arms that open and close around a Cube to grab it. It is powered by a Snowblower motor attached to a Talon SRX (CAN 12 PDP 7)

Elbow
This joint replaces the Wrist. It is powered by a PG71 connected to a Talon SRX (CAN 10, PDP13). It has limit switches and hard stops that prevent it from moving outside its intended range of motion.

Camera
One Microsoft HD3000 camera mounted towards the front to give the drive team a forward view when grabbing or placing Cubes.
Actual location is TBD. Note that the camera has about a 68 degree horizontal and 30+ degree vertical field of view.
HD3000 @ USB port on RoboRio.

[Louis L]

Adding joystick and game controller definitions.
USB0 is left joystick (X/Y control)
USB1 is right joystick (rotate)
USB2 is gamepad

[Louis L]

Has anyone thoughts about sensors? Here are some I'd like to see.

• limit switch to know when we've acquired a Cube.
• pressure sensor to know when we're done squeezing the Cube.
• potentiometer for the arm's rotation.
• potentiometer for the gripper's rotation.
• limit switches to control the gripper's open/close motion.
• forward facing sonar to detect if we're too close to the Scale - avoid bumping or touching the scale
• limit switches to tell software whether the intake is up or down. Can be the same that tells the motor to start and stop.

I'm sure there's more. Let's hear it.

[Louis L]

Added more details to Climber and Intake in OP

[Louis L]

Added more details to Arm

[ohad z]

A couple of questions/comments:

• There seem to be a few inconsistencies (unless I don’t understand the notations) in the drive/steer motor definitions above: CAN IDs are 1-4 (steer) and 5-8 (drive), right? The table seem to indicate 0-3 and 4-7. Also, the wheel order is FR-FL-RL-RR (there is mention of FR-FL-RR-RL as well)
• If we are short of SRX units, we may want to experiment with SR or PWM for the drive motors - they do not require any of the fancier modes and we are using them with no feedback as of now.  Even if we want to use feedback loop for them, since we only have one distance encoder, we may need to use the software PID since SRX PID would require 4 encoders. This may free up SRX for the intake and claw.
• Arm is long and heavy. Will have to make sure whatever sensor used (Potentiometer) is sensitive and with enough resolution to be able to control the end of the arm with enough precision to avoid sway and missed goals. If in doubt, we may need to aim higher and let the cube drop.
• How about IR sensor for the cube in the intake?
• Some feedback (pot or encoder) for the extension mechanism
• A concern was raised about engaging cubes that arrive at an angle and one idea was to engage different sides of the intake separately to get the cube aligned. Would require additional controller.

[Louis L]

A couple of questions/comments:

• There seem to be a few inconsistencies (unless I don’t understand the notations) in the drive/steer motor definitions above: CAN IDs are 1-4 (steer) and 5-8 (drive), right? The table seem to indicate 0-3 and 4-7. Also, the wheel order is FR-FL-RL-RR (there is mention of FR-FL-RR-RL as well)
• If we are short of SRX units, we may want to experiment with SR or PWM for the drive motors - they do not require any of the fancier modes and we are using them with no feedback as of now.  Even if we want to use feedback loop for them, since we only have one distance encoder, we may need to use the software PID since SRX PID would require 4 encoders. This may free up SRX for the intake and claw.
• Arm is long and heavy. Will have to make sure whatever sensor used (Potentiometer) is sensitive and with enough resolution to be able to control the end of the arm with enough precision to avoid sway and missed goals. If in doubt, we may need to aim higher and let the cube drop.
• How about IR sensor for the cube in the intake?
• Some feedback (pot or encoder) for the extension mechanism
• A concern was raised about engaging cubes that arrive at an angle and one idea was to engage different sides of the intake separately to get the cube aligned. Would require additional controller.

• The 0-3 and 4-7 numbering inside the parenthesis is the physical PDP connection (where the wiring goes to the breaker on the PDP - so we can trace wires if needed). The Index column is the actual CAN ID. It would have been nice to make them the same but that's just not possible. I'll fix the FL-FR-RR-RL typo.
• Nothing wrong with sw pids; everyone used them before the SRX came along. We'll use them where we can. One important consideration that we don't often talk about is the wiring requirements. If we have an end effector (say a claw) that's far from the rest of the electronics, and we have a need to do a PID and/or have limit switches, it's better to mount the controller near the effector and run just power between the controller and PDP than it is to mount the controller near the PDP and then run motor and all control signals down the arm. So localizing feedback loops by using an SRX is great when distance is taken into account. Up close, it's not a big deal. We have a lot of SRXs in stock.
• I'd like an IR (opto) sensor on the claw. It'll be redundant if we use the pressure sensor. They are really effective and simple to use.

[Louis L]

I forgot to add that if we are short on SRX controllers, we can just replace any of the 4 controllers that drive the CIM motors on the swerve drives. We don't currently implement any local closed loop processing so any PWM-based controller can be used. The benefit of using an SRX in this case is the use of the CAN bus to simplify wiring - though even that is not as great as it sounds because of all the connections from controller to controller that must be made. The real benefit is in the reduction of PWM cables, thus allowing those PWM slots for other uses.

[Louis L]

Updated the gripper description for the accelerometer that will sense level-ness. The AD part does not plug into the SRX but rather into the RoboRio. We'll need a long 10-wire cable and let software take care of the leveling.

[Louis L]

Updated the Extension feedback device from a Quad Encoder to a multi-turn Potentiometer.

[ohad z]

Hardware map missing a few of the limit switches (e.g. arm up/down and extension in/out, gripper switch)

[Louis L]

See 3rd paragraph in OP. Most limit switches are not listed because they are wired to a local loopback at the controller. Only a few are wired to the RoboRio.

[Louis L]

Added Rung Detect switch to DIO3

[ohad z]

(Maybe I’m wrong) should you have Talon SRX for local feedback of limit switch? In this case you’d need the extension to be SRX rather than spark.

[Louis L]

No; the Spark, Talon SRX and Victor SP all support limit switches. Only the Talon SR does not.
The Talon SRX also supports other inputs like analog and digital I/O.