SD540 Motor Controller

[mindsensors.com]

The SD540 Motor Controller is now shipping! A seemingly weightless, low cost solution with great functionality is now here and ready to order.

We had great feedback at the recent FRC workshop in Richmond, VA. Many local teams got a chance to experience using the SD540 Motor Controller first hand and witness its amazing control.

Product page (http://www.mindsensors.com/frc/135-motor-controller-for-frc)

Specs (http://www.mindsensors.com/content/71-frc-motor-controller)

Performance Testing (http://www.mindsensors.com/content/73-sd540-performance-characteristics)

[AllenGregoryIV]

Do you have a CAD model of the controllers? I looked around the website but didn't find them, I'd like to add them to our CAD library.

Why are the dip switches on the bottom of the unit, seems like it would make it difficult to adjust once they are on the robot.

[Electronica1]

Do you have a CAD model of the controllers? I looked around the website but didn't find them, I'd like to add them to our CAD library.

Go to the product page, and click on the download tab on the left hand side of the page.

[techhelpbb]

My 2 seem fine, thanks!

[AllenGregoryIV]

Go to the product page, and click on the download tab on the left hand side of the page.

Thanks, I thought I looked there but I guess I missed it.

[mindsensors.com]

See how the SD540 Motor Controller compares with the other FRC controllers available:
http://mindsensors.com/img/cms/SD540/ChiefDelphi/SD540_ComparisonChart.png

The majority of the information on this chart has been taken from the comparison chart form REV Robotics.
See their chart here:
http://www.revrobotics.com/wp-content/uploads/2015/10/Spark_comparison-Chart-e1446132225162.jpg

Similar charts can also be found in Talon SRX, Victor SP, Victor 888, Talon SR, and Jaguar documentation.

[Electronica1]

Quick question, does having a higher output frequency cause any sort of performance difference?

[AllenGregoryIV]

Not to be a buzz kill but did you guys just copy the data complied by REV for the Spark? Even the disclaimer is the same.

[asid61]

I would compare this to the Spark or Victor SP. In terms of weight it beats both, is only $5 more expensive than the Spark, has a limit switch input, and has a thinner form factor than the Spark (although not as flat as the others). The output frequency is also higher, although I'm not sure what effect that has.
The banking option looks handy to slightly lower the cost and use less mounting hardware.
Looks pretty neat, overall! We would buy them if not for the twenty Talons we already own. :P

[pnitin]

Higher switching frequency will make thing more efficient, and power delivery will be continues rather than discrete. In other words better linearity and smooth operation.

[GeeTwo]

What does "multi-bank" mean? I see nothing on the web pages that gives me even a hint of a clue. The price sounds pretty good, but perhaps if I understood what "multi-bank" means it would actually be worth buying.

[marshall]

I'd like to know how the upgradable firmware works. Can you shed any light on that?

[Mark McLeod]

What does "multi-bank" mean?

Packaged as single, dual, or quad
Examples:
http://www.mindsensors.com/frc/139-motor-controller-for-frc-bank-of-4
http://www.mindsensors.com/frc/138-motor-controller-for-frc-bank-of-2

[Sohaib]

What does "multi-bank" mean? I see nothing on the web pages that gives me even a hint of a clue. The price sounds pretty good, but perhaps if I understood what "multi-bank" means it would actually be worth buying.

If you scroll down the the bottom of the webpage, you'll see there's a "pod" of 4 motor controllers referred to as the "Quad-Bank Model" and a subsequent Dual Bank Model. It's essentially a block of motor controllers.

[Electronica1]

At the workshop they said you could replace one of the controllers on the bank without having to replace the entire bank. Not entirely sure how that works in relation with the rules though.

[BBray_T1296]

For the 7 people who say they "do not like this product" could I ask why? Seems like a perfectly competitive option. What is there to not like?

[Joe Ross]

Have you tested the higher switching frequency for interactions with the locking pins in the window motors?

[wilsonmw04]

For the 7 people who say they "do not like this product" could I ask why? Seems like a perfectly competitive option. What is there to not like?

It could be that it's new. It might also be kids who have no idea what they are talking about. I really think it's the fact that some folks just like to be snarky when a poll is anonymous.

[Scott Kozutsky]

I like both the sd540 and spark for the same reason-cost. The Spark currently wins this albeit only slightly. The size difference isn't enough for me to really care and the low weight scares me for use with higher power motors (whether that fear is justified has yet to be seen-if it doesn't matter then it's definitely a nice boon).

Of those two my favorite is the one that's more reliable, available and has better customer support.

[wmarshall11]

For the 7 people who say they "do not like this product" could I ask why? Seems like a perfectly competitive option. What is there to not like?

It could be that it's new. It might also be kids who have no idea what they are talking about. I really think it's the fact that some folks just like to be snarky when a poll is anonymous.

There's also no "I'm ambivalent about these features" option. "I do not like it, Sam-I-Am" becomes the default option, since the others are super positive about the product.

From my chair, none of the features of the SD540 stand above my primary criteria for selection of a speed-controller, which is "Reliable, as verified by real FRC teams using real hardware on a real robot".

Not to imply that the product isn't reliable, just that being burned to the tune of a set of speed controllers during build/competition season is enough disincentive to keep me preferring more tried-and-true offerings.

[DaveL]

I like the idea that the output has a higher signal frequency. Plus if it is more efficient at transferring power, it won't get as hot. Time will tell if these differences are significant.

Big plus in either case is now we have smaller, lighter and more chip resistant motor controllers! This is a big change from just a few years ago.

Dave

[topgun]

I haven't seen anything that states whether or not it is FRC legal for 2016. If it isn't, then why are we wasting time on it?

[notmattlythgoe]

I haven't seen anything that states whether or not it is FRC legal for 2016. If it isn't, then why are we wasting time on it?

http://www.chiefdelphi.com/forums/showpost.php?p=1502188&postcount=1

Cough cough.

[marshall]

I haven't seen anything that states whether or not it is FRC legal for 2016. If it isn't, then why are we wasting time on it?

http://archive.usfirst.org/roboticsprograms/frc/blog-2016-motor-controllers

…we’ve also approved the following devices:

SD540 Motor Controller (Part #: SD540x1)

So yeah, it's legal.

[mindsensors.com]

I'd like to know how the upgradable firmware works. Can you shed any light on that?

Since this controller is currently only a PWM device, we will release a device to perform the firmware upgrade. All you have to do is connect it and change it to bootloader mode with the dip switches. More information will be available once the device it released.

[mindsensors.com]

Not to be a buzz kill but did you guys just copy the data complied by REV for the Spark? Even the disclaimer is the same.

Credit has now been given below the chart.

[mindsensors.com]

I like both the sd540 and spark for the same reason-cost. The Spark currently wins this albeit only slightly. The size difference isn't enough for me to really care and the low weight scares me for use with higher power motors (whether that fear is justified has yet to be seen-if it doesn't matter then it's definitely a nice boon).

Of those two my favorite is the one that's more reliable, available and has better customer support.

What motor rating are you worried about?

[marshall]

Since this controller is currently only a PWM device

Emphasis added... are there plans to enable other communication methods line CAN? Possibilities or plans to interface this with encoders in the future?

[AdamHeard]

What motor rating are you worried about?

I think you'll find the rating most teams will care about is, "has been run by many other teams on many different robots without failure".

for 90% of FRC teams, all the other specs are meaningless. They just want something to make the motor spin without failure.

[Scott Kozutsky]

What motor rating are you worried about?

I was just worried about overheating problems in heavy duty applications like drivetrain. At around 60% the weight of other controllers there is substantially less thermal mass. I'm worried about it but it may be a non issue (especially if it's more efficient). I'll wait for teams to use them before I make final judgement.

Within reason, cost and reliability > all other factors for a speed controller IMHO.

[mindsensors.com]

Emphasis added... are there plans to enable other communication methods line CAN? Possibilities or plans to interface this with encoders in the future?

We are planning on implementing CAN on future models. Possibly as a single board swap out kit. The firmware upgrader will actually use I2C that is already implemented for bootloading the device.

[mindsensors.com]

I was just worried about overheating problems in heavy duty applications like drivetrain. At around 60% the weight of other controllers there is substantially less thermal mass. I'm worried about it but it may be a non issue (especially if it's more efficient). I'll wait for teams to use them before I make final judgement.

Within reason, cost and reliability > all other factors for a speed controller IMHO.

Have you seen the results of our performance tests? Check it out at the link below.

http://www.mindsensors.com/content/73-sd540-performance-characteristics

[asid61]

Have you seen the results of our performance tests? Check it out at the link below.

http://www.mindsensors.com/content/73-sd540-performance-characteristics

It seems to be getting quite hot; I'm not sure I would consider these for my drivetrain.

[AdamHeard]

Have you seen the results of our performance tests? Check it out at the link below.

http://www.mindsensors.com/content/73-sd540-performance-characteristics

This graph doesn't mean anything to most teams.

They need to see it run by a bunch of teams in a bunch of different applications w/o failure before they believe in it.

[MrBasse]

It seems to be getting quite hot; I'm not sure I would consider these for my drivetrain.

Those results show a 50 amp load with the motor mechanically stalled. Even then, after two minutes the controller is under 100 degrees Celsius.

If you typically stall your motors for 5 minutes at 50 amps, then temperature might be of concern.

[asid61]

Those results show a 50 amp load with the motor mechanically stalled. Even then, after two minutes the controller is under 100 degrees Celsius.

If you typically stall your motors for 5 minutes at 50 amps, then temperature might be of concern.
The stalling doesn't matter as much as the current; IIRC the heat generated is proportional to current.
I would be worried about getting a burn or burning something at that temperature. Plus, CIMs often run at high currents for the duration of the match; it's certainly possible to average 40-50 amps for a match.

[GeeTwo]

There's definitely inertia in teams adopting any new item, whether part of the control system, an actuator, or a mechanical system. Our overwhelmingly positive experiences with the Talon SR and Spike (and negative experiences with Victors and even worse with Jaguars) led us to use these two motor controllers/switches exclusively last year. This year, especially as the Talon SR has been discontinued, we do plan some experimentation with the Talon SRX, and some of the new less expensive motor controllers (SPARK and SD540). Over the years as an occasional purchaser for the government, I've learned to take vendors' tests with a big grain of salt. It's rather harsh to say this, but one failure under conditions where we cannot produce calculations that would lead us to expect failure or which may be beyond our reasonable control can put a motor controller on our black list, along with the Jags and Victors. At this point, we keep Vics and Jags around just to give the freshmen a sense of how much things have improved even in recent years; we haven't put either on so much as an off-season project in over two years.

In the interest of total disclosure, I am personally quite harsh on vendors who seriously disappoint me. For example, I haven't had a McDonalds hamburger since my sophomore year in high school (can't you dress a hamburger without including that awful special sauce?), and I haven't bought anything but a few batteries and tires (and those under otherwise desperate situations) from Wal-Mart in over ten years. The traffic from selling groceries drove me 90+% away circa 2003; the way they abandoned New Orleans after Katrina in contradiction of all of their advertising about helping communities after disasters sealed the deal.

[Sperkowsky]

This is competing with the spark but, the spark has the advantage of being from a more experienced company, and looking pretty. It looks decent and we will buy one to test but for us staying with talon SRX'es and Sparks or Victor Sp's for this year make sense.

Next year we will see how people feel about these guys and it they work we will use them.

[cbale2000]

Honestly I don't have many feelings one way or another about this speed controller (our team uses CAN).
That said, a few things did stick out for me...


It requires me to have 6-32 screws, and have them at a specific length to mount to anything (Imo, through holes are better, and allow you to avoid hunting for "that one screw").
The signal input connector seems like an odd choice, and it looks like the kind of thing that PWM cables could fall out of easily, and then, due to lack of labeling, get reconnected incorrectly.
If you have a bank of controllers, and one of them dies, do you have to replace the whole bank?
Would be nice if brake/coast could be changed on the fly (we used to do this with victors by connecting a PWM cable where the jumper would go).


Might get one of these to play around with it, but generally we avoid new, un-FRC-proven components the first year they're out (unless there are no alternatives like in 2014).

[mindsensors.com]

Honestly I don't have many feelings one way or another about this speed controller (our team uses CAN).
That said, a few things did stick out for me...


It requires me to have 6-32 screws, and have them at a specific length to mount to anything (Imo, through holes are better, and allow you to avoid hunting for "that one screw").
The signal input connector seems like an odd choice, and it looks like the kind of thing that PWM cables could fall out of easily, and then, due to lack of labeling, get reconnected incorrectly.
If you have a bank of controllers, and one of them dies, do you have to replace the whole bank?
Would be nice if brake/coast could be changed on the fly (we used to do this with victors by connecting a PWM cable where the jumper would go).


Might get one of these to play around with it, but generally we avoid new, un-FRC-proven components the first year they're out (unless there are no alternatives like in 2014).

To answer your questions:
The mounting screws are included when you purchase the SD540. Also, our case is 3D printed so there are multiple options in the works that do not call for a complete redesign. We plan to release casing options with different mounting options and through holes.

The connector is not only for PWM. Currently it allows for firmware updates, and in the future CAN, encoder connection, and possible I2C. Labels are on the bottom.

If a unit dies on one of the multi-bank options, you only need to replace that unit. A kit will be offered for just such a situation.

Brake/coast can be changed on the fly. There is a dip switch on the bottom that just needs to be flipped. You can also change direction.

[philso]

oops. double post.

[philso]

Have you seen the results of our performance tests? Check it out at the link below.

http://www.mindsensors.com/content/73-sd540-performance-characteristics

It would be best if Mindsensors can present time/temperature charts that show the temperature stabilizing. It would be even better if you can present such charts with different (continuous) loads (10%, 20%, 40%, 60%, 80%, 100%). In FRC, it is rare that a motor controller would be run for the duration of the match at the same current level but these extra load lines can give the users some indication of what kinds of temperatures they can expect by estimating their average current over a short time period. The time/temperature charts will also give some indication of what the short term thermal capacity of the motor controller is; i.e. it may withstand an 80A load for 1 second better than it can withstand a 50A load for 2 minutes or longer). Your chart ends at just past 4 1/2 minutes which is much longer than a standard FRC match. In practice sessions, we have often run our robots continuously for much longer than 4 1/2 minutes, often repeating the most stressful actions. Considering how quickly the temperature is still rising at 270 seconds, I would be concerned that the transistors hit thermal-runaway and self destruct.

It is also of concern to me that your time/temperature chart is reaching almost 100 degrees at 150 seconds and about 125 degrees at 270 seconds, with your initial temperature of 25 degrees. It appears from your photo that these temperatures are measured on the top of the heatsink. If this is true, your transistor junction temperatures (taking into account the thermal impedance through the base plate of the your heatsink and the junction-to-case thermal impedance) will be much higher, possibly leaving you with very little (or no) margin from the maximum operating temperature of your transistors, depending on your device type. These high junction temperatures will lead to reduced life of the transistors. Have you done extended life testing on your motor controllers? Batch-to-batch variations in the transistor characteristics can have a large effect on your temperature performance so a test result showing little or no thermal margin raises red flags in my mind.

Lastly, the high heatsink temperatures are a concern, as Asid has also pointed out. Various safety standards specify different "maximum touch temperatures" but they will all be well below 100 degrees C (UL/IEC 60950-1 specifies a maximum of 75 C). With the thermal mass of your heatsink, temperatures at 100 degrees and above will most likely cause serious burns to anyone touching the heatsink. America has far too many lawyers. Some of them have children on FRC teams. I would not want to see Mindsensors dragged into court and many students be deprived of a great resource.

I am sorry if I am being hard on Mindsensors. They have a pretty good history in educational and hobby robotics where the power levels are low (NXT/EV3, Raspberry Pi, Arduino) and the energy sources have limited capacity (AA's or equivalent). They have now entered an arena where the energy levels are much higher and the hazards and consequences are much more serious. My comments and warnings are based on my experience developing power electronics products for mass production over the last 20+ years.


The stalling doesn't matter as much as the current; IIRC the heat generated is proportional to current.
I would be worried about getting a burn or burning something at that temperature. Plus, CIMs often run at high currents for the duration of the match; it's certainly possible to average 40-50 amps for a match.

The heat generated has two components; the switching loss in the output transistors and the conduction loss of the output transistors. The switching loss is roughly proportional to the switching frequency (output frequency) of the controller. The conduction loss is calculated by multiplying the on-resistance of the output MOSFET (at the instantaneous operating current) with the square of the instantaneous output current (P = R x I^2).

I have not seen actual efficiency numbers for any of the motor controllers currently in use or for the new ones from Rev and Mindsensors so it is not clear how people in this thread are saying that the new controllers are more efficient.

[philso]

The signal input connector seems like an odd choice, and it looks like the kind of thing that PWM cables could fall out of easily, and then, due to lack of labeling, get reconnected incorrectly.



Is there a polarizing feature on this connector? Connectors of this type, with 16 pins generally don't fall out on their own but changing to one with latches would give added security.

How many mating cycles is the connector rated for? It looks like a tin plated type in the photo. One major manufacturer of such connectors, Tyco Electronics, considers 50 cycles a "large number" for their tin plated connectors. This means they will not guarantee "stable electrical contact" after 50 mating cycles.

http://www.te.com/documentation/whitepapers/pdf/sncomrep.pdf

[aldaeron]

This product looks like something that was developed by someone with limited FRC experience. The features being touted as benefits are actually detractors in my mind:

- Lightweight (The difference is negligible in my mind. If we get to the point where we need to save a fraction of a pound, we get out the big drill or hole saw. I also question what was skimped to get the weight loss.)
- Low Cost (REV Spark is $5 cheaper and has fewer issues that I can see. Honestly this controller would have to be under $40 for me to consider buying over the REV.)
- Multi Bank Option (Sure we need a bank of controllers for the drive train, but sometimes they need to be placed creatively to get the rest of the bot to work. I can mount them touching each other just fine by myself without the need for the bank. Also there is no air gap between controllers. I like a small air gap, especially if these are the drive train motors that will producing a good deal of heat.)

Things I like:

1) Well labeled (colored) inputs and outputs

2) Robust screw terminals for a ring type connector or bare wire

Things I dislike:

1) Single 16 pin male connector with no cable retention. It is very easy to plug the PWM into the limit switch pins or vice versa. Do I use a standard PWM connector (3x1) and two 2 pin limit switches connectors? Or do I make my own 16 pin custom connectors? How do these stay in during the season (please no more hot glue)? How do I keep the exposed male pins safe (especially from student hands when they are rooting around in the belly pan)? Also I am not sure why connectors are mounted parallel to the mounting face instead on normal to it (this will increase the part footprint quite a bit when it is used).

2) Brake/Coast & Cal under the mounting face. To me this is inexcusable. If I want to change/control the mode or re-cal a controller I have to demount these (by unscrewing them from the bottom - see #3)?! Why not use the spare 8 pins on the connector for these features?

3) Lack of thru hole mounting. I can't zip tie these down to something temporarily. Grrrrr.

4) Heatsinking. The test data shows a test at 50A continuous and does not reach steady state in the data provided. Not sure why you used 50A and not 60A (since the specs say 60A continuous). We want a controller we can practice with for long sessions, not just one FRC match. Based on your test data it looks like you will hit a steady state temp of 140-150C on the heatsink, curious what junction temp you will hit on active devices. If you are relying on a thermal pad or thermal grease to keep your ICs cool, what happens over a period of time as these degrade? We want to keep these controllers for a few years! Your test needs to be repeated many times at different loading profiles to convince me you have a proper passive thermal cooling design (and at 60A continuous like the spec sheet says). If you can truly run the controller at 60A continuous (and are not just copying the IC's specs) then show multiple 15-20 minute tests of a single controller at 60A.

5) 3D printed case. Other plastic manufacturing methods would make more consistent parts for cheaper and with better properties (at the right manufacturing quantities).

6) No CAN. I don't expect this in a low cost controller, but would love to have it.

As others have noted, these concerns lead me to believe there will be reliability problems when using this controller during FRC season. It is a great prototype, but needs some major packaging rework.

-matto-

[philso]

- Multi Bank Option (Sure we need a bank of controllers for the drive train, but sometimes they need to be placed creatively to get the rest of the bot to work. I can mount them touching each other just fine by myself without the need for the bank. Also there is no air gap between controllers. I like a small air gap, especially if these are the drive train motors that will producing a good deal of heat.)

It would be good if Mindsensors could provide temperature test data covering the 2-bank and 4-bank configurations with all inverters in the bank loaded the same way. Because the individual inverters are right next to each other and the heatsinks rely on convection cooling, the heat coming off one heatsink WILL cause the temperature on the adjacent heat sinks to be higher than if there were "ample space" around individual heatsinks. A simple test of this would be to monitor the heatsink temperature of all 4 heatsinks of a 4-bank controller where only one of the middle ones is loaded and the other 3 are not loaded. The two heatsinks on either side of the loaded inverter will be hotter than ambient.

Temperature test data with the controllers mounted in different orientations would also be helpful to the potential users.



2) Robust screw terminals for a ring type connector or bare wire

Solid wire would be acceptable under the screw head but no one should be using solid wire on a robot. Stranded wire would be risky since it could slip out. Mindsensors can add a clamp plate under the screw head for just pennies to make this safe with bare, stranded wire.




1) Single 16 pin male connector with no cable retention. It is very easy to plug the PWM into the limit switch pins or vice versa. Do I use a standard PWM connector (3x1) and two 2 pin limit switches connectors? Or do I make my own 16 pin custom connectors? How do these stay in during the season (please no more hot glue)? How do I keep the exposed male pins safe (especially from student hands when they are rooting around in the belly pan)? Also I am not sure why connectors are mounted parallel to the mounting face instead on normal to it (this will increase the part footprint quite a bit when it is used).

2) Brake/Coast & Cal under the mounting face. To me this is inexcusable. If I want to change/control the mode or re-cal a controller I have to demount these (by unscrewing them from the bottom - see #3)?! Why not use the spare 8 pins on the connector for these features?

Locating the 16-pin connector and the Brake/Coast & Cal DIP switch to the top surface would increase the footprint of the product. While they are at it, they may as well move the LED's to the top surface so they would not be obscured by the wiring.


3) Lack of thru hole mounting. I can't zip tie these down to something temporarily. Grrrrr.

The blind, threaded mounting holes on the bottom may be a very bad idea. What happens when a screw that is too long is screwed in till it bottoms out and is continued to be driven in? Will it damage the circuit board? Will it cause a short circuit and possibly a fire? Will it push the heatsink off the top?

Making it mandatory to have access to the back side of the mounting surface severely restricts where these can be mounted and remain serviceable. The mounting holes will have to be drilled pretty accurately or nothing will line up. The low-resource teams who are likely to be attracted to this controller will likely find it hard to do this. Mounting ears that one can match-drill from the front side would have been much better.


5) 3D printed case. Other plastic manufacturing methods would make more consistent parts for cheaper and with better properties (at the right manufacturing quantities).

If this product does gain wide acceptance, will Mindsensors be able to manufacture them fast enough? The build period for FRC is very short and not receiving their motor controllers in a timely manner would be (near) fatal for any team.


Mindsensors may want to consider dropping the switching frequency to half of what they are using now. It would cut the switching losses in the transistors in half and should reduce the heatsink temperatures very significantly. It is not clear what benefit the 32kHz switching frequency gives. It may also be beneficial to attach a fan like those used to cool the CPU's in a desktop computer. A modest amount of air flow will increase the heat removal capacity of the heatsink by several times.

As it is, the high heatsink temperatures would make me question the service life of the product. Any electrolytic capacitors used in the controller would live a very short life since they are typically rated for operation in an 85 degrees C environment with some available that are rated for 105 (but they are more expensive and probably physically larger). Mindsensors may also want to check the temperature rating of the plastic they are using for the casing since many are only rated for around 90 degrees C.

[cbale2000]

...Brake/coast can be changed on the fly. There is a dip switch on the bottom that just needs to be flipped. You can also change direction.

I was more referring to changing the Brake/Coast state while the robot is in operation using a signal input.

Is there a polarizing feature on this connector? Connectors of this type, with 16 pins generally don't fall out on their own but changing to one with latches would give added security...

Is there actually an associated connector that goes with the speed controller? Just looking at it, it looks like you're expected to just connect the 3-pin PWM and 2-pin limit switch cables directly into the port at their associated pins (like the front panel button/LED pinouts on a PC motherboard).

[philso]

Is there actually an associated connector that goes with the speed controller? Just looking at it, it looks like you're expected to just connect the 3-pin PWM and 2-pin limit switch cables directly into the port at their associated pins (like the front panel button/LED pinouts on a PC motherboard).

The 16-pin connector is normally used with something like the one in the link below.

https://wwws.samtec.com/technical-specifications/default.aspx?seriesMaster=HCSD


I looked more closely at the drawing showing the pinout of the connector.

http://www.mindsensors.com/content/71-frc-motor-controller

It does look like one would plug a standard 3-pin connector onto 3 of the 16 pins then plug a 2-pin connector onto 2 of the other pins for limit switches. This is a somewhat dangerous way to do it since if the PWM cable is plugged onto the wrong pins, either the motor controller, the robot controller or both may be damaged. Now I know what aldaeron was referring to when he wrote "It is very easy to plug the PWM into the limit switch pins or vice versa."

[GeeTwo]

It does look like one would plug a standard 3-pin connector onto 3 of the 16 pins then plug a 2-pin connector onto 2 of the other pins for limit switches. This is a somewhat dangerous way to do it..

I agree. If we get these, we shall also get a bunch of 2x8 housings and clearly label one long edge with red and the other with green (or something similar) to clearly communicate "this side up" to the wiring team. We might even notch it some way and put our own tabs in place to prevent an incorrect insertion.

[philso]

I agree. If we get these, we shall also get a bunch of 2x8 housings and clearly label one long edge with red and the other with green (or something similar) to clearly communicate "this side up" to the wiring team. We might even notch it some way and put our own tabs in place to prevent an incorrect insertion.

You could also get some 1 x 4 and 1 x 5 housings, insert some female pins and plug them onto the unused pins to block them off. This would allow you to use the standard 1 x 3 and 1 x 2 connectors that you are probably already using. Hansen Hobbies has the needed parts.

[mindsensors.com]

Check out this video of the SD540 in action (https://youtu.be/x8IP1fQpnFk)!!

[AdamHeard]

Check out this video of the SD540 in action (https://youtu.be/x8IP1fQpnFk)!!

Now do the same thing on a 2014 style 6 CIM traction 6 wheel drive that belongs to another team so they can independently beat them up.

[JesseK]

Now do the same thing on a 2014 style 6 CIM traction 6 wheel drive that belongs to another team so they can independently beat them up.

Presuming 6 CIMs are legal in the drive train this year :rolleyes:

::ducks and covers::

[Scott Kozutsky]

Check out this video of the SD540 in action (https://youtu.be/x8IP1fQpnFk)!!

I want to see it on a 2 (1 per side) CIM pushybot with good traction being abused for 3+ minutes with a temperature measurement at the end. I think that's about as "worst case scenario" you can reasonably get for that speed controller.

[cbale2000]

It does look like one would plug a standard 3-pin connector onto 3 of the 16 pins then plug a 2-pin connector onto 2 of the other pins for limit switches. This is a somewhat dangerous way to do it since if the PWM cable is plugged onto the wrong pins, either the motor controller, the robot controller or both may be damaged. Now I know what aldaeron was referring to when he wrote "It is very easy to plug the PWM into the limit switch pins or vice versa."

That's my point though, the average team that uses PWMs is not going to go out and buy a bunch of these 16 pin connectors (which also adds to the cost of each controller), strip apart the ribbon cables, and splice each one with a 3-pin and 2 2-pin PWM cables, they're going to just plug a standard PWM cable into it, which seems like a terrible idea with this connector.

Check out this video of the SD540 in action (https://youtu.be/x8IP1fQpnFk)!!

What's with that shaking/noise in the bot at the beginning of the video? It goes away at about the 14 second mark, and then comes back again at ~24 seconds.

[Ari423]

What's with that terrible shaking/noise in the bot at the beginning of the video? It goes away at about the 14 second mark, and then comes back again at ~24 seconds.

I would like to hope any terrible rattling you hear is a mechanical problem with their test bot. Though it wouldn't speak well to their quality of building robots (and therefore robot parts), I don't think it should affect your opinion on the motor controller itself. Although, we did have one Jaguar that squeaked at us......

[mindsensors.com]

What's with that terrible shaking/noise in the bot at the beginning of the video? It goes away at about the 14 second mark, and then comes back again at ~24 seconds.

The test program switches the direction at full speed every 200ms for a given amount of times, then runs for a few seconds and switches direction at full speed again..

This tests the responsiveness of the controller as well as the peak currents on the floating motors. This test was run for 15 minutes without failure.

[philso]

That's my point though, the average team that uses PWMs is not going to go out and buy a bunch of these 16 pin connectors (which also adds to the cost of each controller), strip apart the ribbon cables, and splice each one with a 3-pin and 2 2-pin PWM cables, they're going to just plug a standard PWM cable into it, which seems like a terrible idea with this connector.

Those connectors can be purchased for under $2 each but it would be another part to buy and keep in stock. They take some finesse and knowledge to assemble correctly. It can be pretty easy to short out adjacent wires or get the ribbon cable swapped like the ones for the DIO's a couple of years ago. As the person responsible for teaching the electrical skills on our team, I would not want to have to teach yet another fiddly skill and to have to do QC on it.

Plugging a PWM cable into the 16-pin connector can be dangerous because there is nothing on the case of the controller indicating which pin the Pin 1 of the cable should plug onto. One would have to refer to drawings or manuals which are not always available. It would be best if the cable connection had some sore of key to prevent a reverse connection or at least the product is self-documenting in a way that is clearly visible. The connector being on the side makes it very difficult to use any sort of alignment marks that may be on the enclosure.


The test program switches the direction at full speed every 200ms for a given amount of times, then runs for a few seconds and switches direction at full speed again..

This tests the responsiveness of the controller as well as the peak currents on the floating motors. This test was run for 15 minutes without failure.

There have to be some objective test criteria for any test to be meaningful. What were the heat sink temperatures at the end of the 15 minutes? What were the peak and average currents during this test? Do the currents approach the maximum rated current (or current limit level, if there is such a feature)? What happens if the motors are run at "full power" for 1 or 2 seconds at a time for the full 15 minutes. The momentum of the robot will really come into play making it a more realistic test. How many drivers can switch directions 5 times in one second?

If the temperatures get as high as your published data shows, the service life of some of the parts in your product will drop from years to months or even weeks, most likely leading to failure of the controller. In our practice sessions our drivers will run until the batteries are noticeably weak (typically half an hour, depending on the total number of motors) then they will do a quick swap of the battery (1-2 minutes) and start practicing again. Some of the motors/controllers could be running at full load, essentially continuously, for a couple of hours at a time. I would not doubt that many other teams practice in the same way. Time is precious in this competition. No one can afford to wait for parts to cool down before continuing to practice.

[Matt_Boehm_329]

Can they be purchased without the 3d printed parts in a sort of "Kit"?

[techhelpbb]

I want to see it on a 2 (1 per side) CIM pushybot with good traction being abused for 3+ minutes with a temperature measurement at the end. I think that's about as "worst case scenario" you can reasonably get for that speed controller.

Do you have a particular drive train like that in mind?
If you do I have 2 of these speed controls and a lot of spare parts.
Depending on what you have in mind I may have everything required.

[Akash Rastogi]

How many FRC teams have these been beta tested with?

Agreeing with Adam...that's usually what most of us care about.

What is your current inventory like? Supply limitations are usually a big turn-off.

[Scott Kozutsky]

Do you have a particular drive train like that in mind?
If you do I have 2 of these speed controls and a lot of spare parts.
Depending on what you have in mind I may have everything required.

full FRC weight (154lbs with bumpers and battery) plaction (or similar) wheels at around 10fps. That's about the worse I've seen at a competition. A test both with and without fans would also be interesting if you don't mind.

[philso]

Do you have a particular drive train like that in mind?
If you do I have 2 of these speed controls and a lot of spare parts.
Depending on what you have in mind I may have everything required.

full FRC weight (154lbs with bumpers and battery) placation (or similar) wheels at around 10fps. That's about the worse I've seen at a competition. A test both with and without fans would also be interesting if you don't mind.

That sounds more realistic.

Do you have a way to monitor or measure the temperature of the heatsinks?

[wilsonmw04]

That sounds more realistic.

Do you have a way to monitor or measure the temperature of the heatsinks?

Do you have a protocol for this?

[techhelpbb]

full FRC weight (154lbs with bumpers and battery) plaction (or similar) wheels at around 10fps. That's about the worse I've seen at a competition. A test both with and without fans would also be interesting if you don't mind.

Does it really matter if it has bumpers if it is the proper weight?

I have 4", 6" and 8" AndyMark plaction wheels: I assume 4"?
I'll likely stick with the keyed shafts as I only have a limited amount of hex shaft and bearings.
What distance between the wheels (frame dimension)?
What configuration of the wheels: center drop with 6 wheels all driven with chain?

Fans are no problem I have fans and a CFM meter somewhere.

I have a lot of ways I can measure and log temperature.
What sort of resolution are you after?

Anyone care if a cRIO is used as the control system for this test?
I'll use the FRC approved master breaker and the FRC PDB that came with the cRIO if I do that.

[AllenGregoryIV]

Does it really matter if it has bumpers if it is the proper weight?


He was just saying that 154lbs is the actual max FRC Robot weight. Some people might think they should test at 120lbs since that is the weight limit but they would be forgetting the 34lbs from bumpers and battery.

[techhelpbb]

He was just saying that 154lbs is the actual max FRC Robot weight. Some people might think they should test at 120lbs since that is the weight limit but they would be forgetting the 34lbs from bumpers and battery.

I've got plenty of exercise weights I can toss on there.

[philso]

Do you have a protocol for this?

Most safety standards state that parts that can be touched (i.e. the heatsink) should remain below 65 to 75 degrees C. With approximately a 25 degree C ambient temperature, those numbers will also leave plenty of thermal margin for most electronic parts such that their lifetime is acceptable (in the range of years).

One would want to see the temperature stabilize for some reasonable period of time. Considering the small thermal mass of the heatsink on this controller, a 2-3 degree range over 5 minutes seems reasonable. It certainly should not still be showing an upward trend as in the data published by Mindsensors. In our lab at work, we stop the tests after there is less than 1 degree C of variation over an hour but that is not realistic here with a robot that is constantly in motion and a load that is not held constant.

[James Kuszmaul]

Is there any data on all this floating around somewhere for existing motor controllers? Obviously, we know that the existing victors and talons work fine, but it would be interesting to see the data from the new controllers compared to an existing one rather than seeing numbers thrown out without any intuitive scale.

[techhelpbb]

full FRC weight (154lbs with bumpers and battery) plaction (or similar) wheels at around 10fps. That's about the worse I've seen at a competition. A test both with and without fans would also be interesting if you don't mind.

Single stage and single CIM AndyMark Stackerbox with a 3.57:1 ratio feeding a 12 tooth double sprocket which is #35 chain driving a 26 tooth sprocket on the AndyMark 4" plaction tires. Arranged as a 6 wheel center drop with the gear box on one end and the other end driving 1:1 off the center axle. Sounds like that's just over 10.1fps to me but I am pretty tired right now.

That meet your expectations?

I've got the double sprockets and the #35 chain with link kits.
I've got 10 single stage Stackerboxes.
I -may- have some 26 tooth sprockets on some used tires if not I'll need to order those.
I've got some sprocket spacers for the AndyMark tires.

[Scott Kozutsky]

Single stage and single CIM AndyMark Stackerbox with a 3.57:1 ratio feeding a 12 tooth double sprocket which is #35 chain driving a 26 tooth sprocket on the AndyMark 4" plaction tires. Arranged as a 6 wheel center drop with the gear box on one end and the other end driving 1:1 off the center axle. Sounds like that's just over 10.1fps to me but I am pretty tired right now.

That meet your expectations?

I've got the double sprockets and the #35 chain with link kits.
I've got 10 single stage Stackerboxes.
I -may- have some 26 tooth sprockets on some used tires if not I'll need to order those.
I've got some sprocket spacers for the AndyMark tires.

If you really want to go overboard on these controllers go 4 wheel, your choice. Otherwise looks absolutely fine to me. Realistically there will be more variance in "aggressive" driving than from any individual design choice.

[techhelpbb]

If you really want to go overboard on these controllers go 4 wheel, your choice. Otherwise looks absolutely fine to me. Realistically there will be more variance in "aggressive" driving than from any individual design choice.

To be clear, since I described one side of a potential drive train, when you proposed going even further with 4 wheel you would end up with a robot with 8 wheels total. 4 on the floor at any one time and 2 elevated at each end.

I agree that the driving style is very important and I only have 3 pairs of 4" AndyMark plaction tires, 12 bearings of the 20 I have on hand, and need to order sprockets because I only have 4x 24 tooth sprockets on my 8" used mechanum wheels.

So there's going to be a short blocking delay while I wait for the few little parts I need to do this with just 6 4" wheels total. I am not entirely blocked because I can still start putting things together.

Frame dimensions or wheel spacing?

[Scott Kozutsky]

To be clear, since I described one side of a potential drive train, when you proposed going even further with 4 wheel you would end up with a robot with 8 wheels total. 4 on the floor at any one time and 2 elevated at each end.

I agree that the driving style is very important and I only have 3 pairs of 4" AndyMark plaction tires, 12 bearings of the 20 I have on hand, and need to order sprockets because I only have 4x 24 tooth sprockets on my 8" used mechanum wheels.

So there's going to be a short blocking delay while I wait for the few little parts I need to do this with just 6 4" wheels total. I am not entirely blocked because I can still start putting things together.

Frame dimensions or wheel spacing?

I meant 4wd total (2 per side-more turning scrub=more motor work). Honestly the number of wheels isn't that important. Just use whatever you have on hand.

[techhelpbb]

I meant 4wd total (2 per side-more turning scrub=more motor work). Honestly the number of wheels isn't that important. Just use whatever you have on hand.

I will emulate an AndyMark wheel spacing and frame. Thinking about ways to rig the frame so it can drive on 4 or 6.

Aside from that: 8 wheel with 4 down has as much scrub as 4 wheels plus additional chains and losses but I agree it is just a bit more than necessary to test this.

[techhelpbb]

Consecutive posts because of the time between them:

Orders for the few missing pieces have been placed.
I will start some assembly this weekend.

[talon540]

In Talon 540's workshop, we shot a short video of our robot running with SD540's, which you can view here: http://youtu.be/9lq6U3EpyTg

There are a total of six SD540 motor controllers on this robot: four for the mecanum wheels, one for the lift, and one for the pneumatic pump.


They worked like a charm! Our team highly suggests you switch to SD540's for the 2016 season competition and onward! The manufacturer, mindsensors, has their main web page at: http://www.mindsensors.com/

[techhelpbb]

In Talon 540's workshop, we shot a short video of our robot running with SD540's, which you can view here: http://youtu.be/9lq6U3EpyTg

There are a total of six SD540 motor controllers on this robot: four for the mecanum wheels, one for the lift, and one for the pneumatic pump.


They worked like a charm! Our team highly suggests you switch to SD540's for the 2016 season competition and onward! The manufacturer, mindsensors, has their main web page at: http://www.mindsensors.com/

Since you have these on a robot already.
Also since I will be travelling to Toronto next week till the weekend.
Additionally I will be judging NJ FLL this weekend.

Would you mind measuring the heat sink temperature during operation if you can find the necessary tools?

I'll keep working on slapping my parts together as I need to do that anyway for something else.
So far I've welded up dead axles and wired up a control system.

[philso]

Since you have these on a robot already.
Also since I will be travelling to Toronto next week till the weekend.
Additionally I will be judging NJ FLL this weekend.

Would you mind measuring the heat sink temperature during operation if you can find the necessary tools?

I'll keep working on slapping my parts together as I need to do that anyway for something else.
So far I've welded up dead axles and wired up a control system.

It would be good to monitor the (average) motor currents at the same time.

[techhelpbb]

It would be good to monitor the (average) motor currents at the same time.

While I do have the RoboRIO PDP laying around I don't have a RoboRio yet to connect to it. I haven't tried to do CAN with the PDP to the cRIO 4 slot or 8 slot that I do currently have and have been assembling.

So when I get this assembled I'll have to do that some other way unless the RoboRIO arrives by the time I get that far.

It looks vaguely like that Talon540 robot had a RoboRIO on it. So perhaps they could grab that data.

[Cory]

They worked like a charm! Our team highly suggests you switch to SD540's for the 2016 season competition and onward! The manufacturer, mindsensors, has their main web page at: http://www.mindsensors.com/

Just out of curiosity, are you affiliated with mindsensors.com in any way?

If you are affiliated with mindsensors, it seems slightly disingenuous to refer to yourself/your team as a third party without a stake in the game. This is especially true when it comes to endorsement of a new product that serves a critical role and has no competition heritage.

I am in no way accusing you of not doing due diligence or appropriate testing, or questioning your results, but I think it's important for teams to know whether testimony they are basing their purchasing decisions on is coming from an end user or essentially from the inventor(s)/vendor.

[AllenGregoryIV]

Just out of curiosity, are you affiliated with mindsensors.com in any way?

If you are affiliated with mindsensors, it seems slightly disingenuous to refer to yourself/your team as a third party without a stake in the game. This is especially true when it comes to endorsement of a new product that serves a critical role and has no competition heritage.

I am in no way accusing you of not doing due diligence or appropriate testing, or questioning your results, but I think it's important for teams to know whether testimony they are basing their purchasing decisions on is coming from an end user or essentially from the inventor(s)/vendor.

This controller is designed jointly with Team 540 students and manufactured in Richmond, VA with the help of local FIRST students. Source: http://www.mindsensors.com/frc/135-motor-controller-for-frc

Their team helped to design them and from that seems like they help build them as well.

[techhelpbb]

Just out of curiosity, are you affiliated with mindsensors.com in any way?

If you are affiliated with mindsensors, it seems slightly disingenuous to refer to yourself/your team as a third party without a stake in the game. This is especially true when it comes to endorsement of a new product that serves a critical role and has no competition heritage.

I am in no way accusing you of not doing due diligence or appropriate testing, or questioning your results, but I think it's important for teams to know whether testimony they are basing their purchasing decisions on is coming from an end user or essentially from the inventor(s)/vendor.

Just to share - I have nothing to do with MindSensors or their team.
I merely like the idea of competition for the pricing of FRC motor controls.
It's easy to go back through my post history to show that I have built other controls in the past and expressed public interest in the matter on this forum.

To be fair I also bought 2 Sparks as well.
This is not a Team 11 thing either.
It's just little old me being curious.
I have my own parts to build FRC robots so I don't have to impact Team 11 or 193 operations to do this.
I also have my own machine tools.

At the moment I am planning on doing the temperature and current measurements with an Arduino based data logger but I have more development boards than I care to discuss so I could do this with something more powerful. I will likely use a Dallas 18B20 for the temperature measurement with it installed in a steel cartridge in direct contact with the ESC heatsink and a either a TI or Maxim chip for the current measurement using a current sense resistor of a value I will disclose. It's likely the current sense resistor will be less than 1mOhm right now. I need to disclose that because it has a slight impact on the motor circuit.

[philso]

Just to share - I have nothing to do with MindSensors or their team.
I merely like the idea of competition for the pricing of FRC motor controls.
It's easy to go back through my post history to show that I have built other controls in the past and expressed public interest in the matter on this forum.

To be fair I also bought 2 Sparks as well.
This is not a Team 11 thing either.
It's just little old me being curious.
I have my own parts to build FRC robots so I don't have to impact Team 11 or 193 operations to do this.
I also have my own machine tools.

At the moment I am planning on doing the temperature and current measurements with an Arduino based data logger but I have more development boards than I care to discuss so I could do this with something more powerful. I will likely use a Dallas 18B20 for the temperature measurement with it installed in a steel cartridge in direct contact with the ESC heatsink and a either a TI or Maxim chip for the current measurement using a current sense resistor of a value I will disclose. It's likely the current sense resistor will be less than 1mOhm right now. I need to disclose that because it has a slight impact on the motor circuit.

Is it too much to ask if one of the Talon SRX's or Victor SP's to act as a point of reference?

As long as the temperature data is measured at the same output current, the value of the current sense resistor does not matter. The losses in the controller are related to the characteristics of the switch devices used (MOSFETS?), how they are driven by the circuitry in the controller, the switching frequency and the output current. As a user, one would only have control over the output current.

[techhelpbb]

Is it too much to ask if one of the Talon SRX's or Victor SP's to act as a point of reference?

As long as the temperature data is measured at the same output current, the value of the current sense resistor does not matter. The losses in the controller are related to the characteristics of the switch devices used (MOSFETS?), how they are driven by the circuitry in the controller, the switching frequency and the output current. As a user, one would only have control over the output current.

I don't have either to use as a reference currently.
AndyMark is sold out of the Victor SP.
I can get it here:
http://www.robotmarketplace.com/products/IFI-VICTORSP.html

At some point I have to point out that the more parts I have to accumulate on short notice the higher the unplanned cost to me of this exercise. I don't really need these chassis until well after build season outside of this. However I will entertain this because I probably will buy at least 2 of the Victor SP sooner or later. I do have the older gray Jaguar, black Jaguar, Victor 888 , Victor 884 and Talon SR (not the SRX).

Here are the constraints of doing this with a proper Arduino and the hardware I have planned:

1. The DS18B20 has variable bit resolution measurement. The more resolution the longer the readings take. I intend to run it at the fastest of 9bit resolution at 0.5C resolution. This means I need to wait likely more than 75ms to get a temperature from it. After issuing the request it can be configured to be non-blocking so I can go off and do other things then check back for the reading.

2. I will likely use either the A/D of the Arduino which for the Mega2560 is 16 channel analog muxed 10bit or something like the MCP3008/MCP3208 like that found on the Propeller ASC+ from Parallax. With the current sense resistors as I plan them this should give me something around a 0.1A resolution for the current. I would figure these are not super high-end A/D so some error is to be expected but most of the error I hope will cancel by being consistent across all measurements. The current sense resistors are high enough wattage that a complete stall shouldn't cause them to fail but likely will rail the current reading. I am going to assume we won't be trying to run the motors consistently at 95A or more.

3. The AdaFruit Data Logging shield provides a DS1307 RTC and access to SD card storage. I can also go down the route of this: https://www.parallax.com/product/27937

Since the current PDP model can only report current as fast as 25ms over the CAN bus connection to the RoboRIO, the only part of this I think is a bit slow is the DS18B20. No matter how fast my CPU/MCU that 75ms is pretty slow but thermally the heatsink mass is not so small that I think we need to be all that fast reading temperature.

4. My initial thought is to store the 2 temperatures and the 2 currents packed.
9 bits (temp) + 9 bits (temp) + 10 bits (current) + 10 bits (current) = 38 bits
Stored as 4 bytes and some bytes for any time stamps.
A trivial amount of code can unpack that and dump it into Excel.

[wilsonmw04]

Let's say someone wanted to test these new controllers. I have access to something that will read the temp. My question is how do I get the current readings off the PDB through the CAN bus? is it as simple as accessing the web based monitor?

[techhelpbb]

Let's say someone wanted to test these new controllers. I have access to something that will read the temp. My question is how do I get the current readings off the PDB through the CAN bus? is it as simple as accessing the web based monitor?

Can you read the heatsink temperature(s) with the RoboRIO with whatever you have (does it have an analog, I2C, SPI output)? If you can you should be able to get the current and the temperature together and log or display it with some coding.

If I had the RoboRIO laying around on a robot with the necessary accessory this would be a fine way to do it.

In Java:
http://wpilib.screenstepslive.com/s/4485/m/13809/l/219414-power-distribution-panel

In C++:
http://wpilib.screenstepslive.com/s/4485/m/13810/l/219414-power-distribution-panel

In LabView (see GetPDPCurrents):
http://www.fightingpi.org/Resources/Controls/Beta/2015_Beta/LabVIEW.shtml

For the cRIO in general there's some information on National's site about using the DS18B20.
For I2C temperature measurement one might use this: https://www.sparkfun.com/products/11931
Never tested any of this temperature reading stuff on the RoboRIO.

This will help with writing the data you collect out:
http://www.chiefdelphi.com/forums/showthread.php?p=1437880

If you do manage to test this please do post the results because the scope of work for me to do: it seems to be growing :).

[philso]

I don't have either to use as a reference currently.
...

I do have the older gray Jaguar, black Jaguar, Victor 888 , Victor 884 and Talon SR (not the SRX).


A Talon SR would be a good reference too.

[techhelpbb]

A Talon SR would be a good reference too.

LOL if you had written that about an hour ago ;)
2 Victor SP are on the way to me.

[philso]

LOL if you had written that about an hour ago ;)
2 Victor SP are on the way to me.

With all the facilities and parts you have mentioned in your previous posts, I go a serious case of "shop envy". It is now a bit worse :o

[techhelpbb]

With all the facilities and parts you have mentioned in your previous posts, I go a serious case of "shop envy". It is now a bit worse :o

At the rate of accumulation I have 8 Lowes 12 gallon plastic totes filled to the very top in storage. It got to the point I couldn't remember my inventory so I have an inventory spreadsheet. It's not quite as expensive as one might imagine: as I have been accumulating parts for years and only accelerated in recent months. I cleaned out quite a few MicroCenters nationwide after giving everyone several months and a ChiefDelphi thread to beat me to it. MicroCenter discounted most of the AndyMark parts down to 75% off. I routinely hit AndyMark's Tuesday deals. I'm also often the reason a few of you aren't winning your eBay auctions the last few months ;) and at least in a recent case that means I sponsored a team or so indirectly.

It's not just for me, at least I hope not, I am working towards setting up a MakerSpace with FRC resources available. Hence my growing portable MaxNC toolset with the T2 lathe and 10 mill. I am also doing modifications and repairs on them such that if someone breaks them I can fix them cheap and easy.

This is why I was going to build some robots anyway. I will be using smaller final robot dimensions when I get there. I want mine to fit in the largest TSA approved hardshell suit cases so I can take the robots and my portable CNC tools safely more places. This is more an educational exercise out of my pocket than a competitive exercise. It's just not practical for the most dedicated students to learn CNC and programming in 6-10 weeks and the high cost of CNC entry is daunting just to get to a point you realize you don't know G-Code from Rhino VBA ;). (For anyone that points out the MaxNC machines are glorified Sherline/Taig machines: cutting wax for someone that knows no better is just as good on 1/3HP as it is on 10HP. Sure the feeds change and that just goes to reinforce the critical nature of that change.)

If this doesn't work out I will have to open a new web based FRC retailer :D

[talon540]

If you are wondering how the SD540's heat up over time, mindsensors and Talon 540 performed a few tests on one of our old robots.

http://www.team540.com/sd540/

[techhelpbb]

If you are wondering how the SD540's heat up over time, mindsensors and Talon 540 performed a few tests on one of our old robots.

http://www.team540.com/sd540/

That's great! Can we get the drivetrain information that produced those temperatures? Wheels, ratios and motor configurations please. There seems to be a section of your website for it, but that information does not seem to be there.

[philso]

If you are wondering how the SD540's heat up over time, mindsensors and Talon 540 performed a few tests on one of our old robots.

http://www.team540.com/sd540/

Do you have any thing to show the test conditions such as ambient temperature, motor current. These have a significant effect on the measured value. Test results are meaningless without knowing the test conditions.

[talon540]

I just realized... I need more caffeine! Apologies for an earlier post, but our robot does NOT use an SD540 for our pneumatics. It was for our lift mechanism.

Man, that's embarrassing. I'll drink some Redbull and be quiet now.

[Chris is me]

Will a firmware upgrade be released to remove the "safety feature" that cuts motor output if the input voltage drops below 9.5 volts? The "feature" is a deal breaker for me, as that is a surprisingly easy condition to reach on an FRC robot.

Also, the spec sheet claims the speed controller operates at voltages as low as 6 volts, but this "safety feature" kicks in long before that, so the spec sheet is wrong.

[sastoller]

Since you guys seem to be SD540 experts in this thread, I was wondering if you could comment on the very high output resistance of the SD540 that was measured by CTR in their tests (surely you've seen the results). The voltage drop (power lost) in the motor controller is drastically worse than the competition? Did you guys make a design choice or tradeoff that resulted in this? Or is it possible that CTR just got a bad (or damaged) SD540?

And I'll also echo Chris's question regarding a FW update to modify the 9.5V brownout feature. Could you make this voltage threshold user adjustable in the future so that users could control which motor controllers shut off first? Would it be possible to add a throttling feature to reduce output to 50% when a certain voltage threshold is reached?

http://www.ctr-electronics.com/downloads/pdf/Motor-Controller-Power-Testing.pdf

[Andrew Schreiber]

Will a firmware upgrade be released to remove the "safety feature" that cuts motor output if the input voltage drops below 9.5 volts? The "feature" is a deal breaker for me, as that is a surprisingly easy condition to reach on an FRC robot.

Also, the spec sheet claims the speed controller operates at voltages as low as 6 volts, but this "safety feature" kicks in long before that, so the spec sheet is wrong.

And claiming it's a safety feature makes little sense to me. I can run Victors off a 2S Lipo (7.2-8.4V) and be fine. No safety issue, just the robot only operates at those voltages (say for smaller than FRC robots) but this "feature" makes SD540's worthless in these applications. Despite them appearing to be a better fit because of lower cost. (Performance isn't as critical in this application, cost is more a factor)

[pnitin]

Will a firmware upgrade be released to remove the "safety feature" that cuts motor output if the input voltage drops below 9.5 volts? The "feature" is a deal breaker for me, as that is a surprisingly easy condition to reach on an FRC robot.



If you are letting down your battery 9.5 V your are basically killing your battery( actually 10.8V that is 1.8V per cell).
Lead-Acid battery will quickly built lead sulfide layers on plates ( no matter what is battery technology and what manufacturer claims)
you are basically screwing up battery and now it will have much high internal resistance so the you will start seeing voltage drop when you try to take out good amount of current.

[notmattlythgoe]

If you are letting down your battery 9.5 V your are basically killing your battery( actually 10.8V that is 1.8V per cell).
Lead-Acid battery will quickly built lead sulfide layers on plates ( no matter what is battery technology and what manufacturer claims)
you are basically screwing up battery and now it will have much high internal resistance so the you will start seeing voltage drop when you try to take out good amount of current.

Don't think I've seen a robot get through a match without dipping that low in their battery voltage.

[Andrew Schreiber]

Don't think I've seen a robot get through a match without dipping that low in their battery voltage.

Pretty sure I've seen that on a non aggressively geared kitbot that only weighed 80 pounds... Unless the 9.5V limit only kicks in after a period of time in which case I'd like to see that in the documentation (and still complain because my use case for low cost controllers involves lower voltages anyway)

[notmattlythgoe]

Pretty sure I've seen that on a non aggressively geared kitbot that only weighed 80 pounds... Unless the 9.5V limit only kicks in after a period of time in which case I'd like to see that in the documentation (and still complain because my use case for low cost controllers involves lower voltages anyway)

I guess a robot that doesn't move would probably keep a pretty high voltage too.

[geezloueez]

Don't think I've seen a robot get through a match without dipping that low in their battery voltage.

I am a first year mentor for a rookie team. May seem like a dumb question, but I have not been involved first hand in a match yet. What is causing the batteries to drop so low? Are you using old batteries?

[notmattlythgoe]

I am a first year mentor for a rookie team. May seem like a dumb question, but I have not been involved first hand in a match yet. What is causing the batteries to drop so low? Are you using old batteries?

Running any number of motors at the same time. Compressors running a lot. Pushing matches with other robots. FRC robots can use a lot of power and usually do.

[geezloueez]

Running any number of motors at the same time. Compressors running a lot. Pushing matches with other robots. FRC robots can use a lot of power and usually do.

What is the lowest you have witnessed in a match?

[asid61]

If you are letting down your battery 9.5 V your are basically killing your battery( actually 10.8V that is 1.8V per cell).
Lead-Acid battery will quickly built lead sulfide layers on plates ( no matter what is battery technology and what manufacturer claims)
you are basically screwing up battery and now it will have much high internal resistance so the you will start seeing voltage drop when you try to take out good amount of current.

Hence why batteries in FRC have such a low lifetime... :P Interesting tidbit.
We don't use batteries from 2011 or earlier. And we're probably going to start phasing out the 2012 batteries too. They start being unable to hold a significant charge.

[Chris is me]

If you are letting down your battery 9.5 V your are basically killing your battery( actually 10.8V that is 1.8V per cell).
Lead-Acid battery will quickly built lead sulfide layers on plates ( no matter what is battery technology and what manufacturer claims)
you are basically screwing up battery and now it will have much high internal resistance so the you will start seeing voltage drop when you try to take out good amount of current.

Momentary drops to 9.5vs are not at all uncommon in FRC matches, depending on the number of motors on the machine, weight, traction, etc. It might not be great for batteries but I'd rather be able to drive for the rest of the match and potentially shorten a battery's life than not be able to drive to save a couple of bucks later on. Basically, I don't want the products I use to try and protect me from myself.

[marshall]

What is the lowest you have witnessed in a match?

I've seen my share of robots in brown out conditions. It's less severe these days than it used to be but it can still cause you some heartache at competitions. This is from one of the presentations on the control system last year:

http://i.imgur.com/rJcp9fg.png

And this is current (no pun intended) info about what happens and when:

http://wpilib.screenstepslive.com/s/4485/m/24166/l/289498-roborio-brownout-and-understanding-current-draw

EDIT: You can help prevent this by keeping happy batteries around and always keeping good ones in the robot.

[notmattlythgoe]

What is the lowest you have witnessed in a match?

A temporary drop to 8V is a pretty common occurrence. I don't know what the absolute lowest is though. Current draw is going to be a very important thing to watch in the coming years.

The compressor turning on can drop the voltage a good 1-1.5V itself.

Edit: See Marshall's post.

[Knufire]

Hence why batteries in FRC have such a low lifetime... :P Interesting tidbit.
We don't use batteries from 2011 or earlier. And we're probably going to start phasing out the 2012 batteries too. They start being unable to hold a significant charge.

We only use batteries in competition for a single year. After that they'll be used for practice for 2-4 years and then recycled.

[Andrew Schreiber]

What is the lowest you have witnessed in a match?

<6V followed very closely by the robot stopping moving as the CRIO reset. Though occasionally we did see it spike that low and come back up.

[Jared Russell]

I am a first year mentor for a rookie team. May seem like a dumb question, but I have not been involved first hand in a match yet. What is causing the batteries to drop so low? Are you using old batteries?

Internal resistance is usually on the order of ~0.01 ohms for the sealed lead-acid batteries that we use.

If your battery is charged to, say, 12.7 volts and you are running 4 CIM motors at stall (= 4 * 131A = 524A current), you can expect a voltage drop of ~5.2V just due to battery resistance (in reality, there are other losses in wiring, connectors, and speed controllers as well, so treat this as an approximate). 12.7 - 5.2 = 7.5V.

This situation happens (instantaneously) any time you rapidly change direction assuming your wheels don't slip on the ground first. Once the drive is moving, your motors draw less and less current, and battery voltage quickly recovers.

You can imagine that a 6 CIM drive, or simultaneously driving while powering mechanisms or the compressor, will only make things worse. I have seen robots drop below 6V relatively frequently in other seasons. Design with care!

[pnitin]

Momentary drops to 9.5vs are not at all uncommon in FRC matches, depending on the number of motors on the machine, weight, traction, etc. It might not be great for batteries but I'd rather be able to drive for the rest of the match and potentially shorten a battery's life than not be able to drive to save a couple of bucks later on. Basically, I don't want the products I use to try and protect me from myself.

Actually what I am trying to say here is if you treat your battery well, it will serves you faithfully, if you abuse it, it will not serve you well. Momentary drops are called spikes and most of the filter will take care of it ( you will not see brown out for spikes) I think problem is when you want to start with 9V battery to begin with, you have problem.

That way CTRE chart is incorrect since no one ( sane person) will be turning on robot with 9V battery level in competition.
what you really want to see is how well they handles those spikes.
.

[Jared Russell]

Momentary drops are called spikes and most of the filter will take care of it ( you will not see brown out for spikes)


Citation needed.

[aldaeron]

https://xkcd.com/285/

[scca229]

As an FTAA watching plenty of matches during competitions from close behind the drivers (anyone at events where I've FTAA'd can affirm that I move around a LOT), I see MANY driver station displays with the battery section flashing red throughout the match to indicate voltage momentarily dropping below thresholds. Not sure a match goes by that doesn't have at least 1 robot where we are watching for a brownout so that we can quickly inform the team why the robot isn't moving when they tell us they lost connection to the field. I try to inform the coach as the match is still going on so that they see it happening in realtime and not just get told after the fact so they know what to look for when trouble starts.

I also kind of make a habit of looking at the battery voltage readout on each DS as I pass them verifying connection to the field to get an idea of which bots might be in trouble in the case that I see a sub-12V reading on the display. Sub-11.5V (and barring being way behind schedule) and I ask them if they have another battery next to the field that can be quickly swapped.

[Mark McLeod]

I am a first year mentor for a rookie team. May seem like a dumb question, but I have not been involved first hand in a match yet. What is causing the batteries to drop so low? Are you using old batteries?
Here are a couple of real life examples to give you an idea of what you have to be prepared to manage in your power design.
Both Driver Station logs are from different teams that borrowed one of my laptops during competition.
Learn how to examine your own DS logs after a match. They are automatic and just brimming with useful data about how your robot performed.
Remember, too, that the power drawn during practice at home is tame compared to power drawn during a real match with competitors.

The yellow line shows the battery voltage for the duration of the match.
No roboRIO brownouts were experienced by either team during these logged events.

Both of these robots had good batteries.
These voltages are what the roboRIO and speed controllers directly experienced.
The first example is from a robot during an off-season event this past October with a large number of motors - drive, lift, tote grabbers all running.

The second example is also from an off-season event, but one held in November. It was a robot with four drive motors and one lift motor, and shows a lot less stress.

The biggest dips are when the motors are starting up from a complete stop, lifting a heavy load, or suddenly reversing.
These logs are taken from a game without active opposition. Expect much worse this coming season.

[s1900ahon]

Momentary drops are called spikes and most of the filter will take care of it

What filter are you referring to?

[pnitin]

Since you guys seem to be SD540 experts in this thread, I was wondering if you could comment on the very high output resistance of the SD540 that was measured by CTR in their tests (surely you've seen the results). The voltage drop (power lost) in the motor controller is drastically worse than the competition? Did you guys make a design choice or tradeoff that resulted in this? Or is it possible that CTR just got a bad (or damaged) SD540?

And I'll also echo Chris's question regarding a FW update to modify the 9.5V brownout feature. Could you make this voltage threshold user adjustable in the future so that users could control which motor controllers shut off first? Would it be possible to add a throttling feature to reduce output to 50% when a certain voltage threshold is reached?

http://www.ctr-electronics.com/downloads/pdf/Motor-Controller-Power-Testing.pdf

My big takeaway from all this is that the SD540 is unnacceptable for use in FRC robots due to the brown-out issue. In addition, with it's high output resistance, it would no doubt, would get very, very warm in a stall condition. You can estimate the power that is turned into heat in the output devices of the SD540 to be nearly 50 Watts in the resistive load test 3, at 11.20 volts. With a CIM motor, the SD540 would be dissipating ~100 watts of energy as heat. I wonder how long it takes to melt (can someone test and post pictures please)?


All FRC the controller on market use synchronous rectification,
they are not linear converter, so what is mentioned above is incorrect.
for example, consider your cellphone charger 115V In 5V Out @ 1A current,.
According to your theory it should dissipate 110W and should melt, but it does not. It dissipate much low power since it uses switching topology.

[mman1506]

Actually what I am trying to say here is if you treat your battery well, it will serves you faithfully, if you abuse it, it will not serve you well. Momentary drops are called spikes and most of the filter will take care of it ( you will not see brown out for spikes) I think problem is when you want to start with 9V battery to begin with, you have problem.

That way CTRE chart is incorrect since no one ( sane person) will be turning on robot with 9V battery level in competition.
what you really want to see is how well they handles those spikes.
.

Are you trying to say that the SD540 looks at an average voltage reading rather than a instantaneous reading so current spikes would not cause it to brown out? Thus making a low voltage cut off to protect you from draining the battery below a 9v state of charge?

[Daniel_LaFleur]

All FRC the controller on market use synchronous rectification,
they are not linear converter, so what is mentioned above is incorrect.
for example, consider your cellphone charger 115V In 5V Out @ 1A current,.
According to your theory it should dissipate 110W and should melt, but it does not. It dissipate much low power since it uses switching topology.

Incorrect.

The output is 5VDC@1A not the input. The input is closer to 115VAC@0.05A or ~6Watts (assuming 1W inefficiency which is actually high).

In a phone charger (or most other chargers/USB power supply sources) you have a AC to DC converter (most likely a bridge rectifier). Then you have a buck converter (probably a transformer) and a switcher boost (High speed MosFET, inductor, and shottkey diode).

[pnitin]

Incorrect.

The output is 5VDC@1A not the input. The input is closer to 115VAC@0.05A or ~6Watts (assuming 1W inefficiency which is actually high).

In a phone charger (or most other chargers/USB power supply sources) you have a AC to DC converter (most likely a bridge rectifier). Then you have a buck converter (probably a transformer) and a switcher boost (High speed MosFET, inductor, and shottkey diode).



Exactly ,
Same is applicable for motor driven by these motor controller, input current and output current are not identical due to switching and stored energy in motor inductance. so you can not just calculate power dissipation in switch by looking at difference in output voltage and output voltage and output current

[Sparky3D]

Exactly ,
Same is applicable for motor driven by these motor controller, input current and output current are not identical due to switching and stored energy in motor inductance. so you can not just calculate power dissipation in switch by looking at difference in output voltage and output voltage and output current

Except in the case of CTRE's testing they were using power resistors instead of a motor (so no motor inductance), and commanding each motor controller to 100%. In that case, power output should equal power input minus losses in the controller.

[cadandcookies]

Exactly ,
Same is applicable for motor driven by these motor controller, input current and output current are not identical due to switching and stored energy in motor inductance. so you can not just calculate power dissipation in switch by looking at difference in output voltage and output voltage and output current

Are you by any chance affiliated with MindSensors or FRC 540? If so, it would definitely be worth mentioning-- then your comments aren't being taken as being from some random person on the internet, but instead as someone who actually has knowledge of how this controller was designed, which is something many of the people in this thread are interested in, and lends your statements more weight.

If you are just some random person on the internet, ignore me, this back and forth is vaguely interesting (as someone who has very little knowledge of electrical engineering).

[pnitin]

Except in the case of CTRE's testing they were using power resistors instead of a motor (so no motor inductance), and commanding each motor controller to 100%. In that case, power output should equal power input minus losses in the controller.


To calculate power loss in any circuit, you have to look at power in minus power out this is correct, but power is V*I so you have to measure I_in and I_out not just I some random current.

[Monochron]

Momentary drops are called spikes and most of the filter will take care of it ( you will not see brown out for spikes)
Do you know this to be true for the SD540? Please answer 'yes' or 'no'.

If the answer is 'yes' I think the SD540 will made a lot more sales. If the answer is 'no' then it is still up in the air because momentary drops below 9.5V are going to kill robots on the field.

[AdamHeard]

Do you know this to be true for the SD540? Please answer 'yes' or 'no'.

If the answer is 'yes' I think the SD540 will made a lot more sales. If the answer is 'no' then it is still up in the air because momentary drops below 9.5V are going to kill robots on the field.

Why take the risk at this point?

There are so many proven controllers on the market, let other teams be the guinea pig this season.

Speed controllers especially are very high on the list of FRC components where no level of failure or odd behavior is tolerable to any team.

[sastoller]

It's a little different than a cell phone charger taking 110V AC input and 5V DC out...

For the conventional motor controller, you can make the assumption that Iin = Iout. Here's Why:

If you look at conventional motor controller designs, the current that drives the motor flows from the input of the motor controller, through a large output device (Power MOSFET or BJT), through the load (motor, or bank of resitors), and then back into the motor controller, through another large output device, and finally, back out the negative battery input on the motor controller.

You can think of the output devices in this case like a switch. When the output devices are "on" (transistors are in the saturation region), they have a small resistance (this is what causes the voltage drop between the input and output of the motor controller). This resistance here is in series with the load. Kirchhoff tells us that current through all components in the loop is the same. Operating on the assumption that the SD540 is in fact built like most conventional motor controllers, the input current will be the same as the output current (assume extra current consumed for control circuits etc in the motor controller is negligible). You know the resistance of the resistor bank, and you know the total power output, so you can easily calculate current through the motor controller. Now, knowing Iin and the delta V across the motor controller, you can calculate the amount of power consumed in the motor controller. This power is dissipated as heat.

As you can see, from the 50A load test on the MindSensors site, this motor controller does, in fact, get HOT (125C after 5 minutes at 50A), and still climbing... Seems to me like a lot of energy lost to heat in the SD540, not to mention a potential safety hazard...
http://www.mindsensors.com/content/73-sd540-performance-characteristics

[marshall]

It's a little different than a cell phone charger taking 110V AC input and 5V DC out...

For the conventional motor controller, you can make the assumption that Iin = Iout. Here's Why:

If you look at conventional motor controller designs, the current that drives the motor flows from the input of the motor controller, through a large output device (Power MOSFET or BJT), through the load (motor, or bank of resitors), and then back into the motor controller, through another large output device, and finally, back out the negative battery input on the motor controller.

You can think of the output devices in this case like a switch. When the output devices are "on" (transistors are in the saturation region), they have a small resistance (this is what causes the voltage drop between the input and output of the motor controller). This resistance here is in series with the load. Kirchhoff tells us that current through all components in the loop is the same. Operating on the assumption that the SD540 is in fact built like most conventional motor controllers, the input current will be the same as the output current (assume extra current consumed for control circuits etc in the motor controller is negligible). You know the resistance of the resistor bank, and you know the total power output, so you can easily calculate current through the motor controller. Now, knowing Iin and the delta V across the motor controller, you can calculate the amount of power consumed in the motor controller. This power is dissipated as heat.

As you can see, from the 50A load test on the MindSensors site, this motor controller does, in fact, get HOT (125C after 5 minutes at 50A), and still climbing... Seems to me like a lot of energy lost to heat in the SD540, not to mention a potential safety hazard...
http://www.mindsensors.com/content/73-sd540-performance-characteristics

Stupid questions but the casings for the SD540 controllers seem to be 3D printed. What is the plastic they are printed with? Is it ABS? Doesn't ABS begin to melt around 110C or so?

[techhelpbb]

Stupid questions but the casings for the SD540 controllers seem to be 3D printed. What is the plastic they are printed with? Is it ABS? Doesn't ABS begin to melt around 110C or so?

80-125 degrees C is the glass transition (https://en.wikipedia.org/wiki/Glass_transition) temperature for most variants of ABS. So it will start to get soft there but that doesn't mean the entire case will melt at all. If it was enough to liquefy the case then we wouldn't 3D print ABS at much higher temperature.

At worst it would likely melt the FDM layers together making it more a solid than it started.

I often print ABS over 225 degrees C and vacuum form over 150 degrees C.

To put that temperature in perspective your heated 3D print bed to keep that ABS from warping can be 110 degrees C.
So if the heated print bed isn't turning it into a puddle or ruining it...

[marshall]

80-125 degrees C is the glass transition temperature for most variants of ABS. So it will start to get soft there but that doesn't mean the entire case will melt at all. If it was enough to liquefy the case then we wouldn't 3D print ABS at much higher temperature.

At worst it would likely melt the FDM layers together making it more a solid than it started.

I often print ABS over 225 degrees C and vacuum form over 150 degrees C.

To put that temperature in perspective your heated 3D print bed to keep that ABS from warping can be 110 degrees C.
So if the heated print bed isn't turning it into a puddle or ruining it...

Like I said, stupid questions... Thanks for explaining though.

[sastoller]

Stupid questions but the casings for the SD540 controllers seem to be 3D printed. What is the plastic they are printed with? Is it ABS? Doesn't ABS begin to melt around 110C or so? Not a stupid question at all :). I had noticed this as well and wondered too.

[philso]

Wow! Go on vacation and lots happens.

Exactly ,
Same is applicable for motor driven by these motor controller, input current and output current are not identical due to switching and stored energy in motor inductance. so you can not just calculate power dissipation in switch by looking at difference in output voltage and output voltage and output current

No! A typical FRC motor controller will not have any significant energy storage elements in them so the input current is going to be pretty close to the output current. The difference between the input current and the output current is the current consumed by controller circuitry and should be insignificant at high motor currents. The motor's inductance does not have the effect you think it has.


It's a little different than a cell phone charger taking 110V AC input and 5V DC out...

For the conventional motor controller, you can make the assumption that Iin = Iout. Here's Why:

If you look at conventional motor controller designs, the current that drives the motor flows from the input of the motor controller, through a large output device (Power MOSFET or BJT), through the load (motor, or bank of resitors), and then back into the motor controller, through another large output device, and finally, back out the negative battery input on the motor controller.

You can think of the output devices in this case like a switch. When the output devices are "on" (transistors are in the saturation region), they have a small resistance (this is what causes the voltage drop between the input and output of the motor controller). This resistance here is in series with the load. Kirchhoff tells us that current through all components in the loop is the same. Operating on the assumption that the SD540 is in fact built like most conventional motor controllers, the input current will be the same as the output current (assume extra current consumed for control circuits etc in the motor controller is negligible). You know the resistance of the resistor bank, and you know the total power output, so you can easily calculate current through the motor controller. Now, knowing Iin and the delta V across the motor controller, you can calculate the amount of power consumed in the motor controller. This power is dissipated as heat.

As you can see, from the 50A load test on the MindSensors site, this motor controller does, in fact, get HOT (125C after 5 minutes at 50A), and still climbing... Seems to me like a lot of energy lost to heat in the SD540, not to mention a potential safety hazard...
http://www.mindsensors.com/content/73-sd540-performance-characteristics

Yes! Stop talking about cell phone chargers. The circuit topology is totally different and the energy transfer mechanisms are also totally different and are not comparable with what goes on in the motor controllers used in FRC.


Thanks CTRE for posting test results that are well documented and give the test conditions. I used the values to estimate the losses in each of the motor controller using the data from the 11.05 V input case.

Iout = Vout / 0.2 Ohm
Pcont = dV * Iout

Victor SP - 12.4 W
Talon SRX - 15.1 W
Spark - 21.8 W
SD540 - 44.3 W


The high voltage drop and high watt loss in the SD540 is consistent with the data that Mindsensors has published showing excessively high temperatures on their heat sink (125 degree C, and climbing).

Does anyone have an SD540 where they have opened it up, or are willing do so, and report what sort of MOSFET's are used in it?

[mindsensors.com]

Thank you all for your feedback!

The SD540 is equipped with a battery safety feature that would disable operation when battery voltage drops below 9.5 Volts.

Based on your concerns we have realized that such a safety feature is not desired by the FRC community, so we have released a model that does not include this feature. The new SD540B will work down to 6 Volts without disabling any operations! Here is our voltage comparison chart:
http://www.mindsensors.com/content/77-what-is-difference-between-sd540-and-sd540b

Since our design and production facility is local and our SD540s are made here in USA, we have the advantage to implement changes quickly. The new model SD540B is available now and ordering information is here: http://www.mindsensors.com/frc/159-sd540-model-b

[AdamHeard]

Thank you all for your feedback!

The SD540 is equipped with a battery safety feature that would disable operation when battery voltage drops below 9.5 Volts.

Based on your concerns we have realized that such a safety feature is not desired by the FRC community, so we have released a model that does not include this feature. The new SD540B will work down to 6 Volts without disabling any operations! Here is our voltage comparison chart:
http://www.mindsensors.com/content/77-what-is-difference-between-sd540-and-sd540b

Since our design and production facility is local and our SD540s are made here in USA, we have the advantage to implement changes quickly. The new model SD540B is available now and ordering information is here: http://www.mindsensors.com/frc/159-sd540-model-b

Can you comment on the appreciable efficiency difference? Will you be able to fix that as well before kickoff?

[wilsonmw04]

Since our design and production facility is local and our SD540s are made here in USA, we have the advantage to implement changes quickly. The new model SD540B is available now and ordering information is here: http://www.mindsensors.com/frc/159-sd540-model-b

regardless of anything else, making changes that quickly is pretty darn cool.

[tcjinaz]

Which motor control microcontroller is buried in there?

[geezloueez]

The SD504B graph looks much more comparable to the other controllers now. It is amazing how fast those changes were implemented.

Graph link (http://www.mindsensors.com/content/77-what-is-difference-between-sd540-and-sd540b)

[Rick]

Will the SD504Bs be FRC legal? What happens to the customers that purchased SD504s?

[mindsensors.com]

Will the SD504Bs be FRC legal? What happens to the customers that purchased SD504s?

SD540Bs will be legal.

If you have purchased a SD540 you should have received an email regarding the new model. Please check your spam folder just in case.

[AdamHeard]

SD540Bs will be legal.

If you have purchased a SD540 you should have received an email regarding the new model. Please check your spam folder just in case.

How were you able to "fix" the efficiency issue?

Do you have test data to support this, or just a graph?

[wilsonmw04]

How were you able to "fix" the efficiency issue?

Do you have test data to support this, or just a graph?

They pointed to their local suppliers and short supply chains in making these changes. I have been in almost daily contact with mindsensor. They are doing everything they can to give the FRC community a solid product. They are new to this space. Give them time.

[philso]

Thank you all for your feedback!

The SD540 is equipped with a battery safety feature that would disable operation when battery voltage drops below 9.5 Volts.

Based on your concerns we have realized that such a safety feature is not desired by the FRC community, so we have released a model that does not include this feature. The new SD540B will work down to 6 Volts without disabling any operations! Here is our voltage comparison chart:
http://www.mindsensors.com/content/77-what-is-difference-between-sd540-and-sd540b

Since our design and production facility is local and our SD540s are made here in USA, we have the advantage to implement changes quickly. The new model SD540B is available now and ordering information is here: http://www.mindsensors.com/frc/159-sd540-model-b

How were you able to "fix" the efficiency issue?

Do you have test data to support this, or just a graph?


If the output voltage of the SB540B is very close to that of the SPARK, it would translate to losses that are about half that of the SD540 (based on the very comprehensive data from CTRE). This is a very dramatic reduction in losses. Most engineers working on inverter designs would sell their grandmothers to get a 5 or 10% increase in efficiency.

Mindsensors - How do the firmware changes for the SD540B (other than removing the undervoltage-lockout safety feature) change it's behaviour relative to the SD540 to account for the increase in efficiency? Has the switching frequency been changed? Have the switching edge rates been changed? Is the heatsink temperatures different? Is the linearity performance the same as for the SD540? I am not expecting you to give away any major trade secrets but there are only so many ways to increase the efficiency of an inverter.


They pointed to their local suppliers and short supply chains in making these changes. I have been in almost daily contact with mindsensor. They are doing everything they can to give the FRC community a solid product. They are new to this space. Give them time.

The motor controllers are mission critical components. The Build Season starts in 2 1/2 weeks. Once a team commits to using a particular controller and builds their robot, they would have very little time to change to a different controller if they are not happy with it.

[aldaeron]

The motor controllers are mission critical components. The Build Season starts in 2 1/2 weeks. Once a team commits to using a particular controller and builds their robot, they would have very little time to change to a different controller if they are not happy with it.

This is a very important comment that needs some highlighting.

Below is my summary of this thread, especially for newer teams struggling to read between the lines. This is my opinion only and does not represent my team or any other individual. I have never seen or tested one of these devices in person. Based on the test data released and statements in this thread:

The test data supplied by Mindsensors and others, number of last minute changes, questionable design choices and lack of properly instrumented testing in a truly representative FRC game environment make buying this motor controller a very risky investment at this point, especially for high current, high duty cycle motors like the drive train.

By comparison and using the same publicly released data, the REV Spark controller looks less risky.

If you are considering buying these because they are lower cost than previous controllers, just be aware of the risk you are taking. DC motors have been the main source of power for FRC since its inception and I do not expect that to change. If your motor controllers are not working well, you are very likely to have a bad experience this coming season. If you choose a certain controller for 4-6 drive motors, plus at least one spare, you have invested a few hundred dollars in that controller. If you cannot afford buying a whole new set of controllers mid season, I would stay away from any of the new controllers (MS SD540 and REV spark).

It is possible that these controllers will work fine and all the bugs and concerns voiced in this thread will be fixed. Maybe not. Just take care that you can turn your motors consistently and reliably. No one wants to see a team chasing "motor controller demons" during the competition.

-matto-

[Greg Needel]

If you cannot afford buying a whole new set of controllers mid season, I would stay away from any of the new controllers (MS SD540 and REV spark).
-

While there is always RISK in trying something new, I don't think it is correct to make a recommendation like this without data to back it up.

Speaking directly about the SPARK, we have done everything we can (including testing them on robots at numerous offseason events, on abusive test bed robots (6 cim - 2 speed drive train weighing 200+ lbs), abuse testing them at higher voltages and higher current, dumping piles of aluminum chips on them, static testing, etc) into it to make sure that it is a hardened controller ready for FRC prime time. The SPARK that is in production right now is actually our 3rd revision of the design, based on the feed back of the above testing. Every time we made a design change we continued trying to break the controller until we felt that it would be WAY out of reach of teams breaking them.

As someone who has been involved with FIRST for 14 seasons, on numerous teams with many blue banners, making sure the SPARK was bullet proof was at the top of our priority list when developing it. We would not have launched the product if I didn't feel 100% comfortable putting them on my own team's robot. 2848 will defiantly be using SPARKs this year (and we are a team that can easily afford talon SRX's everywhere).

We check 100% of our motor controllers at 50 AMPS load on our production line. All that being said if a team does fine an issue we will stand behind it's performance. If any team has any problems with a SPARK, that are not user caused (ours will die in the same way that the talon, victor, and SD540 will from reverse polarity, or wrong hookup) we will replace them.

We designed this motor controller to be low cost so that we could help Rookie teams and those who have budget issues each year, that doesn't mean that we designed it with any less performance than the other controllers on the market.

TL: DR Teams should not have any reservations choosing the SPARK for 2016.

[techhelpbb]

Just a little something I'd like to put out there:

Taking risk is what encourages people to sell products. If your market must have zero chance of issue before any financial or morale return can be made you'll discourage innovation and you'll leave yourself with a small number of choices. Eventually that drives up cost artificially.

Yes - MindSensors decided to make a change in their design. The Jaguars in the past made changes in their design. That's nothing actually new and the Jaguar manufacturing resources took much longer to do it.

FIRST doesn't really let you build your own control systems for competition use. They let you change out modules. Even though my team (FRC11) gave me all their old Jaguars after a bad experience - I as the CSA at several competitions simply took note of these controllers and the experience each team had with them. If you put the time in you could make the Jaguars work - how much time was really up to your team's resources to approach the issues. Even the change MindSensors made addresses a situation which may or may not be a deal breaking issue. I mean they did drive an FRC size robot around with these original controllers and it did move - plenty of people never got that far with the Jaguars.

It should be up to the individuals where there comfort level stands and why. FIRST obviously realizes not every team has the resources to take any risk at all - and for those teams this practice of tightly controlling the control system components is advantageous. It also stops teams from trying to build entirely unique controls in just 6 weeks and then having weird problems with no standards for the FTA/FTAA/CSA to help hunt down to keep the competition playing.

So there's give and take here. I hope the community has some patience with these new guys so they can sort any issues out and polish their work till it represents the best possible outcome. I bought both Sparks and SD540 and I have no regrets because in my particular situation $100 of both was a small price to increase the market diversity.

I write this not because of my trivial investment or any involvement with these companies. I write this because I've put give or take 20 years into FIRST FRC and I personally would rather see some small controlled risk of issues that get addressed than a lock-out that drives not just cost but limitations to the very cool diversity that FRC frequently demonstrates. This isn't FLL. This is high school level and by now as we teach STEM I should hope we can drive metric driven decisions and independent thought.

[AdamHeard]

The time to test these to build confidence for teams was in the offseason at events.

It'd be foolish for teams to run these without being cognizant of the substantial possible risk compared to more established brands.

I know we will be worried about picking teams running these until substantial independent testing in competition proves robustness.


Just a little something I'd like to put out there:

Taking risk is what encourages people to sell products. If your market must have zero chance of issue before any financial or morale return can be made you'll discourage innovation and you'll leave yourself with a small number of choices. Eventually that drives up cost artificially.

Yes - MindSensors decided to make a change in their design. The Jaguars in the past made changes in their design. That's nothing actually new and the Jaguar manufacturing resources took much longer to do it.

FIRST doesn't really let you build your own control systems for competition use. They let you change out modules. Even though my team (FRC11) gave me all their old Jaguars after a bad experience - I as the CSA at several competitions simply took note of these controllers and the experience each team had with them. If you put the time in you cloud make the Jaguars work - how much time was really up to your team's resources to approach the issues.

It should be up to the individuals where there comfort level stands and why. FIRST obviously realizes not every team has the resources to take any risk at all - and for those teams this practice of tightly controlling the control system components is advantageous. It also stops teams from trying to build entirely unique controls in just 6 weeks and then having weird problems with no standards for the FTA/FTAA/CSA to help hunt down to keep the competition playing.

So there's give and take here. I hope the community has some patience with these new guys so they can sort any issues out and polish their work till it represents the best possible outcome. I bought both Sparks and SD540 and I have no regrets because in my particular situation $100 of both was a small price to increase the market diversity.

[techhelpbb]

The time to test these to build confidence for teams was in the offseason at events.

It'd be foolish for teams to run these without being cognizant of the substantial possible risk compared to more established brands.

I know we will be worried about picking teams running these until substantial independent testing in competition proves robustness.

So you are suggesting you'd punish teams at selection time because they are using hardware you think is an issue?

You haven't even played the first match. That's sort of a bold stance to take. I suppose I could do the same.

I pour money and time into FRC and there are often field and technology problems in the control system.
Perhaps I shouldn't do that any more ;) I mean I take risk doing that. I could cut my losses.
Cause I can actually prove that these issues have cost matches - where as I can make no such claim about these ESC.

You've implied there's a standard for testing here - so I honestly wonder what it might be because an ill-defined standard isn't much of standard. I've got some experience with proposing hardware to FIRST but I can't say that anyone has ever handed me any documents that define the criteria clearly for the levels of test required. I am also fairly certain FIRST is trying to hire a test engineer:

https://jobs-usfirst.icims.com/jobs/1146/systems-engineer/job/job?mobile=false&width=1424&height=500&bga=true&needsRedirect=false&jan1offset=-300&jun1offset=-240

Perhaps that role being unfilled contributes hard to say.

[AdamHeard]

It's not a punishment at all.

You're drafting a team and a robot. That robot is made up of many design decisions that may be positive or negative. This wouldn't be any different than passing up a team because their mechanical design isn't robust due to choices they made.


So you are suggesting you'd punish teams at selection time because they are using hardware you think is an issue?

You haven't even played the first match. That's sort of a bold stance to take. I suppose I could do the same.

I pour money and time into FRC and there are often field and technology problems in the control system.

Perhaps I shouldn't do that any more ;) I mean I take risk doing that. I could cut my losses.

Cause I can actually prove that these issues have cost matches - where as I can make no such claim about these ESC.

You've implied there's a standard for testing here - so I honestly wonder what it might be because an ill-defined standard isn't much of standard.

[Rick]

My team has been in at least two situations where a desire to save money has cost us a match. I won't get in to details.

In both situations, looking back to the decision to save money was the wrong because we ended up spending more in the long run to fix the problem.

IMO, the potential to save a few hundred bucks is not worth the risk of experimenting with this new controller for this upcoming season for any team.

[techhelpbb]

It's not a punishment at all.

You're drafting a team and a robot. That robot is made up of many design decisions that may be positive or negative. This wouldn't be any different than passing up a team because their mechanical design isn't robust due to choices they made.

Just to be clear you'd do so because you have actual reasons for declaring it a negative right?
That's the heart of the issue: what testing do you define as sufficient to take risk on.

Cause I could argue that surviving 10 matches of FRC on 10 designs is enough. You may argue that it's 1,000 matches of 100 designs. That was why I was so very specific to elicit criteria when I started tinkering early in this topic.

It's not much of an experiment without clear expectations.

So if we can put it out there we don't feel they are adequately tested which can drive hardship back to the manufacturer - can we in fairness put out there what adequately tested is?

If we can't define what the actual testing barrier to entry is we are basically saying FIRST is 'all over the place' about how you make a product that is FRC approved and ready for sale. That kind of situation is painful for everyone involved.

To close my previous post: if you view FIRST as an experiment for an educational process/product. FIRST doesn't set their achievement by the minority of technical issues that have happened. They set the value on the overall impact which is greatly positive. These new ESC products haven't had time to set any other experience but it is safe to say that time will tell and I'd like to know for reference how one charts a path to a conclusion because it seems in < 2 months some people have a pretty negative outlook. It sets expectations for people that might want to make FRC products. Is it okay to have a problem when you first release a product if you fix it? How about 2 problems which you do fix...? How about a product that looks a little different? I would hate to hold the teams building robots to the same level of scrutiny. I've seen lots of robots evolve in positive directions after a bumpy start.

[aldaeron]

After re-reading my posts I think I am not stating clearly enough to both REV and Mindsensors that you need to post appropriate, preferably independent, test data. That is what builds confidence. I believe the major reason there was widespread adoption of the last two new motor controllers was the public and independent testing done by Alpha and Beta teams. You need to replicate this level of testing if you want to get widespread adoption.

Our team did not buy Talon SRs the year they came out because of the lack of available test data.

Here is a great example of an appropriate test (http://www.ctr-electronics.com/downloads/pdf/Motor-Controller-Power-Testing.pdf). Well documented with appropriate methods. It includes photos and part numbers so anyone can repeat it and it is revision controlled. This is the kind of report I would expect to see at work.

Only slightly behind as an example is the Vex Pro Motors (http://motors.vex.com/#testing) page (would have liked to see photos and part numbers of test assemblies, but very, very good).

While there is always RISK in trying something new, I don't think it is correct to make a recommendation like this without data to back it up.


For crying out loud - post the data on your website!!


Speaking directly about the SPARK, we have done everything we can (including testing them on robots at numerous offseason events, on abusive test bed robots (6 cim - 2 speed drive train weighing 200+ lbs), abuse testing them at higher voltages and higher current, dumping piles of aluminum chips on them, static testing, etc) into it to make sure that it is a hardened controller ready for FRC prime time. The SPARK that is in production right now is actually our 3rd revision of the design, based on the feed back of the above testing. Every time we made a design change we continued trying to break the controller until we felt that it would be WAY out of reach of teams breaking them.

This should also be on your website. Help convince us you have a great new product. As I have noted in this thread and others, your design does look good, just send data to back it up.


As someone who has been involved with FIRST for 14 seasons, on numerous teams with many blue banners, making sure the SPARK was bullet proof was at the top of our priority list when developing it. We would not have launched the product if I didn't feel 100% comfortable putting them on my own team's robot. 2848 will defiantly be using SPARKs this year (and we are a team that can easily afford talon SRX's everywhere).

Here's the deal - you had some great looking products last year, but were unable to deliver them due to a variety of issues (our team was bummed to have had to go elsewhere). Great intentions do not necessarily always come through and you should be a little more aware of well-founded concerns that are raised about such key components as motor controllers. Again, providing test data will assuage many of these fears.


techhelpbb has raised an excellent point about offering new and innovative products. I think the new offerings are great and that vendors should continue to offer new products, but the risks should be noted and understood. I think that there is a great community here on CD that would have offered constructive feedback months ago if engaged. The issues being discussed here could have been put to bed long ago at no cost to manufacturers. We all donate hundreds of hours a year to make this program great and hundreds more on CD to help those in need draw on our experience. I hope that in the future that vendors will reach out more to get help.

-matto-

[Greg Needel]

After re-reading my posts I think I am not stating clearly enough to both REV and Mindsensors that you need to post appropriate, preferably independent, test data. That is what builds confidence. I believe the major reason there was widespread adoption of the last two new motor controllers was the public and independent testing done by Alpha and Beta teams. You need to replicate this level of testing if you want to get widespread adoption.


For crying out loud - post the data on your website!!



This should also be on your website. Help convince us you have a great new product. As I have noted in this thread and others, your design does look good, just send data to back it up.




Yup, you are right on these points, we have not released enough of our testing data. I will compile it into a format that makes sense and release it ASAP.




Here's the deal - you had some great looking products last year, but were unable to deliver them due to a variety of issues (our team was bummed to have had to go elsewhere).

Yes, we have heard this many times this year, and I am really sorry that it happened. Last year was particularly hard for us as a new company with limited cash flow to purchase inventory. When you combine that with a game that was as perfect as you could imagine for our new products it created a shortage.

This year we have re-invested all money made last year in new products and inventory. We have plenty of SPARKs and other products in stock and ready to go for the year. *Obviously there is a chance for huge demand that we can't keep up with, but if that happens we have safeguards in place to help get us back in stock quickly.




Great intentions do not necessarily always come through and you should be a little more aware of well-founded concerns that are raised about such key components as motor controllers. Again, providing test data will assuage many of these fears.

What you have said is very true, and we are listening to the concerns. As team mentors ourselves we know and understand the issues deeply as we have seen the same things. That's one of the reasons I know the SPARK is solid, because we tested it the same way that I would want a company to test it as a potential customer. That being said....our test data on the way.

We have also given some controllers to respected members of the community for further testing to get an outside perspective.

Thanks for your perspective and thoughts, I really do appreciate it.

Greg

[aldaeron]

Yes, we have heard this many times this year, and I am really sorry that it happened. Last year was particularly hard for us as a new company with limited cash flow to purchase inventory. When you combine that with a game that was as perfect as you could imagine for our new products it created a shortage.

What you have said is very true, and we are listening to the concerns. As team mentors ourselves we know and understand the issues deeply as we have seen the same things.


I think a lot of people saw what happened and were sympathetic. I also noticed the changes you made to utilize Amazon for shipment of the motor controllers. I have seen all FRC vendors struggle over the years with inventory at various times. You don't know the game and most of the part orders are placed in the span of ~4 weeks. Tough business to be in and my hats off to all of the FRC vendors. Just be wary of what you promise because what I have seen is that the mob remembers these promises and shows up with pitchforks come late January (they also do not notice the asterisks you place with your statements)



Thanks for your perspective and thoughts, I really do appreciate it.


Hopefully they're are coming across as honest and constructive criticism. It is hard to do with black and white text. Ultimately we want better/lighter/cheaper products to use for the season and for vendors to be successful.

Keep up the good work!

-matto-

[s1900ahon]

Mindsensors - How do the firmware changes for the SD540B (other than removing the undervoltage-lockout safety feature) change it's behaviour relative to the SD540 to account for the increase in efficiency? Has the switching frequency been changed? Have the switching edge rates been changed? ...

I didn't see any response from Mindsensors on this here, so I'll speculate.

There are two contributors to an efficiency loss. The IR drop due to Rds(on) is one and is the contributor most are familiar with. The other is the refresh of the boot capacitor.

To turn on the high-side MOSFETs, the Vgs must be high enough for efficient conduction, but since the source voltage is also that connected to the motor, it means that the gate voltage relative to ground is greater than the battery voltage (by more than 5V, typically). So, the high-side gate drivers use a capacitor as a source of voltage/current and that cap (the boot cap) is periodically refreshed. This means that when driving the motor at 100%, the gate driver cannot actually drive a high-side MOSFET on for 100%, it is more like 99.9%. The 0.1% is enough to refresh the boot cap.

Since the test setup uses a resistive load and RMS multimeters, the refresh will appear like further IR drop. To figure out the refresh component, a scope can be put across the resistive load and the duty cycle measured.

Some newer gate drivers (like the one announced by TI earlier this year) use an integrated charge pump and can keep a boot cap charged without requiring this loss.

So, Mindsensors *could* have updated their firmware to reduce the refresh time/duty cycle and improve efficiency.

Scott

[philso]

I didn't see any response from Mindsensors on this here, so I'll speculate.

There are two contributors to an efficiency loss. The IR drop due to Rds(on) is one and is the contributor most are familiar with. The other is the refresh of the boot capacitor.

To turn on the high-side MOSFETs, the Vgs must be high enough for efficient conduction, but since the source voltage is also that connected to the motor, it means that the gate voltage relative to ground is greater than the battery voltage (by more than 5V, typically). So, the high-side gate drivers use a capacitor as a source of voltage/current and that cap (the boot cap) is periodically refreshed. This means that when driving the motor at 100%, the gate driver cannot actually drive a high-side MOSFET on for 100%, it is more like 99.9%. The 0.1% is enough to refresh the boot cap.

Since the test setup uses a resistive load and RMS multimeters, the refresh will appear like further IR drop. To figure out the refresh component, a scope can be put across the resistive load and the duty cycle measured.

Some newer gate drivers (like the one announced by TI earlier this year) use an integrated charge pump and can keep a boot cap charged without requiring this loss.

So, Mindsensors *could* have updated their firmware to reduce the refresh time/duty cycle and improve efficiency.

Scott

Thanks for your input, Scott. It is interesting to get your perspective as a power electronics professional.

If changing the refresh time will make the MOSFETs saturate properly, they could update the firmware in the original and improve it's performance too. The stated change to make the "B" version was to remove the under-voltage lockout feature which should have no effect on how the MOSFET gates are controlled during "normal" operation.

It would be interesting to see if anyone who has an SD540 or SD540B can put a scope probe on the output. It is possible that the SD540B uses a switching frequency lower than 32.25 kHz to cut the switching losses in half. I would also be interested to see how clean the output waveforms are. I have had to fix inverters where poor internal layout led to excessive voltage surges which led the designers to greatly increase the gate resistance (increasing switching losses and allowing the Miller Capacitance to cause oscillations).

[s1900ahon]

Thanks for your input, Scott. It is interesting to get your perspective as a power electronics professional.

Ha ha.. I have to LOL on that comment. I'd hardly give myself that attribute. I'm an embedded semiconductor kind of guy (architecture/hardware/software). My experience with power electronics is due to my being employed at Luminary Micro some years ago who built microcontrollers (MCUs) for use in applications such as motor control. Specifically, you can blame me for Jaguar (he ducks as rotten tomatoes are hurled in his direction).

If changing the refresh time will make the MOSFETs saturate properly, they could update the firmware in the original and improve it's performance too.

To be clear, I wasn't suggesting that the Cboot voltage was decaying and affecting the Vgs level on the high-side MOSFETs. Actually, the scenario I was thinking about was that the they were over refreshing and therefore incurring an un-necessary drop in efficiency.

The Cboot cap is charged up when the connected terminal (M+ or M-, there is one Cboot for each) is driven low (the low-side MOSFET is turned on). The cap charges through a diode and current limiting resistor. The Cboot charge time is therefore 3-5 RCboot times. But, the firmware in the MCU controls the timing. If you're curious, check out the Jaguar's published schematics.

The stated change to make the "B" version was to remove the under-voltage lockout feature which should have no effect on how the MOSFET gates are controlled during "normal" operation.

Yeah, the under voltage would be the VBUS voltage reduced by a divider circuit to an ADC input, being sampled by firmware, and setting a different trip point value or updated software-based filtering to activate exceptional processing. Also a firmware change (likely).

It would be interesting to see if anyone who has an SD540 or SD540B can put a scope probe on the output. It is possible that the SD540B uses a switching frequency lower than 32.25 kHz to cut the switching losses in half. I would also be interested to see how clean the output waveforms are. I have had to fix inverters where poor internal layout led to excessive voltage surges which led the designers to greatly increase the gate resistance (increasing switching losses and allowing the Miller Capacitance to cause oscillations).

Agreed. From a pure curiosity perspective, I'd like to see this done for all motor controllers. It would provide some insight into the real power loss (IRds(on)). It is easy to see: connect small resistive load across M+/M-, connect scope to M+ and V-(ground), set output to 100% forward, measure duty cycle and frequency on scope.

Scott

[philso]

Ha ha.. I have to LOL on that comment. I'd hardly give myself that attribute. I'm an embedded semiconductor kind of guy (architecture/hardware/software). My experience with power electronics is due to my being employed at Luminary Micro some years ago who built microcontrollers (MCUs) for use in applications such as motor control. Specifically, you can blame me for Jaguar (he ducks as rotten tomatoes are hurled in his direction).



To be clear, I wasn't suggesting that the Cboot voltage was decaying and affecting the Vgs level on the high-side MOSFETs. Actually, the scenario I was thinking about was that the they were over refreshing and therefore incurring an un-necessary drop in efficiency.

The Cboot cap is charged up when the connected terminal (M+ or M-, there is one Cboot for each) is driven low (the low-side MOSFET is turned on). The cap charges through a diode and current limiting resistor. The Cboot charge time is therefore 3-5 RCboot times. But, the firmware in the MCU controls the timing. If you're curious, check out the Jaguar's published schematics.



Yeah, the under voltage would be the VBUS voltage reduced by a divider circuit to an ADC input, being sampled by firmware, and setting a different trip point value or updated software-based filtering to activate exceptional processing. Also a firmware change (likely).



Agreed. From a pure curiosity perspective, I'd like to see this done for all motor controllers. It would provide some insight into the real power loss (IRds(on)). It is easy to see: connect small resistive load across M+/M-, connect scope to M+ and V-(ground), set output to 100% forward, measure duty cycle and frequency on scope.

Scott


Regardless of the opinions other people have of the Jaguar, you clearly did a decent job with the design of the inverter section. I have seen the results of other embedded designers trying to design a 3-phase inverter for automotive applications. This guy clearly just copied a generic schematic for the inverter and did not know how to minimize the inductance in the circuit or how to bypass the inverter. They were using 1200V devices with a DC supply in the range of 300-400V and were still blowing it up. That start-up never got to market.


It would be interesting to see the output of the motor controllers even with no load connected. Issues with excessive inductance in the controller will show up as large spikes, possibly with abnormally slow voltage rise and fall times.

[ozrien]

...employed at Luminary Micro some years ago who built microcontrollers (MCUs) for use in applications such as motor control. Specifically, you can blame me for Jaguar (he ducks as rotten tomatoes are hurled in his direction).


Yeah I'm not sure that's fair Scott, that's a bit harsh...
"The first one through the wall always gets bloody." - Moneyball (film)

Before the Jag, CANbus was totally unheard of. And because of the Jag, teams got their first glimpse at what smart motor controllers could do in FRC.

Teams also got exposed to web-based diagnostics through CTRE's 2CAN and Jags. And now the RIO has both web-based diagnostics and CANbus integrated. So I'd say it was a learning curve that benefited several aspects of the control system.

[techhelpbb]

Yeah I'm not sure that's fair Scott, that's a bit harsh...
"The first one through the wall always gets bloody." - Moneyball (film)

Before the Jag, CANbus was totally unheard of. And because of the Jag, teams got their first glimpse at what smart motor controllers could do in FRC.

Teams also got exposed to web-based diagnostics through CTRE's 2CAN and Jags. And now the RIO has both web-based diagnostics and CANbus integrated. So I'd say it was a learning curve that benefited several aspects of the control system.

As far as I am concerned - the problem with the Jaguars was not the concept or even the initial delivery.

The problem with the Jaguars was that once issues started to pop up it was difficult to get either clear support from the community or any one else. Often the list of potential issues that could cause complications was also so large such that the Jaguars never stood a chance.

Take CAN as a fine example. Yes there was CAN support from both the cRIO control system and the Jaguar but there were all sorts of issues lurking around in there. CAN itself is extremely robust and easily safe to use in vehicle applications.

I still have all the FRC11 Jaguars in my storage and frankly I still consider them usable as long as one is prepared to explore the intricacy. That's the killer right there - planning on the intricacy.

Even if my idea of building a Makerspace with FRC gear doesn't play out - at least now I have both an AndyMark drivetrain and a custom drivetrain to run tests with uncommited to the FRC competition itself. Once the Jaguars started giving FRC11 trouble it was a mess for us. There was not enough uncommitted hardware to do any testing either just for FRC11 or just for the sake of feeding results to the community. So that intricacy was bad news for the Jaguars because we could toss Victors onto what we had those years and it ran. At some point we just had to toss the Jaguars aside to keep moving forward.

[s1900ahon]

Yeah I'm not sure that's fair Scott, that's a bit harsh...
"The first one through the wall always gets bloody." - Moneyball (film)

True.

Before the Jag, CANbus was totally unheard of. And because of the Jag, teams got their first glimpse at what smart motor controllers could do in FRC.

Glimpse for some, taste for others, a meal for very few. Rarely does improvement occur when one iteration is allowed (we made improvements to the Jaguar from Grey to Black version, but not significant enough to address the major issues). Believe it or not, we had concepts in mind for an SRX-like design back in 2012, but we couldn't convince TI to allow us to follow on. Well, it probably wound't have sold for what the SRX does had it been allowed.

Anyhow, back to the subject of the thread at hand: I need to find where I put some old power resistors...

[marshall]

True.



Glimpse for some, taste for others, a meal for very few. Rarely does improvement occur when one iteration is allowed (we made improvements to the Jaguar from Grey to Black version, but not significant enough to address the major issues). Believe it or not, we had concepts in mind for an SRX-like design back in 2012, but we couldn't convince TI to allow us to follow on. Well, it probably wound't have sold for what the SRX does had it been allowed.

Anyhow, back to the subject of the thread at hand: I need to find where I put some old power resistors...

I take it you were involved with the design for the Jaguar... We were one of the few teams who adopted them and the 2CAN (both versions) and stuck with them. We really enjoyed using them and when conformal coating was added they got even better because we quit frying two per year. We also lost a few from failed firmware updates. One of them I managed to recover using one of the TI launchpads in the kit.

Can you explain the decision behind using RJ11 as the data connector though? I've always wondered about it. Was it just a convenient form factor? Were any other options ever discussed or considered?

[s1900ahon]

Can you explain the decision behind using RJ11 as the data connector though? I've always wondered about it. Was it just a convenient form factor? Were any other options ever discussed or considered?

There were other options discussed at the time. We started with different CAN standards (DB9 comes to mind, so does a 2-row square pin header). But we ended up with the 6P4C modular connector. The form factor seemed convenient, the tools could be found cheaply, the parts were available from many places, etc.

I much prefer the current solution provided by the PDP, PCM, roboRIO, etc. The connection is more reliable, no tools needed (finger), and the foot print could fit inside that of a single 6P4C connector (2x2). Mike and Omar have done a great job.

[marshall]

There were other options discussed at the time. We started with different CAN standards (DB9 comes to mind, so does a 2-row square pin header). But we ended up with the 6P4C modular connector. The form factor seemed convenient, the tools could be found cheaply, the parts were available from many places, etc.

I much prefer the current solution provided by the PDP, PCM, roboRIO, etc. The connection is more reliable, no tools needed (finger), and the foot print could fit inside that of a single 6P4C connector (2x2). Mike and Omar have done a great job.

Indeed they have. Thanks for the background info!

[thatprogrammer]

Now that this season is over, I would like to ask if any teams used this controller this year and what they thought of it.

[geezloueez]

I mentor team #6194. We used the SD540B and had great results. The controllers gave out great power. We qualified for the Cheseapeake District Championship in Maryland as Rookie Team. We will use this controller again next season.

[udpatil]

Team 540 also used the controllers this year and they were very successful for us. We had 7 controllers on our robot for the drivetrain, flywheel shooter, pickup mechanism, and manipulator arm and each used the SD540B motor controller. We used three single controllers and two sets of double controllers (the 2 controller bank). Overall, they were good and we were able to go all the was to St Louis with our successes and made one of our best robots in team history!

[FarmerJohn]

Can someone outside of Virginia comment on their experiences with these motor controllers? Just looking to eliminate any potential regional bias.

[Joe Ross]

Can someone outside of Virginia comment on their experiences with these motor controllers? Just looking to eliminate any potential regional bias.

Per http://www.firstinspires.org/robotics/frc/blog/2016-by-the-numbers-2 only 7 teams uses SDS540s. Of those 3 used it as their only motor controller, 2 used it as their primary motor controller, and 2 used it for 50% or less of their motor controllers.

[RyanN]

I'm not affiliated with the company, but I do those that used it to post Amazon reviews. That's a strong factor in me selecting or not selecting a part.

Currently, there is only one review and it's very negative.

[Michael Corsetto]

I'm not affiliated with the company, but I do those that used it to post Amazon reviews. That's a strong factor in me selecting or not selecting a part.

Currently, there is only one review and it's very negative.

Here is a link to that review. (https://www.amazon.com/review/R1JCF3G3RLAH92/ref=cm_cr_dp_title?ie=UTF8&ASIN=B01A7B13F2&channel=detail-glance&nodeID=165793011&store=toys-and-games)

This review echoes many of the concerns myself and others had when this product was initially announced.

-Mike

[geezloueez]

I read that Amazon review. That may have been an earlier model. The single banks that we used had a black molded case and held up very well. We also used two double banks. They were 3-D printed, but they too had no issues.

[marshall]

Here is a link to that review. (https://www.amazon.com/review/R1JCF3G3RLAH92/ref=cm_cr_dp_title?ie=UTF8&ASIN=B01A7B13F2&channel=detail-glance&nodeID=165793011&store=toys-and-games)

This review echoes many of the concerns myself and others had when this product was initially announced.

-Mike

I'm glad they attached pictures to the review but wish they had provided a better one of the soldering.

[cbale2000]

...The single banks that we used had a black molded case and held up very well...

Pictures?

[AdamHeard]

I read that Amazon review. That may have been an earlier model. The single banks that we used had a black molded case and held up very well. We also used two double banks. They were 3-D printed, but they too had no issues.

Were they 3D printed or were they molded?

[geezloueez]

Were they 3D printed or were they molded?

The single banks we used had black molded casings. The multi-bank options had the 3-D printed casings. All controllers worked great. The product page has pictures of the older gray 3-D printed casings and the black molded casings that we received.

Here is the link:
http://www.mindsensors.com/frc/135-sd540b-motor-controller-for-frc

[AdamHeard]

I just don't see how to get over this huge difference in performance;
http://www.ctr-electronics.com/downloads/pdf/Motor-Controller-Power-Testing.pdf

[Sperkowsky]

I truly hope they didn't lose too much money with these things. Frc doesn't need more motor controllers at this point and there was really nothing special about these that made them worth the risk..

Frc could use more cots components however.

[JesseK]

I remember these being the cheapest when they came out, but perhaps the SPARKs came out after the SD540's and dove below the price point? Am I remembering this correctly?

I truly hope they didn't lose too much money with these things. Frc doesn't need more motor controllers at this point and there was really nothing special about these that made them worth the risk..

Frc could use more cots components however.

Aren't all legal motor controllers COTS components? So simultaneously FRC does and doesn't need more motor controllers?

[Anupam Goli]

I truly hope they didn't lose too much money with these things. Frc doesn't need more motor controllers at this point and there was really nothing special about these that made them worth the risk..


Really? I thought the multi-bank feature sounded pretty cool. Sure the other specs of the controller are less desirable but maybe the next iteration will be better.

[Sperkowsky]

I remember these being the cheapest when they came out, but perhaps the SPARKs came out after the SD540's and dove below the price point? Am I remembering this correctly?

Aren't all legal motor controllers COTS components? So simultaneously FRC does and doesn't need more motor controllers?

Iirc the sparks came out a month or so before at a lower price point.

[JesseK]

Really? I thought the multi-bank feature sounded pretty cool. Sure the other specs of the controller are less desirable but maybe the next iteration will be better.

QFT - usually tech gets better with more iterations, and this one definitely has a niche that isn't seen elsewhere. For performance, there's "THE FASTEST!" vs 'fast enough', and I think the SD540's demonstrated the latter just fine.

[Greg Needel]

I remember these being the cheapest when they came out, but perhaps the SPARKs came out after the SD540's and dove below the price point? Am I remembering this correctly?


We didn't learn about the SD540 until days before the public announcement, at which point our prices had already been set. The SD540 was available to purchase a few weeks prior to the SPARK, but their existence didn't influence our cost.



If I can step back from my obvious SPARK bias a bit, my main issue with the SD540 is that the calibration switch and brake coast mode switch is on the bottom of the unit. I don't understand from a user interface standpoint how this works for teams. Do teams have to lift up their motor controllers while the robot is powered and enabled to calibrate them? Also my team plays with the brake/coast mode all season for different applications and it would be frustrating to me to have to turn over each controller for access to this feature.

[Michael Hill]

I just don't see how to get over this huge difference in performance;
http://www.ctr-electronics.com/downloads/pdf/Motor-Controller-Power-Testing.pdf

The fix for the SD540 power output is probably just a change in the MOSFETs or thermal characteristics. They probably just used MOSFETS with a higher Rds(on). I'm not sure of the actual topography of the SD540s, but I get an equivalent Rds(on) of ~ 17 mOhms with the SD540s. In comparison, the Victor SP has an equivalent of ~ 4 mOhms. When I say I don't know the topography, it'll be an H-bridge, but how many parallel MOSFETS there are on each leg is key. Also, I'm guessing the SRX has an additional current sense resistor over the SP, which would explain why the Victor SP tests better (just my guess). As for the SD540s, I'm betting when they designed it, they trusted the MOSFET data sheet. MOSFET Rds(on) specs in datasheets are some of the biggest lies ever. They'll give you the Rds(on) with a junction temperature of 20 degC on the front page, but when you heat it up to ~100 degC, it can change drastically. Always check the graphs.

[Sperkowsky]

Really? I thought the multi-bank feature sounded pretty cool. Sure the other specs of the controller are less desirable but maybe the next iteration will be better.

Heres the way I see it.

4 Victor SP's or 4 Talon SRX's side by side is 2.75" by 4.74" by 1.185"
A bank of 4 SD540's is 2.7" by 6.1" by 1.2"

So you get a larger footprint with the 'feature' that if one of the controllers in a bank fails you are stuck with a dead controller sitting on your robot.

Now, you could argue that Spark's have a larger footprint which is true. But even with the quantity of 4 they come in cheaper than the bank of 4 SD540's.

and their dimensions in line are not much bigger at
2.74" by 7.5" by 0.868

[Alan Anderson]

4 Victor SP's or 4 Talon SRX's side by side is 2.75" by 4.74" by 1.185"

Did anyone try using such a compact array? I'm worried about how hot the center two are going to get if they are mounted that way.

[Jared]

17 mOhm Rds on is really high for this type of motor controller. At 30 amps, which FRC robots will draw for a few seconds, you're dissipating 15.3 watts in your FETs!

It seems weird to have this so high - you'd almost have to go out of your way to find FETs with 8 mOhm Rds. There are tons of FETs designed for motherboard switching power supplies that do much, much better. It seems more likely there's some other issue, like V_gs dropping on the high side FET, or insufficient gate current, or possibly even thermal issue.

[Chak]

Did anyone try using such a compact array? I'm worried about how hot the center two are going to get if they are mounted that way.

We ran 4 Victor SPs side by side with a footprint of 4.82" * 2.5" * 1.22" with no problems. However, the motor controllers were staggered in a up-down-up-down pattern and raised about 2" above the electronics board, which could've helped with cooling.

[Michael Hill]

17 mOhm Rds on is really high for this type of motor controller. At 30 amps, which FRC robots will draw for a few seconds, you're dissipating 15.3 watts in your FETs!

It seems weird to have this so high - you'd almost have to go out of your way to find FETs with 8 mOhm Rds. There are tons of FETs designed for motherboard switching power supplies that do much, much better. It seems more likely there's some other issue, like V_gs dropping on the high side FET, or insufficient gate current, or possibly even thermal issue.

I agree it's too high. Looking at the pictures more closely, it looks like this is the MOSFET: http://www.nxp.com/documents/data_sheet/PSMN1R0-30YLD.pdf All looks fine to me (in fact, I think it's the same as, or at least related to, the one used in the Talon SRX as shown in this teardown: http://imgur.com/gallery/2xqoU). The current sense resister seems odd to me. I'm trying to make sense of the marking. The SRX uses a 0.5mOhm sense resistor (M50), but the SD540 has a marking of "50m", which doesn't make any sense to me since the math wouldn't add up (50mOhm). Is there an alternate interpretation of that marking?

Large picture of the SD540 here: https://images-na.ssl-images-amazon.com/images/I/81X6vyE3RyL.jpg

[Jared]

I agree it's too high. Looking at the pictures more closely, it looks like this is the MOSFET: http://www.nxp.com/documents/data_sheet/PSMN1R0-30YLD.pdf All looks fine to me (in fact, I think it's the same as, or at least related to, the one used in the Talon SRX as shown in this teardown: http://imgur.com/gallery/2xqoU). The current sense resister seems odd to me. I'm trying to make sense of the marking. The SRX uses a 0.5mOhm sense resistor (M50), but the SD540 has a marking of "50m", which doesn't make any sense to me since the math wouldn't add up (50mOhm). Is there an alternate interpretation of that marking?

Large picture of the SD540 here: https://images-na.ssl-images-amazon.com/images/I/81X6vyE3RyL.jpg

I think R50M is 0.5mOhm. It's kind of a weird label, but it's the only thing that makes sense. http://www.tai.com.tw/index.php/en/product-3/resistors/current-sensing-chip-resistors/34-product/resistors-products/current-sensing-chip-resistors/111-rlf

What's a current sense resistor doing here though? I didn't know it needed to measure current.

Also - I just noticed it has 8 FETs (two in parallel everywhere), compared to the Talon's 4. Kind of odd.

[Hitchhiker 42]

Did anyone try using such a compact array? I'm worried about how hot the center two are going to get if they are mounted that way.

Our four Talon SRX's for our drive were mounted side by side very closely and we had no problems with heating. It seems that the SRX's are very good about low heat loss.

[NickE]

Did anyone try using such a compact array? I'm worried about how hot the center two are going to get if they are mounted that way.We ran 7 Talons in a row with no issues.

[frcguy]

Our four Talon SRX's for our drive were mounted side by side very closely and we had no problems with heating. It seems that the SRX's are very good about low heat loss.



Same. We did that and even had them mounted under another plate and there were no issues.

[adciv]

What's a current sense resistor doing here though? I didn't know it needed to measure current.
Alternate theory: It's a 0.5 Meg ohm and the purpose is to bleed off the capacitor when not in use.

[Michael Hill]

I'm wondering what the copper thickness of the board is. I see in the SD540 picture that solder is being used to lower the impedance of the traces (the blobs of solder you see on the copper), but it looks a little dodgy in some places (there are some places where no solder is on the traces like next to the nearest MOSFET). Also, if someone has a picture of the other side of the board, that would be cool to see.