Was there a particular reason you chose to go with the MA3 absolute encoder for steering as opposed to another SRX Magnetic encoder?
I’m also interested in this question. The reason we used the MA3 on our modules was because it has a supported shaft built in which in our case made the design a little simpler. Perhaps it’s the same for them?
Very cool module design! It’s really interesting to poke through the CAD and see all the little details. How did the needle roller bearings work out for you on the wheel shaft? The wheel shaft was made out of some kind of steel I presume?
The needle bearings they’re using (for packaging reasons I assume) don’t react thrust load so they need a separate bearing for this to react the load of the bevel gears . Makes for a rather expensive module hardware wise.
Not speaking on their behalf but my guess would be to keep the encoder cables shorter, along with if they designed these to swap out easily, then that’s one less wire that needs disconnected.[/quote]
AJ is correct here.
The 3" wheels are driven by a 775Pro motor(s) and go through 3 gear stages: the first is a 100:12 32DP stage. The second is a 26:16 20DP stage. The final gear stage is a 15:15 bevel gear stage using the bevel gears sold by VEX.
The result free speed of the drive is about 18.1 fps.
Of course it depends on the game, but we would likely run a little slower in the future. It is difficult to get more reduction out of either of the first two gear stages in this design, so more reduction would be needed out of the bevel gear stage, by either using the AndyMark bevel gears, or some customized ones from another vendor (KHK, etc.). There may be other bevel gears becoming available so this design change is very much still a work in progress.
The steering of each module was powered by a 550 motor going through a 2-stage VP and a final gear reduction after. We used a 9:1 and a 5:1 stage inside the VP, and the final gear reduction after the VP was a 64:44 20DP stage. The final ratio of the system was 65.45:1.
One change we would make in the future would be to change this ratio to something closer to 100:1 with a 550, or something around 84:1 with a BAG. The modules steered plenty fast, and while we never burnt up a steering motor from regular performance, they were the limiting factor on how long we could practice before the drive needed a break (about every 20-30min of driving).
I’m also interested in this question. The reason we used the MA3 on our modules was because it has a supported shaft built in which in our case made the design a little simpler. Perhaps it’s the same for them?[/quote]
I’m not sure I would say the shaft itself was the reason, but at the time it was definitely the simplest option for the current design available. The steering encoder was the last thing added to the design, so adding it the way we did was an easy way to do it.
We had an MA3 fail during finals at our 2nd district event in Milford, and it caused our drive to perform poorly and crash our lift into the scale, ultimately causing our alliance (sorry 67 and 1701!) to lose in the finals.
We still have not definitely found what caused the failure, but seeing as the wires looked completely fine and the sensor physically did not appear damaged in any way, our suspicion is ESD. The MA3 is definitely more susceptible to ESD then other options, and this would be a big reason we would switch to another option in the future.
We would definitely use a Mag encoder here in the future, and if not the CTR Mag Encoder, then we would make the output of the VP for the steering a 1:1 to the module so we could put the encoder stage into the VP.
The needle bearings they’re using (for packaging reasons I assume) don’t react thrust load so they need a separate bearing for this to react the load of the bevel gears . Makes for a rather expensive module hardware wise.[/quote]
Mike is right on all of this. The needle bearings were used due to packaging, as normal ball bearings had too large of an OD to fit with the bevel gear above.
With needle bearings, you need something to deal with the thrust load; ball bearings take care of this but needle bearings do not. The thrust bearings on the inside of the wheel forks deal with the thrust load. The thrust bearings on the outside of the forks are only there to allow us to bolt into either end of the shaft. Because it is a live shaft, we couldn’t just bolt into the shaft up against the needle bearings, as the housing for the needle bearing does not rotate; if it was a ball bearing you can do this since there is an inner race of the bearing spinning with the shaft.
The wheel shaft was made from steel, more as a precaution then anything else. It was worth the weight to know the shaft wouldn’t fail, as it is a drive shaft and is a smaller diameter then your average shaft. We also wanted to make sure the shaft did not wear too much in the needle bearings.
Overall the setup worked out well, but as Mike mentioned, the cost of the bearing setup for this is more then would be ideal. In future iterations we will be looking to find a way to just use 2 ball bearings for the wheel shaft to cut down complexity and cost; ideally making the shaft a dead axle would greatly simplify the design, using ball bearings on the wheel/bevel gear and the shaft being directly bolted to the wheel forks which would make the module even stronger.
How did the wear on the 32dp gears look at the end of the season - especially the ones with 2 motors on them?
What advice do you guys have for using 3D printed nylon in FRC?
My team is currently experimenting with using our MakerGear M3s to print Taulman Nylon 645.
What is the weight (as pictured)? I noticed that the picture shows 1 775 driving but the CAD shows 2. Can you drive it fine with just 1?
Why was that a requirement?
Aint nothing like having the real thing!
Thanks for posting this, very helpfull.
I have one question: Is it for a reason that you decided to go for a 2RS bearing seal (on your 6816) instead of a more common seal like zz?
For something in this environment, I imagine the rubber reals of the RS bearings help keep out carpet and other field gunk a bit better, and metal zz seals are easier to damage depending on how they’re used. Additionally, most rs seals can be removed to inspect the races/balls/etc and reused without issue where the zz seals often damaged by removal, and slight bends prevent them from fitting back into place correctly.
Nothing very noticeable on the 32Dp gears, even the modules with 2 drive motors. The motors are spaced equidistant around the 100T gear, so there is no uneven load on the gear. We ran the 7075 aluminum version of the 32DP 100T gears from VEX.
We got all our printed parts from shapeways.com last year. It was more expensive then if you had a printer and ran everything yourself, but honestly the part quality we got from Shapeways was great, and we knew when we would receive the parts (It was 6 days total from the time we ordered them, which for the drive was fine since we ordered early and were able to plan around knowing the delivery schedule). These parts are Nylon SLS parts; I do not know the exact printer Shapeways uses, but it is definitely a higher end industrial level one.
We have ordered a Markforged Onyx One this offseason and will be likely be printing parts with this in the future. If we feel we need more bandwidth or something though I would happily use Shapeways again. #TeamMarkforged
We ran a single 775Pro drive motor on our front two modules, and 2x 775Pro drive motors on our back two modules.
In CAD, the weight of the 2x drive motor version with the talons is around 7.25lbs.
I do not know the final actual weight of the 2 drive motor version with the talons, however I can say that the single drive motor version without the motor controllers mounted weighed in at 4.9lbs.
The version of that module in CAD in the past estimated about a quarter to half pound heavier, still haven’t totally nailed down where in the model the extra weight is coming from compared to real life. Part of this is likely the printed parts; in CAD they are a completely solid body of Nylon, but in reality because they are SLS parts, while they are 100% fill by nature they are not as dense as what the parts estimate as in SolidWorks.
We wanted to bolt into either end of the wheel shaft as a way to make sure the wheel forks could not flex outward at all. If the shaft was a dead axle, then it would act as a great way to tie the two forks together rigidly. With the live axle we cannot do this, so bolting into the shaft was the next best option. Hard to say how crucial this was; I think the module ended up being pretty solid with how the forks mounted to the housing above anyway, but better to be safe on such a critical part of the robot.
We hope you and 359 are enjoying the module we auctioned off at the IRI silent auction! We were glad it raised as much money as it did for the IRI charities.
For something in this environment, I imagine the rubber reals of the RS bearings help keep out carpet and other field gunk a bit better, and metal zz seals are easier to damage depending on how they’re used. Additionally, most rs seals can be removed to inspect the races/balls/etc and reused without issue where the zz seals often damaged by removal, and slight bends prevent them from fitting back into place correctly.[/quote]
Troy is generally correct on this. That said, I wouldn’t say we went out of our way to pick this specific seal type for the bearing over another. It was really the bearing that was available that we found at the time that fit the dimensions we needed. That said, if we had looked into options for other types of seals, we likely still would have used the ones we had.
Thanks for releasing the CAD files. I am greatly enjoying digging though them.
Can you describe how the 64 tooth 20 DP turning gear was manufactured? Was it a COTS part that you guys modified with a router and a lathe or is that something custom made? Is that a press fit into the big 80mm ID Amazon bearing or a clearance fit?
I know Stryke Force uses a spring for suspension in their swerve modules to ensure that each module gets the same amount of traction. Did 33 ever investigate the benefits of such system? Did you guys have any issues with a rigid mounted, no suspension swerve that would make you want to develop a suspension?
The 64T gear part of the module is one of the printed parts of the module. It snugly fits into the ID of the bearing, and the top part of the module (also printed) is bolted to the 64T gear part. These two parts lightly clamp on to the inner race of the bearing.
We did not try doing any suspension system on the drive. My assumption is there is likely a marginal gain, but I expect it is pretty minimal. 2767 could speak to whether they have measured how much of an impact it has actually had on performance. We didn’t feel like the added complexity was really worth spending time on. We did not experience any issues related to losing traction on a wheel from what we could tell that would make us think adding suspension is something we would need for this drive in the future.
Nick’s description is pretty accurate. Seems to help in auton but still the biggest gains in a straight driving swerve is a tight drive train, high count encoders, hyper tuned PIDs and a flat frame regardless the the suspension. That said, we will keep the suspension as long as we use our current topology because its there.
Nick, I love your module and could have held it in my hands all day… like a puppy.
Interesting the 64 tooth gear was printed. Very cool. Was the gear driving it also printed? If not, were there any wear issues caused by the two different meshing materials? Was there any type of lubrication? (I would assume not, based on the fact its Nylon SLS, but figured why not ask.)
3 inch wheels are pretty small, based on how often we go through the 4 inch wheels, I am going to assume they probably wore fairly quickly. How often did you guys have to replace them? Did you find they wear faster than if you had put them on a tank drive? Would you guys swap modules out when you wanted to swap wheels, or just pull the shafts and swap the wherls? Trying to figure out what to expect in terms of how many times the modules will go on and off the robot over the course of a season.
It was my understanding and opinion that the suspension wasn’t super necessary. I was just curious what your thoughts were. Thanks for all the info! And thanks Mark for responding on the matter also!
The driving gear was a 44T VEX aluminum gear. No lubricant of any kind between the 44T aluminum gear and the 64T printed gear. We had no issues; there was even plenty of carpet gunk that got in the printed gear and it just didn’t care. We would likely experiment with printing the 44T driving gear in the future (would probably also change that final ratio to a 1:1 so that we could use a mag encoder stage on the VP. We have also discussed switching the VP to a VP lite potentially.
The wheels did wear. We tweaked values on auto as they wore, and generally replaced the wheels once per competition. Most of the wear the wheels saw wasn’t from spinning the diameter down, but radiusing the sides of the wheels from pushing through turns hard. This had a lot to do with more refinement needing to be done still on the steering control. The diameter of the wheel would wear over time, but it seemed to wear slower then your average skid steer wheel would, and this is what we expected.
When we did swap wheels, all we had to do was unscrew the 4 bolts that mount the forks to the module housing above, and the entire wheel fork assembly drops off. We always had 4 spare wheel fork assemblies at competition with new wheels on, so we could do a wheel change NASCAR-pit style in about 60 seconds by the end of the year (we used a drill with the clutch set to a certain value and a straight allen wrench in the drill to do this).
We used an absolute encoder too (not for swerve). They are nice because the position is, as the name implies, absolute. This means they update the position regardless of the program, even when the robot is off. So, if the module turns between matches, when the robot turns on, it still knows exactly where it is. A relative encoder needs a reference of some sort to determine its position off of.