We printed all the wheel guards on our Markforged printers. We went through a couple iterations of the design on these after encountering some issues that we ended up fixing leading up to MTTD. The first image is our previous version (which we took to Chezy), second is the final (which we took to MadTown).
The first issue we found was that the hole clearance on the first iteration was too tight to remove the wheels, which made it tedious to replace tread when it wore out. There were also a few other issues we found when we started driving. The cone-shaped chamfer often broke when driving over the steel bars at the rendezvous point, and the bolts we used to mount these to the drivetrain rails were previously the same bolts that held the modules on, so when the guards would break it meant the modules weren’t strongly constrained to the rails.
For our final version, we increased the diameter of the hole for wheel removal, and we made some of the mounting holes large enough to fully clear a socket-head bolt. This made it so that we could have four bolts mounting the module directly to the frame and another four mounting the guard to the frame, so that if the guard broke it wouldn’t impact the integrity of the module. Finally, we changed the shape of the chamfer from a cone to the pyramid shape (below) so that we could add some 1/4"-20 flat-heads in to hold the layers together. All of these changes helped us get through MadTown with no broken wheel guards.
Thanks for sharing all of this really appreciate it. I really like your idea of putting bolt all the way through. Really makes it a lot stronger. Did you fell like it helped protect the swerve drive. Also where they 100% infill or what settings did you use for the markforge
Having the bolts all the way through definitely helped keep all of the layers together, preventing the modules from getting damaged. The previous versions left the modules more vulnerable since the bottom layers of them tended to rip off when we hit the rendezvous bars. As for what settings we used, we were able to get away with the default 37% infill and didn’t need to use reinforcement material or adjust any other markforged settings. Every guard was printed at either 0.1mm or 0.125mm layer height depending on when we needed them completed.
That is really good to know. We just got a markforge to trying to figure out what settings to use for parts that will see impacts. Thanks for sharing
Thank you for your questions!
- We switched to the polycord for the intake after we had issues with 3D printed pulleys getting shredded by the belts we were using, and to prevent slipping we just made sure that the pulleys had really high flanges so they wouldn’t fall out.
- The 2020 climber rotates upwards by tightening spectra cable that’s tied to the pulleys on the hex shaft below the arms, which brings the arms in from their resting position, and also releases the arms out of the larger tubes, and that position gets locked with the latches on the side bars. We can then tighten the polycord further pull the arms in and climb.
- Our design lead Zach Hoblit, talked a lot about wheel guards in a different response: Citrus Circuits 2020 and 2021 Code and CAD Release - #22 by zhoblit.
- Yep, we experienced issues where the flanges of the bearings would actually pop off during matches, and we ending up actually switching to using bushings for the 2020 robot. Those issues were the reasons we switched to having bearings on all sides yep!
- For our team, we try to pick which bellypan to use based off of the robots packaging. In 2020 we tried the normal regular bellypan, but it led to major issues for wiring, so for the 2021 bot we reversed the bellypan to make it easier to access electronics. The main added difficulty with the reversed bellypan is making sure that there are cutouts and holes for routing wires, and making sure that the battery is secure.
like replacing a PDP wedged half under the indexer at LAN 2020. Big fun.
I physically winced being reminded of this moment haha. Big (not) fun!
What was the logic behind having an 8 falcon drive on your 2021 bot - is the robot not traction limited already with 2 falcons?
It’s swerve drive. 4 modules, 2 falcons/module.
I was looking at their tank drive robot clemen-teeny which has 4 falcons per drive side.
l notice that your team has used some LED strips on your robot. Can you provide the buying URL of your LED strips since our team also wants to use LED strips this year but we can’t find where to buy it and but which one?
Thanks a lot!
I’m not @Michael_Corsetto but if I’m remembering last year correctly i can put a little color behind the logic, not sure which of these factors was the primary motivator…
The track drive absorbs a ton of energy in both internal efficiency loss and scrub forces, and iirc they were at like 20+fps too(?), so very little torque per motor to push past those first two factors.
They had the PDP slots and the budget, combined with a very tight execution timeline and minimal experience with tracks = no reason not to throw an extra motor on at design stage.
Once they did, spreading the torque requirements (ie current requirements) out over four motors allows for much lighter footprint on the battery usage, and more continuous practice/film runs between swaps.
How did you guys import your swerve modules? I am trying to, but they keep coming without mates pre-applied. They might not, but I just want to make sure that I am not doing something wrong.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.