Hi Teams,
If you haven’t yet seen, check out our uncensored teaser video!
A lot is changing for CVR. Best of luck this season!
-Mike
Hi Teams,
If you haven’t yet seen, check out our uncensored teaser video!
A lot is changing for CVR. Best of luck this season!
-Mike
absolutely amazing. you guys blow my mind every year. hope we get a chance to play together this season!
Thanks Mike, you guys are awesome. This is the purest form of FRC robot I’ve seen this year. My favorite by far
It looks like the chassis with the weighs on it is lifted slightly higher than the unweighted one. Is this some counter weighting action going on here?
Is your team utilizing the TalonSRX motion magic for your arm and elevator?
The movements on those subsystems in this video are incredibly fast. We have a system we designed to move similarly quick, but have not achieved the tuning/profile needed to make it work that well…that quickly. What advice would you give for programmers aiming to tune their systems to that level?
The difference in winching height was pretty arbitrary. We can control each winch independently if one robot is tilting further than the other.
We have a spread out wheel setup for climbing (18" in back, 29" in front), so our system is very tolerant to differing weights in our buddy bots.
-Mike
Absolutely brilliant, can’t wait to see this in action.
This is a truly incredible robot by 1678. I hope I get to see this in person!
We use MotionMagic! We purposely tune the P constant to be more aggressive then necessary, and go ham on the D to get rid of oscillation. Once we have a jerkily crazy (but accurate) mechanism over the simple Position mode on the Talon, we use those gains with MotionMagic. We tune cruise velocity to be slightly below free speed, and guess around with acceleration.
Hope that helps! Cheers
Are you guys just using a velocity feedforward for motion magic? We’re using a static friction and gravity feedforward on our arm and elevator (along with velocity for motion magic), just kinda curious what other teams are doing. One more thing, you were running a state space controller on your elevator last year, right? any reason you’re not doing that again this year?
Just wow! 1678 continues to impress year after year!
Am I right that you do not have the climbing mechanism on the robot that’s doing hatches and cargo in the video?
Yes, the programmers were working on their autos on one practice bot while the mechanical team was assembling the climber on the other bot.
How does your hatch panel manipulator work?
From the video, I could gather about this much:
So you “spear” the hatch panel with the rhombus shaped wedge. When the hatch panel is in the rhombus, the rhombus is actuated outwards such that the hatch panel can’t fall out. Then, on the edges of the hatch panel, you push out with another set of pneumatics, turning the hatch panel into a pringles shape. To release, you compress the rhombus again and back off.
I’m not sure if this is completely accurate, but I’m interested in the “pringles” shape of the hatch panel. It might have been a stray frame in the video, but you could definitely see the hatch panel taking a more conical shape. What was the rationale behind this?
This is awesome. I see some cool high strength 3D printed parts like the fork brackets. How does the arm get the hatch from the hatch intake?
Are those small red wheels on the back (front?) of the robot a ground hatch panel intake? It looks a lot like gear intakes teams used in 2017 which is what led to my conclusion.
Velocity feedforward via the built-in kF, and a gravity feedforward via the arbitrary feedforward option in the Phoenix library. We don’t use static friction, since the velocity feedforward is already strong enough to break friction every time. We’ve found that static friction feedforwards only has really tangible benefit on drivetrains.
We chose not to go state-space PWM this year, and went the CAN route due to simplicity. It is both easier to control/use programmatically, and CAN daisy-chaining cleans up wiring considerably.
The 1 kHz on-board PID has also proven to be as robust (if not more) as our state-space stuff from last year.
Cheers!
Our hatch panel intake has two “arrow” pieces that are actuated outwards by pneumatics. Like you observed, at all times except when we are scoring, the arrowhead pieces are actuated outwards. When we score, the arrowhead pieces retract and we can move backwards without dislodging the hatch panel.
The two outer sets of pneumatics were to prevent the wobbly-ness of the hatch panel while moving, as well as to fully press the loop of the panel edges onto the rocket/cargo ship hook while scoring.
The pringle shape of the hatch panel is because we have two main points of contact on the edges, which naturally bows the panel in a bit… no real intent behind the shape.
The mechanism in the video has come quite a bit since the video (think ~four iterations), so quite a bit of it has been changed since. The general idea of it is still the same!
The red wheels are a ground hatch panel intake!
Do you have an album of photos you could share?