The SparkMax is perfectly capable. What encoder are you trying to use? How is it connected?
Well we originally bought the Andymark Swerve and Steer already assembled wheel modules, but then we put Neo Brushless motors in place of the CIM motors. But that’s the part that’s working fine.
But we kept the original PG71 Gearmotors that came on the already assembled modules.
And from what I can tell this is a link to the encoders they used in assembly.
Right now we have those plugged into the ENCODER port on the sparkmaxes with 6pin to 4pin JST cables that we had to splice to get to work. So there could be something wrong there too.
We saw something about the Data port on the sparkmaxes along with something about alternate encoder mode? Is that something we need to look into?
Ah okay, so yes, that’s a hall-effect encoder, but the signal it returns is quadrature, so you can use kQuadrature. That is, if you’re wiring it directly to the SparkMax sensor port (you’ll need to connect to pins 2, 5, 7, and 10 for the 4 pins on the back of the motor).
If you’re wiring it back to the roborio, you’ll need two DIO ports (5V and GND from one, and the two signal pins). You could then just use a simple WPILib Encoder object.
1 Like
FYI Team204 is also going ahead with swerve and steers. We may take a different approach than full swerve though. We replaced the CIM motors with NEOs but kept the others. The turn motor is connected to a TalonSRX that is configured with position control. The encoder on the back of the turn motors are not used. Instead we have an MA3 absolute rotary position sensor geared to the turn output with a 5V-3.3V level shifter connected to the analog input of the TalonSRX. We only have two MA3s hanging around so we are also investigating an AS5600 based solution.
A few more notes. Team204 has never functioned with swerve and steer before this year. Another team told a mentor that they were prone to breakdown. This is my first year with the team so I am getting this second hand. Upon inspection, I found a few flaws that we hope to correct before competition. The most glaring is an improperly sized thrust bearing between the upper and lower assemblies. They are off by half a millimeter on one. The latest CAD shows the correctly sized needle bearing parts from McMaster but we have bronze and steel washers that came with ours. There are a couple of other rigidity concerns but that is the big one. The other thing is a concern for all of the swerve drives, lack of cowling. We can compare notes on both hardware and software if you’re interested.
If you’re interested I would be happy to try to get my library to work with your code?
Just curious, are you asking AronRubin, or me?
From the looks your making a library with the goal of making swerve drive implementation easier?
we have the swerve and steer pre-assembled from andymark, and these last two weeks are the first weeks we have ever even messed with swerve drive. If you think you can help us get swerve drive up and running for competition this year, we are definitely interested. Looks like we have a few wiring things to fix from other replies above, but if you think you can help us get swerve drive working sounds great to us!
2 Likes
Everything for the swerve drive is wired in, we just don’t have the correct wiring for the encoders, which we are getting to the bottom of that problem currently. We do have MA3 Absolute encoders, but we don’t have a good place to mound them, are they a necessity for swerve drive or are they just a nice perk to have?
We were thinking about not using the absolute and sticking with the built in. encoders for this year.
other than encoder wiring though, and any other problems that may occur with that. It’s just coding.
1 Like
You do need absolute encoders since built-ins tend to drift and if you experience a brown out your robot drive will then be unusable. While it is possible to operate without one, it is not recommended at all.
Any help is good help as I am my team’s only non-teacher mentor. However, we are forcing the students to go through phased introduction to actual swerve driving. First tank drive by holding turn positions on the turning motors. Next we will have explicit strafing (all 90*) and spinning (45* FR, -45* FL, 45* BL, -45* BR). Finally full swerve. That is as much to do with our understanding of how to arrange controls for the driver as software.
I tried to capture the current wiring. We are dealing with sensor values from talonsrx that seem wrong. The raw values look fine so I think it is just a wrapping configuration that we have wrong.
Thank you for showing me this! My colleague said “No one is using Talon’s for Swerve” AND HE WAS WRONG!! I do have to add onto my library now to support you though.
Just figured I’d drop in to say my team used these modules for the 2018 and 2019 seasons, and I’m very familiar with them. If you have any questions specific to these modules, feel free to ping me.
It depends. Pre-2020, there were a few specific issues that teams would generally run into. AndyMark revised the module for the 2020 season, but by this point the SDS MK2 module had released, and most teams - including us - switched over. As a result, most teams don’t have hands-on experience with the revisions, myself included. I do recall looking over the changes and seeing that they had addressed every failure mode we ran into, however.
When were these modules purchased from AndyMark?
The module has a place to mount them, on the short side by the steering motor. If they were bought with the MA3s as an add-on option, it should’ve included a gear specifically to interface with the encoder. If you bought them separately, I recall teams coming up with a 3D-printed solution should you have access to a printer.
They’re not strictly necessary, but “nice perk” is underselling it. The robot simply doesn’t have a way to know the module positions at boot-up without them, so you’d need to manually align the wheels before every match. I highly recommend figuring something out.
These issues are more theoretical than real in my experience. You’d need to brown out to the point that the Talon SRX loses power, not just disabled, for this to take effect - and that’s assuming the encoder is wired to the Talon and not the RIO.
They also don’t drift unless you have a gear skipping (which an absolute encoder wouldn’t solve on this module) or an inaccurate scalar
All currently-sold COTS modules are intended to be used with a brushless steering motor, so it is a bit of an outdated practice. We did use 8 Talon SRXs on the 2018 amd 2019 bots though.
(I’m assuming you specifically mean the SRX and not the FX.)
1 Like
Our district is weird about buying from vendors that don’t have a presence in the state. So it has been more challenging to buy REV. For a lot of things the mentors have too purchase and wait for reimbursement. So if the talons work we figure to avoid hassle. The NEOs are paired with spark max controllers of course.
1 Like
Just so we know we are doing this right, we are working on getting Absolute Encoders implemented.
And we will be using those INSTEAD of the built two channel hall effect ones. So we will have the ones built into the NEO motors, and the absolutes for the PG71 Gearmotors.
In no scenario do we need to use all THREE encoders correct? May seem like a dumb question, but I just want to make sure there is zero confusion.
And we will be wiring the Absolute Encoders to the ANALOG INPUT slots on the roboRIO. That’s what we’ve gathered from online at least.
Then after that it should just be coding. But is there an easy way to check to see if the encoders are working like intend. Like printing the output to console or something. Just a way to monitor it? This is our first time ever working with encoders.
Just making sure we are on the right path.
We are keeping the PG-71 in place. We need the weight and I suspect (no evidence) the available brushless motors don’t have enough poles to make precision movements at low speed.
I’m not criticizing it; the Swerve and Steer is discontinued and thus wasn’t included in my statement. You probably could retrofit a brushless motor to work (maybe a NEO 550 with an Ultra planetary gearbox?) - the pole count is more than fine once you factor in the reduction - but it’s not worth the trouble in my opinion. Just using what it was designed for is the way to go.
It depends, if you want to take advantage of the close-loop PID on the Neo’s you need to use the built-in encoders and configure conversion factors. If you would like to use one of the WPILib PIDController classes you do not need to worry about the built-in encoders. I do not know about the PG71 gear motors. If you want to control you robot’s velocity you also need the built-in encoders on the drive motor or another external one.
With the modern WPI features like continuous PID available, this is how I would do it if I were using these modules today; just close the loop on the MA3 and don’t even bother with the PG71 encoder. In fact, if you’re doing it this way, you don’t really gain anything from the SPARK MAX’s more “smart” features, and could afford to swap them for a cheaper controller like the Victor SPX (or the discontinued regular SPARK, if you have some lying around) with no loss to functionally.
However, that’s just a cost-saving measure. If you already have enough SPARK MAX controllers for the whole robot, it doesn’t save you anything to swap them out.
I would look into glass. It’s a tool from WPILib designed to monitor robot data in realtime as a programming aid.
As an aside, I recall our MA3s having measurably different outputs. They were all linear, but none of them went from exactly 0V to 5V; they all had slightly different points at which they wrapped around, like 0.1V-4.8V or 0.2V-4.9V. It may be worth measuring that yourself and creating slightly different conversion factors for each one.
To be extra clear here, @amosbessler’s team is only using NEOs for the drive motors; the steering motors where control loops are a hard requirement are using the PG71. To use the PID on the SPARK MAX, they would need to wire an encoder to it and use the alternate encoder mode; personally, I feel that’s more trouble than just implementing a PID controller in software.
The integrated NEO encoder is the way to go on the drive motor for odometry and autonomous. It’s too difficult to integrate an additional encoder somewhere else, and the integrated one is precise enough.
2 Likes