VCU/controller for 4 motor setup

aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

VCU/controller for 4 motor setup

Post by aesthetect »

I am trying to figure out hardware and a topology for controlling 4 leaf motors independently - ie different torque / current signals to each. I am planning rev3 OI board on gen 2 leaf inverters. This is to build a platform for proof of concept testing on some torque vectoring IP, leaf motor power level and geometry are a good fit and I have the mechanical/packaging worked out. I would plan on a central supervisory controller (VCU) that would get throttle etc as inputs, run an array of algorithms and output torque commands to the inverters. I am thinking zombieverter or a general industrial controller that I would program in codesys. I would generally prefer to use zombieverter just so i am not building all the basic stuff from scratch. also just because of the work that has been done here in communicating with other OEM components that I will likely need so I would prefer to support it where I can.

The CAN and circuit/PCB details are new to me but my professional work is lithium ion battery systems engineering so am happy to help with any questions there so please consider me a resource.

1. Main question - Can zombieverter support 4 different inverters on the same CAN network? I saw it said on zapateros thread that different torque to each of his 2 motors would be no problem, but how would this be done? Regardless of which supervisory controller, my understanding is each leaf inverter uses the same canbus ID, so will this inherently cause problems? Is it possible to change canbus ID via the OI board?

2. If #1 doesn’t work, my backup plan is to use analog signals out of the supervisory controller (throttle, regen) as a means to operate all the different motors. This would work fine but is there any way I could get speed (resolver) data back to the supervisory controller from each motor?

3. How much capability would I have for setting up algorithms on zombieverter? minimal need is look up tables (although things like state machine, etc would be preferred). I am adept at high level matlab/simulink/labview, but not much experience with low level, C etc. Any insight into what I should expect to have to get into would be appreciated. Another option might be to use zombieverter and a separate controller for algorithms.

4. I would have additional IO beyond the usual suspects - things like steering angle sensor, gyroscope/accelerometer, etc - not likely to be CAN. is there room for more analog inputs to zombieverter? Looking diagrams ive found so far connectors etc seem to be full but I'm not 100% i've found all the right documentation yet


Any other advice or words of wisdom are appreciated - thank you in advance!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

If it's just a one off, intended purely for algorithm validation, then I'd be looking at an industrial PC board running a realtime linux kernel with a CAN dongle for each motor (plus whatever interfaces you need for the other sensors). It minimises the amount of low level code (just the bit to interface to the dongles and handle the Leaf inverter protocol) while allowing you to continue to use the high level apps, languages and tools you are already familiar with.

If you get into custom hardware and low level software there is a real danger you will spend all your time on that rather than tuning/testing/proving your algorithms.
User avatar
johu
Site Admin
Posts: 5682
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: VCU/controller for 4 motor setup

Post by johu »

aesthetect wrote: Fri Mar 17, 2023 6:09 pm 1. Main question - Can zombieverter support 4 different inverters on the same CAN network? I saw it said on zapateros thread that different torque to each of his 2 motors would be no problem, but how would this be done? Regardless of which supervisory controller, my understanding is each leaf inverter uses the same canbus ID, so will this inherently cause problems? Is it possible to change canbus ID via the OI board?
When swapping the control boards for the OI aka Rev3 one you can assign different CAN ids for throttle control so they can be all on the same bus. Heck, you could even put the 4 torque values in the same message in different positions ;)
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

Thanks guys, already very glad I asked.
Pete9008 wrote: Fri Mar 17, 2023 6:57 pm If you get into custom hardware and low level software there is a real danger you will spend all your time on that rather than tuning/testing/proving your algorithms.
100%. Basically this post was all about getting input to figure out the best setup to minimize that exact point to the greatest extent possible.

My thinking was the low level coding on an industrial controller with CODESYS should be minimal (?), just would have to pull in a bunch of different prebaked software modules (CAN, etc). I would have to set up and orchestrate all the contactor controls, etc, but that is all easy to execute, just need to think it all though.
Pete9008 wrote: Fri Mar 17, 2023 6:57 pm If it's just a one off, intended purely for algorithm validation, then I'd be looking at an industrial PC board running a realtime linux kernel with a CAN dongle for each motor (plus whatever interfaces you need for the other sensors). It minimises the amount of low level code (just the bit to interface to the dongles and handle the Leaf inverter protocol) while allowing you to continue to use the high level apps, languages and tools you are already familiar with.
This is a great point that I really hadn't considered. Any recommendations for hardware for analog IO? Each CAN dongle then would effectively be its own CAN network, have one for the BMS as well, etc (right?). I'm a linux noob, but that should be surmountable (obviously at least one component of this is going to be something I'm not adept at, just a matter of picking the right one...!).

johu wrote: Fri Mar 17, 2023 7:23 pm When swapping the control boards for the OI aka Rev3 one you can assign different CAN ids for throttle control so they can be all on the same bus. Heck, you could even put the 4 torque values in the same message in different positions ;)
Excellent! Thank you - this was the main item I was trying to confirm for planning purposes. I assume it is the same as far as resolver/speed info from each inverter, that I could assign different CAN IDs?
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

aesthetect wrote: Sat Mar 18, 2023 7:34 pm Any recommendations for hardware for analog IO?
Depends what your budget is, you can spend anything from a few pounds for a cheap one that uses the ADCs on a micro to do the conversion (limited resolution, limited speed, variable quality) all the way up to several hundred for things like National Instruments data acquisition cards (much more sophisticated, high quality and easy Labview integration but expensive). It realy depends on your requirements. I'd suggest that you work out what you need in terms of channel count, voltage range and resolution first and then have a look at what's available.

Btw, just in case you are unaware there are two fundamentally different ways of driving the Leaf inverter. You can either use the Nissan protocol, either directly or via a Zombieverter (both based on celeron55's reverse engineering of the protocol), or replace the Nissan logic board with an Openinverter board and then use the OI configurability to program the CAN messages to be used. The later gives you much greater flexibility, complete control of the motor and can increase the power available but does involve extra hardware and configuration.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

Sorry, going a little off topic (but not sure it's worth a new thread and is vaguely relevant to this), I have a question that you may be able to help with. I have a RWD ICE track car and have been thinking of adding a front axle electric boost/regen to it for ages (see viewtopic.php?t=3290 for a bit of discussion) plus possibly some torque vectoring to improve stability. I think I know how to do most of it but the battery is the stumbling block. I need something that can store just enough energy to give a 75kW 10sec boost (say 0.5kWHr) but be able to handle more or less continuous 75kW charge/discharge. I have wondered about super caps and batteries but so far haven't found anything light enough (not too worried about size but want to keep weight down to around 50kg). Are you aware of anything that might fit the bill?
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

Pete9008 wrote: Sun Mar 19, 2023 9:17 am Sorry, going a little off topic (but not sure it's worth a new thread and is vaguely relevant to this), I have a question that you may be able to help with. I have a RWD ICE track car and have been thinking of adding a front axle electric boost/regen to it for ages (see viewtopic.php?t=3290 for a bit of discussion) plus possibly some torque vectoring to improve stability. I think I know how to do most of it but the battery is the stumbling block. I need something that can store just enough energy to give a 75kW 10sec boost (say 0.5kWHr) but be able to handle more or less continuous 75kW charge/discharge. I have wondered about super caps and batteries but so far haven't found anything light enough (not too worried about size but want to keep weight down to around 50kg). Are you aware of anything that might fit the bill?
Sounds awesome. I have a 240Z track car that I'm building an EFI ITB system for now.
You're spot on in that post that 10C is a good reasonable target but not any ol battery will give you that. You definitely want something designed for a hybrid (higher power density, lower energy density). Also consider you will need a well cooled system (where the cooling very effectively gets to the cells) - also remember that will add weight. I don't think you'll be able to quite hit your weight target but should be able to get kind of close. So I'd give some thought to whether you'd rather sacrifice a little on power or weight.
10 seconds is too long for supercaps to be competitive.
I like LTO batteries for high power stuff but too heavy and expensive here.
Unfortunately I'm a better help at how/what will work than being familiar with the spectrum of OEM batteries available.
However, definitely look into the NSX battery, though its more in the range of 52 kW. 1.3 kWh, supposedly it is ~90 lbs. I believe voltage is around 200Vmax but never got a 100% answer (I was looking at using that dual motor front end).
Also check out the i8 battery, though I don't have specs offhand. I believe Sasha Anis from Mountainpass performance went with that for a similar use on his (very well built) time attack 350Z.

Now, that all being said, there's a company EVDrive that has a battery system and cooling design I like. I'd rather not post all their specs online without their consent, but after I typed all that above, just did some quick math and I think they are perfect for you. I haven't used them before but have talked to them quite a bit and that is what I am planning for my car. PM me and I will put you in touch.

One thing to note, with a small high performance hybrid system, managing state of charge is a challenge - ie balancing usage to keep SOC in the middle so you can charge when you want and discharge when you want. Its a fun game but not an easy one. Luckily you can trial and error fine tune for exactly how you want it for yourself. Also goes to say you'll want your BMS to be reliable and accurate, even moreso if you are running tight margins (good reason to go with EVDrive as they have their own BMS and thus is actually calibrated and validated for the cells).
Pete9008 wrote: Sat Mar 18, 2023 10:55 pm Depends what your budget is, you can spend anything from a few pounds for a cheap one that uses the ADCs on a micro to do the conversion (limited resolution, limited speed, variable quality) all the way up to several hundred for things like National Instruments data acquisition cards (much more sophisticated, high quality and easy Labview integration but expensive). It realy depends on your requirements. I'd suggest that you work out what you need in terms of channel count, voltage range and resolution first and then have a look at what's available.

Btw, just in case you are unaware there are two fundamentally different ways of driving the Leaf inverter. You can either use the Nissan protocol, either directly or via a Zombieverter (both based on celeron55's reverse engineering of the protocol), or replace the Nissan logic board with an Openinverter board and then use the OI configurability to program the CAN messages to be used. The later gives you much greater flexibility, complete control of the motor and can increase the power available but does involve extra hardware and configuration.
Very glad you said that about the options to drive the leaf inverter. Obviously I'm trying to minimize detail configuration/setup. Good thing to have in mind as I evaluate VCU hardware options.

My needs are really simple as far as channels/speed/resolution, nothing crazier than a regular throttle pedal as far as inputs, just a few more than normal; and outputs are all just to command contactors/relays (and display/HMI).

Using a full NI cRIO was actually my plan when I first started on this. I used NI stuff a lot in grad school (15 years ago...), and its the only complete package as far as hardware and software; and seems well suited here. I definitely wouldn't mind spending money on hardware I knew would give me easy solutions to the detail stuff, I'm just still fishing for what that is. But even still, say trying to keep things in the <$5k range.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

Thanks for that, what you've said pretty much confirms the conclusions I'd come to but it's good to have it confirmed by someone who knows the technology. The NSX battery looks well worth a bit more investigation too. Not sure how much of the other thread you read but that NSX dual front motor looks like exactly what I was thinking of making.

Regarding compromising on power/weight the car is around 1100kg (and the intention would be to reduce that a bit before starting a hybrid conversion) and has just over 400bhp. My main concern is that it would be very easy to add weight and power and end up back at pretty much the same power to weight ratio. I realise that a hybrid solution offers other advantages too but to be worth doing I'd be looking for a percentage increase in power of at least twice the percentage increase in weight (a 25% boost in power for a 10% increase in weight was the ballpark target). I take your point on the SOC management and agree that in many ways it would be the most difficult part of the project. The car has to continue to feel right, the moment the acceleration or deceleration becomes unpredictable due to SOC limitations the hybrid boost becomes a problem not a benefit.

On your application I keep dithering as to the best solution. An industrial PC is going to be the quickest and easiest way to go but where I get uneasy is the robustness. If it's for a test bed that is going to have a relatively easy life then it's probably the right option. However, if it will end up on track, or in another high vibration and high G environment then I'd get uneasy about the reliability/longevity, especially if any commercial grade connections like USB are used. I also get a little uneasy about USB in general. I've had mixed experiences with it, sometimes it will work fine for years without trouble while other times the drivers hang for no obvious reason (although having said that it was on windows, linux does seem a lot more stable here).

Do you have any experience programming in C/C++, or an interest in learning? If so it would open up other options for more bare bones platforms.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

Sorry, another question on batteries. Just looking at the Blue Energy EHW5 cell which is what I believe Honda use in the NSX. I can't find much data but most of what I do find agrees with this https://www.gs-yuasa.com/en/newsrelease ... 461410_446 - 5Ah but with a maximum current of 300A, that's 60C!

What am I missing here?

Edit - also surprised by this https://www.marklines.com/en/report_all/rep2074_202010 which indicates that, in the Honda Fit at least, they are air rather than water cooled?

Edit2 - Pictures of the NSX hybrid battery look like it has ducts for air cooling too.
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

Pete9008 wrote: Mon Mar 20, 2023 12:10 pm Thanks for that, what you've said pretty much confirms the conclusions I'd come to but it's good to have it confirmed by someone who knows the technology. The NSX battery looks well worth a bit more investigation too. Not sure how much of the other thread you read but that NSX dual front motor looks like exactly what I was thinking of making.

Regarding compromising on power/weight the car is around 1100kg (and the intention would be to reduce that a bit before starting a hybrid conversion) and has just over 400bhp. My main concern is that it would be very easy to add weight and power and end up back at pretty much the same power to weight ratio. I realise that a hybrid solution offers other advantages too but to be worth doing I'd be looking for a percentage increase in power of at least twice the percentage increase in weight (a 25% boost in power for a 10% increase in weight was the ballpark target). I take your point on the SOC management and agree that in many ways it would be the most difficult part of the project. The car has to continue to feel right, the moment the acceleration or deceleration becomes unpredictable due to SOC limitations the hybrid boost becomes a problem not a benefit.
I really wanted to use the NSX dual motor, its a great, small package, but its just not enough power for my application. It includes a gearbox / clutch on each end, which is nice but obviously also presents large opportunity for additional complication. But if you could reverse engineer it all that would give you a great complete solution (motor/inverters/battery)

the rule of thumb i've come to accept for electrification (reluctantly & unfortunately for sports car minded guys like you and me) is power to weight gets (much) better as weight increases. if you're looking at it strictly from a power to weight standpoint i don't see it being worth it. if you can gain benefit as far as torque vectoring, braking capability, etc then maybe. but hands down, turbo or engine swap is going to give you much better power to weight. but I can see you're like me, willing to trench through the design/engineering spiral for as long as it takes in the belief that the vision can be achieved.

also FYI the EVDrive battery costs may likely be on par with used OEM options you'd be looking at, just in case that was a cause for disinterest.
Pete9008 wrote: Mon Mar 20, 2023 12:10 pm On your application I keep dithering as to the best solution. An industrial PC is going to be the quickest and easiest way to go but where I get uneasy is the robustness. If it's for a test bed that is going to have a relatively easy life then it's probably the right option. However, if it will end up on track, or in another high vibration and high G environment then I'd get uneasy about the reliability/longevity, especially if any commercial grade connections like USB are used. I also get a little uneasy about USB in general. I've had mixed experiences with it, sometimes it will work fine for years without trouble while other times the drivers hang for no obvious reason (although having said that it was on windows, linux does seem a lot more stable here).

Do you have any experience programming in C/C++, or an interest in learning? If so it would open up other options for more bare bones platforms.
that actually pretty well seals the deal on industrial PC for me then. it is a development mule, so if it needs some TLC after each test session thats OK. not ideal, but in the interest of minimizing development/setup effort, well well well worth it. At least I'm sure I can find a PC that can do it, would be nice to avoid USB, but there are ways to secure those cables (funny how its still main such a mainstay on any highly ruggedized PC, I guess its fairly unavoidable for a PC). It will definitely see hard track use, but G forces and vibrations arent too high amplitude. crash would be a larger set of headaches anyway. long term it is hard to say it wont see offroad/loose surface/rally but that is far enough away I can plan to handle it when I get there and is not strictly necessary (plus with the amount of weight i'll have there are bigger areas of concern).

so far labview is seeming like the best software solution. python and codesys free and good but less able as far as complexity. generally speaking, i'll be using look up tables inside state machines (more or less). any revision to that?

also... could I bother you to throw out a couple of specific hardware options? as far as PC, CAN dongle, and IO module. a couple example options and/or some things to consider or look for in alternatives would give me a hugely valuable starting point.

I do have C/C++ experience but id very much rather avoid it. I'm less worried about the coding and syntax, but so many of the peripheral aspects (interfaces, structure, libraries, setup) would be so foreign at this point it would take me forever. I would be much more willing and interested to learn on the inverter programming / IGBT operability side (actually eager to do so).

thank you very much for this feedback and consideration, I can't tell you how valuable it is.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

aesthetect wrote: Mon Mar 20, 2023 9:24 pm I really wanted to use the NSX dual motor, its a great, small package, but its just not enough power for my application. It includes a gearbox / clutch on each end, which is nice but obviously also presents large opportunity for additional complication. But if you could reverse engineer it all that would give you a great complete solution (motor/inverters/battery)

the rule of thumb i've come to accept for electrification (reluctantly & unfortunately for sports car minded guys like you and me) is power to weight gets (much) better as weight increases. if you're looking at it strictly from a power to weight standpoint i don't see it being worth it. if you can gain benefit as far as torque vectoring, braking capability, etc then maybe. but hands down, turbo or engine swap is going to give you much better power to weight. but I can see you're like me, willing to trench through the design/engineering spiral for as long as it takes in the belief that the vision can be achieved.

also FYI the EVDrive battery costs may likely be on par with used OEM options you'd be looking at, just in case that was a cause for disinterest.
Costs are an issue in the sense that my wife is an accountant and as such keeps a very close eye on the household books! TBH though I prefer building rather than buying if there's a choice, it's harder work and slower but somehow more satisfying when complete. The car's already had a supercharger added and I'd still like to change the camshafts to better suit it but that's as far as I want to go on the engine side.

The hybrid bit is as much about a challenge as improving performance but I do need to come out of it with an improvement that feels like it justifies the work. Can't see me starting on it for a couple of years (although I am starting to lookout for bits).

Edit - not disinterest in the EVDrive offerings, I did have a look and their motors and inverters do look impressive (not much detail on the batteries though). It's just less convenient as I'm in the UK and shipping batteries would likely be an issue. It looks like the Blue Energy batteries would be a similar problem though, none of the models that used them seems to have been available in Europe. Trying to find i8 battery details at the moment but not getting very far.
aesthetect wrote: Mon Mar 20, 2023 9:24 pm that actually pretty well seals the deal on industrial PC for me then. it is a development mule, so if it needs some TLC after each test session thats OK. not ideal, but in the interest of minimizing development/setup effort, well well well worth it. At least I'm sure I can find a PC that can do it, would be nice to avoid USB, but there are ways to secure those cables (funny how its still main such a mainstay on any highly ruggedized PC, I guess its fairly unavoidable for a PC). It will definitely see hard track use, but G forces and vibrations arent too high amplitude. crash would be a larger set of headaches anyway. long term it is hard to say it wont see offroad/loose surface/rally but that is far enough away I can plan to handle it when I get there and is not strictly necessary (plus with the amount of weight i'll have there are bigger areas of concern).
Fair enough, although the idea of the PC crashing while on the limit going round a corner does worry me a little ;)

Thinking a bit more I put a car PC in my wife's 350Z back in 2006, it has USB connected peripherals for the tuners, steering wheel interface, touchscreen, GPS, bluetooth, media HDD, etc. Ran for 10+ years and they never caused any problem at all (edit - the physical USB connections were no problem, the XP drivers did occasionally need a reset).
aesthetect wrote: Mon Mar 20, 2023 9:24 pm so far labview is seeming like the best software solution. python and codesys free and good but less able as far as complexity. generally speaking, i'll be using look up tables inside state machines (more or less). any revision to that?
If it can be done with look up tables and state machines why do you need the complexity/expense of LabView? If it was running complex algorithms modelling the behaviour of the car (based on suspension travel, steering angle, F/R acceleration, yaw sensors, etc) I could understand using LabView but to me it seems a little over the top for what you describe?
aesthetect wrote: Mon Mar 20, 2023 9:24 pm also... could I bother you to throw out a couple of specific hardware options? as far as PC, CAN dongle, and IO module. a couple example options and/or some things to consider or look for in alternatives would give me a hugely valuable starting point.
Afraid I'm a little out of date on these things, it must be 10years since I last specified one. For the PC I'd start from what the processing requirement is, work out how many cores and what clock speed and work from there. I always preferred fanless machines with soldered RAM if possible (and I imagine that's now much easier to achieve). And definitely a solid state disk!

Similarly I've no great recommendation for CAN interface. I have had a Lawicel CANUSB interfacing the heating system to my home BMS system for the last 5 or so years. It's nothing special but easy to program and I have never had to reset it or reload drivers despite it running 24/7 (on Linux though). I can't comment on how it copes with higher data rates as I only use it at 125kbps. They also do a RS232 version too if you want to avoid USB! There are also lots of clones available, many of which also copy the Lawicel protocol.

There are others on here much better able to comment on CAN dongles for automotive use. For example there's a suggestion in this thread viewtopic.php?t=2907 for example.
aesthetect wrote: Mon Mar 20, 2023 9:24 pm I do have C/C++ experience but id very much rather avoid it. I'm less worried about the coding and syntax, but so many of the peripheral aspects (interfaces, structure, libraries, setup) would be so foreign at this point it would take me forever. I would be much more willing and interested to learn on the inverter programming / IGBT operability side (actually eager to do so).
Might be worth you setting up a dev environment for the OpenInverter or Zombieverter code and having a play (this may help viewtopic.php?t=2633) . Johannes firmware does a pretty good job of abstracting a lot of the lower level bits so you may find it less of a learning curve than you expect. If the processing requirements are fairly modest then one of these platforms could form a starting point (although floating point support may be an issue?).
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

Pete9008 wrote: Mon Mar 20, 2023 8:36 pm Sorry, another question on batteries. Just looking at the Blue Energy EHW5 cell which is what I believe Honda use in the NSX. I can't find much data but most of what I do find agrees with this https://www.gs-yuasa.com/en/newsrelease ... 461410_446 - 5Ah but with a maximum current of 300A, that's 60C!

What am I missing here?

Edit - also surprised by this https://www.marklines.com/en/report_all/rep2074_202010 which indicates that, in the Honda Fit at least, they are air rather than water cooled?

Edit2 - Pictures of the NSX hybrid battery look like it has ducts for air cooling too.
Well, main thing is that's going to be peak rating, which is limited to something like 10s, and is dependent on ideal temperature and voltage conditions. But generally the main factor to have in mind behind those ratings/capabilities is internal resistance, and its hard to say too much without knowing what that is. Also consider resistance of a pack is not the same as resistance of a cell. There are also electrochemical factors driving the voltage dynamics that are much harder to account for. Just to say, real performance determination ultimately comes from testing (all of the above adds up to the more familiar term voltage 'sag'). I'm sure that complete system isn't pumping out 300A but it is certainly a lot more than you'll find in most OEM quality places. And remember, its taking a hit as far as weight, with the cell design sacrificing energy density for power density, but then compensating by only needing a small amount of kWh. Just those cells alone would work out to the energy density of a complete all-in Chevy Volt battery - being an obviously heavy pack itself.

Well designed air cooling systems can for sure be surprisingly effective. Its all about materials, heat transfer and volume/flow of fluid. Horses for courses.

Tying those questions together, low internal resistance also means low heat generation. Also since operation consists of only short bursts, the cycle size or depth of discharge is kept very low, so cumulative heat generation is again low. But for sure its a lot of current so its significant (RMS current is what ultimately drives thermal). No doubt they have tested and are operating very mindful of all of those limits - in concert with balancing SOC as we mentioned before.
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

Pete9008 wrote: Mon Mar 20, 2023 10:39 pm Costs are an issue in the sense that...
...
Might be worth you setting up a dev environment...
This is excellent - lots for me to dig in on and run with - thank you again very much.
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

Pete9008 wrote: Sat Mar 18, 2023 10:55 pm You can either use the Nissan protocol, either directly or via a Zombieverter (both based on celeron55's reverse engineering of the protocol)
Just to confirm - does that same CAN protocol derived by celeron55 (and thus the different solutions using it) work for gen 2 and gen 3 leaf motor/inverters, the 110 kW and 160 kW versions? I can't seem to find a solid answer.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

Thanks, I'll probably start another thread to discuss smaller high power density batteries.

Curious about how you are going to couple the Leaf motors to the wheels. Are you keeping the Leaf gearbox and losing the diff or replacing with something else? What top speed are you going to gear things for?

If you are defininitely set on the Leaf then it would be worth getting a Leaf stack, a battery, setting up a test PC (desktop/laptop for now) and trying a few things. Two Leaf stacks would be even better, you could couple the two together, run one as a motor one in regen and really get a good idea of how to control and the performance limitation (the other advantage is that if you use a common battery it only needs to cover the system power losses not motor power).

One other thing on CAN bus that I forgot to mention - it's worth looking up GVRET/SavvyCAN. It's an open source CAN analysis and debugging platform that is widely used for reverse engineering. It's also got a very nice user interface which includes powerful filtering, graphing and CAN message generation tools so is very handy when in the early stages of getting things working. It also supports lots of different CAN dongles so might be worth referring to when choosing one.

Final thought. I'm back on a PC being the best development platform for you, the main reason being that it just makes the data collection, analysis and algorithm development cycle so much easier. I would suggest that you look into real time Linux kernels though. You need something that isn't going to disappear for 100ms while it services some odd OS background task! Also came across these while doing a quick google (probably lots of other alternatives but this is the first one I saw) https://www.okdo.com/p/okdo-rock-3-comp ... bluetooth/. This one has the downside of needing a motherboard but I'm sure there must be equivalents that don't. It offers a quite impressive range of built in IO, reasonable performance and supports Debian/Ubunto all in a pretty small and robust package (things have definitely moved on since I last looked!) so may be worth a thought.

Edit - Looks like real time kernels on Ubuntu is now pretty straight forward, see https://ubuntu.com/blog/real-time-ubunt ... -available and https://ubuntu.com/engage/an-introducti ... nux-part-i
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

Pete9008 wrote: Tue Mar 21, 2023 11:34 am Curious about how you are going to couple the Leaf motors to the wheels. Are you keeping the Leaf gearbox and losing the diff or replacing with something else? What top speed are you going to gear things for?
winters quick change diffs. can get reduction ratios up to soemthing like 9:1, hard mount and will have axles out to the side. i'm honestly surprised they arent used in more EV conversions. fitting two side by side, in my case, is definitely a squeeze so it takes a lot of leg work on looking at subframe options and being as sure as can be about what will fit.

Pete9008 wrote: Tue Mar 21, 2023 11:34 am If you are defininitely set on the Leaf then it would be worth getting a Leaf stack, a battery, setting up a test PC (desktop/laptop for now) and trying a few things. Two Leaf stacks would be even better, you could couple the two together, run one as a motor one in regen and really get a good idea of how to control and the performance limitation (the other advantage is that if you use a common battery it only needs to cover the system power losses not motor power).
yup, i'm going to pull the trigger on a motor/inverter set shortly now, just wanted to feel confident in the interface to the inverter first, in concert with VCU setup. knowing more about the two approaches you pointed out and now after researching each was basically the last hurdle to 100% commit to the leaf.

Pete9008 wrote: Tue Mar 21, 2023 11:34 am One other thing on CAN bus that I forgot to mention - it's worth looking up GVRET/SavvyCAN. It's an open source CAN analysis and debugging platform that is widely used for reverse engineering. It's also got a very nice user interface which includes powerful filtering, graphing and CAN message generation tools so is very handy when in the early stages of getting things working. It also supports lots of different CAN dongles so might be worth referring to when choosing one.

Final thought. I'm back on a PC being the best development platform for you, the main reason being that it just makes the data collection, analysis and algorithm development cycle so much easier. I would suggest that you look into real time Linux kernels though. You need something that isn't going to disappear for 100ms while it services some odd OS background task! Also came across these while doing a quick google (probably lots of other alternatives but this is the first one I saw) https://www.okdo.com/p/okdo-rock-3-comp ... bluetooth/. This one has the downside of needing a motherboard but I'm sure there must be equivalents that don't. It offers a quite impressive range of built in IO, reasonable performance and supports Debian/Ubunto all in a pretty small and robust package (things have definitely moved on since I last looked!) so may be worth a thought.

Edit - Looks like real time kernels on Ubuntu is now pretty straight forward, see https://ubuntu.com/blog/real-time-ubunt ... -available and https://ubuntu.com/engage/an-introducti ... nux-part-i
Excellent, I'll definitely have to check out GVRET/SavvyCAN and toy with it when I get my setup going.

what software stands out in your head for running on the PC? (lot of options and I have my thoughts but wanted to ask yours untainted)

i keep considering NI/labview for two reasons. one, partly for it being easier to make changes and tweak algorithm, as well as the ease of visualizing functionality for development. but two, primarily because its a one stop shop for easily getting the hardware/software all setup to the point of being able to just develop algorithms. i feel like its as close to plug and play as I can get, and easy to google answers and even have actual tech support. ie even for PC linux setup I'd be googling where to put what files for configuration, how to initialize things, stacks, what drivers for XYZ, patch when/what/where, etc etc. All stuff I am sure I can learn, and I wouldn't be worried if I decided to go that route, but I'm doing the premeditation now so I can make a fully aware decision. also, im waiting to see if a couple funding options pan out. if they do i'll have a good bit more room for NI, if not, I'll most certainly go with PC. so think of it as that for the time being I'm trying to research/learn and wrap my head around the amount of setup for PC and how I can further minimize it (as well as if NI is even as much simpler as I think it will be).

edit: also, if I use a CAN dongle for each motor/inverter and one for the BMS (assume I put any/all other CAN devices on that bus), I will effectively have 5 separate CAN networks, correct? that wont cause excessive computation or anything?
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

Not sure how much help this will be as our comfort zones differ but the following is how I would do it:

Firstly I would split it up, both in terms of hardware and software.

In terms of hardware I would have two platforms, an in-car platform and a development platform:

The in-car platform would be the type of thing mentioned above, a middle of the line embedded PC card running a real time version of Linux (TBH the real time bit is probably less critical these days with multi core processors being the norm but I'd probably still do it). It would connect to all the input sensors and the CAN busses and would run the data acquisition, algorithms and inverter control functions. It would run gdbserver to allow full debug access to the local applications.

The development platform would likely just be a laptop (if in car use is required) or a desktop. It would connect to the in-car platform via ethernet (WiFi could be used but unless there is some specific justification for it I'd stick with a physical cable). It would basically provide the development environment and HMI for the system. I would expect it to be only connected during development/debugging and be disconnected in normal operation.

Turning to software:

On the in-car platform I would split the application into 2, possibly 3 applications which would communicate with each other via a comms link (probably TCP/IP and, initially at least, probably JSON encoded to make it human readable for simpler debugging). These would probably run as deamons under systemd. The first would be an acquisition program and would read all the system inputs and send out a regular comms packet containing the latest data. The second would contain the main control algorithms, it would accept the sensor data packet, run the control algorithms and output a control packet. The control packet would go to the third program which would control the drives (and probably also send a drive status packet back - current temperatures, power, torque, speed, errors, etc). The last is the optional one, if simple enough I might include it with the control algorithms (having it separate is nice for reasons explained below). I'd either leave systemd to monitor and restart them if needed or add an extra watchdog process to do this. I might also use processor affinity and priority settings to dedicate a processor core to critical tasks.

Not mentioned above for simplicity I would also include TCP streams for diagnostic data and data logging in each program. The streams would contain all program data that might prove useful diagnosing unexpected behaviour but wouldn't go anywhere unless the development platform was connected. The logging would probably just be to disk file to again allow analysis of unexpected behaviour when the development platform wasn't connected.

The development platform would contain all your existing algorithm development tools plus cross compiler tool chains for the in-car platform programs and possibly some form of HMI/live data display/configuration app. The idea is that your existing tools would still be used to develop/tune the algorithms while also being able to use real data collected from the in-car logging or diagnostic streams. Once you were happy with the algorithms they would be compiled using the cross compiler tool chains and then pushed down to the development platform and/or debugged using the gdb debugger (bit of care needed debugging a live system but worth having the capability).

In terms of software I would do pretty much everything in C/C++. Firstly because I'm comfortable with it but secondly because there is a pretty good chance that you could then feed the exact same code through your simulation/algorithm development tools and also compile it to run on the in-car platform (keeping the drive control routines separate to the algorithms would probably make this easier although some form of wrapper code would likely be required either way). It may be possible to do exactly the same using other development languages but I don't have the experience to comment here.

The other advantage of the above is that it becomes relatively straightforward to move to a more embedded hardware platform in the future. The acquisition task could easily be split out to a dedicated hardware, either keeping the ethernet or moving to CAN communication. Similarly the control algorithms could be ported to an embedded processor in the same way once you have a good idea of resource requirement. Again using C/C++ from the start would make this a relatively simple task with a low risk of introducing errors.

It's a long time since I've seriously looked at LabView (25years maybe) but have just had a quick look. If you do use it the real time module may be worth a look (afraid I've no idea what it's like for doing real time control without it or whether it's justified though).

Hope that all makes sense and is helpful.

Edit - Having said all that I'm sure if you asked a dozen engineers about this you would get a dozen different answers. The main thing is to find a solution that you are comfortable with!
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

It is indeed a bit out of my comfort zone, but equal to the algorithm development & IP, this whole thing is an opportunity for learning in some areas I'm less experienced at and for that your perspective and that approach/writeup is immensely appreciated. Now just to settle up with some coffee and google and soak it in...

Having not yet fully absorbed the above, my thinking for an 'in between' approach is something like:
full industrial PC & display in the vehicle, CAN and analog IO via USB and external modules (just as close as I can get to plug and play), routines all running from python. would prefer octave as most of my experience is matlab but i dont think it really gets into automation/control. although there is the whole approach of building in those environments and compiling into C. simulink would definitely be overkill. codesys might (?) have more tools for 'plug and play' setup/configuration but looks like it would cost same as labview
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

Your in-between approach, hardware wise, is virtually the same as the platform I described above, it just has the HMI added. It's mainly the software that differs.

I may have missed a bit of the explanation/justification for my approach above so I'll just go back a little (apologies if I'm preaching to the converted).

Over the years I've come to realise that the actual hardware platform is often not that important (which really goes against the grain as a hardware guy). What is important, for anything involving algorithm development, is quality of data and how easy it is to use. Now that's not the most data, the fastest data, the highest resolution data but the most appropriate data to enable the best solution to be chosen or algorithm to be developed.

For me having access to all the measured data on your test rig vehicle, either live or logged, is more important than the exact hardware used to collect it. It may be your algorithms all work first time and there is no need to go round the loop again but if not having access to the real world test data can make the difference between getting to a working solution or not. Also without the data it's very difficult to determine whether any intermittent problems are due to noise, sensor errors/inadequacies, comms problems, latencies, etc or the algorithms themselves.

The data must be accessible - there is no point having full access to the data when the development system is connected only to find that all the interesting bugs show up when it isn't. Now this suggests that the development system should always be connected and that is one solution but I've often found that as the development progresses people (me included) are less likely to bother initialising everything before running a test. I've also found that the more complicated you make the core system the more likely it is to break so my preference is to have the core system as simple as possible and the development system separate (but always log enough data to be able to understand what happened). It's also really nice to be able to disconnect the development system, complete with data, from the test rig and take it somewhere more comfortable to work.

When developing algorithms I always try to have the same core code run in both the modelling/simulation environment and the target application, at least once real world testing starts. I also try to have the ability to play back the data collected from the real world system back through the simulator used to develop the algorithms in the first place (and ideally being able to compare the modelled result with the real world result) . This has the added benefit in systems like yours where you are unable set a break point when something interesting happens (well you could but if the car is travelling at that point in time it could be followed by another interesting, noisy, violent and probably expensive event!). By playing the data back through the simulator you have the opportunity to see exactly what the algorithms were doing, pause, repeat and even try alternative solutions/fixes. To me this is well worth the extra initial work setting up such a system (this is what I'm aiming for with the motor simulator, calculator and data logging threads on here which have already helped understand and improve the FOC motor control code).

I know that you can achieve the above with programs like Scilab using algorithms in C/C++ and am fairly sure Matlab would make it even easier to do. It's also quite likely that other languages python could be used in the same way (although I do get a little uneasy about interpreted languages in real time systems - however given the speed of modern processors and the relatively low update rate I guess you need (10ms??) it would probably be fine).

One final point about data, you can generate an awful lot of data from simulation and it's a fantastic way to start. At some point though you have to start validating that data against the real world and for me that should happen as soon as is realistically possible - so your plan of getting a test platform up and running makes an awful lot of sense.
User avatar
fuzzy
Posts: 3
Joined: Thu Mar 17, 2022 2:03 am
Has thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by fuzzy »

aesthetect wrote: Fri Mar 17, 2023 6:09 pm I am trying to figure out hardware and a topology for controlling 4 leaf motors independently - ie different torque / current signals to each.
This sounds like a fun project. I'm assuming each motor will drive a wheel on a 4 wheeled vehicle of some sort? You kinda hinted to this in a different post about ratio.

A somewhat related question is dealing with a independent motor per wheel and a software type differential system? Does the VCU handle this? (newbie question)
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

fuzzy wrote: Thu Mar 23, 2023 6:47 pm This sounds like a fun project. I'm assuming each motor will drive a wheel on a 4 wheeled vehicle of some sort? You kinda hinted to this in a different post about ratio.

A somewhat related question is dealing with a independent motor per wheel and a software type differential system? Does the VCU handle this? (newbie question)
Thanks! Making electric vehicles as fun and engaging to drive as possible is the whole idea here. Yes, each motor will drive one wheel in a fairly conventional looking road vehicle.

That software type of differential system is exactly the focus of the project - look into 'torque vectoring', and I think you will very much like what you find. Yes this will all be handled by a VCU, of some sort... identifying the best approach to that is what I'm trying to figure out here. :)

Pete9008 wrote: Thu Mar 23, 2023 10:55 am Your in-between approach, hardware wise, is virtually the same as the platform I described above, it just has the HMI added. It's mainly the software that differs.

I may have missed a bit of the explanation/justification for my approach above so I'll just go back a little (apologies if I'm preaching to the converted).

Over the years I've come to realise that the actual hardware platform is often not that important (which really goes against the grain as a hardware guy). What is important, for anything involving algorithm development, is quality of data and how easy it is to use. Now that's not the most data, the fastest data, the highest resolution data but the most appropriate data to enable the best solution to be chosen or algorithm to be developed.

For me having access to all the measured data on your test rig vehicle, either live or logged, is more important than the exact hardware used to collect it. It may be your algorithms all work first time and there is no need to go round the loop again but if not having access to the real world test data can make the difference between getting to a working solution or not. Also without the data it's very difficult to determine whether any intermittent problems are due to noise, sensor errors/inadequacies, comms problems, latencies, etc or the algorithms themselves.

The data must be accessible - there is no point having full access to the data when the development system is connected only to find that all the interesting bugs show up when it isn't. Now this suggests that the development system should always be connected and that is one solution but I've often found that as the development progresses people (me included) are less likely to bother initialising everything before running a test. I've also found that the more complicated you make the core system the more likely it is to break so my preference is to have the core system as simple as possible and the development system separate (but always log enough data to be able to understand what happened). It's also really nice to be able to disconnect the development system, complete with data, from the test rig and take it somewhere more comfortable to work.

When developing algorithms I always try to have the same core code run in both the modelling/simulation environment and the target application, at least once real world testing starts. I also try to have the ability to play back the data collected from the real world system back through the simulator used to develop the algorithms in the first place (and ideally being able to compare the modelled result with the real world result) . This has the added benefit in systems like yours where you are unable set a break point when something interesting happens (well you could but if the car is travelling at that point in time it could be followed by another interesting, noisy, violent and probably expensive event!). By playing the data back through the simulator you have the opportunity to see exactly what the algorithms were doing, pause, repeat and even try alternative solutions/fixes. To me this is well worth the extra initial work setting up such a system (this is what I'm aiming for with the motor simulator, calculator and data logging threads on here which have already helped understand and improve the FOC motor control code).

I know that you can achieve the above with programs like Scilab using algorithms in C/C++ and am fairly sure Matlab would make it even easier to do. It's also quite likely that other languages python could be used in the same way (although I do get a little uneasy about interpreted languages in real time systems - however given the speed of modern processors and the relatively low update rate I guess you need (10ms??) it would probably be fine).

One final point about data, you can generate an awful lot of data from simulation and it's a fantastic way to start. At some point though you have to start validating that data against the real world and for me that should happen as soon as is realistically possible - so your plan of getting a test platform up and running makes an awful lot of sense.
I think its mostly just that the hardware (and hardware side of the software) is where my lack of experience is, so I'm probably overly circling around on it and probably assuming it is more complicated than it is, and thus liking a combined 'all in one' hardware/software system like NI. Sure data is important (especially for troubleshooting in consistencies), but it will be better and accessible enough to keep running tests for most key aspects of algorithm development. So, just to say, I won't be doing that much modeling and simulation - practically none, despite that being where my real experience is. Also, given that the driving experience and 'feel' is the product, and that itself is practically impossible to model. I will definitely be 'crawling before walking' as far as testing though. But yes, simulink or labview would make the troubleshooting process downright pleasant by comparison.

interpreted languages on real time was one of my particular concerns, but yes, I'm expecting something like 10ms to be sufficient (edit: at least for my commands (I think), the leaf inverter requires some messages every 10 ms so I'm considering that the driving force), so I'm fairly comfortable with it. actually appears to be quite a bit of support for that kind of thing with python though. however labview has labviewRT where I can basically do object oriented programming that runs straight onto FPGA. (ive not used it, just found while Ive been researching).

I'm now figuring out components for my bench setup... which will not be 'labview money'... but gives me a chance to see how far I can get with the more proper electronics/DIY solution (ie as you have laid out). One thought is still maybe zombieverter and some kind of raspberry pi... use the raspberry pi for IO and algorithms as a piggy back on zombieverter?

edit 2:
raspberry pi was more just an example of whatever-cheapo-SBC, the thinking was just something peripheral and it is very linux/python friendly and could maybe just run algorithms there while zombieverter handled all the 'real time' pressure. interface via CAN?
also what do you think of this: pyRTOS - real time python...? looks like I could run micropython script and it would work for (soft) real time.
https://blog.adafruit.com/2021/06/04/py ... uitpython/
also looks like it runs on a bunch of STM boards (https://www.engineersgarage.com/what-is-micropython/)
just started down this rabbit hole but I am liking it..

Again, this is where my experience is weak, so I'm working through those notions along with your tremendously appreciated input and explanations. EG I still want/need to fully wrap my head around the capabilities and role that OKdo board could play, I think that may be similar role to the raspberry pi as I mentioned(?). This is where I am admittedly feeble, hence I keep talking about hardware probably just because I dont fully understand the options and differences (yet).

Anyway, wife took the kids to her moms for the past few days so I got a big chunk of unexpected time to dive back in and make some serious progress on the 240Z (which was greatly successful!) ...now back to this!
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

johu wrote: Fri Mar 17, 2023 7:23 pm When swapping the control boards for the OI aka Rev3 one you can assign different CAN ids for throttle control so they can be all on the same bus. Heck, you could even put the 4 torque values in the same message in different positions ;)
Would I be able to control 4 of them with OEM control boards via CAN through a single zombieverter VCU?

I just realized I had in my mind that would work for some reason and now that I actually put some thought to it, I'm pretty sure it would not...

My hesitation with using the OI control board would just be to avoid more complication than necessary (ref multiple pages of noob controller hardware questions above). But is there a sort of off the shelf 'plug and play' setup/settings that can be done to get going with the OI control board; e.g. use most aspects off the shelf, and then only have to mess with setting CAN IDs
User avatar
johu
Site Admin
Posts: 5682
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: VCU/controller for 4 motor setup

Post by johu »

The Nissan boards come pre-programmed with appropriate firmware and parameters. I also have one up for sale here that has all connectors soldered: viewtopic.php?t=2769
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
aesthetect
Posts: 21
Joined: Fri Jun 03, 2022 6:15 am
Has thanked: 4 times
Been thanked: 1 time

Re: VCU/controller for 4 motor setup

Post by aesthetect »

johu wrote: Tue Mar 28, 2023 8:10 am The Nissan boards come pre-programmed with appropriate firmware and parameters. I also have one up for sale here that has all connectors soldered: viewtopic.php?t=2769
Excellent - thank you. That one you have for sale is definitely of interest, I am probably going to hop on that and then buy a zombieverter VCU with support for my initial bench setup.

These inverter control boards work for gen 2, so it would work for 110 kW motor/inverters but not 160 kW?

Just to confirm, I would not be able to operate 4 leaf motors simultaneously (as is, via CAN, without open inverter control boards) with zombieverter VCU?
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: VCU/controller for 4 motor setup

Post by Pete9008 »

I'm probably doing the same as you here - I know little about your algorithms so may well be overestimating their complexity, processing requirements, need for debug access and so over complicating the solution.

If that's case it does open up other possibilities. If you are happy to work on the firmware in C/C++ it's possible that a VCU could handle the whole job. The main limitation is that the the CPU only has one core running at 72MHz (assuming it's the STM32F1 family - afraid I'm not too familiar with the Zombie) and no hardware floating point support. If that's enough to do what you need, and if you use the IO inverter board to allow them all to exist on the same CAN bus then it would be an option. If you need a bit more performance then it would be possible to offload that to a Pi and leave the VCU to just handle contactors, monitoring, etc.

Regarding the Raspberry Pi vs the OKdo board it was really the IO that caught my eye, for example the Pi 4 has 1 UART available while the OKdo has 8, the Pi has 2 SPI ports, the OKdo has 4, Pi has no analogue inputs while the OKdo does and so on. The UART and SPI in particular could be used to add CAN ports (either via serial to CAN dongles or MCP2515 type chips). Having said that it is harder to use the IO on the OKdo as a custom motherboard is needed, on the Pi you can just add shields. The best thing to do is get hold of some hardware and have a play.

On the real time side the simplest way to test it is to just generate an IO line toggle from whatever language you want to use and check it on a scope. If the worst case pulse output timing is regular enough, and has low enough jitter, to satisfy your algorithms requirements then go with it.

On the two options for controlling the motors.

Using the Leaf protocol has the advantage that you are using the motors in the way Nissan intended and so benefiting from the 1000's of hours they will have spent tuning the inverter, algorithms and motor to each other. The downside is that if you find that Nissan approach causes problems (for example any throttle ramps are too slow to suit the needs of your algorithms) then there is very little you can do about it. You also need multiple CAN ports.

The OI option on the other hand gives you much more control of what the motor is doing. If you find something that causes you a problem you have the ability to dive into the parameters, or even the firmware as it's open source, and fix it. You can also have as many motors as you want (within reason!) sharing the same CAN bus. The main downside is that it's not as mature a platform. For example until fairly recently there were still problems running above base frequency (search unwanted regen or acceleration on the forum). Hopefully that's all now sorted but I doubt it is ever going to be as well tuned to the motor or quite as stable as the OEM solution.
Post Reply