WCP Swerve X Flipped - Team 5550 Journey

Team 5550 decide to jump into swerve this offseason and thought I would post about our journey.

The first decision we had to make was what motors we had currently that we would feel comfortable dedicating to this project. We have a total of 10 falcons and with us not being sure if we could get additional ones any time soon decided to see what options we could come up with to only use 4 of them. We do have plenty of CIM/MiniCIM motors, Talon SRX controllers and Mag Encoders, so that seemed like a viable option to use for the turning part of the swerve module.
In looking at the SDS and WCP flipped options available only the WCP Swerve X appeared to have the option of using CIM motors as the turning motor, so we decide to order 4 of the Swerve X Flipped Tube mount modules back in July and received them in the middle of October.

Things we’ve learned so far:

Separate Parts by Steps for Assembly - The parts were not labelled and the person assembling them didn’t know the difference between a Thunderhex bearing and a non-thunderhex bearing was so we had to redo a few steps and swap out some bearings at times. After completing the first one I then sorted all the parts out by steps and had a zip-lock bag for each of the steps to make assembling the other 3 modules go much smoother.

Press Fit Pinions on CIM issues - We remove the back casing from the motors and attempted to press the 9 tooth pinions on the MiniCIM shafts and ended up bending the shafts in the process. We did eventually take one of the motors to an expert who eventual got it on, but it required removing a slight bit of material from the inside of the pinion. At this point we started investigating other options that would make more sense for us. We decided to use a 10 tooth keyed pinion, and adjust the gear sizes of the other gears in the turning portion of the module. It changed the ratio from about a 12:1 to a 11.75:1, so we don’t think that will make much difference.

MiniCIM Interference - since the MiniCIM has a slightly bigger diameter than the Falcon, one edge of the tread on the wheel does ever so slightly hit the motor when turning. Currently we have 3D printed tread that we beveled the edge on, so it currently isn’t an issue, but we’ll have to keep this in mind when trying out different tread.

WCP 5550 Swerve Tread

We built a 26" x 26" frame with a belly pan and have attached all 4 modules to the frame. Next step is getting everything wired up and start working on the programming.


Here is an update - 2 weeks later

Wiring is complete and all the controllers have been configured and assigned their unique numbers.

Encoder Mount Change - The encoder mount that came with the Swerve X was not getting the encoder close enough to the magnet and resulted in all 4 encoders having an orange light instead of a green light. We sanded down the posts on a couple of the encoder mounts until we were able to get the encoders to show a green light. We have since gotten the STEP file for the encoder mount from WCP and used OnShape to make the needed modifications and are printing new mounts.

Another change in the mounting of the encoder was to flip it around 180 degrees to get the ribbon cable away from the gears. This resulted in a needed change to the gearbox cover one of our students designed. See picture below. Should have all the gearboxes printed by end of day tomorrow.

Software Status - We communicated with @mjansen4857 about PathPlanner and whether the example code we were using would integrate well with PathPlanner. It was suggested that we look at switching from Timed based to Command based, but that either style could be made to work with PathPlanner. At this point we are going to stick with Timed based.

We have worked out our plan for using the Mag Encoders for getting the initial direction the wheels are facing so that we can get everything initialized correctly.

For PID control we are still going back and forth on using the Controllers for the PID loops versus the RoboRio ( this is what the example code we started with is doing), but I think we are headed down the path of letting the controllers handle that piece.

Next Steps - Prepare the code for tuning our PID values. Purchase carpet for the workshop for testing the robot. Install new encoder mounts and gearbox covers. Begin introducing the students to PathPlanner.


Another Update - 2 weeks later

Here is what the robot currently looks like

Software Status - Our plan for using the Mag Encoders to initialize the direction the wheels are facing worked out great by grabbing the pulse position from each encoder and comparing that to what the pulse position would be if the wheel was at zero degrees.

PID loops were tuned and they are running on the controllers. This video shows our initial attempt at tuning the steering PID loops. As you can tell the wheels oscillated a bit at the end so we bumped up the “D” value to take care of that. We did base our starting PID values off of 364’s swerve drive code which was helpful.

It did take us a bit to figure out that we needed to invert our steering encoder in the code. Initially we thought we had defined the locations of our modules incorrectly, so after messing around unsuccessfully with that for a bit we finally got around to doing that to fix our issue.

Here is a video of it moving around. We have very limited space in our workshop so we could only do so much testing and we had to drop the max speed way down. We did have one module where the wheel decided that zero degrees was in a different direction, so we have marked that module and will continue testing to see if that same module continually messes up or if other modules have the same issue. Our guess at this point is that the wiring needs to be looked at on that module.

Here are our 3D printed items and Java Code
Onshape Encoder Mount

Onshape Gearbox Cover

Current Java Code

Finally we showed PathPlanner to the students and how you could build paths with it. We still haven’t incorporated any pathing into our code, but that is the next step.


Just out off curiosity, What filament are the treads printed with? We have been testing different tread filaments in the off season.

We used overture 95A TPU. We haven’t driven enough to know how it will hold up though. Have you found a filament that has worked well?

[Edit] Here is a link to our tread CAD
Onshape Wheel Tread

In 2021, we tried printing our tread out of the same material. It wore out much too fast for our tastes so we never ended up running in. I tried to nail down a material that would provide better stress results but nothing I found seemed to get over the physical limits of 3d printed geometry. I think there was maybe a team in texas that eventually succeeded, but I can’t find them anymore.

Here’s our cad for when we tried it on our swerve wheels: Onshape

1 Like

If you can remember, can you provide more detail on how it wore out? Pieces of TPU breaking off? Tread tearing away from the hub?

I’m assuming your design had a bit more traction than what we are currently using.

Yeah, the design initially had heavy wear on it to rub the material smooth. But modules also tore and partially separated the tread from the wheel. There were defiantly chunks missing as well.
However this was on a 125 pound robot with some very small wheels and very high speed modules, so much more traction and much more wear.

My initial post did highlight some failures with our progress, but I in no way meant for it to dissuade you in your design. This clearly can work in some way, and you probably just have to make small tweaks to get this working, and then keep those in mind when designing your robot this year. The stuff you have is already awesome.

You in no way dissuaded us. I think your design is different enough that we might not have all of the same issues you saw. My biggest concern is it tearing around the holes we use to attach the tread. If we can get each tread to last one day of competition, then I would be happy with it; otherwise, we’ll just use the tread most other teams use.

We tried several TPU filaments. Currently, Priline 95A TPU has held up in off season competitions. Couple of comments. Dry TPU real good. I do 24 hours at 160F. TPU will print wet but, it greatly affects the layer adhesion, toughness and durability. We at first printed with a .4mm nozzle. Found that toughness was much better with a .8mm nozzle. Also print hot. Recommended max temp from manufacture was 220C. We print at 230-235C. There are softer better traction TPU’s. We are after better wear. Up till this year we used AM 80A high grip wheels. In the later competition the matches became more intense and wear became a problem. That’s our motivation. Tried several tread patterns. Our current version duplicates the AM tread.

Another 2 Weeks Later

Finally, we took the robot up to the school to give a good test. Our goals during testing were:

  1. Give each of the student experience driving the robot
  2. See how well the tread held up
  3. We have had a specific module lose its heading a couple times, so we want to see if that same module would continue to lose its heading and maybe fix it.
  4. Make sure the MiniCIM motors would not overheat.

Here is a video of one of our students driving the course

We drove the robot for about an hour and sure enough the same module would lose it’s heading every so often. So far we have only swapped out the ribbon cable going from the Talon SRX to the encoder, and that didn’t resolve the issue. Next steps are checking the CAN connection, Power Connection, and maybe swapping out the entire encoder. Maybe a look back through the driver logs will tell us something.

The MiniCIM motors were a tad warm after an hour of driving, so we were pleased with that.

The tread did wear down a bit, but not enough to concern us that they wouldn’t last an entire day of competition. So far, we are happy with how they held up. We’ll see how they do once we add some weight to make it 120lb and once we bump the speed up.

It was great to be able to give the students driving practice. This year we are making an effort to give the students more driving time, which is something we have not done in the past.

Couple of other issues we had is that we kept bumping up the max speed in the code and the robot didn’t go any faster. Also we have tried to run the Path following part of the example code without any success. It has been discovered since our drive practice that we had the encoder on the Talon FX controller set to CTRE Mag Encoder instead of the Internal Encoder, so that could very well be our problem with both of those issues.

We did switch over to the command-based style of programming, so we are now more comfortable with that. We mainly switched because all the sample path following stuff we found was using command based. Once we get the last couple of issues resolved, I’ll post both our final timed based and command based code for our offseason swerve.

Final Pre-Kickoff Report

After looking at the driver’s station, it appears that the voltage was dropping too low and brownouts were occurring around the time the module lost its way. Our batteries aren’t exactly new so one step we are taking is to order new batteries. After reviewing a few posts on brownouts on swerves drives we have also added a ramp rate and have gotten a little more aggressive with the current limiting. There were also suggestions of limiting speed if the modules weren’t at the correct position yet to limit the fighting of the modules with each other. We did not implement anything in regards to that.

The max speed constant wasn’t being utilized at all in the code. Now it is.

Once we defined the encoder correctly on the Talon FX, we were able to get the robot to follow a short path as shown in this video. We only had a small area to work with.

Our final code for the offseason swerve is posted at the same link as was posted above.

This is probably the best offseason project we have done. Looking forward to hopefully using the swerve drive for the upcoming game.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.