With very few exceptions, things you see in the KoP are donated by their suppliers. In recent years, IFI has put more motor controllers into FIRST Choice than into Kickoff Kits. With Victor SP supplies exhausted*, it wouldn’t shock me** to see SPXs in FIRST Choice this year.
*I do love that IFI seems to do one last blowout run of an outgoing motor controller for FIRST Choice. They had tons of Victor 888s in there when the SP/SRX came out.
**With the Rover Ruckus release, to the best of my knowledge I’m out of FIRST NDA secrets (including game, FIRST Choice, and Kit of Parts information) from my time in Kokomo. At this point, I’m a fan just like you.
Although Victor SPXs don’t support current limits, it shouldn’t be an issue in this configuration. So long as you set a limit on the SRX and the motors are similar, the current draw should be roughly evenly distributed across all the motors in the gearbox. The talon implements current limiting by modifying output voltage until the current is within the limit, and follower controllers match the output voltage of the master. Therefore, if the talon starts limiting current, the victors will follow.
Right, it definitely doesn’t support it as a built-in function, but set up in follow mode it should be able to pseduo-limit.
The key is probably how much any given setup “needs” aggressive limiting to avoid brownouts - we went for a single speed, aggressively fast gearing, with the assumption that we’d “fix brownouts in software”, but ended up wrestling with the problem in a piecemeal way and after some other schedule slip threw in the towel on the drive SPXs to get to “known good” hardware in place.
In retrospect a significant amount of the problem (addressed after going back to 3x SRX) was our bad implementation of the new format of current limiting commands (too long a window, not a low enough limit, etc), so I’d love to revisit the problem.
Is it feasible to do the current monitoring and current limiting by reading back the values from the PDP? I just started mentoring a team that has around 20 unused, in the box SPARKS for some reason. I like the advantages of the CAN-capable devices but the cost savings of using parts we already have is very compelling.
We ran 1x SRX and 2x SPX per drive side this year (3 MiniCIM config) with no issues, and ran current limiting on the SRX after our first event. We ran it as a hard capped limit (i.e. time limit = 0, never allow the voltage to go above the limit) and that was sucessful at keeping all 3 motors at the same current per gearbox, even though only one motor was actually being monitored. Haven’t tried it any other way, but anecdotally it worked for us as intended.
We will definitely use the SPX again, it was a perfect drop-in replacement for all followers. We made the conversion from PWM to CAN for the 2018 season, so the addition of the SPX to the market saved us a boatload of money.
It’s very possible, but the value is debateable. High latency from PDP observation -> report to RoboRIO -> reaction at controller means it’s difficult to catch a brownout-inducing spike before it knocks you out, but if you wanted it for other reasons it’s definitely possible.
Is it Necessary? Probably not. Current limiting technology is only important when you’re pushing the envelope or made a mistake.
In our experience, reading from the PDP to the Roborio is too slow. We more or less use Talon’s for everything. We are using Victor SPX’s on our offseason bots as slave’s and they’ve been working well. Would recommend.
Since we don’t have the sort of budget where 20+ SPARKs are of insignificant value, we will probably use them in the upcomming season for applications like the Victor SRX. We have some Talons that we can use for applications that need that functionality.
If sample rate of the values from the PDP is too slow to do control, would it still be useful for stall detection, say for an elevator hitting the end-stops? One would only be stalling one or two motors and so much less likely to induce a brownout.
You could also put a limit switch on the mechanism. Or an encoder on the drive shaft. Or a time limit on the calibration routine and grim acceptance that you’re stalling for a period of time up to that limit.
Implementing this would be a neat trick though, and if a student implemented and explained it well the judges would likely be pretty impressed.
First you build a time machine. Make a lot of money*, then go back in time (possibly in disguise) and sponsor your previous self. Boom - done!
If you’re not smart enough to make a lot of money with a time machine, you’re nowhere near smart enough to build a time machine.
Seriously, I guess we only did this last year, and looking back at our pics there are four SRXs there. However, our team discussions about a “basic CAN motor controller” defined the SPX so well that in hindsight I thought we had actually used it.
Now see we were having fun with useless memes and multiple pages of trash and then you had to go and make me pull out the rules.
There are no rules about time travel therefore time machines are a perfectly legal resource. I’m trying to wrap my head around paradoxes for R14 and R15 though. I feel like there might be something there but if you have a time machine then I think you’re good.
The designs are instantaneously created the moment the time machine arrives from the future, so depending on the arrival time you have different requirements. If you arrive before kickoff, they need to be made public, but after kickoff they were created at that point, so you could keep them hidden.
The sensible thing to do would be to reduce the output voltage when it is anticipated that the mechanism is getting near the end of travel. Then when it stalls, the motor current is not the full rated current. The software would look for the jump in current. My understanding is that the PDP current values update around every 20~25 msec. I would not expect that a motor pulling less than rated current for 20~25 msec would cause a brownout. It should be less work than installing a limit switch and more reliable. The complexity of the algorithm to detect the stall is not very different from the noise filtering algorithm I taught to my 12 year old son to use for his ultrasonic sensor data. He had it running properly in about an hour. The team is starting it’s regular meetings next week and this is one of the things I would like them to try. If that impresses the Judges, that would be a bonus we would be happy about
