[brian_]

I have attached a pic of one of the motors in the subframe, you forget how small the mini is, the subframe is tiny or the motor is massive! With some mods I think I can get the output shaft of the motor to align with the hole in the subframe for the drive shaft. I will be designing the motor, inverter, coolant pump mounts in CAD and most likely get them laser/plasma cut. Saves me time (I have a 5 month old I need to play with).

Once I have the motors mounted, the next step would be to get the inverters working...

I understand the importance of getting the motors mounted to be able to run them, and that there are limitations on how the motors can be located, but have you considered how their mounting will work with other components?

One potential advantage of this dual pancake motor configuration is that there should be room between the motors. In a small front wheel drive car not designed to accommodate a battery, it would be good to be able to one pack of battery modules in the front, and that could be between the motors... but is the battery module design known yet?

 

[brian_]

Part of the problem with those motors is that they don't have back plates and are designed to be bolted together. Not a huge problem, but he'd have to have individual back plates machined for each motor to be able to split them.

YASA's product page for the 750 shows front and back plates (perhaps needing only a cover at the shaft), but of course the motors can be purchased in various configurations. Unfortunately the photos from the classified ad (and the discussion which preceded it) are now gone, so I can't see what these motors look like on the back.

Looking at the original transaxle, it appears that these motors will need to be installed back-to-back anyway to get roughly original axle shaft lengths. I don't know how much shorter the relatively narrow-track Mini could tolerate.

 

[brian_]

I am currently looking through the files and discovered the below block diagram showing PDU HV connectivity so the CAN links are not shown but the inverter, charger, battery, and vehicle management unit (VMU) are. I have all the parts other than the VMU, and this is a problem as the throttle input goes from this VMU to the inverters. Do you think it would be too much of a challenge to develop a VMU of my own?
...
The other option is to reprogram the inverters to run on analogue input and not link the components through CAN but I will lose a lot of the functionality and safety features of the current design. What do you think?

Given that there are separate left and right motors, I think it would be difficult to build a sufficiently capable control system, unless you have substantial ability to add programmed functionality to the motor controllers. For example, Curtis Instruments has controllers which are designed to be able to communicate and to coordinate control of two motors, so one takes the analog accelerator pedal input and serves as the control master, while the other controller gets its commands from the master and acts as a slave; each controller powers a motor. The intelligence needs to be somewhere, and if that's not the motor controllers I think you need a VMU.

 

[brian_]

The Sevcon inverters are currently programmed to work in the same way, ie one is the master and the other is the slave. The master would have been receiving CAN messages from the VCU that it would decode and share with the slave inverter.

It's good to hear that you're not missing critical logic. Now it would help to know what else the VCU does...

Problem now is that I do not have the VCU so I will have to take the output from the throttle pedal, convert it to CAN messages that the Master inverter would understand. I would think you would have to do the same for any leaf inverter for example, so its possible, question is if i can do it with my limited knowledge. I have heard its possible to do this with Ardunio, and there is a lot of info on Ardunio on the net...

Although working in an unfamiliar technology is a challenge, I think you have a similar challenge whether you build up an external device (Ardunio or otherwise) or you modify the Sevcon programming. It might be easier to manage if your work is only in the external device, isolated from the Sevcon programming; you can also be sure that a suitable external device can do anything the VCU did, but it's not obvious that the Sevcon controllers will have all desired input and output capabilities.