We would like to catch up with the competition by building and programing a Swerve drive over the summer.
We realize that going MAXSwerve would have been the easiest path, but due to supply constraints, we are going for MK4i swerve modules with SPARK MAX + NEO motors and Thrifty absolute magnetic encoders.
We see on Thrifty’s website that their absolute magnetic encoders are compatible with the SPARK MAX, so we are thinking that we should connect them to the SPARK MAX directly and follow a logic similar to the ones used by the MAXSwerve modules with their Through Bore encoders (rather than connect them to Rio and add complexity in the code).
Questions:
Is it indeed a good idea to connect the Thrifty encoders to the SPARK MAX controllers?
What breakout board or adapter should we use to connect the Thrifty encoders to the SPARK MAX controllers?
Do we need to do unit conversions in the code so that the Thrifty encoders behave like the Through Bore encoders? (Our plan is to use the MAXSwerve code example as a starting point).
Taking into account questions 1 to 3, is using the MAXSwerve code example as a starting point indeed a good idea?
I have not used these encoders, but probably the easiest way to hook them up is going to be to use a PWMPulse Width Modulation-style cable directly to the RIO, as shown on their site: Thrifty Encoder User Guide.pdf - Google Drive. If you choose to connect directly to the SPARK MAX, I’d do as suggested here: Data Port - SPARK MAX.
The Analog Port on the SPARK MAX can measure voltages up to 3.3V with 12-bit resolution. The SPARK MAX Data Port Breakout includes a 5V to 3.3V amplifier circuit so that 5V signals can be sensed with the Analog Input pin.
I vaguely remember an issue with using the analog encoder input with continuous rotation, as in swerve steering. It could well be fixed (in newer F/W) but I’d check. Maybe someone else will weigh in on this, or perhaps a little time searching this site will turn something up.
On the S/W side of things, it all depends on your S/W team. But, you do have to get things working electrically first. And, any S/W you use to start from is probably going to need some changes if you use it with a setup it isn’t written to handle.
I’m not sure where all I’ve seen this, but here’s one particular post that’s fairly recent and from an authoritative source:
analog output encoders are compatible with the MAX, but they cannot be used for the swerve turning motor at this time
If it were me, I’d probably run the encoders into the RIO and deal with things in S/W. But see my point about you S/W team – it can be hard to make this sort of change, depending on the experience/expertise of the team. I have to emphasize that I don’t know that things can’t be made to work with an analog encoder directly attached to SPARK MAX, but it depends on the SPARK MAX at that point, and this post seems pretty clear. So, your other option might be to use a different encoder – or maybe to find a S/W starting point that’s pretty close to what you want to run.
We used the thrifty encoders, but just used them through the analog data ports on the Rio. This worked out fine, but I would like to try to do what you are and using the dataport. I think something like this would work using the solder pads, but I have not personally used it so if you try let us know how it works. Alternate Encoder Adapter - 2 Pack - REV Robotics
Reading the thread that you referenced, I agree that it is clear that connecting the Thrifty to the SPARK MAX for the purpose of controlling the turn angle was a no-go at the beginning of the season.
You’ll need to either seed the sparkmax encoder position with the analog encoder hooked up to the roboRIO port or use the WPILIB PIDController class to run the control loop and set the motor output.
We used US Digital encoders on our swerve this year and wired them into the roboRIO and did the rotation control loop on the RIO without any issue. Next year we are looking to doing the closed loop control on the sparkmax as these are duty cycle encoders, but its not a priority atm.
If you are using an analog encoder you can not use the sparkmax to command a continuous rotation PID on their current firmware, so you are left with the roboRIO completing this loop. It’s actually really simple to get it working like that, and really works quite well.
Edit: as @Lexeo pointed out you can hook up directly to the sparkmax breakout and use it to seed the value as well.
We connected our analog encoders directly to our Spark MAX this season, and it worked out great. We did this on 4 swerve modules and our Arm encoder. Our programming wasn’t really any different from connecting it to the Rio as we are just seeding with the analog input. We instead just did this to simplify our wiring.
As a first step we have decided to follow your advice and simply attempt to seed the relative encoders with the thrifty encoders connected to the analog data ports on the Rio.
We are struggling to even get that far. In two evenings, we have managed to burn FOUR brand new SPARK MAX controllers trying to tune the PID controllers of the turn motors and we haven’t even put our chassis on the floor yet!
This is the very first time we are playing with the SPARK MAXes, but for comparison purposes, we have only burned three Talon SRXs over the last eight years!
Are SPARK MAXes known for burning for no obvious reason? Are they a bad choice for MK4i swerve modules?
Our initial code is based on the REV MAXSwerve template, with fairly minor modifications to use the relative encoders of the turning NEOs rather than the Through Bore encoder. It can be can be found at FRC2495/MAXSwerve (github.com)
We are looking for feedback on what might be wrong with this code, or for better code examples.
A weird thing we have noticed is that the SparkMaxPIDController seem to be happy to think they have reached their position target once they get within one virtual unit of set reference/target. Not a big deal when using native encoder counts, but a big deal when one uses radians as the virtual units. Has anyone else noticed that?
I am unsure as to how you burned those spark max? Did you release the magic smoke or brick them in some way? Are you using current limits while you are doing your tuning?
Also, take a look at 6328s code implementation if the absolute thriftybot encoders
So I would say something is very wrong if you have damaged four new spark max controllers. I think we had 13 on our bot this year and I do not recall damaging any.
Our code is linked here. It might not be the best example, but it worked.
There is a known issue with the REV motors where in an over-current state the temperature sensor can short to the motor coils. If this happens, the temperature channel of the data cable which is normally +5V gets injected with +12V, which kills the SPARK MAX that’s attached to the motor. Any further motor controller attached to that motor will also be killed. It’s possible that you have a transient short which isn’t immediately killing the MAX but shorts periodically. You may want to try switching the motor and see if the carnage continues.
Thank you for this important information. We will replace all the motors that were connected to the SPARK MAXes that fried.
Is there anything else we could do to attempt to mitigate the problem?
Regarding our second issue, do you know if the SparkMaxPIDControllers have indeed a bug so that they think they have reached their position target once they get within one virtual unit of set reference/target? Is there an API to control the allowable closed loop error?
It seems that most teams are either using MK4(i) with Talons or MAXSwerve with SPARK MAXes, doesn’t it? Have some teams actually successfully used MK4(i) with SPARK MAXes for a full season?
Yes, we have run MK4 and MK4i using all REV (SPARK MAX / NEO) for three seasons now (one was “at home” though) and have not had this sort of trouble – things have been very solid.
I have not had this happen, but have read about the problem with the temperature sense wiring in a NEO being able to damage a SPARK MAX (or more than one of these, as they are swapped). I’d guess this failure mode would not cause the SPARK MAX to get noticeably hot though, so I would not lock in on this theory. If you stall a motor, you can get both/either of the SPARK MAX and NEO pretty hot. Normally, the motor is the first to go – look up “REV locked rotor testing” for details.
If your control logic is commanding the SPARK MAX to go from 100% forward to 100% back, and switching very rapidly, I could see this causing things to heat up, particularly the SPARK MAX. I have not done this, so I have no idea how it would play out, but a timescale of a few minutes fits this theory better than the temperature wiring short I think. I could see this scenario being similar to a locked rotor in some ways. Do the motors hum or do anything noticeable before things fail? Does the steering twitch? Maybe try to watch some of the data coming from the motor the next time you run one.
It’s good you have set current limits. Setting these really low might take some of the risk out while you are developing, but I’d also turn down PID constants really far and start from there. Current limits might not kick in for all scenarios. Do you have trouble with overshooting the steering angle?
On the units stuff, we use native units on the SPARK MAX – rotations, IIRC. I don’t recall seeing support for anything else, although there is a conversion factor you can configure. We run our steering control on the RIO and use C++, so we have nice units support; we leave the conversion factor on SPARK MAX at default (1). But, we read position from the absolute encoder at all times, and so don’t use the NEO encoder on our steering motors for anything.
Yep, we have burned up a Spark MAX doing this before (smoke, failed to power on afterwards).
Another option could be to put significantly lower breakers in your PDPCTRE's Power Distribution Panel/PDHREV's Power Distribution Hub for testing (10-20A), although I would still set a current limit on the controller as well.