Here is a sneak peak at Team 7042’s Traversal Climb! We continue to work some mechanical and software tweaks with the end goal of automating the entire climb process with a total traversal climb time less than 15 seconds.
See you all at the Orange County and Los Angeles Regionals!
do i hear falcons… screaming?
Based on how fast those are extending and how slow / strained they are at retracting, I think you may be operating those motors on the wrong side of the power curve. It’s entirely possible that you could actually speed the climb up by adding a greater reduction to those motors, just by putting them under less load. Depends on your exact gearing. Just something to consider!
Otherwise, this is very cool and a neat design I was really hoping to see someone do this year. Really has that monkey-bar climb feel.
Looks very promising and very controllable (i.e. not a lot of swinging).
Is there a reason why you don’t reach for the trav bar with the left arm after climbing to the high rung with the right arm? Seems like it would save you a hand-off.
Also is there a reason that you transfer the weight of the robot back to the left arm and disengage the right arm at the end rather than just finishing once you are hanging from the right arm?
Faster every time. Poor kid looks stressed… they’ll be happy once its automated 
Also, I think those were R2D2 sound effects.
In this video the Falcons are running at very low power (manually) to hold their position, which is causing a bit of a stall condition. The falcons will make those noises even at low power when near stall. Our automated sequence will run with a vastly improved power curve to prevent this.
Also, when the arm is fully retracted, we use pancake cylinders to lock the arms in place, so there will be no load on the motors when hanging in the final position.
Yeah he’s trying to run the drive and climb with 2 controllers at once. I suggested we just set this up as a test controller to run through everything (and use our button panel) but the programming students insist on making things more “interesting” 
Yes, great question –
The left arm in this video is static and does not pivot. There are several reasons for this (including the amount of space a pivot arm needs behind it to avoid hitting other components, as well as structural reasons).
During testing we discovered that sometimes, the CG of the robot swings that static arm slightly away from the bar. To engage the high bar, we have to pivot the right arm back, which actually rotates the frame forwards and forces the static arm into the bar.
Regarding the weight transfer at the end – I reminded the students that once the weight transfer to the traverse bar is completed, we are effectively done. The weight transfer back to static is just a bonus to stabilize on the traverse bar, and this may help move side to side a bit to help get another team more space to climb to the bar as well.
Quick note about extend/retract speeds –
The initial release is a spring-loaded release. The arms are held in place during the match with pancake cylinders and an unloaded winch line. So these go up quickly.
The pivot and static arms are using 15:1 and 16:1 reductions respectively. When we did the torque calculations for this design originally, we determined those reductions were sufficient with margin to lift up the bot with our winch design. the climb can therefore be much faster than shown. The student controlling manually here was being cautious and trying to prevent swinging so I think he was running around half speed. So, I completely agree that we are on the wrong side of the power curve here, and can probably afford a greater reduction in exchange for keeping the motor rpms up a bit higher. Additionally, a higher reduction will help reduce backdrive (we already use brake mode). We will take a look at this tomorrow.
Running these at a very low speed in software also would explain some of the struggle sounds your motors made. If that control was just percent voltage, then you’ll get more torque as you increase the power and the problem should solve itself.
Leaving the bars unwinched and releasing the pneumatic lock to extend quickly at the beginning is a very clever way to save a couple seconds! Good thinking.
Sad robot noises
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.