+1
The positraction helps drive straighter during auton and doesn’t have a noticeable advantage in tele or pushing matches. Tires come off the ground in pushing matches especially from uneven bumpers. Even during hard acceleration, the front tires come out of current limit which means they’re spinning.
I totally understand how the phenomena you are describing works, and it is absolutely a legitimate concern - I am saying the magnitude of the effect of increased loading due to having to skid steer constantly is going to be worse than this uneven loading in many cases. High CG, offset CG, etc will make the swerve effect way worse, of course.
Is it though?
It would be easy for a swerve with no software protection to get into a state where it fully stalls a wheel or two at 12V (and then sag some) and is unable to slip traction.
Do that for 10 seconds in a match and you’re going to heat the motor quite a bit more than the additional load from turning in place with a skid steer.
Separately an unoptimized swerve will have wheels trying to drive with appreciable voltage while they still have steering error. This can lead to lots of heat very quick.
Teams have solved this by steering faster and/or shaping the drive motor output with something like cos(steering error) or cos(steering error)^2 and other similar looking functions.
Like all engineering there are many solutions that will work for you and it’s more about execution. I understand where you’re coming from on that design philosophy especially if you’ve been burned. I think there are several things teams can do to make the 775 more robust in these applications that may still be lighter than switching to a miniCIM. If you have a solution that works no reason to change, but just some thoughts for the future / others reading this thread.[/quote]
So, I went back and re-read my post and I feel that I may have come across overly critical of the 775s. That was not my intent. Last night, my team pointed out that I had neglected to talk about several applications that we would definitely select the 775s as the preferred motor such as shooters.
My post also generated a decent discussion among our team members (which is great) about what we know and what we don’t know about how to utilize these motors with minimal risk of failure. I am very grateful for threads like this where teams share their experiences and we all learn a few more things that can help us get better at picking the correct engineering solution.
I agree with you that each application requires a level of detailed engineering evaluation to pick the right solution and there is no “one size fits all” here. (My team also reminded me about all the benefits of the 775s in terms of small size, weight and other factors that we consider when making our design choices).
With proper current protection in the talon this is doable, but I somewhat agree with you here.
Stalling arms / wrists doesn’t seem like the right control solution for most motors. Use a limit switch or two? BAGs are really good here though.[/quote]
Our gear intake in 2017 was a motor driven arm (I can’t remember which motor we used, but I don’t think it was a 775). The motor was sitting at stall most of the time when the intake was up. Most of the time it was only up for short periods of time. The only time any smoke came out was on the practice field where we left the robot initialized for several minutes with the intake in the up position (while we were designing a new auto routine and forgot to turn the robot off). So, it can be done. With the increased knowledge we have now about stalling these motors, I’m confident we could implement this design in a more motor-friendly way if we had to do it again.
This really depends on the weight of your lift and the friction in it. We only ran 1 775pro on our lift with no brake, it wasn’t the fastest lift in FRC, but we stalled it constantly at very low voltage to hold position and never had issues. It’s helpful to check current draw in the logs and see what it takes to hold your motor in place. If you aren’t satisfied with that current draw then gear down, add a motor, or add a brake.[/quote]
Seems like gearing down the lift to make it even slower would be a hard trade-off to justify versus switching to a miniCIM. Cycle time is a premium and unless we were really weight critical, I would be picking faster speed over lighter weight. Adding a motor is an option, if you catch it early enough in the design cycle to re-design the gearbox. Adding a brake sounds heavier than switching to a miniCIM.
But as I said above, every application needs to be thought through carefully.
Strongly disagree. 775s are the ideal motor for hanging because they’re high power, low weight, and in this application they don’t need to run long. You don’t need a ratchet, just need enough friction in the system that it doesn’t want to back drive when brake mode is on. We used ball screws this year and lead screws in 2016 for this. You can also put a brake on it.[/quote]
They may not need to run long (we typically try to climb in a few seconds), but they can potentially need to “hold” the hang for several seconds. Recall that the testing results that started this thread showed smoke after only a few seconds. If you start your climb too early and you need to hold for 15 or 20 seconds, you might smoke the motor. The brake mode on the controller worked great this year and now that we know how to use that, I think we might have more success with 775s holding a hang.
But, as it was, in order to get the climbing speed we wanted this year, and in order to lift 500 lbs (3 robots plus margin) we needed the power of 3 CIMs which allowed us to use a COTS, 3 CIM Ball Shifter. I’ve not done the math with 775s, but I expect we would have needed a bunch more motors and we may have exceeded our motor limit and also required a non-COTS gearbox (which we could have done, but elected to spend our resources elsewhere).
So again, it is about evaluating the design requirements, doing the math and figuring out the best solution for each application.
Anyway, apologies if it seemed I was ruling out 775s carte blanche. That is not how I feel about it (and after the discussion last night, clearly not how my team feels about it either).
I am looking forward to using 775s in the future and looking forward to applying all the knowledge that people are sharing here to reduce and hopefully eliminate all the drama from 2017.
One problem I’ve noticed over both the 2017 and 2018 seasons is the difference between each individual 775 motor, as mentioned earlier in this thread. In 2018 we used a 2x 775 gearbox at about 45:1 for our scale bot’s elevator; at one point early in the season we accidentally ran the motors against each other, but the elevator still operated slowly, as one motor out-performed the other. The kicker? Both motors came from the same Vex order…
Designing can be irksome with these differences, although after we corrected the motor directions and added a cots cooling fan it was mostly smooth sailing. We frequently stalled the motors without current limiting for 10 to 20 seconds with no magic smoke and no noticeable performance degradation. (During one match we tipped over, and the 775s were stalled for 40 seconds before smoking, although those particular two were quite dead after about 55).
I realize none of this is very specific or scientific in method, but it’s what I’ve observed - an additional cooling fan, when properly positioned to pull through the motor, has a big effect for preserving the life of the 775s
To add just a bit of humor to this serious discussion, designing with a 775 is a love-hate relationship…
I missed this comment earlier and while I understand that you do not hate 775 pros I feel the need to clarify this as I believe the “775 Pros are bad at stall” is a generalization.
775 Pros are great at stall! You can stall them all day if you want. A stalled 775 pro will last for minutes putting out the same amount of torque that would kill a stalled BAG motor in seconds. However the 775 Pro cannot break the laws of physics. The 775 pro has roughly twice the amount of power to weight as a BAG motor so you cannot stall it at full volts for any appreciable amount of time. You pretty much should always be implementing current limiting in any application where the motor will be stalled.
While it’s totally reasonable to use a motor other than the 775 pro because you may not have the resources to implement more advanced control solutions it’s just simply not true that the 775 pro is bad at stalling.
If you want anecdotal evidence our wrist and arm were both powered by one 775-pro each. This was without counterbalance and liberal gearing. No issues once we had current limiting correctly implemented. They were stalled for the majority of the match. They barely got warm. A bag motor in the same applications would of failed. We would of had to significantly increase gearing and slow down the arm.
Your take is right on, but this take is also pretty misleading. Pretty much any FRC motor is “great at stall” at a particular holding voltage and gear. You can stall RS550s at 2V if you want. I think it’s really, really important you include this clarification in this post because some kid is just going to read “775s are great at stall! better than bags!” and get the wrong idea.
The Vex motor site is a great resource for determining a ballpark maximum safe voltage (or current, if you wanna get fancy) to stall these motors at. If you design your geartrain so that the motor stalling at a safe voltage can hold up whatever you need to hold up, you’re unlikely to run into problems, whether it’s a 775 or a BAG or anything.
Current limiting to protect stalling motors is great, but I mean, most times where you intentionally stall one of these motors is when you’re using feed-forward offsets to hold a mechanism in position - and that’s where stalling at a design voltage comes in. That’s all current limiting is doing anyway, just in a fancier way.
You finally made us do it. You made us blow up another 775 pro. You maniacs!
We repeated our 775 pro stall testing last night with a new motor. This time we stepped up current limiting in increments of 2A, and held the motor stalled for 60s while recording voltage and current through the Talon. We then performed a reverse-dyno health check after each test (that test acted to cool the motor between tests too). The results were consistent with last week, but they make me a little more confident we can design/program a more aggressive 775 pro drive gearbox. In short:
Surprisingly we could not see any signal in the logged current and voltage data from the Talon during the 11-23A stall tests. We had hoped that there’d be a noticeable change in voltage (for a fixed current) when the motor started to fail. If it’s there it’s hidden in the noise: The motor voltage (measured by the Talon) oscillated +/- 0.5 to 0.7V (2sigma, 95%) during the stall tests, but the average only rose about 0.3 to 0.4V for every 2A increase in current limit (into the Talon), so there was some overlap between tests.
[edit] - for reference, and to compare with the motors.vex.com curves: at 9A, the peak motor voltage was about 3.9V during the test (3.2V average), and at 11A the peak motor voltage was about 4.3V (3.6V average).
Conclusions:
This is only a single motor test, so don’t take my word for it, but it looks like we’d have to set the current limit to ~9A (~3.5V, ~100W, ~6% of the rated 12V stall current) if we wanted to stall a 775pro/Redline for up to 60 seconds with no damage.
While the measured voltage and current signals during stall didn’t show any signal, our “Reverse Dyno” health seems to strongly differentiate healthy motors and partially damaged motors. We’ll keep developing it as a diagnostic tool.
I’ll post the raw data to a CD paper sometime in the next few days if I can grab some time.
We were discussing last night, and we’d really like to make a feature request to CTRE, either by adding a new function to the Talon, or modify the existing current limiting function:
Low Speed Current Limit: Switch to a lower current limit X, after Y seconds below Z counts/sec velocity measured by the encoder.
They already have a two step current limit don’t they?
Limit of X for Y time, then folds to Z?
Wouldn’t be crazy to implement what you’re saying on the rio side as well.
How frequently did you record the current values and voltages during the stall tests? Did you make any current measurements with external instruments? It seems reasonable that you should see the current start to rise as the motor starts to fail. Are you doing a locked-rotor test where the rotor is not allowed to turn at all? If the motor is not turning, there should not be any noise from the commutator indicating that the noise is coming from the switching action of the Talon itself.
Have you had a chance to dissect a damaged motor yet?
+1 This would be a great safety feature.
It is also very easy to implement with the options they’ve already given use. He even wrote the psuedocode for it 
roughly 10 Hz. I’ll post the raw data when I have a chance to tidy up the presentation.
Did you make any current measurements with external instruments?
Not this time - most of our instruments had been sent with the toolbox to Robots@CNE
It seems reasonable that you should see the current start to rise as the motor starts to fail. Are you doing a locked-rotor test where the rotor is not allowed to turn at all? If the motor is not turning, there should not be any noise from the commutator indicating that the noise is coming from the switching action of the Talon itself.
We were doing a locked rotor stall test. I was surprised we didn’t see a rise in current (or, being current limited, a drop in voltage) as the motor started to fail, but there was a lot of noise in the data. I agree that this is likely the work of the Talon’s PID (we could hear and feel the torque vibrating during the test).
Have you had a chance to dissect a damaged motor yet?
Not yet. It was late 
Counterpoint, why should this be a Talon feature? With the >1sec response time, it seems like the Rio could be a fine home for this type of function? Using PDB & encoder could make it independent of speed controller architecture too.
My understanding of the standard function CTRE has implemented is that if current exceeds X amps for Y ms then it clamps to Z limit.
So if your trigger X is 30A for time Y 5 ms, you could still peak past 70 or 100A for those 5ms before clamping to limit Z 25A.
Sure, we could do it on the Rio easy enough (as easy as running another thread is anyway). But only the Talon SRX offers closed-loop current limiting, and the Talon also can read the encoder, so it seems like a natural fit that would open up the option to more teams with less programming skill.
[edit] - at stall current limiting and voltage limiting do kinda the same thing, so I suppose you could do a low speed “cut to 3V” thing on the Rio with other motor controllers.
How was the motor voltage measured? Voltmeter, Talon?
Talon in yesterday’s test
You also have access to the PDP current sensing channels. Not sure what the sample rate is, but it’s something.
