Prepare for a climbing mechanism

[kevlam2706]

Design & Fab team is going to meet this week to design a climber that can be added to the robot. The schedule is tight, and they will need software to test by the weekend.

Let's try to stay ahead of the curve by preparing the software to support the climber. There are many things we obviously don't know yet, but let's make some "worst case" assumptions, create the mechanism code, and then adjust when we know more.

Let's assume:

• it will be driven by a single motor controlled by a Talon SRX (so we'll need to assign it a CAN ID)
• it will have both a forward and a reverse limit switch to stop travel
• it will require current-limiting
• it will require driver or operator controls to deploy AND to retract (so assign some button mappings - make sure they're unlikely to get accidentally triggered during normal teleop stuff)
• assume we would drive the motor at some fixed speed (slow-ish) by manual control, and assume we will need a way to adjust this fixed speed quickly during testing

[KyleRAnderson]

Likely going to be mapped to X and B on operator controller after I move the override lift stuff to the left stick as part of #125.

[KyleRAnderson]

Basic climber subsystem and commands have been completed. Just need testing.

[kevlam2706]

Thanks Kyle. Some additional requirements, based on tonight's discussion with the Design & Fab people. The basic behaviour of the proposed (and still theoretical) climber is a bar attached to a motor that would rotate downward, lifting up the front end of the robot to the top lip of hab level 3. Think of a pole vault but in slow motion. Then two pneumatic pistons would fire to lift up the back of the robot, while the bar is still rotating and pushing the robot forward onto the hab platform. The pistons would retract, the bar would remain hanging downwards, but not touching the level 1 hab surface.

Based on this:

• Let's assume the Talon would be on CAN ID 7.
• Let's assume there's an encoder on the motor. This might negate the need for a limit switch if we set a soft limit at 0. We would need another soft limit at some theoretical point where the bar is fully extended. This value will need to be configurable of course.
• The two pistons would be on the only two remaining PCM outputs: (4,5) and (6,7). They must always fire and retract together as a pair.
• Your two button mappings are now: one button to lower the bar, another button to extend/retract the pistons.
• Note: this assumes that there is no need, and no way, to retract the bar once it starts lowering. We may need to revisit this assumption. It would be bad if we started climbing too early or needed to adjust.
• We might need to come up with an automatic sequence where the pistons extend automatically when the bar reaches some position X on the encoders OR when the robot pitch hits some degree as measured by the gyro. There could be a point in the rotation where the robot would end up falling over if the sequence wasn't completed quickly. We would need to be able to configure where X is.
• As per previous discussions, let's make the code as bulletproof as possible. So logging of errors if the systems can't be initialized properly, etc. D&F may only have time to build and install the climber on one robot, which means the code needs to be deployed on a robot with, and a robot without, a climber. Make the code smart enough to detect when the climber is present. If it isn't, it should log this at the start but not spam the console/logs.

Go go go!

[KyleRAnderson]

I'll add an additional note: might make sense to disable the compressor while climbing to maximize power available. Would that make sense @kevlam2706?

[kevlam2706]

UPDATE: no, do not disable the compressor. The pistons are huge and if there isn't enough air to fire them the compressor will need to run in the middle of the climb.

[KyleRAnderson]

Some more things that I need to do:

• [x] Remove compressor turning off
• [x] Raise intake arms (if they are not already up)
• [x] Add voltage ramp so motor doesn't go too fast initially.
• [x] Remove forward limit switch.

[kevlam2706]

Yes, we'll remove the compressor disable because those huge cylinders might require the compressor to keep running to pump the air. This might actually interfere with the idea of a timed sequence. We'll need to test this to make sure that a timed sequence won't fail and tip the robot over if the pistons are moving more slowly because of lack of air. There are possible ways to mitigate this including plumbing a few air tanks with a check valve so that they will only feed the climb pistons.

[kevlam2706]

So to summarize:

• [x] One motor driven by a Talon SRX, CAN ID 7.
• [x] Has an encoder.
• [x] Reverse limit switch to prevent backdriving into the frame.
• [x] No current limit
• [x] Set a voltage ramp of about 0.3 seconds
• [x] Soft limit on the other side. NO physical limit switch.
• [x] Constant to determine the soft limit encoder value.
• [x] Two pistons. PCM ID's 4,5 and 6,7.
• [x] Even PCM ID's (4 and 6) to deploy pistons.
• [x] Odd PCM ID's (5 and 7) to retract.
• [x] When the climb sequence is engaged, run the motor at 100% output (configurable for testing, but when deployed for real, it will need to run the motor at full power to get the highest torque)
• [x] When the bar reaches the climb threshold, fire the pistons but keep the motor going
• [x] When the bar reaches the soft limit, stop the motor
• [x] Constant to determine the climb threshold value
• [x] Do NOT run the motor backwards, at least not for level 3 climb. There is no "retract" for the bar.
• [x] Retract the pistons at the end of the climb sequence
• [x] Probably want to set all this to run on a "whileHeld" button trigger so you can cancel by letting go in case the climb isn't going well? When the button is let go the command could end by stopping the motor and retracting the pistons.

[kevlam2706]

One potential other use: We might be able to use the mechanisms to also do a level 2 climb. One way to do it might be to run the arm to a smaller angle (enough to clear the level 2 platform) and then push out the pistons, let them go out half-way or so, then pull them back in (i.e. pull them in before they have fully extended). We MIGHT need to be able to retract the arm back in and drive forward after that. I don't think we need to make any changes right now, but keep this in mind as a possible secondary use.

[kevlam2706]

Good efforts yesterday. We will revisit this but it will likely not be until after North Bay. It will be in a new gearbox which means new encoder values all around.