Mostly just curious. Who used swerves this year with 3D printed parts. Mainly parts that experience high loads, example wheels, forks, pulleys. Also how has the experience been, do the parts hold up?
2 Likes
We’ve been prototyping our swerve module during the off season. We’re replacing most of the 3D printed components with metal as they get finished in the machine shop. The parts were good enough to test fit and function but I wouldn’t trust them on a chassis under load. That said, a few printed parts may remain - encoder mounts, motor mounting plate standoffs, etc. Basically components that don’t see much load.
2 Likes
We check all your items.
Wheels- printed
Forks- printed
Pulleys- printed
Bushing for rotation- printed
They held up great, granted we have been doing that style since 2019. Printed on mark forged with fiber where needed.
4 Likes
Thrifty Swerve. Through the year we had two failures (at the same competion) that were root caused backed to turning the modules sideways as we rotated full speed over the on-field wire way.
They worked fantastically outside that one issue.
2 Likes
That said, I’d plan for a field with higher impacts than this year, the wire cover being the main one. In 2019, we overloaded 3d parts when moving onto the lower ramp, which is not even that much more of an impact than on flat carpets.
ahem
just gonna leave this here.
New SLS Powder: Glass Filled Nylon 12 for Strong, Heat Resistant Parts
– a formlabs employee
edit: it is actually stupid how strong Fuse 1 parts are. My EE brain just can’t comprehend it, as there are neither E-fields nor B-fields involved.
8 Likes
7561’s swerve had a large number of structurally critical parts 3D printed, such as the forks. All held up quite well! Linked is the development thread, from start to comp
1 Like
3005 ran a largely 3d printed swerve module (originally based on the Coussens swerve module). We did a ton of development throughout the season. The reliability at the beginning of the season was pretty atrocious but we chased down the failure points and ended up with a reliable module by the end of the season. Still a few more known improvements that couldn’t be implemented in the time we had as well.
Several parts that were printed at the beginning of the season ended up needing to be metal. At the end of the season the 3d printed parts were:
- Forks
- Wheel (including printed tread)
- Steering plate (this included the pulley and the forks screwed into this)
- Top cap (tied the rotation of the module into the steering encoder while dodging the drive gears)
- Steering pinion (GT2 pulley that replaces part of the output on a UP)
- Corner post (basically a standoff with side holes in the extreme corner of the drivetrain)
All of these parts were printed with a Markforged out of Onyx.
2 Likes
The Coussens swerve module will return with a new iteration in 2022…
3 Likes
Team 6002, ran a modified “Coussens swerve - 2019 winter version”; 3D printed fork/turrets, wheels, steering pulleys with 9mm Gt2 timing belt with Lamprey encoders. The top and bottom plates were milled from polycarbonate sheet on our CNC router. This was faster then 3d printing them. The 3D printer parts were printed with polycarbonate carbon fiber filament on a Voron printer.
The 3d printed parts survived the season with one failure. In our first tournament, one of the folk broke because of bad layer adhesion.
Thru-out the season, we experience several difficulties. We survive several drops from the traversal bar. We experienced a problem, where one of of wheel would be 180 degree out of sync while running the autonomous routine. This problem was not resolved until mid way thru our third tournament. We also ran full speed at a wall from 12ft away; it destroy the 30T aluminum drive spur gear, however the 3d printed parts survived.
We played as the defense robot during the playoff at the Michigan State tournament.
It was a good overall experience for a first time swerve team.
I’m curious to hear more about your experience and see some pictures if possible. Specifically, curious to see what orientation you printed your fork in that resulted in the layer adhesion failure you mentioned, as well as better understanding how the 30T spur gear failed on the impact you mentioned.
Glad you had a good experience with it. I highly recommend adopting one of the newer versions of my module for the future, and as I said above, I will have a new iteration published sometime later this year.
The failed fork was printed upside down on the bed with support. The print speed was set to 120mm/sec with 10K acceleration- too fast, not enough time to fully melt the plastics. It was cold extrusion not the print orientation that caused the failure.
Here is a picture of the aluminum gear after we straighten out the teeth to finish the tournament. We didn’t have a backup gear. This was mesh to a steel pinion gear. The teeth were “rolled” over.
Here are some pictures of the swerve assembly
:
We are changing the 9mm GT2 belt to a 15mm HTD belt.
2 Likes
I try to print the forks on their side so the later line direction ends up being vertical, which makes it very difficult for the fork to break.
Not sure why a high speed impact would have caused the tooth to roll over as you describe, so that’s odd.
How did the lamprey end up working out for you?
1 Like
As to the damage of the aluminum gear, we couldn’t change our auto routine selection from our 5 balls to 2 balls before the match. So the robot was trying to travel 20+ft with a wall at 12ft in its way; trying to move beyond the wall caused the damage. We didn’t have current limiting set on the motor controller or a collision detection system. As you can imagine, there was not much tread left on the wheel.
The lamprey worked well. However, using it for the first time presented some challenges with setting it up. We originally has it wired to the spark max using the analog input. We noticed sometime, one of the wheel would be 180degree out of sync. We thought it was the spark max averaging the 0/360 position to 180, so we wired it directly to the roborio using the pwm signal. It turned out to be, the spark max was not getting its parameters set on initialization. We a not sure of the cause, but we fix it by sending the spark max parameters as the first step of our auto routine. The lamprey did have a problem where it would require re-calibration upon boot-up that has since been fix with the new firmware.
We would use this swerve module along with the lamprey again.
Based on our testing, PWM input was the way to go on the original Lamprey. We didn’t succeed until we switched to that.
A REALLY important thing to know: the -old- Lampreys need to have the RX wire terminated to prevent noise pickup from the motor and drives. There is -also- an updated firmware that turns on the internal pull-up resistor for the same function. Here’s a link to where the issue was identified/solved:
1 Like
Question: did you get consistent voltage ranges for each of the Lamprey sensors? When we were using them during 2020, it seemed like each sensor would put out a slightly different voltage range such that we had to put in different scale factors for each module to get the degrees/volt. This was not a huge problem but it does make swapping out modules messy and also transferring the code from the practice bot to the comp bot. But we were still trying to get them to work directly with the SparkMax and we did not go the route of the PWM signals to the RIO. I’m wondering if the voltage range differences were an issue with the SparkMax interface or with the Lamprey itself.
We didn’t get our summer swerve chassis working well enough to really discover if the PWM scaling was funny or not. We did find that the analog output had some weirdness on it. All four of our Lampreys had a periodic small square wave error in the position signal after the RoboRio processed it from PWM into position. This was not correlated in time between the four Lampreys, but all of them had it and the on-time and period of the error signals weren’t very far apart. We were unable to find the source of this, but we saw it both on the RoboRio and roughly on a scope (it’s very difficult to measure with a scope). When I returned one of the four to Andy he was unable to reproduce the problem. He really tried a lot of ways to hunt for it! Its possible that this is connected to the known floating RX line issue, but I kind of doubt it, as there were no motors running during our tests.
The new Lamprey2 is available at Andymark and many of these issues are now solved.
Also 12-bit resolution!
4 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.