I only forgot about this for like four days and it’s still technically on time so everything is fine i swear
We were supposed to be done this week. We, uh, aren’t, but we’re “done enough” that mechanical can have our parts. By “done enough” I mean “we have a cad release with a .step and main assembly” and “if it were made now i can pretend it works”.
GrabCAD workbench link (should be the same, should also include a .step file):
Some CAD images
Intake iteration 0 (Sushi style intake in order to have one by CAD’s deadline)
Intake iteration 1 (A native claw-style intake with pneumatic actuation in order to intake both game pieces)
Final (we hope) arm
Arm gearbox (missing: brakes)
We began assembly of the chassis, and fabrication of sponsor panels.
Electrical & Pneumatics
In E&P, we were able to figure out a general layout of the belly pan that is able to contain both pneumatics and electronics. Many of the challenges we faced in planning the board came from the large number of components we needed to be on there like the Beelink or the CANdle, in which we were also able to figure out how to have cool LEDs working. In addition, we continue to work with our batteries to ensure that they are ready for competitions and analyze them through the use of Andymark’s Computerized Battery Analyzer.
During the offseason we managed to get working swerve code that can easily be translated to this year’s robot. So going into this season the main priority was figuring out how to optimally utilize swerve during autonomous periods. We began looking into pathplanner as one of our best options as unlike pathweaver, the 3rd party stuff is more suitable for holonomic drive and decoupled headings. By Wednesday we were able to get output from our drive motors that sorta matched what the trajectories we were creating. However, as we moved onto the ground we realized that our current code kept swaying to a side when we imputed a straight line for a path or could not rotate while moving. After a couple days of banging our heads against the computer we created a chief delphi posted to hopefully get some advice on where our code could be going wrong. The creator of pathplanner himself actually replied and provided some extremely helpful advice.
One problem that now seems painfully obvious in retrospect is that we created wpilib’s HolonomicSwerveController in the execute part of the command instead of the initialize. This meant that on every iteration of the command it created a new object instead of reading from the old one. Sorta insane how we missed that. Another piece of advice that we hope to start testing with on Monday is using pathplanner’s own swerve controller. Hopefully this could provide a more accurate translation of the trajectory states that are produced in pathplanner.
The end goal is to use this to reliably run 4-6 key autonomous routines that can make us extremely competitive during matches. Most of them will likely be run through top of the charging station as crossing the wire cables could mess up our odometry, although hopefully our plan to implement apriltag vision into our poseEstimator could help alleviate this potential issue.
We are still early in development for developing the code in our arm subsystem. From the amazing help of our mentors we have been able to learn a solid foundation of inverse kinematics that we hope to apply to the design of our code to make arm movement as seamless as possible. We plan to create a simulation of the arm movements to predict the PID values that are needed for the arm. The idea was explained to us by our amazing mentor Mr.Siegert.
Week 2 Recap Video:
(written by me, Chanon, William, Diego)
happy (belated) (lunar) new year!