blog; Motor Controller Options for 2015

[FrankJ]

Motor Controller Options for 2015
Blog Date:
Wednesday, August 20, 2014 - 08:50

Link to Blog (http://www.usfirst.org/roboticsprograms/frc/blog-motor-controller-options-2015)

Please see the note below from FRC Kit of Parts Manager, Kate Pilotte, regarding motor controllers for 2015.

Hi all,

The Motor Controller landscape for the 2015 FRC season is going to be changing, and we’d like to share a few details in advance of Kickoff to give you a heads up. We normally only provide advance information on the upcoming season when necessary, but we think these details fall into that category.

Victor, Talon, and Jaguar Motor Controllers will be legal for the 2015 season and compatible with the new control system. A selection of these controllers will be available in the 2015 Kickoff Kits and/or through FIRST Choice.

The manufacturers of these motor controllers are, however, discontinuing them, and our understanding is the only ones available for purchase are those already in distribution.

Cross the Road Electronics and Innovation First International (IFI) have been working together on new motor controllers. They’ve published a joint press release about this collaboration and are sharing more information about the new products here.

We are sending new motor controllers to the Beta Teams for evaluation for legality in the 2015 season. While these two new controllers will not be in teams’ 2015 Kickoff Kits, we want to use the beta program to collect feedback on the new motor controllers that will enable us to decide if the new motor controllers will be listed as legal motor controllers for the 2015 FRC season. Based on initial testing results, we don’t believe there will be an issue with approving them for use in 2015, but teams should know the final decision has not yet been made.

The first controller is the Victor SP, a PWM motor controller. The second controller, the Talon SRX, is a CAN enabled motor controller with additional communication protocols and PID control. It is in development now, and will be shared with beta teams upon completion. Technical information for both devices is posted here (http://content.vexrobotics.com/vexpro/pdf/Victor-SP-Talon-SRX-Info-Sheet-20140819.pdf).

Beta test tasks will be updated as needed to accommodate testing and evaluation of these devices. Meanwhile, questions about these devices can be posted to FIRST’s 2015 FRC Beta Test Forum, or emailed to CTRE or VEX.

[Steven Donow]

Here's a document with more info about the controllers. (http://www.vexrobotics.com/vexpro/vex-ctre-announcement)And WOW I like the size

And here's the VEX product page (http://www.vexrobotics.com/vexpro/motor-controllers/217-9090.html) with some other specifics. And the product page for the Talon SRX (http://www.vexrobotics.com/vexpro/motor-controllers/217-8080.html)

And one that sums up pretty much everything. (http://content.vexrobotics.com/vexpro/pdf/Victor-SP-Talon-SRX-Info-Sheet-20140818.pdf)..

[Boe]

Wow I really love how much smaller these are, hopefully everything works out and they're available this year.

[NWChen]

Stupid question. I don't see any screw terminals on the info sheet (http://content.vexrobotics.com/vexpro/pdf/Victor-SP-Talon-SRX-Info-Sheet-20140818.pdf), how do leads connect to the motor controllers?

[Bryan Herbst]

Stupid question. I don't see any screw terminals on the info sheet (http://content.vexrobotics.com/vexpro/pdf/Victor-SP-Talon-SRX-Info-Sheet-20140818.pdf), how do leads connect to the motor controllers?

One of the listed features is:

Robust embedded power & output cables will never shake loose during a match

So the cables are embedded, similar to CIMs.

Not sure how I feel about this yet. On one hand, it will ensure that the cables don't come out of these controllers. On the other hand, it means we either have less reusability by permanently splicing the cables, or the same problem we currently have by using an intermediate connector.

I also have never had a big problem with cables getting jiggled loose from the existing controllers with a proper crimp.

[D.Allred]

This is an interesting announcement. The old controllers are no longer made and the new controllers are not legal yet. Did I read that correctly?

David

[Mark McLeod]

Stupid question. I don't see any screw terminals on the info sheet (http://content.vexrobotics.com/vexpro/pdf/Victor-SP-Talon-SRX-Info-Sheet-20140818.pdf), how do leads connect to the motor controllers?

This might help visualize it.
This is the Victor SP the Beta teams received to test. The specs say the final will be black anodized, and the cooling fins are covered in this early version.
http://www.team358.org/files/programming/ControlSystem2015-2019/images/med_VictorSP-2.jpg http://www.team358.org/files/programming/ControlSystem2015-2019/images/med_SpeedControllerSideBySide.jpg

[Steven Donow]

This is an interesting announcement. The old controllers are no longer made and the new controllers are not legal yet. Did I read that correctly?

David

The new controllers probably will be available, but it's not offical and will depend on results of beta testing (though it seems they most likely will end up being legal)

[ttldomination]

This is an interesting announcement. The old controllers are no longer made and the new controllers are not legal yet. Did I read that correctly?

Yeah, that struck me as weird, too. However, with FIRST opting to go into somewhat of a limbo, I think the fact that is not "approved" is only a formality at this point.

- Sunny G.

[mman1506]

I really love the embedded cables. It allows you to put the speed controllers in areas where you wouldn't have clearance for a screwdriver.

[Ty Tremblay]

Here's a document with more info about the controllers. (http://www.vexrobotics.com/vexpro/vex-ctre-announcement)


Neither company will continue production of the Victor 888, Talon SR, or Jaguar, but these devices will continue to be available while remaining inventory lasts.

Let's hope this doesn't result in a massive shortage of motor controllers in 2015.

[jvriezen]

Stupid question. I don't see any screw terminals on the info sheet (http://content.vexrobotics.com/vexpro/pdf/Victor-SP-Talon-SRX-Info-Sheet-20140818.pdf), how do leads connect to the motor controllers?

The controllers have integrated leads (e.g. 'pigtails') of 5.5 inches. This means you can put them near the PDB and then need to have an extra connection to get power to the motor or put them near the motor and have an extra connection to get to the PDB. Unless the motor is close enough to the PDB.

[timytamy]

Wow, those things are bloody tiny!!!

I'm still skeptical about having permanent cables, but I can see the benefits. Namely the PWM cable will never fall out again, and it will require significant talent to cross make the wrong connections between M+, M-, +12v, and GND.

I'm curious as to how AndyMark fits in with all this. With the Talon being discontinued and it seems like both the Victor SP and Talon SRX being distributed by VEX, will AndyMark find another controller? Or will the be able to distribute them as well?

Can't wait to hear more from the beta teams!

[ebmonon36]

I am curious to see what kind of connectors are on the CAN leads.

I hope it would be within the relaxed rules about repairing speed controllers to replace the cables if necessary. Many teams still have PWM cables getting eaten by drivetrains.

[Jared Russell]

I have lost count of the number of times I have helped teams debug their robots and found issues with how they had attached to their screw terminals, or had totally removed a screw and let debris fall in. The integrated pigtails are a great solution to this problem and will let teams find a connector that works for them while leaving all internal circuitry of the controller hermetically sealed.

Sure, some small percentage of speed controllers may have their leads compromised by being eaten by a mechanism (or being clipped by an overzealous freshman), but the cost reduction more than compensates for this.

[s1900ahon]

...or had totally removed a screw and let debris fall in...

Removing the screws on most motor controllers creates debris within the motor controller as a consequence (i.e. it doesn't have to fall in, it is already there). If I recall correctly, both Jaguar and Victor (at least 884) use captive screw terminals. When the screws are removed, little bits of the removed screw are left behind. This was a bigger problem for Jaguar due to the lack of conformal coating (before VEX manufacture).

[nuclearnerd]

I wonder if FRC would consider brushless motors & controllers in the future. Since the popularity of quadcopters exploded, there are tons of cheap options (http://www.robotshop.com/ca/en/brushless-dc-motor-controllers.html)available

[Thad House]

If they run into a problem and these end up not being legal, I foresee a motor controller shortage next year. I'm glad we have about 20 talons, which should be enough for next year.

Also, not sure how I feel about the pigtails. Especially since they are only #12 gauge. I would have preferred to see #10 gauge, or a version with screw terminals for the teams that want to use them.

[AdamHeard]

If they run into a problem and these end up not being legal, I foresee a motor controller shortage next year. I'm glad we have about 20 talons, which should be enough for next year.

Also, not sure how I feel about the pigtails. Especially since they are only #12 gauge. I would have preferred to see #10 gauge, or a version with screw terminals for the teams that want to use them.

The screw terminals would have dictated a larger packaging.

We were planning on leaving anderson pigtails on each end of EVERY speed controller going forward on 973, glad they made that decision for us essentially.

It's different, but I don't see it being a problem. If we had pigtails for 10+ years then switched to screw terminals people would be bothered in the other direction.

[Jared]

Also, not sure how I feel about the pigtails. Especially since they are only #12 gauge. I would have preferred to see #10 gauge, or a version with screw terminals for the teams that want to use them.

I wouldn't be too worried. CIM motors come with even smaller #14 gauge wires, and teams have been fine with this. If you're very concerned with performance, you can trim the pigtails very short, and you'll end up with a very small voltage drop.

[Gdeaver]

We used andersons on the robot this year and were very happy with them. This change will be a good fit with our current wiring practice. Now the whole robot frame becomes the heat sink.

[Nate Laverdure]

Now the whole robot frame becomes the heat sink.
It's a cool thought, but the contact resistance probably still ensures that natural convection dominates.

[BBray_T1296]

We used andersons on the robot this year and were very happy with them. This change will be a good fit with our current wiring practice. Now the whole robot frame becomes the heat sink.

I realize these things probably aren't supposed to be grounded to their frame, but in the event that they are, I personally would still screw them through a non-conductive piece of material like corrugated plastic or lexan.

[Andrew Schreiber]

I realize these things probably aren't supposed to be grounded to their frame, but in the event that they are, I personally would still screw them through a non-conductive piece of material like corrugated plastic or lexan.

The documents linked state that they are electrically isolated.

[AllenGregoryIV]

I'm fine with the removal of the screw terminals. Andersons end up on our motor ends anyway and for a lot of our speed controllers we'll probably go directly in to the PD panel with the leads for power.

I'm more worried about the PWM cables being attached. We've had far more PWM wires go bad over the years than 12AWG wire. It's going to be a little more annoying to troubleshoot since you can't just swap the PWM wires around at the speed controller. However I am glad that they all come with wires and I would hope they are nice high quality cable and connectors.

Overall these seem like huge improvements over where we were in the past. These will be much easier to mount in hidden places since you don't really need to access them and it will be easier to mount spares on the robot in case a speed controller drops out. 610 has done this in the past but since these take even less room and it's hard to change wires with them, I think more teams wills start following that practice.

[BBray_T1296]

The documents linked state that they are electrically isolated.

Fair enough.
Though I would still prefer using corrugated plastic. Not only because it is light, but you can punch mounting holes in it by simply shoving a screwdriver through it. To each his/her own of course.

[Andrew Schreiber]

Fair enough.
Though I would still prefer using corrugated plastic. Not only because it is light, but you can punch mounting holes in it by simply shoving a screwdriver through it. To each his/her own of course.

VersaFrame holes can easily be used to mount these. Holes are already drilled.

[qnetjoe]

My only question is what is the pinout for feedback pins on the SRX?

I only counted 10 pins on the feedback connector, but the Jag has 12 ( 5 - encoder, 3 Analog Input, 2x2 Limit Switches). I am sure a few pins are doubled up but I wonder which ones?

[Jared]

\I'm more worried about the PWM cables being attached. We've had far more PWM wires go bad over the years than 12AWG wire. It's going to be a little more annoying to troubleshoot since you can't just swap the PWM wires around at the speed controller. However I am glad that they all come with wires and I would hope they are nice high quality cable and connectors.

You bring up a really good point about the PWM cables. It's surprising easy to damage one. We had a few issues with some PWM cables this year that took out one of our drivetrain motors. We had enough time to swap the cable during our 4 back to back matches, but if we had to take the controller out, it would have been much harder.

That said, our PWM cables were likely very low quality because after the incident, I was able to cause another PWM cable on our test board to fail by just bending it back a forth a few times.

[waialua359]

I'm more worried about the PWM cables being attached. We've had far more PWM wires go bad over the years than 12AWG wire. It's going to be a little more annoying to troubleshoot since you can't just swap the PWM wires around at the speed controller. However I am glad that they all come with wires and I would hope they are nice high quality cable and connectors.

Great points Allen! Was thinking the same thing.

[Jon Stratis]

I have to say... opening up the beta box and seeing these last week was pretty exciting! It's a nice, small, integrated component that hopefully is just as reliable and durable as the previous speed controllers we've had to work with. I'm definitely looking forward to trying these out once we put the beta hardware on last year's robot in a few weeks (the robot is unfortunately sequestered at the State Fair until then).

[pastelpony]

Going to love using these. We used mostly Talon SRs on our competition bot this year because the Jaguars we were using were too big. These new ones make the Talon SRs look giant.

[s1900ahon]

My only question is what is the pinout for feedback pins on the SRX?

I only counted 10 pins on the feedback connector, but the Jag has 12 ( 5 - encoder, 3 Analog Input, 2x2 Limit Switches). I am sure a few pins are doubled up but I wonder which ones?

Yeah, but of the 12 pins on the Jaguar, 4 of those were grounds. This was done to try to make each interface easy to wire. Using a unified connector accomplishes the same thing (and an interesting alternative).

Let's speculate.. that's fun. What I suspect is we'll find there is a certain amount of pin multiplexing (peripheral signals that share the same pins; the firmware connecting a single peripheral to a pin based on configured usage). Very common on MCUs.

Assuming that a connection can be established across either the CAN, USART, or SPI connection for control, that needs 6 of the 10 pins on the connector be distinct. Add 2 more for power and ground. That leaves 2 signals for a sensor.

End speculation.

However it ends up, it will be well thought out I'm sure.

[sanddrag]

Well, this will certainly change the way we do wiring a little bit, but I'm sure we'll still come up with a way to make it look nice. I like that the mounting holes are in a line parallel with the case and a nice round 2.000" apart, rather than at opposite corners across a diagonal. I also like that we can pack a bajillion of these into a small area, and do not need to design our chassis around the width of a row of speed controls.

Also, I like that I don't have to practically write a whole grant just to put some speed controls on our robot.

Thank you VEX and CTRE!

[Nemo]

I like it. I hope these are the controllers for a nice string of years so we can stock up and reuse them for multiple years.

It will be a tough call when we decide what controllers to buy this year and how many. Cost of new stuff vs space savings.

[AK Koaster]

The only thing I'm slightly worried about on these is the heat dissipation: I'm not exactly the most knowledgeable on the subject, but looking at the size, I'm a bit worried whether or not there will be enough surface area on the controllers to adequately cool them down. In the documentation, it states that the fins will take care of passive cooling, but we've traditionally put fans on our speed controllers, even the Talons (we had a bunch of extra fans of that size, so we figured why not). Would like to talk to some teams early in the season after they've started working with them, see what their findings are. Active cooling for these might be a challenge, aside from putting a big computer fan over a network just for a little cooling, I don't see an extremely efficient way of doing it.

However, I'm still really excited, as these seem to be pretty well suited for FIRST in terms of price point, size (haven't used Jaguars in years specifically for that reason) and reliability during competition. Not working with screw terminals will be great as well, I always seem to lose those screws, and they're really hard to find once they roll away on the shop floor.

[AdamHeard]

The only thing I'm slightly worried about on these is the heat dissipation: I'm not exactly the most knowledgeable on the subject, but looking at the size, I'm a bit worried whether or not there will be enough surface area on the controllers to adequately cool them down. In the documentation, it states that the fins will take care of passive cooling, but we've traditionally put fans on our speed controllers, even the Talons (we had a bunch of extra fans of that size, so we figured why not). Would like to talk to some teams early in the season after they've started working with them, see what their findings are. Active cooling for these might be a challenge, aside from putting a big computer fan over a network just for a little cooling, I don't see an extremely efficient way of doing it.

However, I'm still really excited, as these seem to be pretty well suited for FIRST in terms of price point, size (haven't used Jaguars in years specifically for that reason) and reliability during competition. Not working with screw terminals will be great as well, I always seem to lose those screws, and they're really hard to find once they roll away on the shop floor.

I trust the parties involved when they say they are fine as is.

The talon worked fine without a fan and the thermal mass on it appeared to be much smaller for reference.

[Ether]

The body is made of aluminum, and it is isolated from the electronics inside. If you're concerned about cooling, rub some thermal paste on it and bolt it to an aluminum plate.

[cgmv123]

If you're concerned about cooling, rub some thermal paste on it and bolt it to an aluminum plate.

Or don't risk violating the rule against modifying electronics and add a fan instead.

[Ether]

Or don't risk violating the rule against modifying electronics and add a fan instead.

What rule did you have in mind, that prohibits mounting a motor controller using the provided mounting holes?

The thermal paste could be omitted, if that is the concern.

[cgmv123]

The thermal paste could be omitted, if that is the concern.

Yes, that would be the concern.

[philso]

I'm more worried about the PWM cables being attached. We've had far more PWM wires go bad over the years than 12AWG wire. It's going to be a little more annoying to troubleshoot since you can't just swap the PWM wires around at the speed controller. However I am glad that they all come with wires and I would hope they are nice high quality cable and connectors.

One of my concerns is that the PWM/CAN wires enters the enclosure within a mm or two of one of the input power wires in both the Talon SRX and the Victor SP. It will likely lead a lot of people to route the PWM/CAN wires adjacent to the input power wires for some distance. This arrangement makes it much more likely that the PWM/CAN wires pick up the noise from the switching action of the output transistors. It is likely that they have been able to use a smaller enclosure by using newer MOSFETs that have lower on-resistance (for lower conduction losses) and/or shorter rise and fall times (for lower switching losses). Shorter rise and fall times are likely to cause stronger inductive coupling of the switching noise into signal wires running in parallel with the power wires.

The integrated PWM wires will probably mean that more teams will have to purchase the pins and crimpers to replace/repair the connectors when they inevitably wear out or get damaged.

I am hoping that the power wires are truly a "high strand count" type (28 or 30 AWG strands instead of 25 AWG strands) with the soft silicone insulation. It would make it so much easier to do a neat job of running the power wires (VEXPro, are you listening?)

[RyanCahoon]

One of my concerns is that the PWM/CAN wires enters the enclosure within a mm or two of one of the input power wires in both the Talon SRX and the Victor SP.

The SRX interface drawing (http://content.vexrobotics.com/vexpro/pdf/217-8080-Drawing-20140818.PDF) lists the CAN leads as being twisted pair, which should help some (though I'm not sure how much).

---

I hope there's an allowance in the rules for year-to-year reuse of motor controllers that have had connectors attached to them.

[donkehote]

Yes, that would be the concern.

What rule disallows thermal paste? Sticking chemicals on the outside of electronics is modification? Would the same rule disallow Velcro attachment, or labels being applied to speed controllers? Both of those use chemical compounds applied to the heat sink causing different operating conditions.
Your post reminds me of the bumper pool noodle tape issue from last year.

Some things don't need regulating IMHO.

[mman1506]

The integrated PWM wires will probably mean that more teams will have to purchase the pins and crimpers to replace/repair the connectors when they inevitably wear out or get damaged.


Or cut an PWM extension in half and solder a new connector on. All teams should have soldering supplies.

Integrated PWM wires are very very common on RC multi-rotors, planes, cars .etc that experience quite a lot of wear. Multi-rotors particularly depend on high speed control loops where noise would be noticeable.

[DampRobot]

Let's hope this doesn't result in a massive shortage of motor controllers in 2015.

This. Given the price point, size, and the availability of other options, these things will be in truely massive demand once the season starts. I wouldn't be suprised if they sold 10,000 in the first month they're on sale. I also wouldn't be surprised if they sold out within the first day. So, basically, there will be massive problems if there aren't enough of these controllers to go around.

I trust Vex and CTRE to learn from their mistakes and do this launch right, but then again, I've been wrong before about trusting companies to have enough stock in time for the season. I hope we won't see any problems with inventpy come January (or even better, come November).

On the other hand, these things look amazing. I'm so jealous of the students that will get to use these things. I remember that it seemed that motor controllers just got 2x better when the origional Talon came out, and somehow they've don't it again. This is a huge leap forward in FRC motor controller technology.

[Jon Stratis]

What rule disallows thermal paste? Sticking chemicals on the outside of electronics is modification? Would the same rule disallow Velcro attachment, or labels being applied to speed controllers? Both of those use chemical compounds applied to the heat sink causing different operating conditions.
Your post reminds me of the bumper pool noodle tape issue from last year.

Some things don't need regulating IMHO.

Personally, I doubt any inspector would even notice thermal paste between a speed controller and an aluminum mount - you would have to take the controller off to see it! And as an LRI, it's something I've never actually considered before. R64 from 2014 does state that they "shall not be tampered with, modified, or adjusted in any way"... so the question comes down to whether thermal paste would be considered a modification or adjustment to the speed controller. I think most people would say no, but someone wanting to be strict may draw a parallel between R64 and R76, which states "All pneumatic COMPONENTS must be used in their original, unaltered condition", and has a blue box that specifically mentions items like painting...

You could, if you wanted, draw a parallel between R64 and R76 as both say you can't modify a part, and then a parallel between paint and thermal paste, as they are both topical coatings for a part. It's a bit of a stretch (and not anything I personally would call at an event unless otherwise instructed by the GDC), but it seems like a good question for the Q&A to me.

[cjl2625]

"Onboard closed-loop PID control" for the Talon SRX? What exactly does this mean? Can you tell it to move to a certain position like a servo, or something like that?

[theawesome1730]

I personally think the integrated pigtails are great. No more soldering crimp connectors (even though you shouldn't need to, better safe than sorry) to 2 sets of wires. I don't foresee reuse to be an issue if you invest in anderson powerpoles or similar connectors. We look forward to being able to beta test these awesome devices

and I'm liking the more standard measurements of the new victor

[Tristan Lall]

What rule disallows thermal paste? Sticking chemicals on the outside of electronics is modification? Would the same rule disallow Velcro attachment, or labels being applied to speed controllers? Both of those use chemical compounds applied to the heat sink causing different operating conditions.
That's exactly the dilemma: FIRST presumably doesn't want you to douse it in toluene (because you might dissolve something important), but they probably don't care if you write on it using a marker. And yet both chemicals' effects are governed only by the rather unspecific rule against modifications.

The typical compromise is to adopt an ad hoc interpretation of the term modification that is as loose as the circumstances will allow, in order to approximate a just outcome. It's a mess and an inefficient use of everyone's time to have to design with this nebulous constraint in mind.

A clear rule predicated on the functional effects of the modification would be more equitable, but it would also be harder to enforce with consistency and rigour, because of differences in officials' ability to identify and evaluate failure modes. A narrower rule that permits more freedom in design choices, but which also exposes some additional failure modes would also be more equitable, but less safe.

In this case, I vote for the latter: the catch-all safety rule is so strong that the additional safety afforded by the no modifications rule is sometimes negligible. Where that's the case, allow modifications, and focus attention on the teams that do something unsafe, rather than dividing attention among the teams that make mundane modifications safely.

[BitTwiddler]

"Onboard closed-loop PID control" for the Talon SRX? What exactly does this mean? Can you tell it to move to a certain position like a servo, or something like that?

PID stands for proportional-integral-derivative. This three dollar phrase means that for a speed control loop you can tell the speed controller to go to 2500 RPM and expect it to command the motor to go to 2500 RPM quickly, smoothly and precisely (assuming you have a rotary encoder to measure the speed at the shaft). I may not have the details quite right in this case but that's the general idea of PID for speed control.

For more on PID enter PID Controller in Wikipedia.

[cjl2625]

PID stands for proportional-integral-derivative. This three dollar phrase means that for a speed control loop you can tell the speed controller to go to 2500 RPM and expect it to command the motor to go to 2500 RPM quickly, smoothly and precisely (assuming you have a rotary encoder to measure the speed at the shaft). I may not have the details quite right in this case but that's the general idea of PID for speed control.

For more on PID enter PID Controller in Wikipedia.

I know what PID is, but I'm wondering what specifically an onboard PID on the motor controller entails and how you could use it. My last post was pretty unclear, sorry.
For example, could you just send an error, output range, and gains to the motor controller and would it calculate the PID itself?

[BitTwiddler]

I know what PID is, but I'm wondering what specifically an onboard PID on the motor controller entails and how you could use it. My last post was pretty unclear, sorry.
For example, could you just send an error, output range, and gains to the motor controller and would it calculate the PID itself?

Oops sorry if I sounded condescending. It would be kinda cool if it could automagically compute the PID coefficients but I suspect life wouldn't be that easy.

[Monochron]

I don't foresee reuse to be an issue if you invest in anderson powerpoles or similar connectors. We look forward to being able to beta test these awesome devices

Could someone post some examples of the Anderson powerpoles they have used with success in the past?

The only types that I have used (excluding the battery connectors) have been very shoddy; wires falling out, plastic crumbling, etc. Admittedly, this was years ago so I am hoping that newer versions are much better.

[Ether]

The second controller, the Talon SRX, is a CAN enabled motor controller with additional communication protocols and PID control.

Has anyone been able to find any details about the algorithm used for the built-in PID in the Talon SRX? Is it strict PID, or does it have, for example, user-selectable feedforward etc.

[timytamy]

Could someone post some examples of the Anderson powerpoles they have used with success in the past?

The only types that I have used (excluding the battery connectors) have been very shoddy; wires falling out, plastic crumbling, etc. Admittedly, this was years ago so I am hoping that newer versions are much better.

We use these (http://www.powerwerx.com/anderson-powerpoles/powerpole-sets/30-amp-permanently-bonded-red-black-anderson-powerpole-sets.html) as well as the 15A/45A versions when appropriate. The trick to them is that you really need the correct crimper (http://www.powerwerx.com/crimping-tools/tricrimp-crimping-powerpole-contacts.html), we've used that one for the past three years, and I can't recall anything really going wrong. We've found that generally the contact gets pulled out of the housing before the crimp fails.

[Jared]

I know what PID is, but I'm wondering what specifically an onboard PID on the motor controller entails and how you could use it. My last post was pretty unclear, sorry.
For example, could you just send an error, output range, and gains to the motor controller and would it calculate the PID itself?

It means you can plug a sensor like an encoder or potentiometer into the speed controller, then, with CAN, you tell the speed controller you want to enable PID control and what your PID gains are, and it will do the PID control logic on the speed controller itself.

The advantage is that you don't have to waste cRIO processing power on PID loops and you can run them much faster. The disadvantage used to be that the only controller you could use for it, the Jaguar, was big, expensive, and not as reliable as the Victor.

[Andrew Schreiber]

It means you can plug a sensor like an encoder or potentiometer into the speed controller, then, with CAN, you tell the speed controller you want to enable PID control and what your PID gains are, and it will do the PID control logic on the speed controller itself.

The advantage is that you don't have to waste cRIO processing power on PID loops and you can run them much faster. The disadvantage used to be that the only controller you could use for it, the Jaguar, was big, expensive, and not as reliable as the Victor.

And the CAN bus was a ticking time bomb on your robot. If one device dropped out the whole bus was screwed due to CAN Timeout exceptions.

Sincerely hope that's been fixed.

[FrankJ]

Has anyone been able to find any details about the algorithm used for the built-in PID in the Talon SRX? Is it strict PID, or does it have, for example, user-selectable feedforward etc.




The original blog says they will be in hands of the Beta testers soon. Hopefully they will post their experiences.

[Jared Russell]

Has anyone been able to find any details about the algorithm used for the built-in PID in the Talon SRX? Is it strict PID, or does it have, for example, user-selectable feedforward etc.




I would love to see a velocity PID loop with:

Selectable Frequency (though a fixed rate would be fine if it is fast enough)
User tunable P, I, D gains
User tunable Feedforward gain
User tunable Forward/reverse stiction compensation
User tunable Maximum output cap
User tunable Maximum integrator output
VERY IMPORTANT: Slave mode so that a single sensor can be used to control a multi-motor, multi-Talon mechanism (like the drivetrain). It was never really clear how to do this with Jaguars.

I do not think I would ever run a position control loop on the speed controller, but I can envision making heavy use of velocity control.

[Jon Stratis]

And the CAN bus was a ticking time bomb on your robot. If one device dropped out the whole bus was screwed due to CAN Timeout exceptions.

Sincerely hope that's been fixed.

The entire CAN subsystem has been re-written for the RoboRio... We've been doing some testing with a CAN robot (6 Jags, PDP and PCM), but we haven't yet tried to drop a jag to see what happens. I'll see if we can give that a try on Saturday.

[marshall]

VERY IMPORTANT: Slave mode so that a single sensor can be used to control a multi-motor, multi-Talon mechanism (like the drivetrain). It was never really clear how to do this with Jaguars.

I do not think I would ever run a position control loop on the speed controller, but I can envision making heavy use of velocity control.

According to CRE in St Louis, that is something they were/are working on. Granted, I don't work for them and we have minimal contact with them but this is one of the things we would like to see as well.

900 makes great use of CAN. We've been using it rather successfully (we think) for the last 4 years (ok, 3 but running Java in between was our own fault and we won't be doing that again). LabView was a lot easier to work with for CAN than Java was.

If we have the opportunity to beta test any of this then we most definitely will. We're eager to get started with our testing this Saturday (We're a residential high school and this week has been the first week back for the students).

Also, we've used both position and velocity control. Position is a lot more temperamental about having the correct values so tuning PID is more important, at least from our experience with it.

[philso]

Could someone post some examples of the Anderson powerpoles they have used with success in the past?

The only types that I have used (excluding the battery connectors) have been very shoddy; wires falling out, plastic crumbling, etc. Admittedly, this was years ago so I am hoping that newer versions are much better.

http://2014.discobots.org/node/94

http://lh5.ggpht.com/-4l8yI7w_YQg/UwAOYItcPQI/AAAAAAAAPdU/f-CPk6Mg2hs/s640/P2126448.JPG

The Talon motor controllers all had Anderson connectors on their outputs. This allowed the electronics panel to be built up outside of the robot then "dropped in" and connected to the eight drive motors and the collector motor. There was also a set of Anderson connectors at the end of the collector arm so that the collector motor could be swapped out without having to pull the wiring out of the collector arm. Anderson connectors were also used at bot ends of the wiring for the Spike relay controlling the compressor so that the compressor could be swapped out. They gave absolutely no trouble throughout the severe punishment of two regionals plus 3 off-season events. The polycarb panel only had to be removed for the Inspectors.

The trick to them is that you really need the correct crimper (http://www.powerwerx.com/crimping-tools/tricrimp-crimping-powerpole-contacts.html)

Absolutely! Doing a pull test on all crimps immediately after making the crimp will decrease the failure rate dramatically. That is what the assembly people at work are taught to do.

[AdamHeard]

Could someone post some examples of the Anderson powerpoles they have used with success in the past?

The only types that I have used (excluding the battery connectors) have been very shoddy; wires falling out, plastic crumbling, etc. Admittedly, this was years ago so I am hoping that newer versions are much better.

You must have been using something else, or counterfeit ones.

We've used Anderson's forever, and they are awesome. The housings are very durable.

[Bryce Paputa]

We've had issues with the Anderson connectors, both with the casings melting and with the terminals falling out of the casings. We use the correct crimping tool and the solder them, any idea what we might be doing wrong?

[philso]

You must have been using something else, or counterfeit ones.

We've used Anderson's forever, and they are awesome. The housings are very durable.

We use them at work in some of our industrial UPS' and have never seen them break down like that either.

We've had issues with the Anderson connectors, both with the casings melting and with the terminals falling out of the casings. We use the correct crimping tool and the solder them, any idea what we might be doing wrong?

It is likely that you may be getting too much heating from the contact resistance and/or sustained high currents. If the terminals are bent, the contact resistance may be high. I have also seen terminals where the silver coating was worn off, possibly leading to higher contact resistance.

[magnets]

Perhaps an EE could help me out, but why go to 15kHz for the switching frequency? Is the 1kHz used on the Victor 888 not smooth enough?

From my small knowledge of EMI, the effective interference from the motors is proportional to switching frequency and current, both of which are very high in this application. Putting so much circuitry right next to the controller (like the CAN bus) makes me a little nervous.

The motors also generate really strong fields and though they drop off quickly, they still have an effect on our control system. Now that our main controller is no longer in a big heavy metal grounded enclosure, I'm slightly concerned about this.

That said, I am not an EE, but I dislike anything that increases electrical interference on the robots.

[s1900ahon]

We've had issues with the Anderson connectors, both with the casings melting and with the terminals falling out of the casings. We use the correct crimping tool and the solder them, any idea what we might be doing wrong?

I had the pleasure of sitting beside an APP employee (Rich, if I recall correctly-I'm bad with names) at one of the Supplier Summit dinners. He was the guy who created the battery wires+SB50 for the KoP. I mentioned my team that year was crimping and soldering the connections. He discouraged soldering, indicating the potential to damage the terminal if soldered poorly. Since then I've just taken him at his word and my team just crimps with one of their tools. We've never had an issue with the housings deforming, either the ones we've crimped ourselves, the ones we've bought from AM (crimped), or the ones we receive in the KoP (crimped).

[Kevin Sevcik]

First off, I'm delurking after several months of down-time/new baby/work specifically to note that I drooled a little when I saw the tech-specs of these new controllers. We've always been attached to CAN, so we never went with the Talon SRs, and suffered mightily on mounting space for it. I'm really looking forward to packing 4-ish Talon SRXs into the footprint of a single Jaguar in 2015, and I will be sorely disappointed if I'm not allowed to do so. Also, I'm dearly hoping that CTRE will make the source for the controllers a little more open than it was for the Jags. The only thing available for the Jags was the very original non-FRC source, which made it troublesome to figure out what they were doing, why speed feedback wasn't reliable/available, etc.

If we're using this thread to put in feature requests, my request for the Talon SRX is for sensor feedback output regardless of what control mode you're in. One of the problems on the Jag was that you could only get certain feedback if you were in that particular mode. So speed feedback was only available in speed PID control. So no using the Jag as a sensor input for your nicer C++ PID code.

Magnets,
I think the number of teams using Jags/Talon SRs with no EMI problems is testament to the notion that PWM frequency isn't a huge EMI source on the bots. Since the new controllers will use the same sign-magnitude/synchronous rectification control as the Jag/Talon SR, it shouldn't be a problem. Sign-magnitude control toggles between the high/low FETs on the switched leg to switch between driving/recirculating the current. This makes for smaller current ripples and less EMI. You're probably going to get more noise from the brush commutation than the PWM switching, especially on high-speed 550-can motors.

[Ether]

Jags and Talons have always been 15KHz output.

The higher switching frequency reduces ripple current in the motor and motor wires. Ripple current contributes to motor heating and electrical noise.

[apples000]

Perhaps an EE could help me out, but why go to 15kHz for the switching frequency? Is the 1kHz used on the Victor 888 not smooth enough?

From my small knowledge of EMI, the effective interference from the motors is proportional to switching frequency and current, both of which are very high in this application. Putting so much circuitry right next to the controller (like the CAN bus) makes me a little nervous.

The motors also generate really strong fields and though they drop off quickly, they still have an effect on our control system. Now that our main controller is no longer in a big heavy metal grounded enclosure, I'm slightly concerned about this.

That said, I am not an EE, but I dislike anything that increases electrical interference on the robots.

I also am not an EE, but have a lot of experience with this sort of stuff. In short, you're right, the higher frequency is proportional to higher interference. That said, I checked the spec sheets, and the old Talons are operating at 15kHz, and people have been fine.

I don't understand the reason to go up to 15kHz for the controllers. Switching up to 100 amps at 15kHz is not something to be taken lightly, as the high current and frequency causes parasitic capacitance to ground. This results in an effect called common mode coupling, which ends up "contaminating" your ground plane. Anything else that uses this ground can be affected by it.

Switching to a higher frequency also makes the system less efficient. Although the more efficient sign-magnitude switching could make up for this loss, you'd see higher efficiency if it switched at 10kHz than 15kHz. The reason is that the faster you switch the FETs, the more time they'll end up spending in their switching state. The transition is not instantaneous, and as you increase frequency, they'll spend more time in between, which is inefficient.

Also, I can't really think of a great reason for them to go this high. The 1kHz frequency was audible, and so will the 15kHz frequency (close to the frequency your CRT television's transformer makes). The talon is 15kHz and the Victor 888 is 1kHz. You really can't tell the difference between the two frequencies, other than the noise they make.

[DampRobot]

Switching to a higher frequency also makes the system less efficient. Although the more efficient sign-magnitude switching could make up for this loss, you'd see higher efficiency if it switched at 10kHz than 15kHz. The reason is that the faster you switch the FETs, the more time they'll end up spending in their switching state. The transition is not instantaneous, and as you increase frequency, they'll spend more time in between, which is inefficient.

While I agree that in theory faster switching will decrease efficiency, I'm not sure that it'll be that large of an effect in practice.

At 15 kHz, a MOSFET would switch on and off twice every 1/(15 kHz), which is a switch about every 30,000 ns at 50% duty cycle. The MOSFETs I've seen on the market nowadays all switch faster than 10 ns, and some even faster than 5 ns IIRC. That's about .03% of each state at 50% duty cycle. Of course, as switch your FETs at closer to 0% or 100% duty cycle, the effect you're describing will be more important, but I don't think it'll significantly decrease the efficiency of the controller.

EDIT: For what it's worth, I'm not an EE either. But that could change in the future.

[SoftwareBug2.0]

The motors also generate really strong fields and though they drop off quickly, they still have an effect on our control system. Now that our main controller is no longer in a big heavy metal grounded enclosure, I'm slightly concerned about this.

I do not remember this ever being an issue with the old IFI controllers and they were a similar form factor.

[ToddF]

My biggest concern regarding the integrated leads is that installing connectors on the ends of the wires constitutes a modification away from COTS state. This means that use of a particular motor controller on a competition bot will (under current rules) only be legal during the year in which the connectors were attached. Currently, we utilize previously purchased Talons as spares. In a pinch, we have even raided previous year's robots for motor controllers (not at an event). With these new ones, unless the rules change, they have a built in expiration date. If you've already attached connectors, you can't use them on a competition bot after the next kickoff day. And cutting off the connectors and putting on new ones isn't legal because just cutting off the connectors doesn't return the wires to their original length. I think now is a good time to revisit the rules regarding reuse of parts. It was bad enough that we couldn't reuse CIMS, but CIMS are fairly cheap, and don't require swapping out very often. Not being able to reuse motor controllers is going to hurt our pocketbook.

[Gary Dillard]

I'm really torn about this. I'm thrilled with the new form factors and functionality in both of the new controllers. Both VexPro and CTRE build high quality, reasonably priced components that have brought competition to another level. But after being burned by the Talon shortage in 2013 and hearing about the Versachassis shortages in 2014, I have honest concerns with either company's ability to meet the demands of introducing a new product line. I don't have many choices - we can stock up on Talons now and miss an opportunity, try to stock up on new controllers (whenever they're available, it appears I can't even pre-order them yet) and gamble on them being legal, or just hang out and hope for the best.
Anyone at either company want to try to give me a warm fuzzy feeling about being able to buy speed controllers week 1? I'm not a business person but I get the difficulty in estimating demand and controlling supply of specific items. Convince me you've figured it out.

[marshall]

My biggest concern regarding the integrated leads is that installing connectors on the ends of the wires constitutes a modification away from COTS state. This means that use of a particular motor controller on a competition bot will (under current rules) only be legal during the year in which the connectors were attached. Currently, we utilize previously purchased Talons as spares. In a pinch, we have even raided previous year's robots for motor controllers (not at an event). With these new ones, unless the rules change, they have a built in expiration date. If you've already attached connectors, you can't use them on a competition bot after the next kickoff day. And cutting off the connectors and putting on new ones isn't legal because just cutting off the connectors doesn't return the wires to their original length. I think now is a good time to revisit the rules regarding reuse of parts. It was bad enough that we couldn't reuse CIMS, but CIMS are fairly cheap, and don't require swapping out very often. Not being able to reuse motor controllers is going to hurt our pocketbook.

Was this ruled on officially by FIRST that teams could not reuse CIMs after crimping on a connector? I don't know that I've ever seen that in the Q&A. I'm not going to throw any teams under the bus but lets face it, teams re-use CIMs.

You are definitely right about this given a pure legal reading of the rules though. I'd just like to know if FIRST has ruled on it.

[Monochron]

My biggest concern regarding the integrated leads is that installing connectors on the ends of the wires constitutes a modification away from COTS state. This means that use of a particular motor controller on a competition bot will (under current rules) only be legal during the year in which the connectors were attached. Currently, we utilize previously purchased Talons as spares. In a pinch, we have even raided previous year's robots for motor controllers (not at an event). With these new ones, unless the rules change, they have a built in expiration date. If you've already attached connectors, you can't use them on a competition bot after the next kickoff day.

I can't imagine that FIRST would rule in a way like this. It would be counter to the way teams have operated for years.

[D.Allred]

My biggest concern regarding the integrated leads is that installing connectors on the ends of the wires constitutes a modification away from COTS state. This means that use of a particular motor controller on a competition bot will (under current rules) only be legal during the year in which the connectors were attached. Currently, we utilize previously purchased Talons as spares. In a pinch, we have even raided previous year's robots for motor controllers (not at an event). With these new ones, unless the rules change, they have a built in expiration date. If you've already attached connectors, you can't use them on a competition bot after the next kickoff day. And cutting off the connectors and putting on new ones isn't legal because just cutting off the connectors doesn't return the wires to their original length. I think now is a good time to revisit the rules regarding reuse of parts. It was bad enough that we couldn't reuse CIMS, but CIMS are fairly cheap, and don't require swapping out very often. Not being able to reuse motor controllers is going to hurt our pocketbook.

Todd,
What rule would not allow CIM reuse?

David

[Jon Stratis]

The rule Todd is referring to is (from 2014):
R13

ROBOT elements created before Kickoff are not permitted.

This is clarified in a blue box,
Please note that this means that FABRICATED ITEMS from ROBOTS entered in previous FIRST competitions may not be used on ROBOTS in the 2014 FRC

along with the definition found in the glossary:
FABRICATED ITEM: any COMPONENT or MECHANISM that has been altered, built, cast, constructed, concocted, created, cut, heat treated, machined, manufactured, modified, painted, produced, surface coated, or conjured partially or completely into the final form in which it will be used on the ROBOT.

So, from a strict reading of the rule, crimping or soldering connectors to the ends of leads or even cutting the leads is an alteration, and makes an item (a CIM motor, one of these new controllers, etc) illegal in future years.

Now, I ask all of you two questions. First, do you think it's the intent of the rules to make a CIM motor illegal because you spent 30 seconds adding a pair of 50 cent connectors on it? Second, do you think your inspector, LRI, or any team at your event is going to know or care?

When I read the rule, two possible intents come to mind (note that I'm not the GDC, so I could be wrong about either/both of these):

The first is fair play - we don't want veteran teams having an advantage over rookie teams by being able to pull out a robot from 7 years ago that can already play the game, and instead of spending 6 weeks build one get to spend it improving and driving one. Veterans already have enough of an advantage through their experience with FIRST and through having people (mentors, upper classmen or graduates) with first hand experience in games similar to those we're playing now (for example, the similarities between Arial Assist and Over Drive).

The second is educational - we want the students on the team this year to have the experience of designing and building a robot, not just using what someone else built before them. I've heard before (on here? In LRI training? Not sure) that reusing an assembled gear box (which ships from the supplier unassembled) is illegal... but taking that gear box, breaking it down and then reassembling it during the build season makes it legal because you returned it to the form it arrived in. That strongly implies that the educational experience of assembling a gearbox and seeing how it works is important with this rule.

As an LRI, even if I was 100% certain that a team reused a CIM motor or speed controller and the connectors they had on it from the previous year, I wouldn't say anything or hassle them in any way. On the other hand, if a team comes in with a shooter on it I recognize, and I can verify that it came from a previous robot, they'll be in trouble. When we went with the new sizing rules, there were several teams that had to be lectured, as their re-use was obvious - they used the previous years frame and (assuming) drive train without modification. In that case, the modifications made to make it fit within the sizing parameters was enough of a penalty and lesson for the teams in question, and we could let them play once they got it fixed (which took the entire practice day, and afterwards their mechanisms had issues due to the changes).

[Gary Dillard]

Todd,
What rule would not allow CIM reuse?

David

R13 ROBOT elements created before Kickoff are not permitted. If you crimp on a connector you've created an element. A specific exception in R13 allowed using battery assemblies from prior years, so if there was a concern with something as simple as charging a battery being a modification it seems that crimping a connector would have the same concern.

[Alan Anderson]

What rule would not allow CIM reuse?

CIMS with crimps fall under the rule that makes any COTS part plus an added connector a non-COTS fabricated "assembly". Battery assemblies got an explicit exception a few years ago, so there is precedent for removing some restrictions on reuse.

[D.Allred]

CIMS with crimps fall under the rule that makes any COTS part plus an added connector a non-COTS fabricated "assembly". Battery assemblies got an explicit exception a few years ago, so there is precedent for removing some restrictions on reuse.

Interesting. I never thought of it this way. Definitely one for the Q&A.

By that logic, I could reuse a CIM (and the new Talons) if I used wirenuts and avoided a crimped connector.

David

[jwfoss]

By the letter of the rule connectors on a motor make it not longer COTS/Reusable, but by the intent of the rule, this entire conversation is beating a dead horse with a level that is unfortunately consistent with all things on ChiefDelphi lately.

I personally commend VEXpro and CTRE on their joint effort to produce this product, and am excited at the form factor and apparent quality, it should have a very positive impact on our wiring layout.

Perhaps they can just have connectors mounted to the motor controllers from the factory or push for a reasonable rule change (about motor leads and connectors on all motors and control hardware).

[AllenGregoryIV]

By the letter of the rule connectors on a motor make it not longer COTS/Reusable, but by the intent of the rule, this entire conversation is beating a dead horse with a level that is unfortunately consistent with all things on ChiefDelphi lately.


I agree it's not the intent of the rule but if some teams are following it to that level. There should be official clarification that they shouldn't be. They are at a disadvantage by holding themselves to a standard that I don't believe FIRST expects for them.

[magnets]

I agree it's not the intent of the rule but if some teams are following it to that level. There should be official clarification that they shouldn't be. They are at a disadvantage by holding themselves to a standard that I don't believe FIRST expects for them.

Agreed. They really need to publish a list that tells you what rules you don't need to follow.

For newer teams, it gets confusing.

[Jon Stratis]

Agreed. They really need to publish a list that tells you what rules you don't need to follow.

For newer teams, it gets confusing.

It's not a question about "what rules you don't need to follow"... it's about reading the rules for both the letter and intent of the law and using common sense in interpreting them.

[Andrew Schreiber]

It's not a question about "what rules you don't need to follow"... it's about reading the rules for both the letter and intent of the law and using common sense in interpreting them.

The issue is my view of intent is very different than your view of intent. But you can issue a red card retroactively if you find I viewed intent differently.

Rules should require intent to follow.

[notmattlythgoe]

The issue is my view of intent is very different than your view of intent. But you can issue a red card retroactively if you find I viewed intent differently.

Rules should require intent to follow.

Exactly, my interpretation of the intent can differ than yours. Just like the issue with the withholding allowance and robots in the parking lot this past season.

[Ether]

It's not a question about "what rules you don't need to follow"... it's about reading the rules for both the letter and intent of the law and using common sense in interpreting them.

Using common sense as a guiding principle, would it be permissible to apply a thin film of non-curing thermal grease (http://dowcorning.com/content/publishedlit/11-1712-01.pdf) to the mounting surface of the new Victor SP (or Talon SRX) before bolting it to the robot?

[headlight]

It was asked in Q&A for 2014. Q454 and Q445. (https://frc-qa.usfirst.org/Question/445/for-the-purpose-of-r18-is-a-cots-motor-with-trimmed-or-stripped-wires-considered-a-fabricated-item-due-to-its-altered-and-or-cut-state-what-effect-does-the-installation-of-connectors-have-on-thi)

Highlights:
"Installation of connectors would make the resulting assembly a FABRICATED ITEM."

"Some additional work must have been done to the part (e.g. trimming leads, adding connectors) after the 2014 Kickoff for the part to be legal per R13."

It was asked in the context of the rule that 45 lbs fabricated components (including spares) must be brought into first day of competition and inspected and that additional non-COTS items could not be stored outside the pits and used on the robot, hence the reference to the 45 lbs limit. The implication was that spare motors must be brand new in box motors with no connectors and they would be exempt from the limit.

Hopefully they straighten this out this year. Or we're going to need more motors.

[RogerR]

...Also, I like that I don't have to practically write a whole grant just to put some speed controls on our robot...

I've seen statements like this in several places, but it appears to me that they are essentially the same price as existing speed controller options. What am I missing that everyone else has noticed?

[Jon Stratis]

Using common sense as a guiding principle, would it be permissible to apply a thin film of non-curing thermal grease (http://dowcorning.com/content/publishedlit/11-1712-01.pdf) to the mounting surface of the new Victor SP (or Talon SRX) before bolting it to the robot?





I've already posted my opinion (http://www.chiefdelphi.com/forums/showpost.php?p=1397300&postcount=47)on that.

[magnets]

Using common sense as a guiding principle, would it be permissible to apply a thin film of non-curing thermal grease (http://dowcorning.com/content/publishedlit/11-1712-01.pdf) to the mounting surface of the new Victor SP (or Talon SRX) before bolting it to the robot?



Regardless of what somebody tells you is okay on the internet, any common sense interpretation of a rule is not guaranteed to be enforced equally between events.

Common sense to an engineer who designs speed controller would dictate that thermal compound is just fine.

Common sense to an inexperienced robot inspector who has no background in this matter might say that this is illegal.

It's not a question about "what rules you don't need to follow"... it's about reading the rules for both the letter and intent of the law and using common sense in interpreting them.

Unfortunately, I do not know the intent of the rule. I'd like to think that FIRST encourages teams to reuse parts from previous years, but in the past FIRST has required use to be wasteful with certain aspects of robot development.

Also, that's not a good enough answer for a team paying $5,000 to compete. An official who is in a bad mood can say "nope, you're wrong" and because they are the highest authority, there is nothing that you can do about it. It also makes things unfair, as different events will have different rules, as not everybody interprets things the same way, especially confusing. For example, nobody can describe the difference between defensive and offensive possession in words, so there will always be disagreements based on interpretation.

Putting in the clarifying sentence (not in a blue box, those things are evil) "Trimming or stripping wires on speed controllers or motors is not considered a modification for the purposes of G-(??)" takes under a minute to write, and helps everybody.

[Ether]

I've already posted my opinion (http://www.chiefdelphi.com/forums/showpost.php?p=1397300&postcount=47)on that.

Exactly. Your common sense says thermal paste is OK. cgmv123's common sense says it's not OK.

[AllenGregoryIV]

"Trimming or stripping wires on speed controllers or motors is not considered a modification for the purposes of G-(??)" takes under a minute to write, and helps everybody.

This should be expanded to pneumatics such as solenoid wires and compressors as well.

In general I think the reuse clause of the rules needs to be rewritten. I have had teams claim to me that if they cut off a section of 4'x8' polycarb in one season they couldn't use any of the rest of that sheet in another season. In my mind that is clearly not the case. The rest of the sheet is not in it's final configuration to go on the robot and is completely legal raw stock material to be cut and used on their robot. However the rule is still confusing teams and we should strive to have as clear rules as possible.

[FrankJ]

Point of reference. I am with Jon. When inspecting I would not consider terminals or leads on a motor/controller to change it from COTs to Fabricated. (Unless the LRI said different, I am a worker bee inspector.) But this in 2014 in came up in terms of the weight allowance for fabricated parts as a grey area. Generally If you look at the definition of "fabricated" in the rules & Q&A, it tends to be strictly defined. For instance using magic on a COTS item makes it Fabricated. I have seen several instances of letter of the rule verses intent of the rule cause headaches. It would be nice to have a blue box exception or similar.

[Alan Anderson]

Using common sense as a guiding principle, would it be permissible to apply a thin film of non-curing thermal grease (http://dowcorning.com/content/publishedlit/11-1712-01.pdf) to the mounting surface of the new Victor SP (or Talon SRX) before bolting it to the robot?

Common sense tells me that applying passive grease to a part is not a modification, but I can respect the opinion of others whose common sense tells them otherwise. However, I can also get all laywer-y and decide to apply the thermal grease instead to the spot on the robot where I'm going to mount the speed controller, and I don't see anything in recent rules that would make doing it a problem.

Actually, I'd probably avoid the messiness of grease and use a flexible thermally conductive pad.

[Alan Anderson]

By that logic, I could reuse a CIM (and the new Talons) if I used wirenuts and avoided a crimped connector.

I'm leaning toward Wago Lever Nuts, myself. They're definitely easier to install than a set of PowerPole connectors. The continuous current rating isn't as high as I'd like, but intermittent operation on a 40A circuit ought to be okay.

[cadandcookies]

I've seen statements like this in several places, but it appears to me that they are essentially the same price as existing speed controller options. What am I missing that everyone else has noticed?

I've been interpreting these statements as "It's really nice we won't have to buy ~$1000 of new speed controllers because our old ones are still legal." I don't have any background with a situation where teams had to replace all their speed controllers in one year, but then I've only been in FRC since 2011, so maybe someone who has been around longer can shed a historical light on this.

[Jon Stratis]

I've seen statements like this in several places, but it appears to me that they are essentially the same price as existing speed controller options. What am I missing that everyone else has noticed?

If I recall correctly, speed controllers used to be more expensive, but when the Talon came out there was a special introductory price that triggered big discounts on all of the speed controllers that pretty much never went away.

[Andrew Schreiber]

If I recall correctly, speed controllers used to be more expensive, but when the Talon came out there was a special introductory price that triggered big discounts on all of the speed controllers that pretty much never went away.

Yes, Victors were $120 if I recall.

[Paul Copioli]

Yes, Victors were $120 if I recall.

The Victor was not $120 when the Talon came out. It was $115 when the Jaguar came out in 2009.

It was reduced when the Jaguar was introduced in 2009 to $79, then reduced again when the Talon was introduced in 2013.

[Andrew Schreiber]

The Victor was not $120 when the Talon came out. It was $115 when the Jaguar came out in 2009.

It was reduced when the Jaguar was introduced in 2009 to $79, then reduced again when the Talon was introduced in 2013.

Sorry, bad recollection.

[waialua359]

I'm really torn about this. I'm thrilled with the new form factors and functionality in both of the new controllers. Both VexPro and CTRE build high quality, reasonably priced components that have brought competition to another level. But after being burned by the Talon shortage in 2013 and hearing about the Versachassis shortages in 2014, I have honest concerns with either company's ability to meet the demands of introducing a new product line. I don't have many choices - we can stock up on Talons now and miss an opportunity, try to stock up on new controllers (whenever they're available, it appears I can't even pre-order them yet) and gamble on them being legal, or just hang out and hope for the best.
Anyone at either company want to try to give me a warm fuzzy feeling about being able to buy speed controllers week 1? I'm not a business person but I get the difficulty in estimating demand and controlling supply of specific items. Convince me you've figured it out.
We're very happy about the new speed controllers and also VERY happy we have a huge stock of the current old ones. Thank God!

[s1900ahon]

The Victor was not $120 when the Talon came out. It was $115 when the Jaguar came out in 2009.

It was reduced when the Jaguar was introduced in 2009 to $79, then reduced again when the Talon was introduced in 2013.

I thought the Victor was reduced at the start of the 2010 competition season and to $90

http://www.chiefdelphi.com/forums/showthread.php?t=80576

[Paul Copioli]

I thought the Victor was reduced at the start of the 2010 competition season and to $90

http://www.chiefdelphi.com/forums/showthread.php?t=80576

I made the decision in 2009:)

The price actually changed in December, 2009.

[Monochron]

The blog say that "A selection of [the old] controllers will be available in the 2015 Kickoff Kits and/or through FIRST Choice".

Were there motor controllers in the KOP (http://www.usfirst.org/sites/default/files/uploadedImages/Robotics_Programs/FRC/Game_and_Season__Info/2014/Black_Tote_2014.1.7.pdf)this past year? Looking at the old FIRST Choice (http://firstchoicebyandymark.com/en/everything) site, it looks like only one type of controller (Talons) were available through there.

Basically this makes me nervous on the availability of old Talon SRs come January. I have been wanting to move our team to all Talon SRs for next year (or the new Victor SPs) if they are available, but this lack of surety has me worried. Right now there is no guarantee that Talon SRs will be available through FIRST channels, and there is no guarantee that Victor SP will be available through private channels.

[BigJ]

The blog say that "A selection of [the old] controllers will be available in the 2015 Kickoff Kits and/or through FIRST Choice".

Were there motor controllers in the KOP (http://www.usfirst.org/sites/default/files/uploadedImages/Robotics_Programs/FRC/Game_and_Season__Info/2014/Black_Tote_2014.1.7.pdf)this past year? Looking at the old FIRST Choice (http://firstchoicebyandymark.com/en/everything) site, it looks like Victors were not available through there.

Basically this makes me nervous on the availability of old Talon SRs come January. I have been wanting to move our team to all Talon SRs for next year (or the new Victor SPs) if they are available, but this lack of surety has me worried. Right now there is no guarantee that Talon SRs will be available through FIRST channels, and there is no guarantee that Victor SP will be available through private channels.

If I remember correctly Victors/Jags were in the KOP through a voucher to IFI/VexPRO.

[qnetjoe]

Paul,

Since you are watching this thread can you post more details about the feedback available on the Talon SRX?

I would love to see an outline on what features would be available, ie encoder, limit switches, analog?

[Monochron]

If I remember correctly Victors/Jags were in the KOP through a voucher to IFI/VexPRO.

That sounds familiar. I wasn't the one on the team doing the ordering so I wasn't entirely sure.

Based on the nature of those vouchers I'm assuming that in 2015 they would be used on the new Victors/Talons which would really be fantastic.

[Richard Wallace]

Definitely one for the Q&A.

By that logic, I could reuse a CIM (and the new Talons) if I used wirenuts and avoided a crimped connector.

I'm leaning toward Wago Lever Nuts, myself. They're definitely easier to install than a set of PowerPole connectors. The continuous current rating isn't as high as I'd like, but intermittent operation on a 40A circuit ought to be okay.I agree with Alan. The Wago lever nuts are made in Germany, where engineers are famously conservative about ratings. Their 32A rating should be sufficient for FRC connections between the new pigtail controllers and CIM motors. Recall that the CIM's own "normal" load is only 27A -- pretty conservative when you consider how hard they are routinely worked in FRC.

I also agree with D. Allred -- an official Q&A response would be helpful to teams (like mine) that have historically used 45A APP connectors between motors and controllers.

[cgmv123]

cgmv123's common sense says it's not OK.

My common sense doesn't matter. I'm just cautioning against applying thermal paste/grease to motor controllers since the (2014) rule against modifying control system components specifically mentions gluing as an illegal modification.

[AllenGregoryIV]

My common sense doesn't matter. I'm just cautioning against applying thermal paste/grease to motor controllers since the (2014) rule against modifying control system components specifically mentions gluing as an illegal modification.

Correct but the adhesive on velcro was readily viewed as okay, so there is a line. Placing that line can be challenging for some teams.

[PayneTrain]

Paul,

Since you are watching this thread can you post more details about the feedback available on the Talon SRX?

I would love to see an outline on what features would be available, ie encoder, limit switches, analog?

I'd be curious if/when they will reveal distributors. It's unclear to me (probably on purpose since it isn't finalized) whether or not VEXpro will be selling both exclusively to teams and its authorized resellers, AndyMark will be selling at least the Talon SRX exclusively, or if everybody is selling both.

[Ether]

My common sense doesn't matter. I'm just cautioning against applying thermal paste/grease to motor controllers since the (2014) rule against modifying control system components specifically mentions gluing as an illegal modification.

The point I was making is that "common sense" often does not lead to the same conclusion.

For example, my common sense tells me that non-curing thermal grease is *not* glue and therefore the gluing rule is not applicable.

But if the common sense of others differs, it's not "lawyering" to ask Q&A for clarification.

Then if Q&A doesn't answer (it happens), give it your best honest shot. Ask around and see what other respected teams are doing.

[wilsonmw04]

I would really like to see producers of these new produces comment on the stock levels they intend to have available on or before January 3rd, 2015. The only comment I have seen from Vex on this thread is correcting how much a Jag cost a few years ago.

[sanddrag]

Attn Paul and friends at IFI and CTRE.

How long are the wires on these things?

I'd pay an extra $10 per unit if the wires were something like 4 feet long, at least on the input and especially PWM wires. Can we make this an option?

[Jon Stratis]

On the parts we got for beta testing, the power and motor leads are 5.5" and the PWM wire is about 18" long.

[Joe Ross]

On the parts we got for beta testing, the power and motor leads are 5.5" and the PWM wire is about 18" long.

5.5 inches and 17.8 inches per the drawing: http://content.vexrobotics.com/vexpro/pdf/217-9090-Drawing-20140818.PDF

[Mark McLeod]

The high strand count Power Input/Motor Output leads appear to be 400 strand.
Nice and flexible.

[Travis Covington]

Attn Paul and friends at IFI and CTRE.

How long are the wires on these things?

I'd pay an extra $10 per unit if the wires were something like 4 feet long, at least on the input and especially PWM wires. Can we make this an option?

Team 254 has the same feelings. While we will likely put it nice and close to the PDB, it never hurts to have extra wire just in case. We do NOT want to have to splice in a wire to go to the PDB ever. The longer PWM would also allow us some breathing room when we inevitably re-terminate the ends once installed on the robot.

On the whole though, seriously no complaints on the form factor. Lots of awesome changes here.

[AllenGregoryIV]

Team 254 has the same feelings. While we will likely put it nice and close to the PDB, it never hurts to have extra wire just in case. We do NOT want to have to splice in a wire to go to the PDB ever. The longer PWM would also allow us some breathing room when we inevitably re-terminate the ends once installed on the robot.

On the whole though, seriously no complaints on the form factor. Lots of awesome changes here.

Now that we don't really need access to them anymore, other than the lights. I'm pretty sure we're going to find a way to mount a lot of them directly under the PD panel and just run the short wires right up to the panel. Having a little more wire would be nice though.

[Foster]

The high strand count Power Input/Motor Output leads appear to be 400 strand.
Nice and flexible.

That's a huge bonus for people trying to thread it around stuff. It's a shame that small rolls are so expensive.

Some other posts about Andersen power poles, I've used them for years in all sorts of conditions and never had a failure on properly crimped connections. Just buy the tool and use it. And there is a ton of connector colors. You can still meet the black /red wires that the inspectors like, but color code the connections.

I'm not sure on the request for 4 foot leads, but 1 foot on the power side would let you make a neat install with the new PDU. 5 inches isn't much to work with.

Thanks FIRST, it's August and we all know about a change, love this new open info flow!!

[Dale]

I know it would double the number of SKUs but I would pay another $5 to have the option of 3ft wires on them. Splicing all those wires doesn't seem like a swell idea from a reliability standpoint.

[BitTwiddler]

Now that we don't really need access to them anymore, other than the lights. I'm pretty sure we're going to find a way to mount a lot of them directly under the PD panel and just run the short wires right up to the panel. Having a little more wire would be nice though.

You'll still want access to the pushbutton to calibrate and change braking mode.

[AllenGregoryIV]

You'll still want access to the pushbutton to calibrate and change braking mode.

I don't think we have had to recalibrate or change the braking mode on any of our speed controllers once we have installed them and they are working. We make the brake/coast decision early on and don't change it. With CAN I believe you will be able to do this in software anyway.

[Andrew Lawrence]

Are there CAD models without the wires? I tried downloading them myself and taking them out but it took forever for Solidworks to recognize features from the imported bodies and eventually crashed.

[Ty Tremblay]

Are there CAD models without the wires? I tried downloading them myself and taking them out but it took forever for Solidworks to recognize features from the imported bodies and eventually crashed.

You could just thicken the surfaces and then cut the wires off.

[Joe Ross]

I noticed that both the Victor 888 and Jaguar are no longer purchasable on the vex pro website. Does this mean that all stock has been depleted, or do you need to do a phone order?

[FrankJ]

I am a little surprised no one has pointed out the main advantage of the new controllers. Not even the most inapt can fill the controllers with hot melt while trying to secure the PWM cable. :]

[Paul Copioli]

I noticed that both the Victor 888 and Jaguar are no longer purchasable on the vex pro website. Does this mean that all stock has been depleted, or do you need to do a phone order?


All stock has been depleted of both products.

[headlight]

Are there CAD models without the wires? I tried downloading them myself and taking them out but it took forever for Solidworks to recognize features from the imported bodies and eventually crashed.

Yeah. You're almost NEVER going to get recognize features to work with surface models.

I cleaned up a model of the new victor (removed interior surfaces), and removed the wires. I have attached a Solidworks model and a step file. The step file should actually come in as a solid (because there aren't as many gaps/overlapping geometry, I think I got all of them). There might be minor loss of fidelity because it got re-saved into step before being re-imported.

[Andrew Lawrence]

Yeah. You're almost NEVER going to get recognize features to work with surface models.

I cleaned up a model of the new victor (removed interior surfaces), and removed the wires. I have attached a Solidworks model and a step file. The step file should actually come in as a solid (because there aren't as many gaps/overlapping geometry, I think I got all of them). There might be minor loss of fidelity because it got re-saved into step before being re-imported.

Thank you very much!

[Kevin Sevcik]

I don't think we have had to recalibrate or change the braking mode on any of our speed controllers once we have installed them and they are working. We make the brake/coast decision early on and don't change it. With CAN I believe you will be able to do this in software anyway.You might need the buttons accessible for the CAN models, depending on how they work out the CAN addressing. To address the Jaguars, you theoretically chained them together, then sent an address set command and pressed a button on the Jaguar you wanted to set. In practice, you usually had to individually connect to a Jag to set its address. Or to read its address, for that matter.

I'm hoping the Talon SRX will have a better system for this. I'd be super happy if they decided to go the typical industry route and have a pair of rotary switches for setting the address, so you can set/read-off IDs without power or connectivity. Software addressing is theoretically nice until you have to figure out which devices on your network have conflicting IDs through said malfunctioning network.

EDIT: Found the detailed drawings of the Talon SRX, and there aren't any addressing switches on there at the moment, alas.

[Mark McLeod]

Here is a height comparison shot.

http://www.team358.org/files/programming/ControlSystem2015-2019/images/med_SpeedControllerHeightComparison.jpg

[Kevin Sevcik]

Here is a height comparison shot.

http://www.team358.org/files/programming/ControlSystem2015-2019/images/med_SpeedControllerHeightComparison.jpgWait. You mean to tell me these new speed controllers AREN'T two-dimensional? I take back everything I said about how ridiculously small these are compared to all previous FRC controllers.

Seriously though, these things are even smaller than Spikes. I can see why you would only bother with 4 relay ports on the roboRIO if you knew these were in the pipeline. Why bother with a 20A max relay with a fuse you have to replace when you can have a 40A speed controller in the same footprint?

[AndreaV]

Why bother with a 20A max relay with a fuse you have to replace when you can have a 40A speed controller in the same footprint?

There are 24.04 reasons why, but none of them are very good.

[Andrew Schreiber]

Wait. You mean to tell me these new speed controllers AREN'T two-dimensional? I take back everything I said about how ridiculously small these are compared to all previous FRC controllers.

Seriously though, these things are even smaller than Spikes. I can see why you would only bother with 4 relay ports on the roboRIO if you knew these were in the pipeline. Why bother with a 20A max relay with a fuse you have to replace when you can have a 40A speed controller in the same footprint?

Cost and Complexity for the end user? A relay is a lot easier to use than an ESC if all you need is forward/stop/reverse.

[Jared]

Seriously though, these things are even smaller than Spikes. I can see why you would only bother with 4 relay ports on the roboRIO if you knew these were in the pipeline. Why bother with a 20A max relay with a fuse you have to replace when you can have a 40A speed controller in the same footprint?

Driving solenoid valves, driving solenoid actuators, powering lights, saving money, and using parts you already have.

I still don't like the 4 relay ports on the roboRIO because we've used more than four relays multiple times. It seems kind of silly to me that we downgraded from a maximum of 16 relays to 4 on the new controller, considering the driving circuitry for the relays is probably not too complicated.

[FrankJ]

In my opinion, the spike is only useful for the compressor where you are allowed a self resetting breaker & very small motors like a window motors. With the mid size & larger motors, the least stall will blow the fuse.

[Joe Ross]

In my opinion, the spike is only useful for the compressor where you are allowed a self resetting breaker & very small motors like a window motors. With the mid size & larger motors, the least stall will blow the fuse.

With the 2015 control system, the Pneumatics Control Module (PCM) drives the compressor directly. That accounts for 90% of the uses of spikes we've had over the years.

[FrankJ]

With the 2015 control system, the Pneumatics Control Module (PCM) drives the compressor directly. That accounts for 90% of the uses of spikes we've had over the years.

Yay.

[Kevin Sevcik]

Cost and Complexity for the end user? A relay is a lot easier to use than an ESC if all you need is forward/stop/reverse.I'll grant you cost, with the Victor SR being $25 more than the Spike. I'm pretty doubtful on complexity of the robot itself. (A Victor SR is obviously internally more complex than a Spike.) The Spike is somewhat different from all the speed controllers mechanically, programmatically, and electrically (with that 20A fuse to think about). So I disagree with your position that a robot with two rather different kinds of motor controllers on it is simpler than a robot with only one type of motor controller. Especially since I've seen our novice programmers get somewhat confused by the difference between relays and speed controllers in C++.

Driving solenoid valves, driving solenoid actuators, powering lights, saving money, and using parts you already have.

I still don't like the 4 relay ports on the roboRIO because we've used more than four relays multiple times. It seems kind of silly to me that we downgraded from a maximum of 16 relays to 4 on the new controller, considering the driving circuitry for the relays is probably not too complicated.See below. With the Pneumatics Control Module, all your solenoid valves and compressors are taken care of. That leaves solenoid actuators and lights. And I wouldn't be surprised if the GDC treated the PCM like the solenoid breakout and let you power solenoid actuators from it. So lights. Which you could drive from a Victor SR if you wanted, actually.

With the 2015 control system, the Pneumatics Control Module (PCM) drives the compressor directly. That accounts for 90% of the uses of spikes we've had over the years.I'll ditto this. We've only used Spikes for compressors or really small loads that I just didn't want to find room for a Jaguar for. Now it's a Spike that I'd have to find room for.

[asid61]

Using common sense as a guiding principle, would it be permissible to apply a thin film of non-curing thermal grease (http://dowcorning.com/content/publishedlit/11-1712-01.pdf) to the mounting surface of the new Victor SP (or Talon SRX) before bolting it to the robot?





To me not allowing that seems mildly ridiculous. It's the equivalent of putting a label on a CIM and having it count as a modification.
Grease would be a safety feature IMO. Nobody wants the robot to go up in flames.

[cgmv123]

It's the equivalent of putting a label on a CIM and having it count as a modification.

Labeling is a listed exemption in the relevant 2014 robot rules regarding modifying electronics; adding thermal paste isn't.

[topgun]

Is there a drawing for the new Talon CAN controller available? What kind of connector will there be for CAN? Will we have to buy a special crimping tool?

I like the zip tie options for fastening, and the small form factor.

In 2013 we hit a limit with 8 CAN controllers. Anything after 8 was sporadic, so we had to back off down to 8. Will the new Talon have a similar limit, or is that more a function of the controller or bus?

I sense another FIRST Choice-esqu meltdown coming as 3000 teams attempt to order 30000 controllers on the first day of availability. :) Every year we are in the 8 - 10 range of controllers on our robot, in addition to several for testing.

[Kevin Sevcik]

Is there a drawing for the new Talon CAN controller available? What kind of connector will there be for CAN? Will we have to buy a special crimping tool?

I like the zip tie options for fastening, and the small form factor.

In 2013 we hit a limit with 8 CAN controllers. Anything after 8 was sporadic, so we had to back off down to 8. Will the new Talon have a similar limit, or is that more a function of the controller or bus?

I sense another FIRST Choice-esqu meltdown coming as 3000 teams attempt to order 30000 controllers on the first day of availability. :) Every year we are in the 8 - 10 range of controllers on our robot, in addition to several for testing.Here's your drawing. (http://content.vexrobotics.com/vexpro/pdf/217-8080-Drawing-20140818.PDF)
CAN wires are permanent pigtails just like the power and motor wires. There's two twisted pairs. Based on the roboRIO, the new CAN bus is two wire, not four, so each pair is a leg of the bus. I'm guessing wago lever nuts or something will be the preferred solution for tying all those pigtails together.

Also, we had no problems with 12 jags on the old CAN bus, so something must have been odd about your setup.

[dmaki]

I am curious to see what kind of connectors are on the CAN leads.


I talked to CTRE at CMP and he said he was considering using a 2 row 20 pin 2mm pitch connector for CAN, limit switch, and encoder inputs in order to fit on the small body of the motor controller. The same type of connector commonly used for JTAG debugging on ARM microcontrollers. Based on the drawing, 2mm pitch looks about right, but went down to 10 pins for limit switches and encoders and moved CAN to dedicated pigtails.

Also, I've just mounted 2 prototype Victor SP on a testbot. The wires are very supple and flexible. "Noodley", good stuff.

[FrankJ]

Since I don't speak for the Cross the Road people, this is based on what I know about CAN. CAN is a two wire bus. It is intended to be daisy chained. That would be the reason for two pairs. One in & one out. The legs of the pairs would be connected together in the Talon. I know some people use the star configuration for CAN & get away with it. It is not to the standard & it in not a best practice.

[Oblarg]

Since I don't speak for the Cross the Road people, this is based on what I know about CAN. CAN is a two wire bus. It is intended to be daisy chained. That would be the reason for two pairs. One in & one out. The legs of the pairs would be connected together in the Talon. I know some people use the star configuration for CAN & get away with it. It is not to the standard & it in not a best practice.

My only problem with the daisy-chain configuration is that it greatly exacerbates the failure mode. It's rather annoying to lose half of your motor controllers instead of just one of them.

It would be nice if there were a supported alternative.

[wilsonmw04]

My only problem with the daisy-chain configuration is that it greatly exacerbates the failure mode. It's rather annoying to lose half of your motor controllers instead of just one of them.

It would be nice if there were a supported alternative.

There is an alternate: PWM's

[Oblarg]

There is an alternate: PWM's

While in the past I would have wholeheartedly agreed, this is a far less-appealing alternative with the new control system.

[Monochron]

While in the past I would have wholeheartedly agreed, this is a far less-appealing alternative with the new control system.

Do you mean with the robotRIO, or because CAN benefits are now available. If the former, why is everyone so down on using PWMs with the roboRIO?

[Oblarg]

Do you mean with the robotRIO, or because CAN benefits are now available. If the former, why is everyone so down on using PWMs with the roboRIO?

The former.

AFAIK, in order to use solenoids, you must use CAN.

[notmattlythgoe]

The former.

AFAIK, in order to use solenoids, you must use CAN.

Correct me if I'm wrong, but I believe that the system is still plug and play with the modules. There is nothing extra needed to make the solenoid module work, the CAN implementation is in the background.

[marshall]

Since I don't speak for the Cross the Road people, this is based on what I know about CAN. CAN is a two wire bus. It is intended to be daisy chained.

Sorry Frank, but I'm really not sure where you are getting this from... In fact, you said it yourself, CAN is a two-wire BUS. Daisy chaining is just an easy method to accomplish it. There is nothing stopping you from putting terminating resistors at each one of your end points and then running everything back to a central hub rather than daisy chaining.

To my knowledge (and I haven't looked at all of the ISO standards and heaven only knows I could be wrong) there is nothing prohibiting the use of a star topology with a CAN network rather than a daisy chain topology.

[NotInControl]

The former.

AFAIK, in order to use solenoids, you must use CAN.

This may not be entirely true. While the new system does have a PCM module that automatically controls the compressor/pressure switch and has support for 8 solenoid channels.

Nothing stops you from using the 4 relay ports on the RoboRio to drive solenoids. Without needing to have a PCM.*

You can use One relay for the compressor, and 3 other relays for double acting solenoids. In fact, this is how we were running our pneumatics system using the RoboRio during Alpha testing when the PCM modules weren't supported yet. Only if you exceed 3 double solenoids, would you need to venture to use the CAN PCM module.

And even if you use the CAN module for pneumatics, that doesn't mean you can't or shouldn't use PWM. In fact, I believe most veteran teams will continue to use PWM on their drive train as a minimum despite the new control system, due to PWMs proven reliability and known failure modes. I believe this will be true even if they choose to use CAN motors elsewhere on their robot. Nothing currently prevents a mix use of CAN and PWM on the Robot.

*This is true as long as the 2015 rules do not prohibit this. Doing this is perfectly legal under 2014 rules.

Regards,
Kevin

[Jared Russell]

To my knowledge (and I haven't looked at all of the ISO standards and heaven only knows I could be wrong) there is nothing prohibiting the use of a star topology with a CAN network rather than a daisy chain topology.

(Passive) star topologies are more susceptible to reflections and fan-out problems than traditional bus topologies and are best avoided for CAN networks in my experience.

[NotInControl]

Sorry Frank, but I'm really not sure where you are getting this from... In fact, you said it yourself, CAN is a two-wire BUS. Daisy chaining is just an easy method to accomplish it. There is nothing stopping you from putting terminating resistors at each one of your end points and then running everything back to a central hub rather than daisy chaining.

To my knowledge (and I haven't looked at all of the ISO standards and heaven only knows I could be wrong) there is nothing prohibiting the use of a star topology with a CAN network rather than a daisy chain topology.

This is not accurate. CAN can not be wired like any other network.

The protocol is named CAN Bus because it should only be used in a bus as it was intented, a bus is a type of topology. CAN can not be used in a STAR or Ring topology or Hub type topology natively without having additional CAN modules, or increasing the complexity of the layout, and even so, in the end, the Ring or Star implementation will only be a cosmetic one, and will not be more efficient then the original Bus topology. You will also loose a lot of link speed.

The current CAN products we have available in the FRC control system, including 2015, are internally hardwired, such that if a device fails, only the device fails, it does not bring down the entire physical bus. The device CANs act as pass-through so you can communicate beyond a failed device. How the software reacts to an ID that does not exist because it failed is a different story. WPI is currently working on implementing a NON-blocking CAN implementation for 2015, which should help teams have more graceful software failures.

Saying that if one CAN module goes down the entire bus goes down, or saying anything beyond the failed device is unreachable after that module goes down is not correct and shouldn't be perpetuated. However, it is a true statement that if you were to CUT the wires on the CAN BUS, you would loose all communication beyond the cut. This is where PWM differs marginally. If you wired every motor to an individual PWM channel, then you would have to cut every PWM cable to have the same effect, making PWM more robust. However, the reason I said marginally is because most teams I have encountered in my FIRST decade use PWM Y cable or even tri cables to drive up to 3 motors off one PWM channel. In this scenario if you cut the one cable, you loose all downstream communication making it very similar to the CAN problem, although you do not need to worry about what the software does if you loose the PWM connection. (Maybe this will be true for CAN in 2015 as well, I haven't beta tested the new CAN implementation yet).

I am not trying to say one is better than the other, I am just trying to clarify the rumors around these technologies so that teams can have all the proper information when choosing which one best suits their needs, based on robot design criteria and experience.

Regards,
Kevin

[marshall]

This is not accurate. CAN can not be wired like any other network.

The protocol is named CAN Bus because it should only be used in a bus as it was intented, a bus is a type of topology. CAN can not be used in a STAR or Ring topology or Hub type topology natively without having additional CAN modules, or increasing the complexity of the layout, and even so, in the end, the Ring or Star implementation will only be a cosmetic one, and will not be more efficient then the original Bus topology. You will also loose a lot of link speed.

The current CAN products we have available in the FRC control system, including 2015, are internally hardwired, such that if a device fails, only the device fails, it does not bring down the entire physical bus. The device CANs act as pass-through so you can communicate beyond a failed device. How the software reacts to an ID that does not exist because it failed is a different story. WPI is currently working on implementing a NON-blocking CAN implementation for 2015, which should help teams have more graceful software failures.

Saying that if one ID goes down the entire bus goes down is not correct and shouldn't be perpetrated. However, it is a true statement, that if you were to CUT the wires on the CAN BUS, you would loose all communication beyond the cut. This is where PWM differs marginally. If you wired every motor to an individual PWM channel, then you would have to cut every PWM cable to have the same effect, making PWM more robust. However, the reason I said marginally is because most teams I have encountered in my FIRST decade use PWM Y cable or even tri cables to drive up to 3 motors off one PWM channel. In this scenario if you cut the one cable, you loose all downstream communication making it very similar to the CAN problem, although you do not need to worry about what the software does if you loose the PWM connection. (Maybe this will be true for CAN in 2015 as well, I haven't beta tested the new CAN implementation yet).

I am not trying to say one is better than the other, I am just trying to clarify the rumors around these technologies so that teams can have all the proper information when choosing which one best suits their needs, based on robot design criteria and experience.

Regards,
Kevin

Very useful. Thanks for clarifying.

[donkehote]

Labeling is a listed exemption in the relevant 2014 robot rules regarding modifying electronics; adding thermal paste isn't.

My common sense doesn't matter. I'm just cautioning against applying thermal paste/grease to motor controllers since the (2014) rule against modifying control system components specifically mentions gluing as an illegal modification.


Again, as Ether pointed out, thermal paste IS NOT GLUE. Glue is an adhesive, thermal paste is not.

Webster defines glue as : a substance used to stick things tightly together
http://www.merriam-webster.com/dictionary/glue
Even if you change glue to adhesive, thermal paste is not there to retain anything. It usually has a very weak bond, and often never sets, remaining a very thick liquid/gel.

Velcro is attached by adhesive or glue, but is legal. Please stop beating the dead horse :deadhorse: and move on. I know at least a few teams will have the thermal paste on these speed controllers, if its explicitly allowed or not. It would be almost impossible for a robot inspector to see the thermal paste in place anyway. Im sure as soon as the Q&A opens, there will be more than one person who asks this. No need to keep dragging up the same ridiculous argument.

[RonnieS]

Will you be able to use all PWM's for your speed controllers and just do a very simple can run to your PCM? I am not a programmer or heavy into electrical beside powers wires so don't kill me haha. Thanks.

[Bryce Paputa]

Will you be able to use all PWM's for your speed controllers and just do a very simple can run to your PCM? I am not a programmer or heavy into electrical beside powers wires so don't kill me haha. Thanks.
You should be able to.

[RonnieS]

You should be able to.

Ty Bryce! We have ran CAN for the last few years and really am ready to throw these $@#$@#$@#$@# jags away. But cost wise, the new victors are a lot more appealing and lending towards PWM use

[Tristan Lall]

Again, as Ether pointed out, thermal paste IS NOT GLUE. Glue is an adhesive, thermal paste is not.

Webster defines glue as : a substance used to stick things tightly together
http://www.merriam-webster.com/dictionary/glue
Even if you change glue to adhesive, thermal paste is not there to retain anything. It usually has a very weak bond, and often never sets, remaining a very thick liquid/gel.

Velcro is attached by adhesive or glue, but is legal. Please stop beating the dead horse :deadhorse: and move on. I know at least a few teams will have the thermal paste on these speed controllers, if its explicitly allowed or not. It would be almost impossible for a robot inspector to see the thermal paste in place anyway. Im sure as soon as the Q&A opens, there will be more than one person who asks this. No need to keep dragging up the same ridiculous argument.
The caution about thermal paste is due to a plausible analogy between substances, rather than a mere dictionary definition. Like glue, it doesn't fall off the surface, so some phenomenon must be holding it there; is that adhesion significantly different from the adhesion provided by glue? If so, why, and how will you convince the officials of that?

If it's an argument of magnitude of adhesion, would you have the officials permit weak glue as well? If it's an argument of function, would you have the officials permit glue whose adhesion is redundant due to additional fasteners? If it's because thermal paste doesn't set, would that make uncured glue legal? If it's because thermal paste is pretty much inert and can't chemically harm anything, would mostly-inert glue (like mucilage) be allowed? Or if it's a combination of these factors, how should they be weighted when making a determination?

As for Velcro, isn't it (usually) covered by exception G in R64? Its legality is not a very strong argument for thermal paste.

Best to let the Q&A sort it out, but by all means let FIRST know now that you anticipate it being an issue during the season.

[Tristan Lall]

Regarding the CAN bus, to some extent, there's always an aspect of star topology on the bus—but traditionally the stub length is short, possibly on the order of a couple of millimetres (in the case of a direct connection to an integrated CAN transceiver). Barring any strange internal arrangement on these controllers, if you leave one pair unconnected, you should still be able to make the connection downstream to the remaining pair, but your stub length will increase.

Here (http://www.onsemi.com/pub_link/Collateral/AND8376-D.PDF) are some general suggestions for optimizing stub length, given other parameters.

[FrankJ]

Regarding the CAN bus, to some extent, there's always an aspect of star topology on the bus—but traditionally the stub length is short, possibly on the order of a couple of millimetres (in the case of a direct connection to an integrated CAN transceiver). Barring any strange internal arrangement on these controllers, if you leave one pair unconnected, you should still be able to make the connection downstream to the remaining pair, but your stub length will increase.

Here (http://www.onsemi.com/pub_link/Collateral/AND8376-D.PDF) are some general suggestions for optimizing stub length, given other parameters.

I think of a star topology as the line length being short (or 0) relative to the stub length. Very different than what the CAN spec recommends. Without doing the math, I think you can get away with something approaching a star topology in FRC because the entire bus length is short. I have also run just one terminating resistor without issues. But if I were to start having problems, one of the steps would be to make the bus wiring completely to spec.

Here is what the CIA (http://www.can-cia.org/)-- the organization that maintains the CAN standard, not the American government entity with the same name has to say.

Network topology

This clause is most interesting for system designers.

Electrical signals on the bus are reflected at the ends of the electrical line unless measures against that have been taken. For the node to read the bus level correctly it is important that signal reflections are avoided. This is done by terminating the bus line with a termination resistor at both ends of the bus and by avoiding unnecessarily long stubs lines of the bus. The highest possible product of transmission rate and bus length line is achieved by keeping as close as possible to a single line structure and by terminating both ends of the line. Specific recommendations for this can be found in the according standards (i.e. ISO 11898-2 and -3).
...

[donkehote]

As for Velcro, isn't it (usually) covered by exception G in R64? Its legality is not a very strong argument for thermal paste.

Best to let the Q&A sort it out, but by all means let FIRST know now that you anticipate it being an issue during the season.



Quoting the 2014 rules, NO exception for Velcro, any team who used it violated the modifying motor controllers rule. I wonder if we should check every robot, and overturn matches from this past season? :yikes:

4.9.11 R64

The Driver Station software, cRIO, Power Distribution Board, Digital Sidecars, Analog Breakouts, Solenoid Breakouts,
RSL, 120A breaker, motor controllers, relay modules, Wireless Bridge, 12VDC-5VDC converter, and batteries shall not
be tampered with, modified, or adjusted in any way (tampering includes drilling, cutting, machining, gluing, rewiring,
disassembling, etc.), with the following exceptions:
Please note that the Driver Station application is a separate application from the
Dashboard. The Driver Station software may not be modified, while teams are expected
to customize their Dashboard code.
A. User programmable code in the cRIO may be customized.
B. DIP switches on the cRIO may be set (applies to cRIO-FRC only).
C. Motor controllers may be calibrated as described in owner's manuals.
D. Fans may be attached to motor controllers and may be powered from the power input terminals.
E. If powering the compressor, the fuse on a Spike H-Bridge Relay may be replaced with a 20A Snap-Action
circuit breaker.
F. Wires, cables, and signal lines may be connected via the standard connection points provided on the devices.
G. Fasteners may be used to attach the device to the OPERATOR CONSOLE or ROBOT.
H. Labeling may be applied to indicate device purpose, connectivity, functional performance, etc.
I. Brake/Coast jumpers on motor controllers may be changed from their default location.
J. Limit switch jumpers may be removed from a Jaguar motor controller and a custom limit switch circuit may be
page 63 / 93
substituted.
K. If CAN-bus functionality is used, the Jaguar firmware must be updated as required by FIRST (see Rule R67-D).
L. Devices may be repaired, provided the performance and specifications of the device after the repair are
identical to those before the repair.


Again, im saying that it should be left to the Q&A, and that lawyering rules to this point isnt what FIRST is about, and as I said in my first post in this thread


Your post reminds me of the bumper pool noodle tape issue from last year.

Some things don't need regulating IMHO.

The tape that many many teams had used for years to fabricate clean tidy bumpers was technically illegal, almost impossible to detect, and spawned a long thread on chief, only to be explicitly allowed by first. Why people keep dragging up the ridiculous argument against thermal paste (replace thermal paste with tape and your back in last years thread) is beyond me, just let the Q&A make the final call.

Come on guys, use some common sense, If adding fans is legal for the purposes of cooling, do you really think first wouldn't allow thermal paste for the same reason?

[Alan Anderson]

Quoting the 2014 rules, NO exception for Velcro...

4.9.11 R64
[...]
G. Fasteners may be used to attach the device to the OPERATOR CONSOLE or ROBOT.

Velcro is a brand of hook-and-loop fastener.

[FrankJ]

snip

Again, im saying that it should be left to the Q&A, and that lawyering rules to this point isnt what FIRST is about, and as I said in my first post in this thread



The tape that many many teams had used for years to fabricate clean tidy bumpers was technically illegal, almost impossible to detect, and spawned a long thread on chief, only to be explicitly allowed by first. Why people keep dragging up the ridiculous argument against thermal paste (replace thermal paste with tape and your back in last years thread) is beyond me, just let the Q&A make the final call.
...

Properly applied, the thermal paste will not be visible to the inspector so it shouldn't come up for discussion. If it does come up & in the inspector's judgement against the rules, it is easily removed. Unlike the thermal paste that is likely on the inside of the motor controller. Please note: I am not suggesting that anybody cheat. Hiding something from the inspector does not make it legal.

Remember it was response to a Q&A question that got bumper tape banned in the First place. After considered discussion, they wisely amended their position. Silliness abounds on all sides. :]

[donkehote]

Velcro is a brand of hook-and-loop fastener.

Not to be stupid, but isnt it an adhesive or glue that attaches each side of the hook and loop to the speed controller? Essentially the same as gluing a nut onto the bottom of a speed controller. It IS a fastener, but its not attached with a fastener, its attached with an adhesive.

I do understand your point though.

[mklinker]

I would love to hear what procedures IRI and CTRE have in place for assessing demand and reacting quickly to the supply of the new motor controllers. Using the initial Talon release and the shortages that ensued along with IFI's struggles to match inventory with demand, motor controllers could be scarce this season. Vex shows no stock of the old Jaguar and Victor controllers to supplement. AndyMark appears to have some Talons.

I expect demand to be high for both of the newly designed controllers!

What will the restocking time frame look like? Is anyone else concerned?

I am looking forward to the new controllers!!!!!!!

[AdamHeard]

I would love to hear what procedures IRI and CTRE have in place for assessing demand and reacting quickly to the supply of the new motor controllers. Using the initial Talon release and the shortages that ensued along with IFI's struggles to match inventory with demand, motor controllers could be scarce this season. Vex shows no stock of the old Jaguar and Victor controllers to supplement. AndyMark appears to have some Talons.

I expect demand to be high for both of the newly designed controllers!

What will the restocking time frame look like? Is anyone else concerned?

I am looking forward to the new controllers!!!!!!!

I'm not concerned for a few reasons.

I imagine all parties involved have learned well from the previous events.

Another reason is essentially they are the only speed controller on the market for FRC. Predicted demand should be easier. It's not them predicting how many teams will reuse speed controllers, how many will buy the competitors, and how many will buy theirs. It's just them predicting how many teams will buy versus reuse.

When you compare this to the mechanical items it's not even fair. The purchase of mechanical components aren't an A or B or C thing, they're A1.... Z1242123. Even though Hex bearings are popular in FRC, I doubt anyone on chief would be able to accurately predict the amount purchased even IF they had access to all of the sales numbers from all of the venders (other than a lucky guess).

I don't think they owe a public explanation to us on HOW they plan to do it (such information is propriety and the kind of knowledge that is worth good money).

I'm pretty confidant it will be handled well.

Edit. Since the parties involved represent the combined only source for speed controllers for the last few years, they now have exact numbers for how many teams purchase versus reuse. Plus margin for teams upgrading.

[Jon Stratis]

I agree with Adam - I think they'll probably do alright with speed controllers. All the same, I personally would encourage veteran teams to hold off on purchasing new ones a little bit so that rookies can get what they need - Veterans simply have more options than rookies do, as we are fortunate enough to have controllers we can pull off old robots.

It's really something when you think about what sort of inventory they might have for this upcoming season. If we just estimate about 5 new speed controllers for every team (some teams won't get any, some teams will buy 20), then that's ~15,000 new speed controllers. With an average price of $70 (assuming even distribution between Talon and Victor), that's over $1,000,000 worth of speed controller stock for just one season!

Obviously, some major assumptions there. How many veteran teams will decide to use the "tried and true" speed controllers and avoid the new ones for at least 1 season? How many teams will decide to use all new ones? What will the mix be between PWM and CAN use with speed controllers and the new control system?

[mwtidd]

I find it a bit curious that they chose to utilize a single button to calibrate the speed controller, as well as switch between brake and coast modes.

[AdamHeard]

For reference. We plan to order 40 or so.

That's a good deal of our budget but we're at the point where we need more anyway and it's a good time to switch.

[Tom Line]

Another reason is essentially they are the only speed controller on the market for FRC.

That's the very unfortunate aspect of what is going on with the new speed controls. In the short 2 year time that the Talon came on the market, we saw an upgraded 888 and a price cut of around 50%.

I hope some creative FIRSTer can get involved and bring another competitive product to market. A single-source supplier for such a critical component usually isn't a good thing from a consumer's point of view. Alternatives are important.

[Andrew Schreiber]

That's the very unfortunate aspect of what is going on with the new speed controls. In the short 2 year time that the Talon came on the market, we saw an upgraded 888 and a price cut of around 50%.

I hope some creative FIRSTer can get involved and bring another competitive product to market. A single-source supplier for such a critical component usually isn't a good thing from a consumer's point of view. Alternatives are important.

While I agree with you as a general rule I'm not sure much can be done here. In FRC these are the only games in town but even if you look at other brands that aren't FRC legal they are fairly close in price once you're comparing feature sets. (12V, 40A continuous, R/C control, Reversible) and I'd gladly pay the SMALL premium to get a brand that has a reputation for solid ESCs.

[Jon Stratis]

That's the very unfortunate aspect of what is going on with the new speed controls. In the short 2 year time that the Talon came on the market, we saw an upgraded 888 and a price cut of around 50%.

I hope some creative FIRSTer can get involved and bring another competitive product to market. A single-source supplier for such a critical component usually isn't a good thing from a consumer's point of view. Alternatives are important.

Tom, isn't the entire control system single source? There's only one source for a RoboRio. There's only one company that makes the required PCM and PDP. We can only use one specific brand/model of router.

The competition comes in, I think, when FIRST put out the RFP for the new control system - companies had a chance to come in, show off what they had for everything (including speed controllers, if I remember correctly) and get themselves chosen to supply things for the next few years.

[Tom Line]

Tom, isn't the entire control system single source? There's only one source for a RoboRio. There's only one company that makes the required PCM and PDP. We can only use one specific brand/model of router.

The competition comes in, I think, when FIRST put out the RFP for the new control system - companies had a chance to come in, show off what they had for everything (including speed controllers, if I remember correctly) and get themselves chosen to supply things for the next few years.

Yep - the control system is singled sourced. That makes perfect sense from a complexity and safety standpoint - those components work together in a number of ways.

A PWM driven speed controller is stand-alone enough that competition can still be created though. The rest of the control system, not so much, except possibly the VRM.

[Paul Copioli]

To be clear, last year there were three speed controllers made by two companies. This year there are two speed controllers made by the same TWO companies, not one. We decided to work together to better be able to meet the demand and have the absolute best products for the market.

This is a small market and the cost to enter this market is very high. Instead of competing all the time, we decided to work together for the greater good of the FRC community. IFI believes this is a win-win-win-win for all parties involved.


With that said, I don't understand why people think it is ok to have a single source for the robot controller and power distribution but is such an "unfortunate" thing to have two FRC suppliers work together on two completely different speed controllers.

Paul

[DampRobot]

That's the very unfortunate aspect of what is going on with the new speed controls. In the short 2 year time that the Talon came on the market, we saw an upgraded 888 and a price cut of around 50%.

I hope some creative FIRSTer can get involved and bring another competitive product to market. A single-source supplier for such a critical component usually isn't a good thing from a consumer's point of view. Alternatives are important.

I don't think that's going to happen. The economics just don't work out.

Let's take a look at what would happen if I (yes, me personally) were to try to get into the speed controller market.

Let's say that I haven't found the "killer app" for speed controllers, I just want to make something that's cheap, reliable, fairly linear, small, etc. Basically, I want to clone the new Vic. Maybe I adapt the package to the requests people have made in this thread, but nothing too out of the box.

First of all, I'd have to invest in commercial CAD software. Eagle (ECAD) runs ~$200 per license, and SolidWorks is probably several thousand dollars, without a whole lot of bells and whistles. Now, I can actually start designing. I'd estimate that it would take me about two weeks working part time to get a solid first revision of a speed controller.

Once I've got a first rev ECAD and MechCAD, I send it around to a few friends to take a look at, make revisions, and start to order prototypes. I can get a run of probably 15-20 speed controller boards at something like $300 for the lot (you don't usually pay per board for prototype PCBs, it's essentially a fixed price for a board of a given size of parts). FETs are going to run about $10 per H-bridge, plus annother $15 for other components, assuming we don't put anything too too fancy on the board. Some basic logic chips, LEDs, caps, etc. Now, let's say that I beg some machine time from a local team I'm friends with rather than pay probably ~$1000 for a run of 15 prototype aluminuim enclosures. Still, I have to pay for material, and maybe some tooling, so let's say that that adds annother $150.

I just paid around $825 assuming I make 15 prototype boards and assemble them myself (and not including the price of the CAD software!). This is just a broad estimate, without doing the research, it's my best guess, but in reality the real number could be anywhere between $500 and $1200. That's around $55 per prototype board, assuming $825 total in prototyping costs. Maybe I give these controllers to some teams to run at offseasons, and make updates to the product as requested for the regular season.

Alright, we've just invested some money in prototype speed controllers, now let's take a look at what kinds of costs well incur from the real production run. In order to make any money on these things, I'm going to get them made offshore, and assembled and tested there as well. We can probably get the board costs down to ~$5 a board for a large run, and let's also say we can bring component costs down, to $15 per board. Assembly is probably going to add $2-3 per board, so with board MFG, components, assembly, and testing, let's say that were paying $25 per board. I'd expect VP to be paying something similar, maybe as low as $15 per board, and certainly no higher than $30 per board. Then I have to pay to get the enclosure made. The Vic casings are aluminuim molded, so that means high startup costs, and low unit costs, so I'm not really sure what that would end up costing per unit. I'll just estimate $10 per unit, including ano. None of this includes the probably ~$1500 trip I have to take to make sure all of this stuff is getting made to my specifications.

Let's ship all this stuff over to the US for, let's say, $5 per unit, assuming we don't break the bank for air shipping. We paid about $40 for each unit. Now, we have to pay some guy to assemble the PCB in the casing, and put it in a nice little cardboard box. Maybe that adds annother $5 per unit, maybe a little less. Were looking at a total cost of $45 per unit. Maybe my estimates too high, but I'm guessing even for VP, they must be paying over $30 per unit that they can actually sell.

So, how do we price them then? Well, even if we assume we have a slightly better product in terms of features than VP, we definitely can't price them any higher $60. No one would buy a new unproved product from a completely new company unless they got some really awesome features or a really awesome price. Let's say I price them at $49.99 per unit in the hopes that I can undercut VP.

Ok, I cross my fingers that the things work well (they do), people like the product (they do), that China doesn't screw up (they don't), and I actually get them in stock in time (I also do). These are really big gambles, but let's just roll with it. Let's also say that I am really confident these guys will sell and order a run of 500. That's probably 3-5% of the FRC market. At $45 in costs per, that's $22,500 invested just in inventory. Finally, imagine these guys do sell like the dickens (again, a big gamble), I've just made $2500. That might, just might, be enough to pay off my development costs.

So, after a season of hard work, big investments, big gambles, and a lot of luck, how much dough did I rake in? Well, if I'm lucky, I didn't lose anything. This is for a probably $20,000 investment from my personal savings (not that I have that much!), and hundreds of hours of work.

I could have made probably $1200 from my actual job, coaching swimming, instead of working on this project, and to earn that money, I wouldn't have had to put up such a crazy amount of money with such a crazy amount of risk. I could have probably make even more money if I got a paid technical internship (designing speed controllers for example).

Basically, my point is that the speed controller market requires a lot of capital, and if you don't have the experience and established reputation like VP and CTRE do, it just becomes really, really risky to get a product that works well at a price that could sell well. While I don't agree with all of VP or CTRE's decisions, I don't think they're putting out a bad product or gouging us. They're probably making a big of money off of speed controllers, but I don't blame them. They've got full time engineers to pay, and a business to run. They're selling good, reliable products, and as a consumer, I feel like I'm getting my money's worth.

But anyway, given the costs and risks involved, it doesn't make that much sense to get into the speed controller market at this point.

Edit: Paul beat me.

[wilsonmw04]

To be clear, last year there were three speed controllers made by two companies. This year there are two speed controllers made by the same TWO companies, not one. We decided to work together to better be able to meet the demand and have the absolute best products for the market.

This is a small market and the cost to enter this market is very high. Instead of competing all the time, we decided to work together for the greater good of the FRC community. IFI believes this is a win-win-win-win for all parties involved.


With that said, I don't understand why people think it is ok to have a single source for the robot controller and power distribution but is such an "unfortunate" thing to have two FRC suppliers work together on two completely different speed controllers.

Paul

Can you comment on what your projected stock levels will be by January, 2nd 2015?

[AdamHeard]

Can you comment on what your projected stock levels will be by January, 2nd 2015?

He doesn't have to. Like I said above such information is generally closely guarded.

It's in the best interest of vex to fulfill everyone's order.

[Paul Copioli]

Can you comment on what your projected stock levels will be by January, 2nd 2015?


This is not something we typically do.

By the way, VEX has NEVER run out of Speed Controllers during the FRC season since I have been the President.

Instead of looking at the perceived negatives of CTRE and VEX working together, I urge the community to look at it from a different perspective.

Consider the things VEX has historically been good at and the things CTRE has been good at and combine them. That is what the teams will get out of this partnership.


**And before anyone goes there again, comparing 2 SKUs for a product that there are limited supplier choices to 300 new SKUs in an environment where there is an established company and a completely unknown use case is just silly.**

Paul

[magnets]

This is not something we typically do.

By the way, VEX has NEVER run out of Speed Controllers during the FRC season since I have been the President.

Instead of looking at the perceived negatives of CTRE and VEX working together, I urge the community to look at it from a different perspective.

Consider the things VEX has historically been good at and the things CTRE has been good at and combine them. That is what the teams will get out of this partnership.


**And before anyone goes there again, comparing 2 SKUs for a product that there are limited supplier choices to 300 new SKUs in an environment where there is an established company and a completely unknown use case is just silly.**

Paul

I do believe that meeting supply is possible, and that if anyone can do it, it's VEX, but people have the right to be a little concerned.

Historically, these sorts of things have sometimes been poorly executed, like everything BaneBots (remember CIM-u-lators in 2012?), game piece availibility (poof balls, orbit balls), VEX gearboxes (2 years), VEX/AM hex bearings, FIRST Choice (twice, and they knew the exact number of teams both times...), and a few others.

IMO, the biggest possible issues wouldn't be stock, but possible issues with the products themselves. They've gone through beta testing and I'm sure they've been designed really well (a group project between Talon and Victor engineers), but issues that pop up during production can be hard to spot.

That said, I really don't think there will be an issue. All companies/people involved know what they're doing, and I have faith in them. Even if something does go wrong, complaining about it on the internet won't solve anything.

[Ether]

Using common sense as a guiding principle, would it be permissible to apply a thin film of non-curing thermal grease (http://dowcorning.com/content/publishedlit/11-1712-01.pdf) to the mounting surface of the new Victor SP (or Talon SRX) before bolting it to the robot?

I created a new thread here (http://www.chiefdelphi.com/forums/showthread.php?p=1398430#post1398430) to share a recent experience with TIM (Thermal Interface Material).

[wilsonmw04]

This is not something we typically do.

By the way, VEX has NEVER run out of Speed Controllers during the FRC season since I have been the President.

Instead of looking at the perceived negatives of CTRE and VEX working together, I urge the community to look at it from a different perspective.

Consider the things VEX has historically been good at and the things CTRE has been good at and combine them. That is what the teams will get out of this partnership.


**And before anyone goes there again, comparing 2 SKUs for a product that there are limited supplier choices to 300 new SKUs in an environment where there is an established company and a completely unknown use case is just silly.**

Paul

Thank you for the reply, Paul. The more transparent you are with this situation, the better your customers will feel about this. Please, excuse my bluntness, but I do I have a concern. Essentially, the two producers of FIRST approved motor controllers have joined forces to create an great new product. I am excited about the form factor. I am worried about supply. This is a rational concern considering that it seems every year something is in short supply in the FIRST community. Will there be a limit on the amount a team can order at one time. If folk order 40 at a time (yeah 40! read the thread) can you guarantee that all customers will have access to this new product?

I have a small supply of new motor controllers on hand from last year and a stock of used ones. If replacements are hard to come by, I am worried I will not have access to this new source of material when i need them for the build season.

[Paul Copioli]

Thank you for the reply, Paul. The more transparent you are with this situation, the better your customers will feel about this. Please, excuse my bluntness, but I do I have a concern. Essentially, the two producers of FIRST approved motor controllers have joined forces to create an great new product. I am excited about the form factor. I am worried about supply. This is a rational concern considering that it seems every year something is in short supply in the FIRST community. Will there be a limit on the amount a team can order at one time. If folk order 40 at a time (yeah 40! read the thread) can you guarantee that all customers will have access to this new product?

I have a small supply of new motor controllers on hand from last year and a stock of used ones. If replacements are hard to come by, I am worried I will not have access to this new source of material when i need them for the build season.

You have every right to be concerned.

Let me try to put you at ease. IFI has 14 years of FRC speed controller history. Unlike gearboxes, wheels, and motors; This history has proven to be very predictable. Our data, combined with CTRE's data from the last two years has kept that predictable trend going.

We are manufacturing enough speed controllers for even the most optimistic of forecasts. Now, getting the mix between the two may take a season to get right but we have accounted for that in our forecast model.

Again, unlike other products for this market, the historical data has proven very reliable. VEX has never run out of speed controllers during the FRC Season in the past and we aren't going to start now.

Paul

[marshall]

VEX has never run out of speed controllers during the FRC Season in the past and we aren't going to start now.

That sounds like a challenge. ;-)

EDIT: Seriously Paul, thank you for commenting and talking to the community. I know I'm not alone in having an appreciation for manufacturers that take the time to reach out like you are.

[Monochron]

For reference. We plan to order 40 or so.

That's a good deal of our budget but we're at the point where we need more anyway and it's a good time to switch.

I feel like I have to ask, how much benefit are you going to see in a 3-4 month period by ordering 40 of these? Would it be any additional burden on your team to order maybe 15 or so for the season, and then order an additional 25 next summer?

While I think we are probably not going to see dire shortages, I don't really get the rationale of purchasing so many at a time. If this is something that a lot of financially able teams do, it may actually have a small effect on supply.

[EricH]

I feel like I have to ask, how much benefit are you going to see in a 3-4 month period by ordering 40 of these? Would it be any additional burden on your team to order maybe 15 or so for the season, and then order an additional 25 next summer?

I'm not Adam, but I think I know where he's going based on past posting history. I would guess that only about 30 will see use during build, the rest are spares. Those 30 are for characteristics testing, a practice robot or two or three, and the competition robot, maybe a couple to loan to other teams. Due to the speed controllers being an unknown quantity* as far as shaving resistance, heat tolerance, I would guess extra spares as well. I'd also hazard a guess that many of those will end up on next year's robot as well, meaning fewer purchased next year.

For perspective, let's assume that a "typical" robot has about 10 motors of various types--minimum 4, maximum 22 not that anybody ever uses that many. 10 seems to be fairly consistent for a medium-complexity robot. All 10 motors need speed controllers--also typical, though occasionally someone'll use a Spike on one or two. Of course, you want some spares--raiding last year's 10-controller robot isn't always a practical option--so let's say 15 for competition. (See, they're already at your proposed quantity, and I haven't even finished.) Now, let's factor in the practice robot that many teams build--that's another 10 controllers; share the spare pool. 25 controllers and counting. And then you throw in that they like to build a full offseason robot after the season, just kind of testing new tricks, and still show up with primary and practice to offseasons. 10 more controllers, so 35. I'm sure I can come up with a good reason for another 5. And I'm not on the team.

See, that wasn't so hard--40 speed controllers, including spares, covers one year for 'em. More, if they reuse the ones off the practice and offseason robots. And it's a lot easier to just cut one check for a bunch than to cut two for the same item several months apart, particularly if it's a "non-consumable" type of item.


*As in, so far so good, no mass complaining yet--but the suppliers' reputation is very good. OTOH, robotics teams are very creative in finding ways to fry speed controllers for some reason.

[Nemo]

If I didn't care how much I was spending but I wasn't completely oblivious to cost (only mostly oblivious), I'd probably order something like 48, because then I'd have 12 of each controller for a regular bot and practice robot, and I wouldn't have to decide which controller to use right now. I can understand the number 40 from a team that is well established and has the means to raise a reasonable amount of funding.

At this point I'm thinking 8-12 Talons for our team. Ideally I'd want 20-24 talons, but I think we will end up mixing and matching and building up our stock of these controllers over a period of about 3 years.

Even if we ended up strapped for cash and unable to buy a single new controller, I wouldn't feel too bad about life. We have enough to get us through next year, because prices on controllers have been good in the last two years, plus we have been able to get some donated controllers through the IFI voucher, AndyMark product donation voucher, and FIRST Choice. And best of all, Talons and Victors are reliable. The motor controller situation has been better than ever in 2013-2014; 2015 looks even better.

Note to IFI / CTRE: if you make a DC motor controller for FTC to compete with the overpriced / unreliable HiTechnic controllers, I promise to order a bunch of them. Seriously.

[PayneTrain]

Sonic, the drive in chain, advertises itself as the Ultimate Drink Stop (or at least they did), similar to VEXpro, the ultimate FRC gearbox stop. Sonic also is in the business of selling tots. People LOVE tater tots even though they're allegedly terrible for your long term health, but that's irrelevant. VEX has been in the business of selling motor controllers for what feels like as long as this year's group of incoming high school freshmen have been alive.

Sonic, while specializing in hundreds of thousands of possible combinations for drinks, may find it difficult to predict sales of some of the niche mixes. However, the tater tots are obvious, consistent, and easy to predict sellers because of a lack of outside competition (no other chain restaurant sells tots) and little to no change in the base product.

VEXpro, while making dozens and dozens of different ways to get FRC motors to work the way teams want them to through some sweet, high-performing gearboxes, may find it hard to predict sales for some of the niche mixes. However, the motor controllers are obvious, consistent, and easy to predict sellers because of a lack of outside competition and little to no change in the base product.

What I'm trying to say is that I'm in a Sonic drive thru right now before a robotics meeting.

[Monochron]

See, that wasn't so hard--40 speed controllers, including spares, covers one year for 'em. More, if they reuse the ones off the practice and offseason robots. And it's a lot easier to just cut one check for a bunch than to cut two for the same item several months apart, particularly if it's a "non-consumable" type of item.

I can certainly see why a team would use 40 controllers or more in a year. I still don't see the need to purchase all 40 at one time, when demand is at it's peak and supply is still an unknown.

To large teams' credit, I'm many of them would re-sell or donate spare controllers to in-need teams if there was a shortage, but I don't see the need to contribute to a potential shortage.

This is probably all useless conjecture, though. Like I said, I doubt there will be a shortage like there was with the Talons from CTRE. I'm just keeping the possibility in mind.

[Wingus&Dingus]

Note to IFI / CTRE: if you make a DC motor controller for FTC to compete with the overpriced / unreliable HiTechnic controllers, I promise to order a bunch of them. Seriously.

Way down under in New Zealand, where it costs even more to buy FTC stuff, we're working on this right now.

[RandomStyuff]

To all those talking about thermal paste, I'm not sure how exactly you intend on applying it. Contrary to the popular belief, thermal paste is a much less successful conductor of heat than Aluminium. The purpose of thermal paste in computers is because nothing is ever perfectly flat, and when you put an aluminium or copper heatsink on a processor, you get small airgaps between the heatsink and the processor. These airgaps are not very good at conducting heat (because air isn't very good at conducting heat), and therefore thermal paste is used to replace those gaps with a more conductive than air material.

Now, unless you plan on using a heatsink on your robot for your speed controllers, or plan on making your entire mounting surface a huge heatsink(which I don't think is a good idea if there is a heating issue, with wires and other things on it) I wouldn't recommend the use of thermal paste. Covering the speed controllers with thermal paste would actually reduce their heat dissipation abilities.

I seriously doubt that any usage within FIRST would require thermal paste. I might mount a large fan in a way that causes airflow in the areas where speed controllers are mounted, that would probably increase heat dissipation capabilities.


NOTE: I'm not an engineer with experience in heat management or anything like that, but one of the sponsors my team had when I was in high school made air conditioning units for aerospace purposes (cooling engines and things like that) - many of the mentors worked there and they liked to give us a little bit of a view into their work

[magnets]

To all those talking about thermal paste, I'm not sure how exactly you intend on applying it. Contrary to the popular belief, thermal paste is a much less successful conductor of heat than Aluminium. The purpose of thermal paste in computers is because nothing is ever perfectly flat, and when you put an aluminium or copper heatsink on a processor, you get small airgaps between the heatsink and the processor. These airgaps are not very good at conducting heat (because air isn't very good at conducting heat), and therefore thermal paste is used to replace those gaps with a more conductive than air material.

Now, unless you plan on using a heatsink on your robot for your speed controllers, or plan on making your entire mounting surface a huge heatsink(which I don't think is a good idea if there is a heating issue, with wires and other things on it) I wouldn't recommend the use of thermal paste. Covering the speed controllers with thermal paste would actually reduce their heat dissipation abilities.

I seriously doubt that any usage within FIRST would require thermal paste. I might mount a large fan in a way that causes airflow in the areas where speed controllers are mounted, that would probably increase heat dissipation capabilities.

I too am not too worried about heat, but if the Victors do end up with a lot of heat, thermal paste could be really useful. Your robot's big aluminum frame has a ton more heat capacity than the little aluminum casing. If the Victors heat up enough to get uncomfortably hot, you could dissipate all of that heat into the robot's frame without raising the frame's temperature by more than a few degrees.
For the purpose of a single speed controller, the robot's frame will be able to absorb most of heat the controller can generate about as fast as it can be generated. The air around the controller is much worse than the frame, and can't possibly keep up with the controller.

[FrankJ]

A bit of scarification. You don't cover your your speed controllers with thermal paste. You put a thin layer between the heat sink & the metal frame you are trying to transfer heat to.. If the internal design of the controller does not use the part of the controller that would attach to the frame as a heat sink then there is not much point in it. The current crop of controllers are a good example of that.

Sonic tater tots don't compare to the supply model of the new controller. If Sonic is out of tater tots, you can order french fries or onion rings. Sonic makes really good onion rings. You can also go to the grocery store & get your own. Or go down to Zestos.

[IndySam]

A bit of scarification. You don't cover your your speed controllers with thermal paste. You put a thin layer between the heat sink & the metal frame you are trying to transfer heat to.. If the internal design of the controller does not use the part of the controller that would attach to the frame as a heat sink then there is not much point in it. The current crop of controllers are a good example of that.

Sonic tater tots don't compare to the supply model of the new controller. If Sonic is out of tater tots, you can order french fries or onion rings. Sonic makes really good onion rings. You can also go to the grocery store & get your own. Or go down to Zestos.

What's a Zestos?

To interject into this heat discussion, we have run tallons for our drive speed controllers for two years without fans and have never had a problem. I think the whole paste thing is pretty moot.

[FrankJ]

What is Zestos? A local burger/soft serve ice cream joint. Great tater tots. Some things you can sole source. Tater tots isn't one of them.

[AdamHeard]

I feel like I have to ask, how much benefit are you going to see in a 3-4 month period by ordering 40 of these? Would it be any additional burden on your team to order maybe 15 or so for the season, and then order an additional 25 next summer?

While I think we are probably not going to see dire shortages, I don't really get the rationale of purchasing so many at a time. If this is something that a lot of financially able teams do, it may actually have a small effect on supply.

We are a small team and we don't work the crazy hours some of the top teams do. To keep programmers and practice/iteration going without conflict, we build two practice bots.

Also, we don't have a huge amount of funds compared to some top teams, this is a HUGE expense for us to upgrade speed controllers but we've weighed the benefits versus costs and are happy with the decision.

On average our robots have 9-13 speed controllers, so 40 is a good number.

I'm not at ALL concerned for a shortage. People are overreacting hugely over this. I've yet to see a well reasoned argument based on historical data as to why Vex will be unable to meet demand.

The talon launch argument is not relevant as that was (at the time) a BRAND NEW supplier. They had no way of predicting how many people would want as FRC is both a very risk avoidant community, and one that LOVES new toys.

Comparisons to mechanical product shortage are also not relevant.

When you then combine the company that released the talon with the company that has been the primary supplier for 10+ seasons (who has NEVER ran out during season) you have a recipe for success, and happy customers.

Separate from all this, I'm sure Vex is concerned with maintaining their reputation. They essentially just removed the entire backup plan (Jaguar, Talon, Victor), so all the eggs are in the new basket. I'm sure they're very well aware of the consequences of failing to deliver here. Any resources put towards more production of a guaranteed obsolete product (Jaguar, Talon, Victor) would be silly as well, as that just takes away from production of the new.

[Qbot2640]

So...is Thermal Paste a suitable condiment for Tater Tots, or would it just serve to scald the roof of my mouth more quickly on contact?

[FrankJ]

I would recommend ketchup for tater tots. As previously stated thermal paste would stick to the roof of your mouth.

[Lil' Lavery]

I would recommend ketchup for tater tots. As previously stated thermal paste would stick to the roof of your mouth.

How well does peanut butter transmit heat?

[cgmv123]

How well does peanut butter transmit heat?

~0.168 W/(m·K) (Page 15 (http://pcfarina.eng.unipr.it/Public/Termofluidodinamica/Utility/Tabelle%20Alimenti.pdf))

[FrankJ]

~0.168 W/(m·K) (Page 15 (http://pcfarina.eng.unipr.it/Public/Termofluidodinamica/Utility/Tabelle%20Alimenti.pdf))

So you have 20 metric tons of peanut butter on a train leaving Chicago heading east at 50 mph...

[Lil' Lavery]

~0.168 W/(m·K) (Page 15 (http://pcfarina.eng.unipr.it/Public/Termofluidodinamica/Utility/Tabelle%20Alimenti.pdf))

That's actually peanut oil. While several other peanut products are listed, I couldn't find peanut butter. I guess I'll have to select another substance to transmit heat from my speed controllers on my edible robot. :(

[Alan Anderson]

So you have 20 metric tons of peanut butter on a train leaving Chicago heading east at 50 mph...

...and it quickly runs out of track as it reaches the shore of Lake Michigan. Pick a different direction.

[Jared Russell]

...and it quickly runs out of track as it reaches the shore of Lake Michigan. Pick a different direction.

> go north

It is pitch dark. You are likely to be eaten by a grue.

Crap.

[Andrew Schreiber]

> go north



Crap.

> Use Peanut Butter on grue


On a topic I don't think has been covered. How's firmware updating on the new Talon done? Is it simpler that the Jags? And how's the error recovery for if we lose power or connection mid flash?

I assume upgrading firmware isn't really an issue for the Victor?

[Jefferson]

>


On a topic I don't think has been covered. How's firmware updating on the new Talon done? Is it simpler that the Jags? And how's the error recovery for if we lose power or connection mid flash?

I assume upgrading firmware isn't really an issue for the Victor?

I assume the firmware on the Talon will be updated similar to the PCM and PDP, through the roboRIO webdash. It's straightforward and painless.
I don't know about error recovery during flash, but I'm sure Omar will take care of us.

[Kevin Sevcik]

> Use Peanut Butter on grue As the grue's favorite diet is adventurers, it presumably ignores the peanut butter. You hear horrible gurgling noises from the darkness.

On a topic I don't think has been covered. How's firmware updating on the new Talon done? Is it simpler that the Jags? And how's the error recovery for if we lose power or connection mid flash?

I assume upgrading firmware isn't really an issue for the Victor? They list several communication channels in addition to CAN. I'd assume serial is likely to be a flashing option as well. If they can get a stable bootloader that they won't be upgrading in the flashes, they could presumably use that as a fallback option. I'm guessing it's going to be even harder to get to a JTAG port inside a sealed speed controller, though it'd be nice if they released a JTAG flashable image invade someone tried.

[aldaeron]

Great thread with lots of good info!

There is one question I was hoping would show up but hasn't - will there be an option to pre-order the controllers soon?

The features and prices seem set. I know there will be last minute tweaks based on beta testing. I know they can't provide an exact ship date yet. I am reassured that there will be enough parts.

It is easier with for the folks that handle the paperwork for our school district to be able to pre-order. There are already opportunities to pre-order the rest of the new components. A nice side benefit is that I don't have to keep checking VEX to see when the controllers actually go on sale - I can pay for them now and they will ship when they're ready (As Ron Popeil would say - "set it and forget it").

Thanks!

-matto-

[FrankJ]

I have not seen that the motor controllers are available for per-order. They are on the VEXpro site as coming soon.

[aldaeron]

The controller is available for pre-order through AndyMark:
http://www.andymark.com/product-p/am-3000.htm

Eric

I meant the motor controllers. I already have that on order =)

[ebmonon36]

I meant the motor controllers. I already have that on order =)

Oops, just realized this was the motor controller thread and not the beta test thread. I had opened both threads...

[mrnoble]

Anyone heard anything new about availability? The only source I've seen that says there will be plenty to go around is this thread. What reliable source has said that there will be Victor SP's and Talon SRX's available in quantity in time for kickoff? The most I've been able to do so far is create a wishlist on VexPro.

[Jon Stratis]

Anyone heard anything new about availability? The only source I've seen that says there will be plenty to go around is this thread. What reliable source has said that there will be Victor SP's and Talon SRX's available in quantity in time for kickoff? The most I've been able to do so far is create a wishlist on VexPro.

Read the posts by Paul, like this one: http://www.chiefdelphi.com/forums/showpost.php?p=1398426&postcount=185

I think he probably has some solid information at his fingertips about availability of the components, and I would consider him a reliable source, given his role in one of the companies involved.

[mrnoble]

Thanks Jon. I was really just wondering if there had been any updates. I guess there haven't, but thanks just the same.

[Sparky3D]

Have any of the beta test teams gotten any of the new Talon SRX's yet, or have line of sight as to when they will get them? It looks like several teams have the new Victors in the beta systems, but I haven't seen anything on the Talon's. It's getting to be a bit late in the year to get them tested and FIRST approved.

[Alan Anderson]

Have any of the beta test teams gotten any of the new Talon SRX's yet?

Yes, Talon SRX speed controllers are in the hands of Beta Test teams. More information will have to wait.

[Jon Stratis]

Have any of the beta test teams gotten any of the new Talon SRX's yet, or have line of sight as to when they will get them? It looks like several teams have the new Victors in the beta systems, but I haven't seen anything on the Talon's. It's getting to be a bit late in the year to get them tested and FIRST approved.

Ours arrived on Friday, and should make it into the robot this week.

[marshall]

Ours arrived on Friday, and should make it into the robot this week.

We got ours installed on Saturday but unfortunately we are waiting on the next release of the LabView software on Tuesday before we can program them.

[Greg McKaskle]

I saw one drive a motor on Friday afternoon.

Greg McKaskle

[Ideal_Nerd]

Just got word from vex saying that the new talons will not be available to order till late December.

[Joe Ross]

And how's the error recovery for if we lose power or connection mid flash?

Can't speak for the Talon SRX, but I just played around with error recovery for the PCM. I pulled PCM power towards the beginning of the flash, towards the middle of the flash, and towards the end of the flash. In all cases I was able to recover.

[Andrew Schreiber]

Can't speak for the Talon SRX, but I just played around with error recovery for the PCM. I pulled PCM power towards the beginning of the flash, towards the middle of the flash, and towards the end of the flash. In all cases I was able to recover.

Sweet. That was one of my big concerns when flashing CAN Jags.

[mman1506]

Do the new talons communicate with CAN over the PWM cable? If so that's awesome.

[NotInControl]

Do the new talons communicate with CAN over the PWM cable? If so that's awesome.

Yes but its the other way around (I.e The new Talon SRX will run PWM over the CAN wires).

The new Talon will auto detect whether you are connect to a can bus or a pwm source.

On FRC you only need two wires for PWMs (signal and ground) to an FRC legal motor controller because all FRC motor controllors ignore the center power pin (these are only used for servos)

You can wire the 2 CAN wires on the Talon SRX to PWM signal and ground and it will auto detect PWM.

CAN_H = PWM Signal
CAN_L = PWM Ground

The Victor SP (which has a 3-pin PWM) can only be used in PWM mode, no CAN available

Hope this helps,
Kevin

[mman1506]

Yes but its the other way around (I.e The new Talon SRX will run PWM over the CAN wires).

The new Talon will auto detect whether you are connect to a can bus or a pwm source.

On FRC you only need two wires for PWMs (signal and ground) to an FRC legal motor controller because all FRC motor controllors ignore the center power pin (these are only used for servos)

You can wire the 2 CAN wires on the Talon SRX to PWM signal and ground and it will auto detect PWM.

CAN_H = PWM Signal
CAN_L = PWM Ground

The Victor SP (which has a 3-pin PWM) can only be used in PWM mode, no CAN available

Hope this helps,
Kevin

Thanks, can you change PID values and configuration over CAN without a separate utility?

[Ether]

The body is made of aluminum, and it is isolated from the electronics inside. If you're concerned about cooling, rub some thermal paste on it and bolt it to an aluminum plate.





Or don't risk violating the rule against modifying electronics and add a fan instead.


What rule did you have in mind, that prohibits mounting a motor controller using the provided mounting holes?

The thermal paste could be omitted, if that is the concern.





Yes, that would be the concern.

Just so everyone is aware, now that the 2015 rules are released:

R55 G (http://www.chiefdelphi.com/forums/attachment.php?attachmentid=17860&stc=1&d=1421424394)

[AdamHeard]

I think it's fair to point out that we are nearing the end of build season, and presumably most teams have got their big orders in...

Vex is still in stock.
WCProducts is still in stock.
Andymark is still in stock.
RobotSpace is still in stock (For Victors, Talons are out. Based on everyone else having stock, I'm sure they will get replenished soon.)

So................. They handled it awesome in my opinion.