I do not know of any inherent advantage of the Spark over the SP for an intake wheel.
The Spark does have input for automatically handling limit switches that the SP does not. The Spark is also cheaper than the SP, but controllers you already have are cheaper :]. I think the teams may simply have had Sparks on hand.
From a general perspective both controllers will function the same way. They will both spin a motor and you program them the same. The difference is the price and the limit switch inputs.
A use case for the limit switches for an intake is if you want to load your shooter or move the ball to a specific location in your robot, you can set your intake to spin until the ball reaches a specific point (where you put a simple limit switch) and then your motors turn off automatically with no code required. Smart mechanisms make controlling your robots easier.
This is a good start to a list, but don’t forget that
-The spark is lighter in weight
-Doesn’t have integrated wires (which if cut to short or fail make you replace the controller)
-Has more visual feedback (through extra LED signal colors_
-Costs $15 less per controller
Also yes, the SPARK has a 3% less max power output(according to the specific test setup you documented), but that is a difference that most teams will never be able to perceive or translate into robot performance, especially on an intake roller using gearboxes that range in the 65%-85% efficiency range.
Overall, I stand behind the SPARK as a great controller and would love to see them on every robot in FIRST, I also support teams making the right decisions for your situation. We built the SPARK to be affordable and fully featured, so teams could save money while building their bots and spend the extra on other things that they need or just build cheaper robots. If you already have controllers that do what you need them to please use those; if you want the extra features of the SPARK or you need additional controllers for more robot features we would be delighted to see them on your robot.
For the Team Cockamamie Robot in 3 Days build, we used both Sparks (which were donated by REV) and a couple Victor SPs (which were [strike]stolen[/strike] borrowed from FRC 4901). The Victor SP was a little friendlier to our ridiculously cramped footprint, but performance-wise there was no noticeable difference and I imagine we could’ve tucked more Sparks in if we had to. (Wouldn’t want to talk about the wiring troubleshooting if we did, but that’s more our fault than either manufacturer.)
I’d use either, no hesitation. Just make sure you use the same one for both sides if you have more than one motor in play on a mechanism. Rookie-year us saw a team member wire all of one side of the drive with Victor 884s and the other with Victor 888s. The 888s had a far more linear response, so they wondered why the robot would pull to one direction. Sure enough, when everything went to 888s the issue went away!
Linear response (steady state RPM vs. PWM demand) is important in many robot mechanism controls. Tom Line (1718) presented some results on this, and Ether has used my Whirlpool motor lab to make the linearity comparison of several controllers when they are driving a CIM motor with dynamometer load. We are still working to extend that comparison to the latest controller types.
While those results are not complete now, I can say that the SPARK and Victor SP controllers showed very similar linearity. Our early results also confirm CTRE’s results (again using CIM motor with dynamometer loading) regarding forward voltage drop across the controllers vs. load current.
As others have said, I think most teams will (and should) use controllers they have on hand, or choose new ones based on cost and features. I like SPARKs for their price, flashy lights, and screw terminals – the latter allow me to select the lead length I want now without worrying that I might need longer leads later on.
The SPARK is lighter (although the wire vs no wire difference is probably why)
Thanks for reminding me that our chart needed to be updated, we fixed the text spec on the page soon after launch, but I forgot about the chart. I have removed the old one, the new one is below. I also removed the weight from the SRX, as that data was not available online either.
Building a little on Richard’s comment building a little on mine…
I mentioned this on the Team Cockamamie Periscope, but when we opened the Spark boxes we were greeted with what might be holy grail of FIRST parts: two additional terminal screws, in a little baggy, tucked in the corner of the box.
As a mentor whose teams have all had at least one Victor sitting in the box with no terminal screws, that right there was enough to sell me!
(Granted, these Sparks didn’t come straight from Amazon–they came in a box from Greg. However, it was inside the retail packaging and if this was Greg trying to hook us up I can’t imagine he wouldn’t just toss the extra screws in the outer box.)
We are moving to the Talon SRX this year (ordered 20+ of them), but both the Victor and Talon are awesome WRT size. It allowed us to package a lot of electronics in an extremely small size last year (it will help this year too, but we aren’t there yet). The integrated wires, when close to the PDB, do save you time and effort when installing things as well. We will likely be terminating the other end with a deans or XT60 connector to make swapping motors easier than before. When we measured, the weight differences were negligible as well when accounting for wire, etc.
I think the price point on the spark controller is awesome and will help a lot of teams, but to us there is a benefit that the added cost gets us when talking about size and proven performance. We will check back again next year when the spark has seen a full (arguably one of the roughest) FRC seasons of use, and will objectively make a decision on what to use.
I have not seen this mentioned anywhere but another feature unique to the Talon SR/SRX and Victor SP is the smart LED. The led will blink at a rate proportional to duty cycle. A faster blink rate means you are approaching full throttle. I find this feature very useful when trouble shooting control loops without the motor being connected.
Paul is correct on this Greg. If you are not including the weight of the leads in your numbers then you are not accounting for the total operational mass. When the leads are factored in an apples to apples comparison, the Victor is actually lighter.
Well this is a silly debate to have, but here goes.
All motor controllers and everything else sold to FIRST teams is based on the unit weight, as it is impossible to figure out everything that attaches to it.
Does the Cross the Road published weight for the Power distribution board take into account all of the wires or the fuses that could be plugged into it? How about the VRM, Pneumatic module, etc? Also when the spec sheets were made for the victor 884/888 or talon SR or Jaguar what length of wire was included in the weight?
For that matter what gauge wire are we talking about, not every motor needs 12awg, so in situations where smaller gauge wire is used, it would change the unit weight.
To teams reading this: We do our best to provide the best documentation and information that we can. If there is something that you would like clarified or anything missing, please feel free to ask.
Why is this a silly debate? You have information on your web site that does not include key information. I can only guess that it is an oversight on your part. You know as well as I do that the apples to apples comparison is to compare either with, or without, wires.
We have done this on the VEXpro web site for our speed controllers. For those that are interested, here is the data:
Victor SP w/o wires - .16 lbs
Wire weight - .07 lbs
Victor SP with wires - .23 lbs
To claim that your data in the table is not misleading potential customers is, well, misleading.
This is only my opinion, but I take issue with you stating the debate is silly because it is not. Some customers just take these tables at face value and you know it.
Just another point for all those considering these two options.
Having the existing wire on the Victor SP is a nice time-saver if you plan out your electronics layout properly. You should be locating your speed controllers near the PDP regardless, and sending the existing Victor SP input wires straight to the PDP saves a lot of crimping and heatshrink time!
I’d like to share our experience:
We always wire our robots on the 3rd weekend of build season. It took us two full 12 hour days to do this in 2014 with the old Talon (pre-SRX). We saved a lot of time in 2015 using the Victor SP due to the pre-existing 10 gauge wire, it only took our electrical team a day and a half (8 hour days this time!) to wire two full robots. This is partly due to the saved time on not using fork crimps and heat shrink anymore. The new control system (roborio) helped as well.
We are building three robots this year. Wiring all three robots this weekend will be a challenge, but using Victor SP’s exclusively will save us valuable time to accomplish our scheduled objectives!
Good luck everyone!
Edit: How could I forget, we don’t bother crimping our own PWM cables anymore, and we don’t have to hot-glue the PWM cable into the speed controller anymore. The integrated PWM cable is another huge time saver for us!
This is what has affected our decisions the most too. For runs that are close enough to use the integrated wires, the SPs and SRXs are amazing. The damaging the integrated cables has not been anywhere near as bad as I feared, we haven’t had to retire any of our controllers due to this yet!
The key advantages to the SPARK, are the cost and limit switches. I think with all the available motor controllers in the KoP, FIRST Choice and PDV. The lower resource teams should be able to get more than enough SPs, SPARKS and 888s. The SPARKs limit switch input is feature that is absolutely amazing in it’s specific use case (actuators with end stops), especially for the price given the other option is a SRX.
Our team is using a combination of SPs and SRXs for the reasons above. I must say I’m not a big fan of having the long CAN cables on the SRXs, partley due to how small they are (and I love how small they are) we haven’t found a nice solution to cable management without cutting significant lengths off (which we’re against for obvious reasons).