2026:Drive Base

From 1511Wookiee
Revision as of 15:39, 22 January 2026 by Mechanical1 (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

1/17/26

Today we CADed drive base 

We also created the drawings for all parts of the drive base

Img1768762236886.png



1/18/26

Today we CADed the bumpers and bumper mounting Brackets 



1/21/26

Robot Space Estimates

(Geoff teams post)

Here are the results from the space estimates for the climber, shooter, and spindexer, as well as some possible layouts for our swerve modules and frame support pieces.  All layouts use the same outer tubes , so those wouldn't need to change.  In the pictures, the climber assembly has been added in it's current state, the red rectangle represents the space occupied by a static shooter, the cyan circle represents the space required to get a full 360° rotation with our current turret idea, and the purple circle represents a spindexer that can snuggly hold six balls at its base.  The bottom of each picture is where the intake would go.  


The first picture has everything laid out the way we have been imagining it, with the swerves pointing front to back, the climber on the side, and the shooter in the corner farthest from the climber and intake.  


The second picture rotates all swerves 90° and swaps the cross-bars to go across the width of the robot.  This accomplishes two things.  Rotating the swerve modules allows the intake pivot to be mounted further forward which serves to reduce interference with other mechanisms, reduce the cantilever on the intake, and reduce the height of the intake when it is folded up.   Switching the cross-bars around would make it easier to mount the climber on the long side of the robot opposite from the intake, which would increase hopper space and reduce the cantilever while climbing.  Unfortunately, it doesn't appear that the climber would be able to fit next to the shooter given their current size, so this design is likely out.  


The third picture shows the same swerve and cross-bar orientation, but with an additional support bar added that allows the climber to move back to the short side.  This layout retains all of the benefits for the intake and removes the interference between the intake mounting and climber mounting that is present in design 1.  Additionally, this grants space for the climber to shift side to side slightly to account for our CG.  Finally, with this orientation, if the climbing motor is swapped from a Kraken X60 to a NEO 2.0, it can fit inline with the climbing axle without needing to gear off, even with a three stage gearbox.  You can see this modeled in the picture.  


Finally, picture 4 shows a hybrid swerve layout where the front two end up pointing side to side, while the rear two remain pointed front to back.  The idea was to keep the benefits afforded to the intake while providing a more integral mounting location for the climber, but this design appears to be more limiting than it is helpful.  


Ultimately, I think option 3 is best, as it gives us the most space not only for our hopper, but added wiggle room for each of our mechanisms as well.  Also, the test base that programming has is currently set up this way anyway. 

Space 1.pngSpace 2.pngSpace 3.pngSpace 4.png

Robot Space Estimates

Here are the results from the space estimates for the climber, shooter, and spindexer, as well as some possible layouts for our swerve modules and frame support pieces.  All layouts use the same outer tubes , so those wouldn't need to change.  In the pictures, the climber assembly has been added in it's current state, the red rectangle represents the space occupied by a static shooter, the cyan circle represents the space required to get a full 360° rotation with our current turret idea, and the purple circle represents a spindexer that can snuggly hold six balls at its base.  The bottom of each picture is where the intake would go.  


The first picture has everything laid out the way we have been imagining it, with the swerves pointing front to back, the climber on the side, and the shooter in the corner farthest from the climber and intake.  


The second picture rotates all swerves 90° and swaps the cross-bars to go across the width of the robot.  This accomplishes two things.  Rotating the swerve modules allows the intake pivot to be mounted further forward which serves to reduce interference with other mechanisms, reduce the cantilever on the intake, and reduce the height of the intake when it is folded up.   Switching the cross-bars around would make it easier to mount the climber on the long side of the robot opposite from the intake, which would increase hopper space and reduce the cantilever while climbing.  Unfortunately, it doesn't appear that the climber would be able to fit next to the shooter given their current size, so this design is likely out.  


The third picture shows the same swerve and cross-bar orientation, but with an additional support bar added that allows the climber to move back to the short side.  This layout retains all of the benefits for the intake and removes the interference between the intake mounting and climber mounting that is present in design 1.  Additionally, this grants space for the climber to shift side to side slightly to account for our CG.  Finally, with this orientation, if the climbing motor is swapped from a Kraken X60 to a NEO 2.0, it can fit inline with the climbing axle without needing to gear off, even with a three stage gearbox.  You can see this modeled in the picture.  


Finally, picture 4 shows a hybrid swerve layout where the front two end up pointing side to side, while the rear two remain pointed front to back.  The idea was to keep the benefits afforded to the intake while providing a more integral mounting location for the climber, but this design appears to be more limiting than it is helpful.  


Ultimately, I think option 3 is best, as it gives us the most space not only for our hopper, but added wiggle room for each of our mechanisms as well.  Also, the test base that programming has is currently set up this way anyway. 

Space 1.pngSpace 2.pngSpace 3.pngSpace 4.png