100+kW Motor Controller

[moffy]

About regen, you need somewhere to dump the energy otherwise your DC bus will go excessively high. In diesel/electric locomotives they use massive fan cooled resistor banks, for yours, if battery fed you would need a safe means of getting the energy back into the battery.

[marcos_]

About regen, you need somewhere to dump the energy otherwise your DC bus will go excessively high. In diesel/electric locomotives they use massive fan cooled resistor banks, for yours, if battery fed you would need a safe means of getting the energy back into the battery.

Regen is only dangerous if you are operating the machine at a speed that produces a BEMF higher than the battery voltage. In a nissan leaf for example I think its ~120kmh.

Below that rpm, you won't have an uncontrolled energy flow situation, since you can clearly define the maximum regen current limit and the act of regen requires a well coordinated firmware effort. Without PWM switching no current flows into the battery. (attached is the GUI to set this)



If you are above said rpm, you better be prepared for some fireworks, because in a fault situation the motor will dump an uncontrolled amount of energy into the battery. If the powerstage and battery can handle that current, and the vehicle and passengers can handle the huge deceleration, no worries! At least the battery will clamp the voltages on the system to safe levels until speed decreases to BEMF=Vbatt.

If not, you have to embrace the possibility of blowing the battery fuse or tripping the main contactor... now you exchange uncontrolled currents for uncontrolled voltages and the IGBTs will have to endure whatever BEMF voltage the motor generates. If your BEMF at 100kmh is 400V, then your BEMF at 200kmh could be 800V. You will *really* hope the designer chose at least a 900V IGBT. If he chose a 650V device you will have instant, regretful fire.

The BEMF comes from the magnets, thats why Tesla can use 650V IGBTs, an undriven ACIM motor won't produce any BEMF, even if its spins at a bazillion rpm. And when they switched to permanent magnet motors, they now needed an extra voltage buffer: enter wide bandgap SiC mosfets. Beside havin less switching losses, they can easily achieve 900V rating, so the introduction of PM motors and SiC drives are tightly coupled.

[marcos_]

This week we added Field Weakening and MTPA support to the vesc firmware and GUI in our github repo.

Here is a writeup about that:
https://hackaday.io/project/164932-axiom-100kw-motor-controller/log/162931-field-weakening-support

FW has been probably the most requested feature of the vesc platform for years, as it allows to operate the machine in the constant power region.



It was just simply not possible to go beyond the constant torque region, as torque would drop to zero.
Not every motor has a flat constant power region, but a good automotive motor will.

[Yansi]

Very nice!

If I may ask, is the FPGA completely necessary? It seems like the MCU is doing the PWM (and possibly the calculations ?). All I can really think of other than that is the encoders, but there are many ARM mcus that can directly interface to incremental encoders nowadays.

Thanks!

Incremental encoders is already supported, but for high performance you want to know the rotor position from the start, otherwise you can't apply full torque at 0rpm, in a launch situation for example. That can be done with resolvers or high speed absolute encoders, a common comm protocol for those is BiSS which I'm not confident can be managed by the already loaded cpu.
The other potential usage is fitting 7 delta sigma demodulators to digitize the 4 voltages and 3 currents directly at the busbars, without any analog signal path. This way everything stays digital, filtering can be tweaked from firmware, no drift, no offsets, etc. We are already using sensors that come with delta sigma variants. In this scenario all motor signals are being input directly to the FPGA and output PWM is an fpga output,so  you could run the control loop at ludicrous frequencies inside the fpga and using the arm mcu as an application processor.

Also the fpga is actually not much more expensive, early versions had a bunch of discrete logic gates doing the basic protection job and the costs sum up, I think overall its a $3 difference that gives you the opportunity to do interesting things.

and afaiu in safety related systems FPGAs are sorta seen as "hardware" and considered more reliable than software, which make sense considering
the many many permutations of what happens in a cpu once you throw in a bunch of interrupts

Now go and tell that to those stupid  formula student germany (FSG) rules makers.

[marcos_]

Now go and tell that to those stupid  formula student germany (FSG) rules makers.

May I ask what's the problem?

[Yansi]

Nothing personal, of course if you thought it was! Just ranting around, as I was involved in formula student for some years and last years changes in rules were downright under-thought.  One of them is to forbid any PLDs as devices handling safety related things.

[ejeffrey]

The problem with putting safety interlocks or other features on an fpga is that it is too easy for them to be accidentally removed during synthesis.  It isn't really a problem in a production / product environment but can be a danger in a development environment like a student project

[marcos_]

The problem with putting safety interlocks or other features on an fpga is that it is too easy for them to be accidentally removed during synthesis.  It isn't really a problem in a production / product environment but can be a danger in a development environment like a student project

+1. No one wants to be responsible of a student injury, especially if its avoidable with a simple rule.

[Yansi]

Synthesis will not remove anything, there is a post synthesis simulation of the design and real HW tests after anyway. So this comment is I think pointless.

I would not like to go into details in this thread,  but it is not only about "real safety",  but also repression of custom built HW, which in direct manner is a violation of it being an engineering competition. What they want you is to just slap together bought off-the-shelf parts, which is what most of the teams do anyway, so why be bothered with others, sigh.

To stay on topic, with the motor controllers: if I remember right what I have been told, you are required to FUSE every output of a custom built motor controller, unless there is a HW based over-current protection. So good luck designing a custom HW for I²t protection circuit, or good luck with finding space and cooling air to install for example 12 fuses for a quad motor controller.  (Of course, off the shelf motor controller does not require the fuses).

So where's the safety in this one? If a team can spin four motors using custom built HW and SW, they likely know ho to code a I²t integrator.  The protection can also be set wrong both on the off-the-shelf one and on the custom built one. So fusing is just solving half the problem and forcing some to be disadvantaged.

[slloyd]

on subject of fault protection, Axiom controller has multiple levels of protection when it comes to current monitoring. for current there is slow moving average, I2t so to speak to watch for overload conditions and throttle back power. it takes feedback from heatsink temperature measurement as well. user configurable. this is in the works.   what is already coded and ready for use is software has a threshold for phase current which will limit power or trip depending on the threshold and then hardware protection for fault current which does not rely on software, it just shuts down the gating. threshold for hardware protection is rather high because its meant to protect against short-circuits, not overloads, here i'm talking about phase current out to the motor. 

there's actually a 4th protection which is for short-circuit where two adjacent IGBTs turn ON at the same time for some reason and the DC link cap shorts to ground.  this is fire inducing failure so we have a detect and shut-down in less than 10us and that's over the wide temperature range too.  we've tested this a lot.. just shorting the output together during operation.  starting up into a dead short.  over and over.  devices survive, no fire. also, we take into consideration when you have a shoot-through and the desat circuit kicks in to shut down the drive in <10us, there is .. after the immediate shut-down .. a very large voltage spike simply because of the very high current being suddenly extinguished and the parasitic inductance in the copper bussing that stored energy during the extreme amps.  the voltage spike after is something designers might forget about; thankfully Axiom didn't. 

actually, there's a 5th level of protection too now that i'm thinking about it.  Axiom monitors for circulating currents and adjusts the operation to compensate and take more action if needed.

[slloyd]

i should also mention that Axiom is for power levels beyond your typical quad copter.  100kW... that sort of system will have its own pyro fuse, but its external to Axiom control board. 

[marcos_]

We are ready to release the Axiom datasheet!

Next Monday all our subscribers will have access to the datasheet through our newsletter.
To subscribe to the newsletter, sign up here!

http://www.powerdesigns.ca/newsletter/

It will be only available to the subscribers for quite a while until we let the file publicly available for download.
Important announcements will happen there as well, so we hope to see you guys in the list.

Cheers!

[marcos_]

Axiom finished on top of the hackaday prize bootlstrap leaderboard!


There are some interesting updates in the project page, and more to come!
https://hackaday.io/project/164932/logs?sort=newest



Cheers