Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control

[thingstodo]

Originally Posted by MPaulHolmes

I got the flywheel attached, cyrusCosmo! It works great.

That's WONDERFUL news!

I tested the battery current limiting, and it seems to work. You can set it to take no more than 'x' amps from the batteries, and separately, no more than 'y' amps into the batteries. That is a separate control from setting the max "motor amps" (line to line amps). I'm going to just send out the controllers to the 2 beta testers,

wwwooOOOOHHHHHHOOOOoooo!!

and worry about polishing the details from a distance. I think it's at a place where the fundamentals are good. So, adding the brake regen feature will have to be added on later.

Works for me!

I don't have a way to test that at all at the moment. I'll just send it with the wig-wag throttle. You can set the regen territory to be any amount you want, so it could just be the small amount that we were talking about that causes the car to feel like it slows down a bit when you take your foot off the throttle.

As long as I know the rules, I'm sure I can work with it

It will be interesting to see how the PI loop tuning goes. For now I'll make a separate C file for that, that will need to be run in debug mode with a locked rotor (emergency brake on?) at a relatively low voltage (48v??).

48V DC on the pack, locked rotor on the motor. Got it. Are you still doing the pulses on the unloaded motor to get the rest of the parameters?

I could do it all as a config mode in the same software as the regular C file, but I'm just trying to keep things simple at the moment.

Simple is GOOD

So, I just need to test the UART and EEProm stuff, and then I'll get the stuff together and ship them out. I hope you guys didn't pay for shipping already. haha. If so, then it will get shipped out in about 2 weeks (payday). haha

I don't remember paying for shipping. You should have my address from paypal. Let me know if you need me to PM it again. And what it'll cost to ship.

Have you shipped to Canada before? I'm told there are many rules, and that they change a lot.

[Astro]

Originally Posted by MPaulHolmes

I got the flywheel attached, cyrusCosmo! It works great. I have never been very mechanical, but finally understand what you guys were saying about connecting a DC motor and doing regen. I could use the same battery bank to power the dc motor, and then run the AC motor in regen, charging the same battery bank. haha. I'm not going to, at least at the moment, as I don't have a Dc motor.

Just don't regen more than the DC motor consumes otherwise this thread might end up in the unicorn corral.

Originally Posted by MPaulHolmes

So, I just need to test the UART and EEProm stuff, and then I'll get the stuff together and ship them out. I hope you guys didn't pay for shipping already. haha. If so, then it will get shipped out in about 2 weeks (payday). haha

Not sure how it all works out. I sent the 6 IGBT's (US$360) and an additional US$500 your way but that was before you knew all the costs.
Let me know what it all works out to once you find out the shipping costs and i will send more cash if required. I will PM you my address to work out shipping.

I wonder what is going to be more expensive, shipping to Canada or shipping to Australia?
Will it be the size or the weight that determines the cost?

I am still in the middle of my EV conversion so shipping delays should not be a problem, the slowest and cheapest boat will do.

[Cyruscosmo]

Originally Posted by MPaulHolmes

I got the flywheel attached, cyrusCosmo! It works great. I have never been very mechanical, but finally understand what you guys were saying about connecting a DC motor and doing regen. I could use the same battery bank to power the dc motor, and then run the AC motor in regen, charging the same battery bank. haha. I'm not going to, at least at the moment, as I don't have a Dc motor.

Your Welcome Paul, I'm glad to hear it worked out for you!

Cyruscosmo

[thingstodo]

Originally Posted by MPaulHolmes

For now I'll make a separate C file for that, that will need to be run in debug mode with a locked rotor (emergency brake on?) at a relatively low voltage (48v??).

I am left without the DC controller I wanted to use on the DC-motor-drives-the-AC-motor-in-regen setup . I need to work with Netgain Controls to figure out what I broke, and what they will charge me to fix it. One controller appears to have an output failed (will not turn on the contactor) and the other took a 2000A+ surge before my fuse blew. The contactors look OK so it's likely something internal.

The Netgain is set up to log motor current and amps, controller temp, motor temp .. so I don't break the DC motor.

I have a couple of recycled 48V Curtis controllers that I can use to get SOME testing done. At 48V on the DC bus the AC motor (a Siemens water-cooled unit) will be able to ramp up to maybe 200 amps. If I can get the motors coupled reasonably well. The Curtis can only do 300 amps, so the motor will be fine with that. The motor temp ... I'll have to monitor.

So, I just need to test the UART and EEProm stuff, and then I'll get the stuff together and ship them out.

I'll agree with Astro - shipping can be slow as long as it's cheap. It will take me a while to get set up for testing.

I understand the UART stuff - you are sending a serial stream updating the variables. What's the EEProm stuff? Somewhere to store the motor parameters, wigwag settings, etc? I should likely know that - I have read through the code from start to end once.

You had mentioned I'll need a PICkit 3. Anything else that you would suggest, or that you are already using? I'll attempt to make testing videos so you can see what's going on. Anything that would help it be a bit easier to understand (and troubleshoot) would be worth the effort.

I guess that's a question for the group as well. Suggestions on what I can use to measure the stuff that needs to be measured?

So far I have a clamp-on meter, a few 100A uncalibrated shunts, voltmeters, a laptop to display the serial data, a crappy infrared thermometer, a digital tach, and a scope. If I need another scope I could likely borrow one.

And a hero3+ camera to record wide angle stuff, and an android phone for a bit more narrow-angle stuff, plus a tripod.

[cts_casemod]

Originally Posted by thingstodo

I'm with Astro on this one. The differential case of going around the corner, and allowing one wheel to 'slip' is OK with the same torque setpoint to each wheel.

If one wheel loses traction, the torque setpoint will accelerate the wheel quickly. Depending on the acceleration rate, I don't know if the current will go down in an obvious way?

Maybe a limit on the difference between the frequency output for the two wheels? That would imply sharing the output frequency between the paralleled controllers.

I see a solution in having the same controller develop outputs for both AC motors - twice the calculations and twice the outputs ... but less complicated to co-ordinate? I don't like that solution but I can't come up with anything better right now.

Not quite. Yes the wheel will accelerate, but by the time you gain traction, if nothing is done, it will kick all the mechanical inertia of the motor to the pavement. Dangerous with icy/rainy conditions.

Most new controllers can drive two motors from the same CPU with little overhead. ST has a few. Then you need to implement a differential in software. The torque is only the same if both wheels are in sync, otherwise kill torque to allow the wheel to adhere to the road again. Once they are synced apply torque again.

EDIT: Kill torque is the wrong expression:
To clarify:
Imagine two DC motors connected in series. As one wheel slips, torque will be lost, therefore the current is reduced. At this point the second motor will also loose torque as the current is shared between them. This is exactly how a mechanical differential works. So its just a case of adapting the control of the AC motor to follow the same path.

[e*clipse]

Originally Posted by cts_casemod

Not quite. Yes the wheel will accelerate, but by the time you gain traction, if nothing is done, it will kick all the mechanical inertia of the motor to the pavement. Dangerous with icy/rainy conditions.

Most new controllers can drive two motors from the same CPU with little overhead. ST has a few. Then you need to implement a differential in software. The torque is only the same if both wheels are in sync, otherwise kill torque to allow the wheel to adhere to the road again. Once they are synced apply torque again.

Good point, except that you may not want them to be synced. For example, let's imagine that you are in a corner ( say, a skidpad ) and the inside wheel lifts up and looses traction. You see this all the time with FWD racecars - usually the inside rear corner is in the air. If it were an AWD car, then that wheel would be having the same issues we're discussing.

So, the point that wheel/motor/drivetrain inertia adds to the torque output of the motor in this case is definitely an issue. However, I wouldn't want to wait for the motors to be synced before applying torque. This won't happen until the car is going straight and it would require tight speed control, which I'm trying to avoid.

Perhaps looking at the relative velocities would be a good thing. Even in an extreme corner they really won't be very different, like they would be if one were on ice or in the air. If the relative speeds are > than XX% different, reduce the torque of the faster motor until the relative speeds are close enough. I wouldn't completely cut the torque, just reduce it so a controlled increase is possible.

Edit: Oh, and I forgot - there's a Majik thing that motors do to help combat this. Look at the torque-speed curves for the MGR - or the Prius - or any motor for that matter. Beyond the base speed, torque drops off fairly dramatically as speed increases. So, let's say you're @ highway speed with a gear ratio that puts 60mph at about 5000 rpm. The torque LIMIT of the motor is about 100 N-m. However, if the other motor spun out and met the max rpm, it's torque LIMIT would be less than 20 N-m.

[cts_casemod]

I edited the post above to better clarify.

[P-hack]

Interesting re: dual motors. To me the simplest is to just one set of igbts and one controller in slip mode and two motors in parallel. Read both motor speed signals and take the max speed for determining slip (prevents wheelspin runaway and encourages the slower one to speed up). Set 0% throttle to not regen and coast around the corners when you can. The latter fits well with "good" driving, traction pie habits anyway, you *shouldn't* be braking or accelerating much while turning and saving your traction for changing direction.

[cts_casemod]

Originally Posted by P-hack

Interesting re: dual motors. To me the simplest is to just one set of igbts and one controller in slip mode and two motors in parallel. Read both motor speed signals and take the max speed for determining slip (prevents wheelspin runaway and encourages the slower one to speed up). Set 0% throttle to not regen and coast around the corners when you can. The latter fits well with "good" driving, traction pie habits anyway, you *shouldn't* be braking or accelerating much while turning and saving your traction for changing direction.

Thats the system the trains use. It does a very good job at controlling traction. It would suit a FWD vehicle, but not a RWD, as the slowest wheel would never be able to go much slower than the fastest wheel (on my setup the maximum slip is 140RPM and can go all the way down to zero) which would limit the curving angle. The other issue is that one could potentially have 100% torque delivered to one wheel while the other was in the air. Not a problem with trains, but not ideal for a car.

Accelerating on a FWD vehicle during a curve actually encourages road grip as the front wheels push the car in the same direction as the steering. Not the same for braking tough.

[P-hack]

meh, accelerating a fwd car unloads the front wheels and makes the car go straight (plus torque straightening here). Still the simple setup seems pretty manageable to me (might want a bit of controller smarts in the speed differential limits).