Paul & Sabrina's cheap DIY 144v motor controller

[Greg Fordyce]

Originally Posted by harlequin2

I've ordered one of these things too. Now thinking about just what/how to use it.
Presently using a NetBook running RTD Explorer.
I'd like to hear your ideas on what you are doing with the display and see if I can help out with the overall project.

My idea is to duplicate RTD Explorer on this platform. Originally I was looking at an Arduino for this and started the CougArd Explorer thread about a year ago. I like the name, so even though there isn't an Arduino in sight I am going to keep it. I also want to interface my bms to it as well, reading and sending serial data over the second serial port on the display. Another idea is to use the battery amp limit command to start reducing battery amps as the pack gets low. This could be made to work on one of the displays GPIO pins, so any bms or other warning system can signal on this pin a low battery warning and the display will start to progressivelly limit battery amps which will slowly reduce vehicle speed. I will post further work on this in the CougArd Explorer thread. Hopefully have some rough code by the end of the weekend, but sadly have to wait till my display arrives before I try it out.

I'm always open for any help on this project.

Greg

[jyanof]

Originally Posted by Greg Fordyce

Really it's just down to processor time vs. accuracy. Unlike a desktop pc, most micro-controllers are limited in their math functions, this one is signed 16 bit integer maths. The look-up table approach will sacrifice some accuracy for speed and also ease of coding. I did have a play with the equation y = 0.0000007 * x^3 - 0.00081698 * x^2 + 0.40709038 * x - 41.63772692 in openoffice and got a graph that looked just like yours! so I can use that to create a look-up table for temperature conversion. One question, what is the equation R^2 = 0.99705769 for?

ah, ok - i forget what micro you're using (if you mentioned). i put together a charger with an atmega16. I used the above equation and had all of the control software interrupt based. thus, whenever the main program got to the temp calculation, it was kinda like it was doing that in the background. not sure if something like that will work for what you're doing, but maybe it's an option. I just thought it was easier than coding in a lookup table, but it's definitely not faster.

The R^2 thing is a correlation factor (or something like that). the closer to 1.0 it is, the closer the curve fit is to the individual data points.

[Greg Fordyce]

The display is made by 4D Systems. There are no interrupts in their programming language, really it's pretty hopeless for anything other than graphics, but the graphics functions look pretty neat. So look-up table it is.

[DJBecker]

Originally Posted by Greg Fordyce

The display is made by 4D Systems. There are no interrupts in their programming language, really it's pretty hopeless for anything other than graphics, but the graphics functions look pretty neat. So look-up table it is.

Does it have native floating point?

If so, the polynomial approach is good. Otherwise the linear interpolation is a much better approach. The ATMega is painfully slow with floating point calculations. Other similar platforms will be almost as slow.

I know what you mean about languages that are easy and look good, but are just a little too simple. My first Arduino program took about five minutes to write, and worked the first time. But immediately after, I was ready to risk overwriting the Arduino bootloader to try out a C program. (It didn't break the bootloader.)

[jackbauer]

Something i've wanted to do for sometime has been to add motor rpm feedback to the controller. Does the micro have sufficent resources left to do this in software? I'm playing with a little frequency detection circuit based on an lm2917.

[DJBecker]

Originally Posted by jackbauer

Something i've wanted to do for sometime has been to add motor rpm feedback to the controller. Does the micro have sufficent resources left to do this in software? I'm playing with a little frequency detection circuit based on an lm2917.

The controller easily has the cycles to do this. The problem is what kind of sensor your motor installation will support.

I initially expected to use an interrupt or timer capture input. But a motor spinning at 6000RPM is only turning at 100 turns per second. Even if sampled at the Cougar's 976 Hz event loop, you can do a little digital filtering on two-edge-per-turn signal.

I'm sampling the PortD digital inputs at the 4KHz rate, just after starting the A/D conversion on the motor current sensor. The filter for these signals is a simple saturating up/down counter. If the input is '0', I count down and hold at zero. If the input is '1', I count up and hold at the high limit e.g. 7 or 15. The output is the half way crossing, which is just the high order bit if you use a power-of-2 counter.

I haven't come up with an elegant way to calculate instantaneous RPM. Instead I'm keeping the timestamp of the most recent 5 crossing events, and use the one I'm about to throw away (six samples away) to calculate RPM. This is simple enough but not great because a little noise creates twice the phase error as other techniques, and I'm not using the info in the other samples to correct for this ("non linear" or "maximal likelihood" filtering).

We'll be trying out several speed sensors in the coming weeks. Once we figure out which is easiest while still being reliable over all speeds and temperatures, I'll report back how much noise we see and how clever the code needs to be to filter it.

The speed sensors we are considering right now are white-black painted marks with a side-by-side IR LED/receiver pair, reflective tape with the same pair, a slotted disk interrupting an IR gap (using a sensor from a mechanical mouse), and a metal slotted disk interrupting a magnetic reed switch from a BMW differential.

[DJBecker]

I should have mentioned my requirements for the RPM estimation, since they are more demanding than some might expect. We can't just count rotations and report the counter value a minute later. We have to get an accurate estimate by measuring the timing of one or a few pulses. Although we don't have to be nearly as precise as knowing the exact angle of the motor shaft as when driving A/C motor phases.

We want to

- Detect motor load by comparing acceleration (change in motor RPM) vs current. Initially this will be just to detect neutral revving and missed shifts, but if the numbers are clean it will adjust the PI control parameters for hills.

- Report speed over CAN. The 01-0c PID reports RPMs up to 16,383.75 in 0.25 RPM steps. While we don't need to reach full precision, it is a goal.

- Fake a tachometer output. We plan to report motor current on the analog tach in a future revision, but having an option to actually report RPM would be a SMOP (simple matter of programming)

- Detect which gear is being used by comparing with the wheel speed pulses. Those arrive on another digital input on portD, and are sampled/counted/filtered at the same as RPM.

- Implement cruise control!

- Rev-match on gear shifts. This is a next-revision goal, but we want to prepare for it. When we know the gear we are in and the load (high or low), we can use clutch and neutral switch inputs to trigger a gear change rev-match for the anticipated next gear. We have a clutch-less motor coupler, so this might be important.

[jpirkola]

Joe,

Sorry to be so long in responding. I have some health issues that knock me back once in a while. Takes a while to get going again.

Also,
Thanks to all of you who responded to my questions.

Originally Posted by jyanof

Cool!

Yes, tinning the buss bars is a good idea - not sure if paul does this for you or not, but there's that cheap tinning solution out there that works well.

Thanks, I'll look into locally available solutions if they do not come pre tinned.

Originally Posted by jyanof

Fan cooling the insides shouldn't be necessary - testing showed that most heat was generated by the mosfets/diodes and the heatspreader/heatsink is their primary thermal path to the air.

water cooling would be good, but I've had success with my air cooled heatsink. I cruise at 200A though, but do push 500A continuously while accelerating. this was in 110F summer weather, btw.

Since I'll be wacking the controller pretty hard I guess that I'll plan on pre chill water cooling the finned heatsink. I'll just wind a coil of aluminium tubing into the fins and epoxy it into place. I can then pump cold water through the system from a external source pre cooling the 8 x 12 heat sink.

Originally Posted by jyanof

Not sure what you mean by programming the controller to work with other voltages. It'll take up to 144V nominal. The input voltage affects the throttle response and that can be programmed. It also affects the overspeed cutout settings, which are disabled by default and user defined. Otherwise, it should all be good...

What I was hoping for was to be able to set the controller to limit itself to use a maximum voltage lower then the pack actual voltage. E.g. the controller can stand a 144 nominal volt battery pack. The controller is set to only pass 120 volts maximum to the motor.

This should allow a bit of headroom in the pack to keep sag under control and allow the controller to maintain maximum kW to the motor without the voltage falling too low. Having repeatable limits helps tuning of the drivetrain

Does the above make sense or am I missing something.

Originally Posted by jyanof

The controller monitors motor amps (limits to 500A) and internal temperature (decreases output at 65C, no output at 75C (I think, maybe paul can verify). So, it protects itself, but not the motor. If you're worried about the motor, you'll need some other sort of temperature monitoring device for that. well, i guess the controller does have an overspeed cutout, so that does protect the motor. it just doesn't know the motor's temperature and it can't really tell with it's stalled.

As for overspeed cutout, there are a couple settings that go into that, and I think it only works for a series-wound motor. (not sure what your prestolite is...) I have my notes somewhere.

The Prestolite is a series wound motor so it looks like you are saying that the controller has overrev protection for the motor but not stall protection for the motor itself. There is an over temp shutdown in the controller that MAY help protect the motor in a stall condition if the controller trips before the motor smokes.

Originally Posted by jyanof

A couple of suggestions:
-use a single 12v battery as your traction pack with your motor in neutral when you first get it together and test it out. if something is wrong, there's less chance of things going poof. You could also use a lightbulb instead of the motor. you won't really be able to control the brightness (since the software is expecting much higher amps), but it should at least turn on and off.
-use adam's RTD explorer to to help trouble shoot any problems in the beginning, changing controller settings, and monitoring the controller temperature for the first few runs. keep in mind it'll probably run a little hotter with higher input voltage when you upgrade the pack.

I have a extra 8 hp golf cart motor that I will be doing the testing on. I also have access to an eTeck motor and a large bank of transit bus brakeing resistors so I can build a light duty dyno if needed. Probably not though.

[DJBecker]

Originally Posted by jpirkola

What I was hoping for was to be able to set the controller to limit itself to use a maximum voltage lower then the pack actual voltage. E.g. the controller can stand a 144 nominal volt battery pack. The controller is set to only pass 120 volts maximum to the motor.

That's not quite the way the controller works.

It applies the full pack voltage to the motor windings, and varies the pulse width so the motor 'sees' a lower average voltage.

Really the controller has a target current, and changes the pulse width to get closer to the goal. So even if the pack voltage sags, the controller just increases its pulse width to compensate. The driver may not even notice the minor response lag.

Direct PWM does mean the motor windings have to withstand the full pack voltage. That's not usually a problem unless you are running absurdly high traction voltage.

[Greg Fordyce]

Originally Posted by jpirkola

What I was hoping for was to be able to set the controller to limit itself to use a maximum voltage lower then the pack actual voltage. E.g. the controller can stand a 144 nominal volt battery pack. The controller is set to only pass 120 volts maximum to the motor.

This should allow a bit of headroom in the pack to keep sag under control and allow the controller to maintain maximum kW to the motor without the voltage falling too low. Having repeatable limits helps tuning of the drivetrain

Does the above make sense or am I missing something.

The controller doesn't have any way of measuring pack voltage or motor voltage, but their are a couple of things you can do. Voltage sag of the pack will be related to the battery amps, which can be limited. Send the command "bat-amps-lim xxx" where xxx is a value between 0 and 511. (zero disables the battery amp limit). At slow motor speeds the motor amps can still reach the 500 amp limit even though the pack amps are limited.

While the motor voltage can't be limited, the controller does have motor overspeed protection built in in software. Since motor speed is a function of motor voltage, adjusting these to suit your setup can give you some protection as well.

Greg