You can view the model here:
https://workbench.grabcad.com/workbench/projects/gcRD2IcvxMu1euycifAqgj5gfv9jC1O0Nuc5g3tgk_Nv56#/space/gcIyxEkCA7pLUacNR34n2a-68TOnap6sMkmVsn-NoM64Kg/link/1424800
Thanks,
Justin
Hey man, that’s a pretty sweet design!! What’s the black …thing… on top of the wheel sticking vertically up? I can’t see an obvious purpose for it.
That’s the slip ring, not showing the wires.
I agree it is a pretty cool design. Very low ground clearance, so maybe not for every game.
I also think it is geared aggressively. 17.33 from the 775pro to a three inch Colson puts the slip current (on FRC carpet) a little over 60 Ampere, so you are traction limited on the “wrong” side of peak power. No real issue as long as you stay out of shoving matches, with other robots or with a barrier.
Would you mind expanding on being traction limited in the “wrong” side of peak power?
Couple of questions:
Why the 775 for steering? With the drive motor on the turret, there will not be any reaction torque back into the steering motor from the drive torque. So it seems like you could easily reduce the size, weight and cost of the module by switching to a smaller motor like an RS550.
What slip ring are you using? How many wires and what rating per wire? What are your wire allocations?
The most appropriate slip ring we have been able to find is a 6 wire with 30 amps per wire rating. But this slip ring would not allow you to send full power to the drive motor without using 2 wires to feed power and 2 wires for power ground return. This leaves only 2 wires for a wheel speed encoder. However, if you limit the motor power to 30 amps in the motor controller, then you would still have 4 wires available for the encoder.
I think that’s a Talon downstream of the slip ring. Looks like the plan is to pass CAN through the slip ring. 2 for power, 2 for ground, 2 for CAN.
RS550 would be a better choice for azimuth IMO.
Has anyone (i.e. Bomb Squad) done this and had success? I would be worried about noise in the slip ring contactors. But maybe at typical swerve rotational speeds the slip ring is pretty noise-free.
At least one team has successfully run CAN through a slip ring, although I forget who. I was quite impressed with it.
323 and I believe 16 as well are doing this.
323 did (as has 16), we had no major issues pertaining to data transmission. I don’t recall seeing CAN errors caused by it. (Logs showed CAN errors caused by some issues on the PDP). Quantifying this data is on my TODO list but it may be OBE by other developments, will depend on prioritization of resources and goals.
It used 2x 775Pros and thus 2x Talon SRXs on each module, they were on 30A breakers each. Encoder feedback could be retrieved via CAN bus but was local to the SRXs for motion profiling purposes.
Wouldn’t you need 4 wires for CAN, as it’s run in series, as in 2 in and 2 out?
For reference, the power curve for the 775 pro is the green line in the first graph on this page.
The “right” side of peak power is faster and lower torque, which is on the right side of the graph. If the load increases, the motor slows down, the torque increases, and the power rises to meet the demand. This side of the power peak also has significantly greater efficiency (dotted red line), meaning less of your battery power turning into heat in the motor.
The “wrong” side is slower and higher torque than the power peak. Same statements, in reverse.
I have never seen heaven and hell in one picture. Great design.
Thank you! And yup, that’s the slip ring.
The 775pro is used for steering mostly due to my unfamiliarity with swerve. I know the 775pro is overkill for this application though. If this is built, I plan to run the 775pro below 12v. It should help reduce thermal buildup compared to an RS550. It is a VP though, so it’s easily changeable to an RS550 if wanted.
The slip ring I found is also a 6 wire rated at 30 amps per wire. I suspect it’s the same one you found. There is a Talon SRX on the module though, so CAN can be used to read the encoder data. This leaves 4 wires for the motor.
The CAN topology is relatively flexible. I believe that 16’s setup was similar in that they ran CAN through their slip ring. It is possible to use only 2 wires for can using a star topology, for example.
The 2 yellow wires and 2 green wires are electrically the same. Inside the Talon they literally twist them together and solder them to the PCB. That’s why there is no labeled “innie” or “outie” on the CAN wires. I don’t see why you can’t make the junction on the stationary side of the swerve. I would dissect the slip ring to try to figure out which 2 slip rings that are farthest away from the others for noise purposes.
We ran CAN up to a PCM module on our gripper/upperstage this year without a return. Even though a couple inspectors didn’t like the fact that we didn’t have a terminating resistor it worked all season.
The CAN bus on FRC robots is surprisingly robust. That being said, minimizing errors is imperative depending on the use case.
The CAN standard was designed to have a large noise margin so that it is fairly tolerant of “non-ideal” implementations. By following the normal guidelines, one is virtually guaranteed success. By using a non-ideal implementation, one introduces risk that is difficult to predict and quantify. Only thorough testing will reveal if the implementation is acceptable. The level of risk is also difficult to reproduce i.e. “copying exactly” what 829 did this year may lead to problems in a different robot.
Do you have a source for “normal guidelines” I can review w/ my students?
Background, we got CAN errors at the end of the daisy chain on this year’s robot, but didn’t have time to troubleshoot beyond “swapped the physical device, it works now go” at SVR.
We ran twelve devices on the bus this year, mostly physically located directly off the PDP (for minimum power wire length to each Talon). The preattached CAN wires were extremely too long, so after we soldered the adjacent devices, we bundled them up and tucked them underneath the power leads. It’s physically beautiful and preserves cable length for future years, but in retrospect added a fat inductance loop between each device. The final device on the daisy chain (Talon controlling an intake arm) got the intermittent control errors.
Would those inductance loops be contributing to this? Or do I need to look elsewhere?
Sweet! The drive rectangle turned out especially well, I really like the packaging you found. Do you have any provision to spring-load it similar to 2767’s positraction?
I’ve been think about this a bit, I wonder if mounting the assembly on a elastomeric damper (like these) would give enough compliance to provide a similar effect with reduced complexity.
