Building the Best Controller

[oldswamm]

First, I know I,m a noob.
Rather than trying to (farther) prove it here, I intend to start a topic 'Noob questions, 2 motor stump crawler ebike' this evening or tomorrow, in which I will do so. But, for example, to the best of my knowledge, I've never even SEEN an EV.... Should make me unique in this crowd.
In spite of my obvious ignorance of the subject, I feel the following points should receive consideration. (I do have experience with Microchip PIC design.)
I'm a devote of versatility.

Kingfish: I assumed traction control would be easily selectable. I expect guys like Luke, who are building the 200v4000a version of this might want to shut off anti spin occasionally!

Eric: The MCU is the easiest part of the project to design and build, yet it's where the true versatility of the project is centered. It should be a careful custom design in my opinion.

For the MCU I would suggest keeping it as small and simple as you can and still have 6 pwm outputs and enough I/O for most people.
THEN, incorporate a simple expansion buss so multiple boards could be stacked. 2 identical boards stacked, one programed as a slave, would work for 4 3ph motors, or 2 6ph, or?. 3 boards for a 6 x 6.
Also other custom 'daughter' boards could be stacked as people think of new needs or functions. Can you imagine anyone needing a daughter board for an extra 24 thermister inputs? (Luke) I thought of a couple other possible daughter board applications while I was at work yesterday, but can't recall them this morning.

The power supply board could possibly be included in the stack (less wires), and maybe even lower powered output boards. (I would expect the fets in high power setups to be on or near the motor(s).)

There should be an input for Dallas Semiconductor's 1 wire bus so we can use DS1820 type temp sensors. Up to 256 can be connected to one input. I like to epoxy temp sensors everywhere.

Consider a serial interface to the handlebar controls.

If you use a commercial display as someone suggested, would you be able to directly interface to it, for example to show fault and error info? Also, could it be modified so it could be used for changing parameters in the field? It seems to me that we either have to design our own readout/control interface, or modify a commercial unit. IMHO it's easier to start from scratch.
Other than housing, it wouldn't be hard to design and build, and if we went with serial to the controls it could act as the handle bar end of that interface.


I would see the final version of this using 3 different driver setups.
1: Seperate boards for each phase and say 80v+ and 50a+.
2: A single board with the drivers for external fets like Luke is working on.
And 3: A single board for all 3 phases using say 50v and 40a max. Don't forget the little guys like me who just want more control over the smaller setups. If you guys like this controller for your super machine, you're going to want them on your wife's ebike and the kids trike, just so you have full access to the programing. This won't be the first developed, of course, even if it is easiest.


For the power board, if you switched the Batt v through a small toroid transformer for the 12v preregulation, pretty much all the HV boys would have to change would be the transistor, a resistor or two and add more turns to the primary.


Kingfish: Could you list some of the other open source controller projects you're looking at, and some of your ideas how this should be handled differently.

And thanks for your efforts here. I don't envy you, and hope you don't burn out before the project becomes self sustaining.

Bob

 

[rhitee05]

Eric: The MCU is the easiest part of the project to design and build, yet it's where the true versatility of the project is centered. It should be a careful custom design in my opinion.

I respectfully disagree. The software is where the true versatility of the project is centered. 99% of the functionality will stem from either custom software or from the hardware on the FET and power supply boards. We have all the flexibility in the world to choose whatever platform and whatever specific MCU part is best suited for our needs. The MCU board design is just a matter of mundane (but important) items like a crystal oscillator, power supply buses, decoupling caps, and so forth. It's a much more efficient use of our time to buy something off-the-shelf and we don't lose any useful functionality in doing so. All the useful I/O expansion capability - 1/2-wire buses, serial ports, etc - is just a matter of making spare pins available on a header, which any reference board will do. Any hardware functionality will live on the other two boards.

 

[oldswamm]

Hi Eric,
Not trying to start an argument with you. :wink:
Not up to us anyway, were just making suggestions.
As to time, that's where a project like this shines. Those of us who aren't qualified to work on the fet drivers, or who hate debugging software, can work on the more mundane stuff.
And I agree that it's the SW that's the heart.
Bob

 

[Kingfish]

Quick status:

• Discussions ongoing about the MCU features.
• We are nearing the end of feature contributions; one day remains.

Addressing the Replies:
Generally speaking, the function and benefit of having the Controller split into three parts implies that each module can exist independently, with its’ own revision track, and derivation:

<Soapbox: ON>

It is implied by virtue of the all-encompassing scope that no one-size fits all when we include all-EV, and that variation must be supported firstly by division of the primary functions, which are Power Supply, Brain, and Drivers, and secondly that the mating pieces be completely compatible with each other regardless version or derivation. Therefore wisely WE shall proceed to define The Standards for this interdependent modularity and do so with progressive anticipation! The best way to feed that anticipation is to retrieve a Feature Request :wink:

I believe that Version 1.0 will be our test of unity, that we can work together with our diverse backgrounds and training, that no one person has the correct answer to everything, that through collaboration and compromise (yes – compromise!) we shall prevail as friends to build an assembly which meets the majority of our Feature List.

That said please allow me to expose my backside and front towards all the arrows you will shoot when I say that Version 1.0 should at least meet the existing criteria for a typical 6FET bike controller – at 75V, 40/50A right out of the box. If you got one of these systems and built it up or down as you like, the PCB should support a BOM that builds a rock-solid entry-level ebike controller which handily replaces the imports AND provides complete customization of parameters in your hands: YOU ARE THE BOSS! 8)

Imagine:

• We could design light-duty versions.
• We could design heavy-duty versions.
• We could augment them in ways that are just now being described; motherboards, daughterboards, 3rd-party devices sharing an integrated digital bus (USB/Bluetooth, something’ else??)
• Wouldn’t you WANT to design beefy variations of each module that could take us down that playa track at Bonneville?! Allow me to stoke the noble ambition: Make a profound world statement, built by the best minds, on a public forum, to be the very best! And then prove we can do it again with Version 2, 3, 4...

Keeping it simple:
The issue here is not whether $5 cap is worth the cost, but whether having that cap keeps the pilot from having a heartbreaking equipment failure in the middle of the flight. WE are here to design the BEST (with reasonable fiscal responsibility).

Our experiences are varied; we know what we know, and we have to be careful with that information. I struggle with my ego constantly, :? however my curiosity always wins out because I want to know what other people know, and I can’t help to babble up and share that in camaraderie. I am also ready to accept what I know could be mistaken - and hopefully through no fault of my own, but if it is – hey I’ll take ownership.

This project isn’t about I, Me, Mine: It’s about Us, We, Together – look what we built, and we’re here to help get you out of that polluting monstrosity that is tearing at the fabric of our freedom.

So now that you’ve heard my idealistic dogma this is my rallying cry:
You’ve got one day left to contribute features! Then we will close the Feature Spec, then we will ask for Stakeholders and Contributors to identify themselves.

<Soapbox: OFF>

What’s a Stakeholder, and what’s a Contributor:
A Stakeholder is “one who is involved in or affected by a course of action”, although a more complete definition can be found here.

A Contributor is one who volunteers time, talent, or supply; they are the workers bees to the hive, the solders to the fort. They are typically less involved in management, yet provide the foundation and labor upon which the achievement rests.

It is my hope that people will come forward and participate; success depends upon it.

With that, I am really looking forward to cracking open these little and big challenges, and especially increasing my acquaintance with kindred minds 8)

Think: Bonneville!
~KF

 

[rhitee05]

Not trying to argue, either. No hard feelings!

Your point is absolutely correct if we get to the point of wanting to make the package smaller or the design more optimal. Any reference design is bound to have stuff we won't need and be a larger size than it really has to be. Designing a custom MCU board is probably a great idea for V2.0.

If you want to spend the time designing the board, I say go and have fun.

KF: Well said.

 

[liveforphysics]

How about the ability to have the circuit tuned for a wide (eg, 8khz-40khz) pwm freq through a simple programming change.

In the programming software, have a setting to input the inductance and resistance of the motor + wires, and have it use a simple look-up table to find the optimal pwm carrier freq to use for that motor.

This might be getting kinda bloat-ware-ish at this point, but for measuring the motor resistance, either for letting the controller tune itself to the motor, or simply doing a motor+wires health check up, with the addition of a single decent A/D setup to read the voltage across any one of the phase leads, it could run a little split second sequence where it energizes that coil fully for 2mS (or whatever it takes to get a stable voltage + shunt reading), and it could determine that phase's total system resistance from this split second reading. Once it knew what it reads with the motor cold, it could be used at any time the motor is not turning to take a really useful winding temperature measurement. This is a hell of a lot better measurement to know than the typical thermistor glued to the stator iron measurements. It also would give temperature measurement ability to any off-the-shelf brushless motor, with out the liability of additional parts to fail, or little wires to snake through the axle.

It would only take a simple look-up table of the % increase in phase resistance.

-40°C 0.7490
-20°C 0.8263
0°C 0.9035
20°C 0.9807
25°C 1.0000
40°C 1.0580
60°C 1.1352
etc etc

You could have the controller setup to back the power down a little when it see's the winding resistance increased by 25-30% or so (depending on the insulation rating of the wire the motor is wound with).


I also think the self-learning hall sequence thing Justin did on his super cool controller for his e-bike across Canada trip is a no-brainer of an idea to use. Wire the motor up in any combo, spin the wheel in the right direction, Poof! The controller now knows the hall/phase sequence. No more fiddling around trying 20 combos.

 

[oldswamm]

Shouldn't the controller be able to have a learning mode where it could determine the ideal PWM freq and optimize the timing.
We have the pulse width, and current, and if nothing else, the operator could indicate the vehicle is on flat and level, at which time the controller could play with the settings and determine the range between measurable increase while holding a constant velocity. And of course we would use a statistical average of many samples.

 

[fechter]

If the controller is going to have a decent (accurate) shunt, then there's no reason not to have some CA-like functions like AHr measurement or at least an accurate battery fuel gauge.
The little CellLog8 units really impress me for a $18 part. The display is small, but can show a lot of useful information. Some kind of handlebar/dash display would be a nice feature, possibly optional.

To do pulse-by-pulse current measurement using shunts will take some pretty beefy shunts. I'm all for them, but what part to use? The chinese controllers all use chunks of resistance wire. Not precise, but cheap. Hall effect current sensors may be more practical at very high currents, but they are expensive and sort of slow to respond.

 

[liveforphysics]

A dedicated rpm based on-off output that has a flyback protection diode with at least 2amp control ability. For people doing series/parallel switching it would cut phase current for a split second while it toggles the relays at the optimal point, and not enable it to switch back until the bemf is below 1/2 of the fet rating, so it doesn't blow the controller from an accidental switching back too soon.

For delta/wye switchers, it does the same the same things, and makes the needed hall signal timing corrections.

Also, a throttle and rpm based look up table used to decide hall timing. Wanna be crawling along slow? It retards the timing. Need maximum speed to pass a car? It advances timing to increase Kv.

 

[texaspyro]

Wanna be crawling along slow? It retards the timing. Need maximum speed to pass a car? It advances timing to increase Kv.

Points... distributor... vacuum advance. Don't need no stinkin' lookum up tables. Now where did I put that flow bench?

 

[rhitee05]

Using the winding resistance as a temp sensor is an interesting idea. I suspect it would be tricky to implement, but would be a nice feature. It would be a pretty noisy measurement, but since temp doesn't change very fast you could take a lot of samples and average. I think you'd also need to know BEMF (to determine the resistive voltage drop across the motor), but using a single ADC you could measure total drop when the phase is active and BEMF only when it's not, average over many commutations, and use the current shunt measurements to find R.

Timing advance would be nice, or you could just implement field-oriented control and let that do the work for you! FOC can also do field-weakening to decrease Kv. There might be a short-cut way to do it with just one, but I think FOC generally requires 2 current sensors to measure all 3 phase currents simultaneously, so that would have to be included in the hardware.

I can think of several reasons why it might be useful to provide a relay drive output. Besides series/parallel or delta/wye switching, you could also use it to control an auxiliary power supply, lights, cooling fan, etc.

 

[oldswamm]

Luke:
Couldn't the processor accomplish the same thing as you would in measuring the inductance and R of the windings to set the pulse freq by using the learning experiment I mentioned before?

Install the motor and use it. When the controller senses a steady state (Batt I, pw, and rpm constant), it tries a different freq. After everything stabilizes again at the same rpm, it measures that current, then returns to the original freq and takes a measurement to be sure conditions haven't changed. If we then operate at the freq that produces the lowest I, haven't we accomplished our purpose?

I can't see why the same technique can't be applied to the hal sensors.

First measure the time between each at a steady rpm. If it's not the same for all of them, set a constant for the one that's off.
(Actually, if the speed isn't changing, we really only need one hal sensor, and can calculate the rest. Even speed change wouldn't make much difference in one revolution, and we COULD even allow for delta r in our calculations. A digression, sorry.)

Then let the processor play with the timing at various speeds.
Shouldn't the timing that gives the lowest current at a given rpm and a steady load be the one that should be loaded in the table you mentioned? Or rather to alter the defalt table.

Many samples in both cases to smooth out error.

All this would take place in the background, just like your EFI car. As you drove it, it would 'run' better and the 'fuel' economy would improve.

I might be missing something. I admit my ignorance of motor tech. Mostly I'm basing my ideas on what I've picked up here and in '12kw RC'.

I'm trying to imagine, 6 colossus, with each phase brought out separately to 6 pair (so you could use 3 fet drivers ea, series/parallel, AND Y/delta switching). That's 54 drivers, and a dozen 6 pole dbl throw relays (I think, I didn't draw it out). Shudder, I hate relays, even with no load switching......

Bob

 

[texaspyro]

I'm trying to imagine, 6 colossus, with each phase brought out separately to 6 pair (so you could use 3 fet drivers ea, series/parallel, AND Y/delta switching).

Actually, a 6 wire connection to the motor can considerably simplify some designs. You drive each phase with its own H-bridge. The nice thing is the high side fets can be static. They only need to change state when reversing or stopping the motor. Only the low fets have to chop at frequency. I've even seen it done with the high side done with (egad) relays...

 

[oldswamm]

Eric:
Re our earlier discussion: I wasn't suggesting a custom mpu till the drivers and PS are worked out. Like so many other things, it's just something to keep in mind as the specs are worked out.

Looks to me like FOS should be implementable in the final versions at least. (Had to google it) I take it this isn't the technique other controllers use for 'sensorless' mode. Couldn't be, or they would have to make you include the exta shunts. Wouldn't it still have the same startup problems?

As to the 'sense wires soldered to a length of cable' type shunt, If done properly, and carefully calibrated they should be as accurate and consistent as a regular commercial shunt, and if your using the cable from the battery to the driver, you save a couple connections (to the shunt).

Yes many extra outputs. If they're open collector (MOSFET?), we can drive relays or things like fans directly.

 

[oldswamm]

I'm trying to imagine, 6 colossus, with each phase brought out separately to 6 pair (so you could use 3 fet drivers ea, series/parallel, AND Y/delta switching).

Actually, a 6 wire connection to the motor can considerably simplify some designs. You drive each phase with its own H-bridge. The nice thing is the high side fets can be static. They only need to change state when reversing or stopping the motor. Only the low fets have to chop at frequency. I've even seen it done with the high side done with (egad) relays...

I can't remember if you are one of the people discussing the colossus motor or not.
See 'Electric Vehicle Technology/Motor Technology/12 KW RC Motor'.
A bunch of guys have spent the last month or so trying to figure out how to drive this motor (for a reasonable price). One idea was to bring out each phase as 3 separate windings, and use 3 lower amperage drivers. My tongue in cheek example would require 6 PAIR for EACH phase, a total of 72 wires from each motor. But it would be something!

 

[rhitee05]

No, field-oriented control (FOC) is not the same as sensorless control. The basic idea of FOC is to measure the current through each phase (measure 2 directly and calculate the 3rd through KCL) and then use some fancy math to convert that into a coordinate system called d-q. The current on the q-axis is at a right angle to the magnetic field and is what generates torque. The current on the d-axis is aligned with the magnetic field, so does not generate torque. The math is messy, but once you have it worked out it's very simple to make a closed control loop which will control torque by setting the q current and tried to keep d current to zero. This effectively takes care of the timing adjustment. In a more advanced version, you can use the control loop to set the d current to a non-zero value. Since d is aligned with the magnets, it can either strengthen (+d) or weaken (-d) the field of the permanent magnets, giving you control roughly similar to that of a separately-excited motor (allows you to adjust Kv up or down a limited amount). It's a really worthwhile goal, but I think would require a lot of software development and testing.

I think if you want the motor to self-tune the PWM frequency, what you really want to look at is the current ripple, not necessarily the average current. A really fast current sensor or a sort of max/min detector could do that. If you have that capability, I wonder if you could make the frequency variable based on the current ripple. The ripple would be highest at startup when there's no BEMF, so you'd want the highest frequency. As you speed up, you could back off the frequency to keep ripple at some threshold level. Having a lower PWM frequency would lower your switching losses. That would be good for cruising, but wouldn't help much under low-speed, high-current conditions.

 

[oldswamm]

Oh, I like the idea of being able to play with the field strength, if only because I like to do what I'm not supposed to be able to!

Measuring the ripple shouldn't be hard if the idea was deemed worth while, just an active filter off the buffered input from the shunts. Probably a balanced input to keep the noise reasonable. Any idea how much ripple we could expect.

If we could do it from the current shunt that will almost certainly be there, without any additional hdw, it would be nice. Seams to me that if I can't measure an improvement in the shunt, it isn't very significant. Also, we can use sampling to improve resolution, and just set up a table. Using the ripple would give instantaneous feedback, but things shouldn't change should they? What I mean is, once we established a table of rpm/freq we shouldn't need feedback, the controller would be calibrated to the motor.

 

[Arlo1]

How about a 3d timing map? Like one you can adjust on the go?

 

[oldswamm]

And/or multiple stored tables (maps). Have to be if it's going to satisfy "everyone"

 

[Kingfish]

Quick status:

• Discussions ongoing about the MCU features, including auto-calibration.
• Also discussed were passive heat detection schemes.

At this time we are closing the Feature Request for Version 1.
Any new features – barring some phenomenal technological breakthrough - shall go to the Version 2 stack. I will need about a day to go through the last posts and document what we have and flesh out the Quick Specs.

OK. Moving right along – allow me to hit the high points:

• We all seem to be in agreement on three modules sharing a common interface between.
• MPS – Main Power Supply (Battery Interface: Regulation and Auxiliary supply)
• MCU (Microcontroller/brain, software interface, and associated hardware)
• Driver (Motor Interface: FETs, PWM out to Motor(s) in Trap or Sino waveforms, Regen, as associated hardware)
• Firmware/Software (tentatively identified as the 4th Module; needs to be flexible and robust)

Where to Next?
Allow me to describe the Big Picture in one paragraph…
We now form teams sorted and based upon our experience. The teams will go through the specs – deciding on what to keep and what to defer; this discussion shall be public on their own thread. Then the real work begins with agreeing on the circuit designs, bread-boarding, cutting prototypes, and stuffing evaluation units onto our EVs to validate the designs. If there are no other changes we lock down the Version, crank out production and celebrate. Wash, Rinse and Repeat for deviations and new versions.

Make sense?

I like a hierarchical organization structure where there is one person at the top answerable to all, with lieutenants that manage the divisions of work. If we go back to the Stakeholders discussion, it would make sense that each of these individuals would need to have a vested interest.

Virtual Sign-Up Sheet:
Calling all volunteers! Let us then commit to signing up for working a module of your choice; specify which Module best fits your expertise. When you sign-up you are instantly a Contributor. A Stakeholder is someone with capital: monetary, manufacturing, production, professional services and so forth. If you want to be a Stakeholder, please indicate with an -S next to your handle.

Teams will form around each Module. The Teams will then elect a leader whose responsibility is to drive the issues to conclusion.

Teams by Module:
You can virtually sign up by just replying to this post, and selecting a Module/Team. Listing your expertise is optional. I will place the consolidated volunteer list the Project Description & Status in the Technical Reference section; please contact me if you wish to change your status or team at any time.

MPS – Main Power Supply
Kingfish –S; offering PCB design

MCU
Kingfish –S; offering PCB design

DRIVER
Kingfish –S; offering PCB design

FIRMWARE/SOFTWARE
Kingfish –S; programming on multiple fronts, documentation

Continuance:
Let’s just give a bit of time for people to respond to either the direction of my comments, to sign up, and to make sure we’re all on board here.

Then if the lamp of desire is still lit, we can branch this thread into 3 or 4 parts leaving this as the master-project discussion

Thanks for your participation! KF

 

[nomad85]

I would like to help.
If i'm being honest most the comments in this thread are greek to me.

I am computer savvy, and learn quickly, if there are any simple parts of the modules I could learn the basics and help out.
I also have batteries and motors I don't mind subjecting to harm, so I could help with testing the prototypes if need be.

 

[rhitee05]

I can think of two possible ways to measure the current ripple (probably others as well).

One would be to just use the existing current shunt and ADC. The ADC would be required to be somewhat fast (1-2 MSPS would be good) and the amplifiers would need to have bandwidth to match. The disadvantage here is that to get the higher bandwidth, you'd have to sacrifice the noise canceling effects of a low-pass filter. The best method is probably to sample the current as rapidly as possible, then take the min, max, and average. Min and max should give the ripple and the average would be the usual current measurement - averaging should help cut the noise back down. Doing all that sampling and math might take some processing overhead, not sure how much.

The alternative would be dedicated hardware. It's very easy to make a peak (max) detector using an op-amp and diode, and by reversing the diode you get a min detector, both taking their input from the existing current amplifier circuit. Add a third op-amp to subtract the two and provide the signal to an ADC. I suspect (can't prove) that the analog version might be a little more accurate than the digital one above, but it would require a quad amp and an extra ADC on the MCU. You could use the 4th amp in the package as part of the current amp.

As far as FOC, it's really a great method if you get the implementation down. Besides automatic timing control and possible field-weakening, you also automatically get a torque-based throttle, since it controls the current. It might take a while, but eventually I'll get around to making use of it.

 

[amberwolf]

IR just sent me an email to announce some new integrated drivers good for automotive stuff:
http://www.irf.com/whats-new/nr100825.html
Would they help any of this project?

 

[Kingfish]

This is an interesting turn of events :?

Either there is little will within the Community to do this or perhaps there is another reason yet mentioned...

Regardless I am soldering on; there are mountains to climb and this is only one… range of them to cross. Contribution is encouraged
I shall continue to post here from time to time on the discoveries and progress.

The lowest hanging fruit is the Power Supply and that's what I'm going to tackle next.

Onward through the fog, KF

 

[amberwolf]

There is a really big holiday in the USA coming this weekend; perhaps many that were participating are preparing for that. (or like me, working a lot because it's coming up and lots of people are out there shopping more now in anticipation of it).