REV Sparks or Vex Victor 888?

[Dylan_Watson]

Hello all, I'm a brand new FRC rookie, and I was wondering, what are the advantages/disadvantages of using the REV Spark instead of using the VEX Victor 888's?

[AllenGregoryIV]

The Victors are a previous generation speed controller. We basically used them for over a decade with great success as the only legal speed controller (when they were the 883s & 884s). The Rev Spark is a new speed controller that is designed to be inexpensive while still giving some of the benefits of new technology like not needing a fan to actively cool it and allowing you to use limit switches directly with the speed controller to add feedback to your mechanisms. We have a few of the Sparks in house have tested them a bit, they seem to be working well so far.

You won't be able to purchase any Victors, what teams already have and what are available in FIRST Choice will be the last of the 888s. The Sparks are available on Amazon and ship prime so you can get them quickly if you need a replacement.

[Sperkowsky]

Sparks! They are on Amazon and prime compatible which is awesome. Also I believe victor 888's are discontinued. We are going to be using Sparks and Victor Sp's this year.

[E Dawg]

REV Spark
-Passive cooling
-Reduced heat generation
-Mechanical limit switch inputs, so no need to program that stuff
-RGB status LED, which I hear is really nice
-Brake/coast mode
-PWM only
-Currently priced at $45.00
-Available on Amazon and Amazon Prime
-Haven't been around long, so I can't speak to long-term reliability just yet

Victor 888
-A staple motor control, performs every basic function you could want
-No passive cooling; you need to wire up fans otherwise the motor controllers can overheat
-Really finnicky trying to get all the wires in the right place
-PWM only
-$70.00
-Discontinued by VEX; you would be hard pressed to find a lot of these

Victor SP
-Passive cooling
-Reliable
-You don't have to fiddle with screws trying to get crimps on the controller (this is a godsend)
-Sealed enclosure means aluminum shavings won't cause you any problems
-Colored wires make it easy to identify which wires go to the PDP and which wires go to the motor itself
-PWM only
-Low profile
-Currently priced at $60.00

Talon SRX
-CAN integration is awesome, especially with the new control system
-Onboard closed-loop PID algorithms (if you don't know that that means, look it up because it's cool)
-Cables are really strong
-Passive cooling
-Sealed enclosure
-Color-coded wires
-Very reliable
-Low profile
-Brake/coast calibration
-Plug and play support for CTRE Magnetic Encoder Sensor makes using the PID algorithms even easier
-PWM available as well as CAN
-$90.00
-My personal recommendation!

[KrazyCarl92]

As a rookie team, we loaded up on 4 Victor 888s through FIRST Choice. Along with the 2 Victor SPs in the rookie kit and the 3 available through the PDV, this was an essentially free way to get ourselves 9 motor controllers. We anticipate the Victor 888s no longer being legal in the future, so we will look to use those up on this year's robot for sure.

With an emphasis on simplicity this first year, we will not attempt CAN and I highly doubt we would adopt a design calling for more than 9 motors. Victor 888s offered us the best value since we have certainty we will use them and we could get them for 50 credits. All of the other motor controllers in FIRST Choice cost 100 credits and are essentially of equal benefit to us this year since we will be using PWM.

[Alan Anderson]

With an emphasis on simplicity this first year, we will not attempt CAN...

Using CAN is no more difficult in software than using PWM. Wiring it is actually simpler, if you can plan the location of the speed controllers in advance. Using the advanced CAN-only features of a Talon SRX will of course add complexity, but you shouldn't avoid CAN just because of things you don't think you will be using.

Price is a good reason to stick with a PWM-only controller, though.

[E Dawg]

Using CAN is no more difficult in software than using PWM. Wiring it is actually simpler, if you can plan the location of the speed controllers in advance. Using the advanced CAN-only features of a Talon SRX will of course add complexity, but you shouldn't avoid CAN just because of things you don't think you will be using.

Price is a good reason to stick with a PWM-only controller, though.

QFT

[Munchskull]

One thing that people are forgotten to mention is that the spark motor controller is more linear than the victor 888. That means as a PWM signal increases, the motor will increase at a more constant rate if you are using a spark motor controller.

[KrazyCarl92]

Using CAN is no more difficult in software than using PWM. Wiring it is actually simpler, if you can plan the location of the speed controllers in advance. Using the advanced CAN-only features of a Talon SRX will of course add complexity, but you shouldn't avoid CAN just because of things you don't think you will be using.

Price is a good reason to stick with a PWM-only controller, though.

I'll bite and share my experience:

I've been a part of a team that has used CAN in 4 seasons. In 3 of those seasons the CAN out right failed at some point and we switched to PWM on at least some of the motors (granted those were all with Jaguars...I have my own opinions on those too).

In 2012, I personally spent over 70 hours during a week troubleshooting with a practice bot to get CAN working in preparation for the next tournament, only to have the CAN fail on the competition bot shooter motors at competition and ultimately switch to PWM.

In 2015, Team 20 used CAN with Talons relatively successfully. However, there were still quirks with the code which definitely burned lots of time during build season. I wasn't personally coding, but I recall us taking over a week to iron out the code for switching between current setting and position setting modes of CAN motor controller operation. There was also one practice match where a motor inexplicably drove the opposite direction it should have throughout a match. We were unable to reproduce the issue and it never happened again, but it was very puzzling. Not sure of the cause. Taking advantage of any of the elegance or benefits of CAN does involve added complexity. And it comes with added risk; if one motor controller fails the whole robot is down (the poor durability of Jaguars exacerbated this issue, but Talons are far more durable, haven't had one fail yet).

And having not used CAN in 2013 and 2014, we were able to get much improved robot performance which I believe is in part attributable to not fussing around with CAN. Every hour we spent other years trying to get CAN to work as intended was another hour we couldn't spend practicing. PWM was set it and forget it...it always just worked. I have yet to be a part of CAN going as smoothly, and I have yet to see a robot do something on CAN that wow'ed me and made me say "darn, there's no way a robot using PWM could achieve that same performance". And that isn't for lack of smart, dedicated people trying.

You are correct that if you just used the set voltage mode of motor controller operation, then CAN is no more complicated to code than PWM. But if that is your planned mode of operation, then why not save yourself $30 per motor controller, or get 9 (7 for vets) motor controllers for free?

Perhaps this is a knee-jerk reaction or I am holding a grudge over past experiences. My point is that for the team I am working with now, using CAN is not the low-hanging fruit for proper allocation of our resources (monetary, time, man-power). I am basing that assertion on my and my past team's experience working with CAN.


Back to the topic of the thread, the real point of my post was to illustrate that you could get 4 Victor 888's for free through FIRST Choice if you are not using the 200 credits (50 per) on something else. Or the SPARK can be purchased for $45 a piece if you would rather spend your FIRST Choice credits elsewhere. The SPARKS are slightly more linear, but this study shows the Victor 888's aren't all that far off from linearity:
http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/11-3-12_Day_9.shtml

[Cory]

We anticipate the Victor 888s no longer being legal in the future, so we will look to use those up on this year's robot for sure

I would not assume that. It has been ages since 884's were provided in the kit, or a "relevant" product, but they have remained legal since teams have stockpiles of them. I would expect 888's to remain the same way.

As Allen pointed out above, they are no longer being sold, so it probably doesn't make a lot of sense to use them after this year, even if they are legal, since you won't be able to get your hands on any additional ones.

[Aren Siekmeier]

if one motor controller fails the whole robot is down (the poor durability of Jaguars exacerbated this issue, but Talons are far more durable, haven't had one fail yet).

Great post, issues we ran up against with CAN as well, long before the current generation of CAN bus hardware and firmware.

One point I'll add though: the Talon SRX's CAN bus wires are hardwired together, soldered together onto the same pad on the pcb. Unless you short them together or somehow burn through the conductor completely, a controller failure will not bring the entire bus down.

We've heard good things about the new implementation, and fully upgraded this year to Talon SRXs from Talon SRs. We're excited to explore the possibilities, but of course ready to pull the plug and wire up PWM if needed.

[GreyingJay]

I am not familiar with the previous years' issues with CAN, but we had a Talon SRX in CAN mode on last year's robot and it was easy to wire, easy to program, and worked fine. Granted, we used it in the simplest possible way, no PID, no sensors.

In theory wiring up a bunch of Talon SRX's in CAN mode is dead easy. You need to assign them CAN bus IDs the first time around, but after that, addressing them in the code is also just as easy. And then when it's time to do PID and limit switches, boom! Easy.

In theory.

I'm slightly nervous about the various horror stories I've heard, but our team will probably give CAN a serious attempt this year. We can always fall back to PWM.

[Jared Russell]

I wouldn't dismiss CAN outright in 2016. Many of the horror stories happened years ago, when the *rio CAN software stack was less mature, CAN speed controllers were less mature, termination resistors were not built into the control system, high quality FRC-oriented reference material was not available, and a trustworthy vendor like CTRE was not yet staking its reputation on a working CAN solution.

All those things have changed since 2012, and many teams ran CAN-only control systems successfully in 2015. As a result, this is the first season that CAN is a viable option for 254.

[Richard Wallace]

I wouldn't dismiss CAN outright in 2016.

..., this is the first season that CAN is a viable option for 254.



This speaks volumes.

[wireties]

We stayed away from CAN for a long time because of the reliability stories on CD. But last year we went all in with 9 Talon SRX controllers. They work as advertised, we were quite pleased.

[Abrakadabra]

In 2015, 3467 also went whole hog with the Talon SRX - we used one running the built-in Speed Control mode for each of our four mecanum wheels, and two (1 master, one slave) for driving our elevator with Positional PID. One of our mentors insisted that the built-in PID algorithm could be faster (he was looking more for a motion-control mode), but it all worked well enough with a minimum of muss or fuss.

Plus - One of the often overlooked advantages of CAN control is built-in current sensing on each motor - granted it wasn't really that useful last year (unless maybe when we were building a twelve stack ;) , but in a defense-heavy game, or a game where climbing might be required, being able to monitor current at the individual motor level might help to intelligently avoid those brown-out conditions that we were all worrying about around this time last year.

[Ari423]

Plus - One of the often overlooked advantages of CAN control is built-in current sensing on each motor - granted it wasn't really that useful last year (unless maybe when we were building a twelve stack ;) , but in a defense-heavy game, or a game where climbing might be required, being able to monitor current at the individual motor level might help to intelligently avoid those brown-out conditions that we were all worrying about around this time last year.

Can't you do the same thing with one CAN run from the RoboRIO to the PDP? The CAN line would even have built-in termination at the PDP. No need for fancy CAN motor controllers if all you need is simple voltage control, and you can still have your current monitoring.

[Abrakadabra]

Can't you do the same thing with one CAN run from the RoboRIO to the PDP? The CAN line would even have built-in termination at the PDP. No need for fancy CAN motor controllers if all you need is simple voltage control, and you can still have your current monitoring.

Yes - if all you care about is the overall current draw on the system, the built-in CAN in the Roborio and the PDP is all you need. I was simply pointing out that having intelligence about each current-drawing node might allow you to make intelligent, real-time decisions about which motor(s) to throttle back, depending on the game scenario.

[Ben Wolsieffer]

Yes - if all you care about is the overall current draw on the system, the built-in CAN in the Roborio and the PDP is all you need. I was simply pointing out that having intelligence about each current-drawing node might allow you to make intelligent, real-time decisions about which motor(s) to throttle back, depending on the game scenario.

The PDP allows you to monitor the current draw on each output (http://first.wpi.edu/FRC/roborio/release/docs/java/classedu_1_1wpi_1_1first_1_1wpilibj_1_1PowerDistri butionPanel.html#a6bbee29a1bf72fb4519bf37af688d70c )(not just the total), so you can still achieve current control with PWM.

[Ari423]

Yes - if all you care about is the overall current draw on the system, the built-in CAN in the Roborio and the PDP is all you need. I was simply pointing out that having intelligence about each current-drawing node might allow you to make intelligent, real-time decisions about which motor(s) to throttle back, depending on the game scenario.

Actually with the new PDP you can get current draws for each power output. So as long as each motor controller is wired 1:1 with a power output on the PDP (which it should be according to 2015 rules), you can get the current draw from each motor.

See documentation here: http://www.ctr-electronics.com/control-system/pdp.html#product_tabs_description_tabbed
The Power Distribution Panel (PDP) is the latest DC power interface for competition robotics. The PDP uses CAN to connect directly to the roboRIO and allows for individual current monitoring on each channel.

EDIT: sniped

[Abrakadabra]

Actually with the new PDP you can get current draws for each power output. So as long as each motor controller is wired 1:1 with a power output on the PDP (which it should be according to 2015 rules), you can get the current draw from each motor.

See documentation here: http://www.ctr-electronics.com/control-system/pdp.html#product_tabs_description_tabbed


EDIT: sniped

OK - thanks. I forgot about that feature. But in my defense, it's still CAN that makes it all possible. :p ;)

As a mentor whose teams have used CAN beginning way back in 2009 when the Jags first came on the scene, I guess I had gotten used to promoting the current sensing feature of the CAN controllers a little too much. In 2012, when the bugs in the CAN stack and the unreliability of the RJ-11 connectors became too much to handle, I was sorry to see that particular feature go. So when CAN looked like it was going to be viable once again last year, I was ready and willing to give it another go, and I, for one, am glad we did.

[ozrien]

I didn't want to distract from the OP but KrazyCarl92's post requires attention.

I'll bite and share my experience:

I've been a part of a team that has used CAN in 4 seasons. In 3 of those seasons the CAN out right failed at some point and we switched to PWM on at least some of the motors (granted those were all with Jaguars...I have my own opinions on those too).

In 2012, I personally spent over 70 hours ...
And having not used CAN in 2013 and 2014, we were able to get much improved robot performance which I believe ...


Yes Jaguars had problems. That's why we created the Talon SRX (which is CAN and PWM). That's why we took the RJ11 out. That's why we integrated termination. That's why we re-wrote the CAN api on the RIO side [props to the NI team and WPILIB for making that happen].


In 2015, Team 20 used CAN with Talons relatively successfully. However, there were still quirks with the code which definitely burned lots of time during build season. I wasn't personally coding, but I recall us taking over a week to iron out the code for switching between current setting and position setting modes of CAN motor controller operation.


This was no current-mode last season for Talon SRX. Talon 1.4.crf had duty cycle, closed-loop pos,and closed-loop velocity. Next season of course is a diff story..... :)
The examples in the Talon SRX Sofware reference manual are meant to save you time. Were they not helpful?


There was also one practice match where a motor inexplicably drove the opposite direction it should have throughout a match. We were unable to reproduce the issue and it never happened again, but it was very puzzling. Not sure of the cause. Taking advantage of any of the elegance or benefits of CAN does involve added complexity.


You were having this level of trouble and didn't bother to ask for help from the community or email CTRE?
I haven't found any post from your team regarding this issue. And I know you haven't emailed support@crosstheroadelectronics.com (since it goes to me).
Did the programmers look at the Talon SRX Software Reference Manual?
This feedback is so far-removed from literally ALL of the feedback I've gotten from last season I'm not sure where to start.

If ANY TEAM has questions/concerns/problems with ANY CTRE product please please PLEASE leverage our support email. Or look around CD for similar posts or post yourself. Or PM me. But email is best. But don't wait a full season and then post it when it's too late to be beneficial. We want to help you.

Carl, if you email us your team's 2015 code, we will figure it out. I have robots dedicated for exactly that purpose. Please PM me if there is more info that you think would be helpful.

[Jon Stratis]

I would not assume that. It has been ages since 884's were provided in the kit, or a "relevant" product, but they have remained legal since teams have stockpiles of them. I would expect 888's to remain the same way.

Just because teams have a bunch doesn't mean FIRST will keep them legal I future years. Just look at BaneBots motors...

The key difference, I think, is in competitive advantage. There really is no advantage to using the older controllers, other than not having to buy new ones. Once there are none left for FIRST choice, though, I do expect them to become illegal within a couple of years - there is a "cost" associated with keeping them, including maintaining WPI lib classes for them and increased inspector training, as newer inspectors down the road may not have any prior experience with the old controllers. As it is, teams have now had two years to switch over, possibly even more down the line, so when they do become illegal I don't think there will be too much complaining.

[Ari423]

Just because teams have a bunch doesn't mean FIRST will keep them legal I future years. Just look at BaneBots motors...

The key difference, I think, is in competitive advantage. There really is no advantage to using the older controllers, other than not having to buy new ones. Once there are none left for FIRST choice, though, I do expect them to become illegal within a couple of years - there is a "cost" associated with keeping them, including maintaining WPI lib classes for them and increased inspector training, as newer inspectors down the road may not have any prior experience with the old controllers. As it is, teams have now had two years to switch over, possibly even more down the line, so when they do become illegal I don't think there will be too much complaining.

We still primarily use Victor 888s to power our robots. We have a ton of them, they are simple and effective to use, and they rarely break if used properly. We plan on continuing to use them into the future until they all break from misuse or they are made illegal. As far as WPILib classes go, I don't believe there is any difference between controlling a Victor 888 and a Spark or Victor SR. I would even be willing to just use the PWM class and manually set values from 0 to 255 if it meant we wouldn't have to spend a ton of money on new speed controllers.

[Cory]

Just because teams have a bunch doesn't mean FIRST will keep them legal I future years. Just look at BaneBots motors,

884's haven't been sold since sometime in 2012, but they remained legal through last season and there's no real reason to expect they won't be legal this year too...so 888's are probably safe for at least 3 more years.

[pilleya]

Just because teams have a bunch doesn't mean FIRST will keep them legal I future years. Just look at BaneBots motors...

With the discontinuation of the Banebots motors( 775 and 550 mainly) there was the potential for a huge power deficit between the motors available to rookie teams and those of veteran teams, especially those holding large stockpiles. There would have been close to a 100 watt power deficit between the BB RS775-18 and the am-9015. This was until VEXPRO released the 775pro, legality is still unknown sadly.

The 888 on the other hand, does not give a major advantage over other currently available FRC controllers. It is still a great controller, and it can cope with serious amp draw.

[GreyingJay]

I've heard people tout the fully-sealed enclosures of the newer controllers as an advantage. Does the "open" nature of the Victor 888 pose a serious disadvantage? Is it highly susceptible to swarf, dust, dirt, etc. blocking the fan or getting into the electronics?

[Greg Needel]

I've heard people tout the fully-sealed enclosures of the newer controllers as an advantage. Does the "open" nature of the Victor 888 pose a serious disadvantage? Is it highly susceptible to swarf, dust, dirt, etc. blocking the fan or getting into the electronics?

Yes. The biggest issue with the 884/888 style is how susceptible they are to catching on fire due to metal chips. Under the fan, you have a direct shot down to the PCB and FETS. While the PCB is conformally coated, it doesn't take much of a shaving to short across the leads of a FET. I would be that 75% + of the failures of these style controllers come from metal shaving or chips inside of them. The rest of the failures come from teams wiring them up wrong (either reverse polarity on the input side or power into the motor side).

[Munchskull]

One thing that people are forgotten to mention is that the spark motor controller is more linear than the victor 888. That means as a PWM signal increases, the motor will increase at a more constant rate if you are using a spark motor controller.

Just to back up my previous statement. The Spark motor controller has very similar specs to the Jaguar motor controller. Both have a switching frequency of 15.625 kHz and switch using synchronous rectification. Knowing that, it is safe to assume that the Spark motor controller would follow the path of the jaguar on the graph bellow.

My source for this graph. (https://github.com/frc-team-3341/Team-3341-Recycle-Rush/wiki/Motor-Controllers)
https://camo.githubusercontent.com/976395014f9218f4b05fabf575de27c6d548dc6c/687474703a2f2f7777772e6669676874696e6770692e6f7267 2f5265736f75726365732f436f6e74726f6c732f426574612f 323031335f50696374757265732f70776d5f76735f76656c6f 636974795f315f63696d2e706e67

[Jon Stratis]

Important note for anyone that looks at the above graph without following the link - "Victor" refers to the really old 884, which was known to have a very non-linear output. "Talon" refers to the original Talon speed controller, not the newer SRX. None of the current commercially available speed controllers is in that graph.

So, in short, with all these new speed controllers the past year or two, the community needs to do some more testing to come up with similar curves for all of them! While we expect all of the newer speed controllers to be very linear, testing to make sure would be really nice!

[Greg Needel]

Important note for anyone that looks at the above graph without following the link - "Victor" refers to the really old 884, which was known to have a very non-linear output. "Talon" refers to the original Talon speed controller, not the newer SRX. None of the current commercially available speed controllers is in that graph.

So, in short, with all these new speed controllers the past year or two, the community needs to do some more testing to come up with similar curves for all of them! While we expect all of the newer speed controllers to be very linear, testing to make sure would be really nice!


We have provided SPARK motor controllers to Richard and Ether to perform this testing series on them http://www.chiefdelphi.com/media/papers/2720

They would like to test the other new motor controllers also but need to get samples.

[Richard Wallace]

As Greg says above, Ether and I will be testing the SPARK for linearity in the same way that we tested the Talon, Jaguar, Victor 888, and Victor 884 a few years ago. REV has sent us SPARKs for testing and we plan to begin next week -- I have spent some time this week validating the test set-up.

I agree that it would be good to test newer controllers using the same methods. I will check to see what 3620 can provide. If anyone can help with samples of newer FRC-legal motor controllers we will be glad to include them in this round of linearity testing.

[Paul Copioli]

As Greg says above, Ether and I will be testing the SPARK for linearity in the same way that we tested the Talon, Jaguar, Victor 888, and Victor 884 a few years ago. REV has sent us SPARKs for testing and we plan to begin next week -- I have spent some time this week validating the test set-up.

I agree that it would be good to test newer controllers using the same methods. I will check to see what 3620 can provide. If anyone can help with samples of newer FRC-legal motor controllers we will be glad to include them in this round of linearity testing.

Richard,

Are you also referring to the Talon SRX and Victor SP when you are asking for "newer sped controllers"?

From my records, you have plenty of SPs and SRXs to do the testing but let me know if you need more.

Paul

[KrazyCarl92]

Carl, if you email us your team's 2015 code, we will figure it out. I have robots dedicated for exactly that purpose. Please PM me if there is more info that you think would be helpful.

Omar, I hope you or others in the FIRST community do not misunderstand. 2015 was by far the smoothest season I have experienced when running CAN. That is largely a result of the hard work and dedication of the folks at CTRE, and the best part is that I think we can expect it to continue improving!

I personally did not contact you during the season because I significantly scaled by my involvement during the 2015 season to finish my Master's thesis. The rest of the team is far less active on CD, so I am unsurprised that they would not take this initiative either. Furthermore, I had actually entirely forgotten about the strange behavior during that one practice match until prompted to comment on my experience with CAN. It never came back to bite us again, so it was a small blip on the radar compared to other problems we were working on throughout the season.

My mistake on the inaccuracy of the description of the mode changing issues. Looking back at my notes, the intended control strategy was to start the match by driving the relevant mechanism to a mechanical limit using set voltage, until it hit a current spike. When this occurred, we would switch to positional control mode with the mechanical limit sensed by the current spike as our 0 reference for use with our optical encoder feedback to know the absolute position. It was this mode change from set voltage to set position that took more time to figure out than anticipated (over a week). We figured it out eventually, but I would still contend that we would have more quickly been able to use current feedback from the PDP and a PWM motor controller with encoder feedback through the digital I/O, leaving us more time for practice. This was more an issue of us not having the existing know-how, but it should still be factored into a team decisions on what motor controllers are used in season.

I generally look to teams like 118, 254, 1114, 1678, etc. as rational decision makers. The fact that 2016 is the first year 254 comes out and says CAN warrants consideration for them is significant from this perspective for a few reasons:
1. Shows how far the implementation of CAN for FRC robots has progressed as a result of the hardware and other improvements (Talon SRX, etc.).
2. If a team with the man-power, expertise, and monetary resources of the Cheesy Poofs is just NOW in 2016 stating that the benefits of CAN may outweigh the costs for them, it should follow that a team with significantly less resources may be better off sticking to the simpler plug-and-play functionality of PWM.
3. Once more and more of these high profile, powerhouse teams start switching to CAN, we may start seeing teams capable of executing something more efficiently or elegantly as a result of using CAN. More resources will become available for teams to learn about how to use CAN. I do envision a future where CAN will be the sort of go to for motor controllers in FRC. The cost-benefit analysis for a vast majority of teams may someday favor CAN motor controllers. Performing this cost-benefit analysis for Team 5811 (rookie team) for this season simply reveals that it is not there yet for us.
(Already some great stuff from CTRE, but the more the merrier:
http://www.ctr-electronics.com/Talon%20SRX%20User's%20Guide.pdf
http://www.ctr-electronics.com/Talon%20SRX%20Software%20Reference%20Manual.pdf)

I am no longer mentoring Team 20, but I will send you an email to start the conversation and include others who were more intimately involved with programming the robot. My apologies it took this long to surface.

[ozrien]

I personally did not contact you during the season because I significantly scaled by my involvement during the 2015 season to finish my Master's thesis. That's a pretty good excuse :)

[Munchskull]

I generally look to teams like 118, 254, 1114, 1678, etc. as rational decision makers.

I agree with what you are saying, but I would like to emphasize for all that each team should choose based on what they personally weigh for pros and cons. An important aspect of FRC IMHO is making trade off, if you follow what a team like the Poofs does because they are the poof then you are not truly learning.

Just a plug for the importance of making your own desicions rather than following others. ;)

[RyanN]

I would not assume that. It has been ages since 884's were provided in the kit, or a "relevant" product, but they have remained legal since teams have stockpiles of them. I would expect 888's to remain the same way.

As Allen pointed out above, they are no longer being sold, so it probably doesn't make a lot of sense to use them after this year, even if they are legal, since you won't be able to get your hands on any additional ones.

To add to this. Victor 884s and 888s have no advantage over the other controllers. In fact, they have disadvantages that have been pointed out (difficult to wire, no passive cooling, exposed FETs.

The only reason I can see teams wanting to use them would be for the cost (as in teams have those stockpiles), and experience (I know they work. They've worked for us for 10 years, why change).

FIRST making them illegal would be a bad move, especially after the Recycle Rush game. Sure teams wouldn't just throw them away, but their usefulness will obviously suffer.

[Tom Line]

Just to back up my previous statement. The Spark motor controller has very similar specs to the Jaguar motor controller. Both have a switching frequency of 15.625 kHz and switch using synchronous rectification. Knowing that, it is safe to assume that the Spark motor controller would follow the path of the jaguar on the graph bellow.

My source for this graph. (https://github.com/frc-team-3341/Team-3341-Recycle-Rush/wiki/Motor-Controllers)
https://camo.githubusercontent.com/976395014f9218f4b05fabf575de27c6d548dc6c/687474703a2f2f7777772e6669676874696e6770692e6f7267 2f5265736f75726365732f436f6e74726f6c732f426574612f 323031335f50696374757265732f70776d5f76735f76656c6f 636974795f315f63696d2e706e67

That graph was actually taken directly from the 2013 fighting pi beta tests on our Web page......... I guess I need to start watermarking the graphs.

http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/11-3-12_Day_9.shtml

[Greg Needel]

That graph was actually taken directly from the 2013 fighting pi beta tests on our Web page......... I guess I need to start watermarking the graphs.

http://www.fightingpi.org/Resources/Controls/Beta/2013_Beta/11-3-12_Day_9.shtml

Tom,
If you have any interest in testing the SPARK I will gladly send a few your way to run the same test.

Greg

[Tom Line]

Sure thing greg. You have a pm.

[evanperryg]

Using CAN is no more difficult in software than using PWM. Wiring it is actually simpler, if you can plan the location of the speed controllers in advance. Using the advanced CAN-only features of a Talon SRX will of course add complexity, but you shouldn't avoid CAN just because of things you don't think you will be using.

Price is a good reason to stick with a PWM-only controller, though.

I'll second this. I'm speaking from the perspective of a team that, after getting tired of dealing with the headaches of CAN in 2012, switched to PWM, then most of our students and mentors experienced with CAN left. Wiring the new CAN system is a lot easier than wiring PWM (these things make it even easier, highly recommend them (http://www.kinequip.com/222-412.html?gclid=CJ71073B-skCFdgMgQoda4EDYA)), but the configuration interface takes a little getting used to, especially for teams that have no experience with CAN. We had some trouble with the CAN configuration system being a little glitchy (although this was probably our inexperience) so I'd suggest learning how to use it before you have to do it on your competition robot. We had no issues using the built-in limit switch and encoder inputs. Overall, CAN was a very pleasant change for us, especially now that we have experience configuring it properly.

[Tom Line]

Just completed some basic Spark Linearity testing:

http://www.fightingpi.org/Resources/Controls/Beta/2016_Beta/Spark%20Motor%20Controller.shtml

[Colin935]

If i were in your position, i would use victor sp's. they are a new generation of victors and they don't make any sound, don't get warm, which means there is no need for a fan.they are also pre-wired out of the package, and I have shown great improvement with my electronics board.

[Ari423]

If i were in your position, i would use victor sp's. they are a new generation of victors and they don't make any sound, don't get warm, which means there is no need for a fan.they are also pre-wired out of the package, and I have shown great improvement with my electronics board.

They also cost a lot more. Sparks don't need a fan and don't get too warm either, according to the tests.

[Richard Wallace]

Sparks look pretty good to me also. So do the Victor SPs and Talon SRXs.

Ether and I have been testing several controllers, collecting data for a comparison of linearity (speed vs. PWM command) over a range of CIM motor shaft loads. I have some of his raw data now and will review that tonight, then post some graphs. I think the initial round of data will only compare Spark against Talon SR -- the older screw-terminal model.

As others have commented (see especially the Fighting Pi data that Tom Line linked), Sparks have a good design for transporting heat out of the power components. I have not made any laboratory thermal tests yet, but I think REV has some data. The Average Joes have run Sparks on a demo robot with no complaints -- the original controllers in that demo (http://www.chiefdelphi.com/media/photos/42261) were Victor 888s and we've seen no significant difference.