Climb Implementation

[Michael Chau]

There is a Climber Mechanism.docx that should give a brief overview on how the climbing will be done. Due to the nature of using motors to power the climber I assume this is how the design of the climber led to the impossibility of climbing a level with one stroke of the climber. The current design latches the top static and dyanmic sets of hooks and then latches the bottom sets to get the required elevation to latch the top sets onto the next level. 

Control of the climb should be as autonomous as possible with a manual override built in. The entire climbing process is 10 stages of latching very prone to human error.

The available sensor to detect current position of the climber is an E4P Optical Encoder with either 250 or 360CPR (Counts per Revolution.) Each full revolution detected should result in 0.150 inches of movement with the current calculation.

Operator control of the climb can be all one button or split into multiple stages. Currently I imagine using 3 buttons for each level of the climb to limit the amount of autonomous. I expect the possibility of needing to have different settings for each level of the climb due to a non-smooth transition between levels. If it is possible to reuse the same settings for all the levels then 4 buttons could be used for latching each set of hooks.

The motor output will be most likely controlled by a closed-loop of the encoder to ensure there is no over or undershooting and to minimize climbing time. At this time a PID Controller is not considered by me as a needed solution due to the need of tuning it.

Moving the climber upwards to latch the dynamic sets of hook will most likely start with a high motor speed that lowers as the climber gets closer to the target height. This prevents the climber from slamming into the hard stops and missing the goal distance due to momentum of a high velocity.

Moving the climber "downwards" to pull the robot up to latch the static sets of hooks right now I imagine to be a pretty consistent motor output throughout the entire process. The motor speed being too low would stall the motors due to the need of resisting the force of gravity for the robot's entire weight. 

The climbing process will require a lot of testing and tuning to make it as accurate and efficient as possible. There is a disadvantage in time already due to our climber design being unable to have a stroke of an entire level. Reliability is definitely the #1 factor though in qualifications and alliance selection. 

Feel free to offer any thoughts about how to program the climber. The solution we end up with should be easy to modify, quick to add changes, and understandable in case of the need of modifications to the procedure during the competition season. We have had a lot of experience with shooting projectiles but not with a multiple staged climb.

[Ryan Quellet]

Michael,

Great job breaking down the climb process!  Do you think you could attach or link to the "Climber Mechanism.docx" that you mentioned?

Thanks,

Ryan Quellet

--
You received this message because you are subscribed to the Google Groups "Zeeland FIRST programming group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zeeland-first-prog...@googlegroups.com.
To post to this group, send email to zeeland-firs...@googlegroups.com.
Visit this group at http://groups.google.com/group/zeeland-first-programming?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael Chau]

Link to the file on Dropbox https://www.dropbox.com/s/r3gopyc4ezkqj1a/Climber%20Mechanism.docx

[Ryan Quellet]

See the comment from Deke below.

---------- Forwarded message ----------
From: "Deke Pyle" <deke...@gmail.com>
Date: Feb 7, 2013 12:04 PM
Subject: Re: [zeeland-first-programming] Climb Implementation
To: "Ryan Quellet" <rque...@gmail.com>
Cc: <zeeland-firs...@googlegroups.com>, <bob85-...@googlegroups.com>

I think you are spot on with what we need, hopefully we get to do some testing asap. 

Where would you like the encoder for the climb?  Or do you plan to use the pto encoder?

-Deke

[Michael Chau]

That was big oversight on my part at the time in how the climber worked. The accuracy added from bypassing the error resulting from chain slack is not worth adding another encoder for. As of now using the PTO encoders and just adjusting the distance ratio would be for the best unless there is something in the climbing or prepare to climb process that would make it worthwhile to put another encoder.

To iterate my understanding of the checklist of electrical things we have on the robot:

4 Motors & Victor 884 for Drive/Climber
1 Motor & Victor 888 for Shooter

1 Motor & Victor 884 for Shooter Belt

1 Motor & Victor 884 for Frisbee Hopper Belt

(We could use a a new Victor 888 somewhere but the shooter is the only critical place needed)

2 Servos for PTO shifting

2 Servos for Hopper locks

1 Servo for Climber lock

1 Halleffect sensor for shooter (what we used last year although there are other options)
2 encoders on PTO for drive/climber

2 Limitswitches on climber for hardstops (to my understanding this is the only place we have a limit for right now)

1 Analog Auto Selector pot (12 positions)

1 Axis M1011 Camera

1 Ring Light (I think we are getting one have to check)

If we use Y splitter PWM cables for the drivetrain CIM motors and the PTO shifters we would use 9 PWM channels and 7 Digital I/O channels all on one Digital Side Car. If we use a relay to control the ring light then we would use 10 PWM channels IIRC.