Re: SD540 Motor Controller
 

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?

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

What is the lowest you have witnessed in a match?

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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:



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

http://wpilib.screenstepslive.com/s/...g-current-draw

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

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

<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.

Re: SD540 Motor Controller
 

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!

Re: SD540 Motor Controller
 

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.
.

Re: SD540 Motor Controller
 

Citation needed.

Re: SD540 Motor Controller
 

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

What filter are you referring to?

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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?

Re: SD540 Motor Controller
 

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).

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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).

Re: SD540 Motor 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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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/7...haracteristics

Re: SD540 Motor Controller
 

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?

Re: SD540 Motor Controller
 

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...

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

Not a stupid question at all :). I had noticed this as well and wondered too.

Re: SD540 Motor Controller
 

Wow! Go on vacation and lots happens.

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.


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?

Re: SD540 Motor Controller
 

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/7...540-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

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

Which motor control microcontroller is buried in there?

Re: SD540 Motor Controller
 

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

Graph link

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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

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

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.


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.

Re: SD540 Motor Controller
 

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-

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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/...un1offset=-240

Perhaps that role being unfilled contributes hard to say.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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. 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 page (would have liked to see photos and part numbers of test assemblies, but very, very good).

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.


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-

Re: SD540 Motor Controller
 

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.



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.



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

Re: SD540 Motor Controller
 

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)


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-

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

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).

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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...

Re: SD540 Motor Controller
 

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?

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

Indeed they have. Thanks for the background info!

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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!

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

Per http://www.firstinspires.org/robotic...-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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

Here is a link to that review.

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

-Mike

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

Pictures?

Re: SD540 Motor Controller
 

Were they 3D printed or were they molded?

Re: SD540 Motor Controller
 

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-s...roller-for-frc

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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?

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

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_sh...N1R0-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....1X6vyE3RyL.jpg

Re: SD540 Motor Controller
 

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/p...istors/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.

Re: SD540 Motor Controller
 

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.

Re: SD540 Motor Controller
 

We ran 7 Talons in a row with no issues.

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

Re: SD540 Motor Controller
 

Alternate theory: It's a 0.5 Meg ohm and the purpose is to bleed off the capacitor when not in use.

Re: SD540 Motor Controller
 

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.