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

[e*clipse]

Hello everyone!

Here is a quickeee update from my end.

I'm ready to put out rev2 of the resolver driver. Hopefully I've addressed the issues folks brought up. Again - please rip on it; I would rather hear about it now.

Some other improvements I've added -
1) It's a bit smaller and does not overlap the IGBT drivers as much.
2) I've added a 2nd fastener hole with plenty of space around both holes. They are 1" on center 3mm bolt holes. ( I really should dump the old school units - please have some patience with me. ) The bottom hole will fit the current motor controller; the top hole will require some component re-arrangement - perhaps for controller rev2?
3) I've added some power supply filtering and OV protection for both the +5V and +24V supplies. All that stuff (as well as the isolation caps for each IC) has been moved to the bottom.
4) A solid ground plane.

I've also tested all the IC's that I had to change for the design. Both the timer IC and the new power op-amp work excellent - in fact better than the original design.

Here is the circuit board:

[MPaulHolmes]

That looks beautiful!! Nice job! I can't wait to try it out. I love the details of your rounded copper pour edges.

On my end, I've got the UART communication just about done. And added some programmable variables...

current-sensor-amps-per-volt (so you can use any current sensor you want)
max-motor-amps (It's technically only max amps per phase if the motor is Y connected. It's actually max line to line amps, but nobody talks like that. units are real life amperes)
max-battery-amps (max real life amperes that can be pulled from the batteries)
max-regen-battery-amps (max real life amperes that can be put INTO the batteries)

It's mostly done. I've just been sick for the last couple weeks, and haven't gotten much done with it.

[e*clipse]

Originally Posted by MPaulHolmes

That looks beautiful!! Nice job! I can't wait to try it out. I love the details of your rounded copper pour edges.

On my end, I've got the UART communication just about done. And added some programmable variables...

current-sensor-amps-per-volt (so you can use any current sensor you want)
max-motor-amps (It's technically only max amps per phase if the motor is Y connected. It's actually max line to line amps, but nobody talks like that. units are real life amperes)
max-battery-amps (max real life amperes that can be pulled from the batteries)
max-regen-battery-amps (max real life amperes that can be put INTO the batteries)

It's mostly done. I've just been sick for the last couple weeks, and haven't gotten much done with it.

Thanks Paul. Hope you get better.

I need to start soldering my board together. I figure I can at least get it running in low voltage/no feedback mode...

Those variables will be very helpful. Perhaps some motor and controller temperature variables would be nice. I guess bus voltage should be ultimately controlled by the BMS; although it would help to give the motor controller some way to deal with it.

- e*clipse

[MPaulHolmes]

Here's the current list of data that will stream. It will be of the form

xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xx <enter>

where xxxx is one of the integers. So, you can watch it scroll as you drive if you want, but it's more intended to be graphed or captured and graphed later.
The variables are:
throttle
temperatureBasePlate
temperatureMotor
IqRef
Id
Iq
duty1
duty2
duty3
rpm
batteryAmps (negative if regen is happening).

Any others?

[e*clipse]

Originally Posted by MPaulHolmes

Here's the current list of data that will stream. It will be of the form

xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xx <enter>

where xxxx is one of the integers. So, you can watch it scroll as you drive if you want, but it's more intended to be graphed or captured and graphed later.
The variables are:
throttle
temperatureBasePlate
temperatureMotor
IqRef
Id
Iq
duty1
duty2
duty3
rpm
batteryAmps (negative if regen is happening).

Any others?

That looks very interesting. - It's going through the UART, right? So it would be possible to make some little PIC read the stream and put out a display on the fly?

In fact, it might even be possible to have the "interpreter" read the stream and put out a PWM or variable frequency signal to drive an analog gage! Now that would be cool!

-e*clipse

[e*clipse]

OK, I'm just thinking out loud here, but it seems there is a big opportunity with control here.

I was looking at the dual front motor setup for my car, and it seems ridiculously easy. Making the motor mounts for 1 motor or two would be about the same amount of work.

So I'm thinking I really need to try this FWD setup first, then go to AWD. All it will require is an "electronic differential." Since the motor controller is controlling torque, this will almost take care of itself. Just give the same throttle signal to both front motor controllers.

The basic "open" differential is really a torque split device that is supposed to evenly divide the available torque between the left & right wheel in a corner. The speed and speed differential is not important. This all works fine, until one wheel looses traction, and all the torque goes to that wheel.

So, now look at the simple dual AC motor drive setup: Again, the torque is evenly split between the left & right wheels, as requested by the throttle. In a corner, that is just fine, as the speed & speed differential don't matter. If one wheel looses traction, it is actually BETTER than an open differential, as the wheel with traction will still get its proportion of the torque.

So, a simple, "do nothing" approach would work pretty well. Of course, doing something would be icing on the cake! This controller already has some features built in that will help. It seems adding some form of traction control or even biasing the torque request would be possible without much additional effort. In the case of a spinning wheel, the motor controller would see a) a drop in current b) an increase in speed c) no change in throttle. This could trigger a "reduce throttle until current increases" type routine.

Thoughts?

- e*clipse

[Astro]

Originally Posted by e*clipse

...
In the case of a spinning wheel, the motor controller would see a) a drop in current b) an increase in speed c) no change in throttle. This could trigger a "reduce throttle until current increases" type routine.

Thoughts?

- e*clipse

Because the throttle is commanding torque is there a possibility of the spinning wheel RPM increasing to dangerous levels as the controller tries to bring the torque up to the requested level? Not easily achieved on a slipping/spinning wheel. I am thinking of one wheel on ice sort of situation. Even in a single motor situation on ice would the controller keep the rpm under control?
This is just a theoretical question for me, living in Australia the only ice i ever see is in my drink.

[thingstodo]

Originally Posted by MPaulHolmes

Here's the current list of data that will stream. It will be of the form

xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xx <enter>

where xxxx is one of the integers. So, you can watch it scroll as you drive if you want, but it's more intended to be graphed or captured and graphed later.
The variables are:
throttle
temperatureBasePlate
temperatureMotor
IqRef
Id
Iq
duty1
duty2
duty3
rpm
batteryAmps (negative if regen is happening).

Any others?

How about Vbat and Vmotor?

Or can you get Vmotor from duty1, duty2 and duty3?

I'd like an accumulated amp-hours, but that's likely too much work and would require some way to reset back to 0

[thingstodo]

Originally Posted by e*clipse

All it will require is an "electronic differential." Since the motor controller is controlling torque, this will almost take care of itself. Just give the same throttle signal to both front motor controllers.

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.

[freebeard]

If this was in an electric sand rail, it would be nice to have a 'cutting brake' where input from the electric steering would spur the outside wheel and retard the inside wheel to throw the front of the vehicle sideways.

You could code in some stubs now and flesh it out in v3.09a.