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

[e*clipse]

Originally Posted by MPaulHolmes

Maybe there could be a separate microcontroller that does all the non time critical stuff that sends the info to the time critical micro? non super-time critical could compute A/D's of throttle, brake A/D pressure switch thing, temperature A/D, DC voltage monitor, UART communication with outside, etc... All stuff that doesn't HAVE to be right this 0.0001 sec. It could even drive an optional 4th half bridge for the boost option. Then the other micro could do current 1, current 2, encoder or resolver, and that's it. boom. FOC with the focus of a ninja. haha. It would have to receive messages but that could be done quickly and reliably.

I am debating (with myself) a system like that to deliver the power to four different wheels. I'm wondering if it would be better to have a microcontroller (something simple like an 18 or 16 series pic) "interpret" the user inputs like throttle, brake, steering angle, etc. The output of this would go as an individual throttle "request" to four independant motor controllers.

Or perhaps a more simple analog solution that also makes these "requests"?

Anyway, I've sort of come to the conclusion that having one computer interpret driver "requests" like throttle is a necessary evil. Two? Hmmm I'm not sure I trust cumpooters that much. I REALLY don't trust the modern systems that use CAN bus for everthing from tire pressure monitoring to infotainment to throttle and ABS brake controls.

Oh, BTW, I'll this previous post

By "frozen" on the startup, I really meant "I don't give a crap what happens there because I never mess with that part. haha (laughing intentionally in quotes)" So, feel free to adjust that to include delays for things that are needed so no extra delays are there.

to mean go ahead with those final "main" mods. I'll put them into a form that can easily be copied into the current code, so your current work won't be affected. I hope this will work out - if not, you'll still have your old code.

*****edit******
regarding the above, for now I'm not going to change anything.
1) I can't see a way to improve the contactor control time, and moving this outside main would not help anything
2) The while(1) loop in main that starts with "ProcessCommand" appears to be only UART stuff, but I'm not sure about the section that looks at the PI values. Since you are debugging PI stuff, I think it's best to leave this alone for now.
***************

I'll just get back to integrating a resolver into the FOC part. I'll see if just the sin or cos can be used so that AN0 doesn't need to be changed.

- Eclipse

[thingstodo]

Originally Posted by MPaulHolmes

Maybe there could be a separate microcontroller that does all the non time critical stuff that sends the info to the time critical micro? non super-time critical could compute A/D's of throttle, brake A/D pressure switch thing, temperature A/D, DC voltage monitor, UART communication with outside, etc... All stuff that doesn't HAVE to be right this 0.0001 sec. It could even drive an optional 4th half bridge for the boost option. Then the other micro could do current 1, current 2, encoder or resolver, and that's it. boom. FOC with the focus of a ninja. haha. It would have to receive messages but that could be done quickly and reliably.

.. Long post .. lots of ranting on random topics .. my apologies in advance!

My basic idea is 3 micros. Hopefully the description makes SOME sense ..


A separate co-processor to handle everything else and feed the dsPIC with exactly the information required, no fluff, no waiting, just the latest value of whatever variable the dsPIC 'asks' for. Hmm.

So the co-processor would handle the throttle (single or dual channels, open circuit/short circuit detection, hall effect or potbox, coast or regen), brake (regen level, drive the brake light), select Park or Neutral or Drive, perhaps Eco mode or Sport or .. Ludicrous? Control the boost IGBT (not sure about how to approach that one), Transmit the throttle signal to the dsPIC once every .. 100 ms? If the dsPIC loses the throttle for 250 ms it turns off the motor outputs and coasts.

I don't like that the dsPIC has to 'ask' for info. How about it just receives a broadcast?

Handling the throttle may not require microsecond processing, but it is pretty important compared to selecting Drive or Neutral.

I hesitate to suggest an even MORE complicated structure ... but .. I would feel better if the throttle, brake, Boost .. were on a microprocessor that did not handle communications with a phone, or a web server, and stuff.

web and phones and park and drive and entertainment .. how about I call this one the 'Firewall' communications micro. That micro sends data via something - CANBUS or Serial? - the next Micro. How about 'DMZ' micro, that does throttle and brakes, boost controller, maybe charger, allow change from Drive to Neutral to Park, interlocks so you don't drive the car away while plugged into the charger, sends some data back to the Firewall, sends the rest - CANBUS or Serial - to the dsPIC that does FOC in interrupts. dsPIC receives information required from DMZ in main, non-interrupt process. And takes the latest value of info needed to send back to DMZ.

Somehow, the datalogs from the dsPIC must pass to the DMZ, and that data as well as logs from the DMZ must pass through to the Firewall. Some sort of command/response/verify?

With no IP stack on the DMZ or dsPIC, it should not be complicated. If there are no write commands direct to memory defined, but only exchange of data with the Firewall - that should remove the simple hacks. If the buffers that interface between DMZ and dsPIC are defined at the end of memory so stack overflows get dumped off the end of the memory map, where there is simply no memory left. Not sure how to guard against the stack overflows and other hacking methods .. kinda out of my league there .. but it would be nice to be reasonably sure that the DMZ and the dsPIC can't get *EASILY* hacked.

[MPaulHolmes]

Perusing IGBTs and found a TO-247 plus IGBT with an isolated back!:
http://www.mouser.com/ds/2/205/DS100...H1)-474217.pdf

I might try that one out.

[Piotrsko]

I hate to say it, BUT, "firewall" could be a simple analog driven device. an 8 bit mux and some logic gates, or if you have enough input pins straight through. I wanna see somebody hack that.

[e*clipse]

Originally Posted by Piotrsko

I hate to say it, BUT, "firewall" could be a simple analog driven device. an 8 bit mux and some logic gates, or if you have enough input pins straight through. I wanna see somebody hack that.

I would rate that as "and" not "but."

Yes, that would be difficult/impossible to hack.

- can someone take control of your device (car in this case) without your knowledge or consent? This is where the access through wireless is a big concern, IMHO.

As an example, the controller for my TDI diesel motor is "hacked." It has been re-programmed for different than OE performance. The big difference here is that the change was very much under my control. The person who did the job had to physically posess the controller in order to re-program it.

In a broad sense, the firewall is a physical barrier between the computer and any means to re-program it. I have PC's that are absolutely not ever connected to the internet. No wire or wireless opportunity exists to mess them up. In that sense, I am pretty certain that they are in little danger of being infected by viruses, etc.

If a person had to physcally access the car's controller in order to reprogram it, or rewire some analog circuit, this would be under control of the owner/driver. It DEFINITELY could not be done while the owner is driving the car, which would be the ultimate scary scenario.

- E*clipse

[thingstodo]

Originally Posted by Piotrsko

I hate to say it, BUT, "firewall" could be a simple analog driven device. an 8 bit mux and some logic gates, or if you have enough input pins straight through. I wanna see somebody hack that.

I'm not sure how an analog device would do 'web and phones and park and drive and entertainment' .. but I guess you could come up with something

I think that the key here is that the 'DMZ' processor does not allow for a write function. Without a method to write to memory of the DMZ processor, a hack does not seem possible.

no IP stack, no wireless.

[thingstodo]

Originally Posted by e*clipse

I would rate that as "and" not "but."

Yes, that would be difficult/impossible to hack.

- can someone take control of your device (car in this case) without your knowledge or consent? This is where the access through wireless is a big concern, IMHO.

As an example, the controller for my TDI diesel motor is "hacked." It has been re-programmed for different than OE performance. The big difference here is that the change was very much under my control. The person who did the job had to physically posess the controller in order to re-program it.

In a broad sense, the firewall is a physical barrier between the computer and any means to re-program it. I have PC's that are absolutely not ever connected to the internet. No wire or wireless opportunity exists to mess them up. In that sense, I am pretty certain that they are in little danger of being infected by viruses, etc.

If a person had to physcally access the car's controller in order to reprogram it, or rewire some analog circuit, this would be under control of the owner/driver. It DEFINITELY could not be done while the owner is driving the car, which would be the ultimate scary scenario.

- E*clipse

I can't say that I can argue with any of this!

[thingstodo]

Originally Posted by thingstodo

web and phones and park and drive and entertainment .. how about I call this one the 'Firewall' communications micro. That micro sends data via something - CANBUS or Serial? - the next Micro. How about 'DMZ' micro, that does throttle and brakes, boost controller, maybe charger, allow change from Drive to Neutral to Park, interlocks so you don't drive the car away while plugged into the charger, sends some data back to the Firewall, sends the rest - CANBUS or Serial - to the dsPIC that does FOC in interrupts. dsPIC receives information required from DMZ in main, non-interrupt process. And takes the latest value of info needed to send back to DMZ.

It appears that none of this is original. Oh well. I guess I read it over at EVTV and recalled it in my own way .. does that count?

From the description above:
- substitute the DMOC645 AC controller for the dsPIC
- substitute the GEVCU for the DMZ, and the communication is CANbus
- substitute the bluetooth/802.11 wireless board as the Firewall, communication is I2C ( I think) from the board to the GEVCU

One of the good parts is that the GEVCU is open source but the bluetooth/wireless board is not. I think I had mentioned that some time ago - the code, the board layouts, et al. I'll go through the forums when I get a chance and see if they had problems somewhere and would do it differently next time around.

[danibjor]

I like the idea of having more motors. Personally I would go for a modular approach where you have one box talking to the car (brakes, throttle, gear selector, steering angle, ABS/ESP system etc) and that box broadcasts torque demand for each wheel. Each inverter is set up to listen to broadcasts over the bus (canbus?) and generate power based on request. Failsafe turns of the motors if error conditions is present on the bus and/or if torque request and status signals are corrupt/missing.

This way it you can easily expand the setup on the car from single motor, to dual (either AWD or two motors on one axle) or quad motor AWD for the big spender. You could probably have dual back and single front motor too.


Got some toys for testing. Water cooled 80kW/280Nm motor capable of 10400RPM

[e*clipse]

Originally Posted by danibjor

I like the idea of having more motors. Personally I would go for a modular approach where you have one box talking to the car (brakes, throttle, gear selector, steering angle, ABS/ESP system etc) and that box broadcasts torque demand for each wheel. Each inverter is set up to listen to broadcasts over the bus (canbus?) and generate power based on request. Failsafe turns of the motors if error conditions is present on the bus and/or if torque request and status signals are corrupt/missing.

This way it you can easily expand the setup on the car from single motor, to dual (either AWD or two motors on one axle) or quad motor AWD for the big spender. You could probably have dual back and single front motor too.


Got some toys for testing. Water cooled 80kW/280Nm motor capable of 10400RPM

Totally agree!


I'm doing something like that on my AWD conversion.

Some years ago, I was inspired by a team that converted a Subaru WRX to AWD electric. Basically, they used two Siemans induction motors; one coupled to the front differential, the other coupled to the rear differential. They used lithium cells ( I don't remember; I think they were Kokam) and were quite successful in autocross and track racing.

One of the huge advantages of electric drive is control. AWD Rally racing cars have an adjustment that allows the driver to bias the torque front or rear on the fly, depending on conditions. The electric WRX took that to the next level.

The ultimate is torque vectoring, which would allow the motors to adjust torque to whatever wheel needs it, on the fly. With it, the motor torque can actuallly help the vehicle around a corner - in both braking and accellerating. Here's an example of it in action, with the Mercedes AMG electric car on the Nurburgring:
If you watch the video, check out the guages - in the lower right is a guage that shows current as a % of total available, both positive and negative. it's a good regen illustration.

https://www.youtube.com/watch?v=2NGDfFCY-tQ

IMHO, were in for a very fun future!

E*clipse