# Starting design & build of the production-grade EV management system



## valerun (Nov 12, 2010)

Hi All, 

My team is starting the design work on an EV control and visualization system with the objective of building something similar to the systems you will find in production EV cars like Leaf, Volt, Tesla.

The plan is to keep the design open-source but commercialize on kits and selling complete units to those who do not want / have time to DIY. This will also be a part of our turn-key EV conversion services (see http://www.eMotorWerks.com).

I'd like to open this thread for your suggestions on functionality, design parameters, etc. Hope that together we could build something that all DIYers will be able to use. 

Here's what has been decided so far:
1. The system will be the main interface to the EV from the driver. It will replace all the discreet gauges normally used in DIY builds. 
2. It will connect to the 2 main components in the EV - charger and controller. Will also connect to BMS if present
3. Data acquisition layer will be based on Arduino architecture (ADCs to capture voltage / current / temperatures, etc.
4. Certain low-level control tasks and tasks requiring persistency of data across sessions to be controlled by Arduino (battery heating / cooling, AH metering in and out of the pack, etc).
5. Remaining processing and visualization to be done in an Android Tablet such as Samsung Galaxy tab (1024x600 screen resolution) or similar. This would include range calculations, BMS displays, etc). 
6. The tablet will also be used as the main entertainment and navigation center for the converted cars
7. The tablet will communicate to Arduino data acquisition layer via bluetooth interface. This will allow for seemless user experience and ability to remote control / monitor.

Comments / suggestions welcome.

Thanks,
Valery.


----------



## frodus (Apr 12, 2008)

Consider having the arduino also take in RS232 and other types of COMM (like from some controllers and chargers) as well as those analog signals. Also consider integrating with some of the BMS out there (Manzanita, Elithion)

Make it scaleable to different sized displays (Archos has 3.2, 4.3, 5, 7 and 10" versions) and make it user configurable on what is displayed.

Disable changes to settings while the vehicle is moving. The more and more people integrate these fancy displays and entertainment devices into their cars, the more of a distraction they are. Keep it simple. If a user wants to blow down into each cell level on a BMS, then make them stop. All they need while driving is a warning.


----------



## Salty9 (Jul 13, 2009)

Is there anything here you can use?

http://www.janspace.com/b2evolution/arduino.php


----------



## valerun (Nov 12, 2010)

Salty9 said:


> Is there anything here you can use?
> 
> http://www.janspace.com/b2evolution/arduino.php


VERY cool! Thanks Salty! 

Definitely some things to incorporate. Those displays are rather expensive though ($80-90 shipped) - which is getting close to the Android Tablet that has better screen, ability to do some advanced math fast, and built-in accelerometers, GPSs, etc.


----------



## valerun (Nov 12, 2010)

frodus said:


> Consider having the arduino also take in RS232 and other types of COMM (like from some controllers and chargers) as well as those analog signals. Also consider integrating with some of the BMS out there (Manzanita, Elithion)
> 
> Make it scaleable to different sized displays (Archos has 3.2, 4.3, 5, 7 and 10" versions) and make it user configurable on what is displayed.
> 
> Disable changes to settings while the vehicle is moving. The more and more people integrate these fancy displays and entertainment devices into their cars, the more of a distraction they are. Keep it simple. If a user wants to blow down into each cell level on a BMS, then make them stop. All they need while driving is a warning.


Great points - thanks. Android is good about scaling graphics (to a degree) so hopefully scaling won't be a super-issue. 

Different types of input are definitely great options. E.g., ethernet for Soliton1, etc. IN the future, probably CANbus, too.


----------



## frodus (Apr 12, 2008)

valerun said:


> CANbus, too.


Now ya see where I'm goin 

Both my controller (Curtis 1238) and my BMS (Elithion) do Canbus.


----------



## Roy Von Rogers (Mar 21, 2009)

Something that struck me on your original post, that your system will replace the discrete gauges, and later you say it will also serve as an intertainment center.

Anyone driving a vehicle needs to know whats going on as to speed etc, and not be tempted to do otherwise, not to mention its illegal.

Roy


----------



## valerun (Nov 12, 2010)

Roy Von Rogers said:


> Something that struck me on your original post, that your system will replace the discrete gauges, and later you say it will also serve as an intertainment center.
> 
> Anyone driving a vehicle needs to know whats going on as to speed etc, and not be tempted to do otherwise, not to mention its illegal.
> 
> Roy


Hi Roy - I meant discreet EV-specific gauges. All the original vehicle instrumentation stays as is (speedo, tach, etc, etc).


----------



## DJBecker (Nov 3, 2010)

We already do something similar to this.

I implemented OBD2 on CAN bus for our EV motor controllers and instrument cluster controller.

CAN bus allows us to plug in a OBD2 reader with bluetooth (as little as $13 if you get lucky on FleaBay). If it reports using OBD2 protocol, you can immediately use dashboard programs such as Torque on Android. Or use single-purpose devices such as Scan Gauge.

Our original motor controller started with a Mega1280 board, and used a SPI-attached MCP2515 CAN controller with MCP2551 transceiver on a prototyping shield. (These only take up a tiny part of the shield.) I wrote the CAN software to be easily added to the Cougar controller -- it operates entirely in poll mode, with just a single call from the main non-interrupt loop. This might be a useful code base to start from if you are using an AVR.

We've since moved on to STM32 processors, originally using a VL-Discovery with the same MCP2515 and subsequently designing our own board to use a '105 chip with its two on-chip CAN controllers. This board is a multi-purpose one that has both an interface to our gate driver board when it has motor controller firmware, and has a handful of inputs and low-on-resistance MOSFETs for driving indicator lights and gauges from PWM outputs.

The processor and inputs may optionally be electrically isolated, with power from a DC-DC converter and the CAN transceiver connected through a Si8421 digital isolator. (This turns out to be less board area and a much easier to buy combination than one of the specialty isolated CAN transceivers.)

The STM32 is far more sophisticated than the AVR. But it's a major PITA to program, far more complex than the AVR with incomplete documentation and buggy tools.


----------



## valerun (Nov 12, 2010)

DJBecker said:


> Our original motor controller started with a Mega1280 board, and used a SPI-attached MCP2515 CAN controller with MCP2551 transceiver on a prototyping shield. (These only take up a tiny part of the shield.) I wrote the CAN software to be easily added to the Cougar controller -- it operates entirely in poll mode, with just a single call from the main non-interrupt loop. This might be a useful code base to start from if you are using an AVR.


DJ - this is AWESOME! Thanks for telling us about this. Yes, having that as a starting point would be super-cool. Also, I agree that making everything available through OBD2 port is probably the way to go! 

BTW, why did you decide to build your own circuits around CAN controller / transceivers? Would Sparkfun's http://www.sparkfun.com/products/10039 do the same thing?

PS. Just installed the Torque app on my Galaxy Tab. Neat. Do you know if one can design their own TYPES of gauges, though? For example, I'd like to be able to create a bar chart of 20 bars corresponding to 4-groups of cells for voltage monitoring etc...

Thank you again for sharing! I'd love to learn more about your codebase, etc.

Valery.


----------



## DJBecker (Nov 3, 2010)

valerun said:


> DJ - this is AWESOME! Thanks for telling us about this. Yes, having that as a starting point would be super-cool. Also, I agree that making everything available through OBD2 port is probably the way to go!
> 
> BTW, why did you decide to build your own circuits around CAN controller / transceivers? Would Sparkfun's http://www.sparkfun.com/products/10039 do the same thing?


I posted a comment there about their design choices. One significant point is that they didn't get the SPI signals from the ISP connector, so there is a problem using that shield with the Mega where the SPI connections are in different locations.

Even if that shield had existed when we started, it wouldn't have served our purpose. The MCP2515 is only an 18 pin part, and takes only 4 or 5 wires to hook up to the host processor SPI. Another handful of wires for the clock connection and 8 pin transceiver and you are done. Most of the prototyping shield area is used for signal conditioning -- resistors and capacitors for the input signals, logic level MOSFETs for the outputs. Those take a lot more work and wiring care to get right.

The big advantage of using CAN+OBD2 is that you move into the standards-based world. You don't have to design everything yourself, all at once.

It's also the least expensive way to get a touch screen display system. Better, you won't have to do anything to have a bigger, faster, better display system available next year, and the following year. (Yeah, Tegra 2)

Torque on Android gives you great looking gauges out of the box. In well under an hour you can have pages configured to display your own CAN PIDs (operating parameters) with custom labels and conversion factors. It's not exactly what we would design as an EV display system, but it's a big step there with almost no effort.


I have much less enthusiasm for non-OBD2 CAN implementations such as OpenCAN. CAN brings no magic by itself. Many parts are badly considered, especially addressing. If you aren't getting some significant benefit, such as working with existing displays, it's not worth the trouble of using. (And OpenCAN? Really? What am I going to do, hook my car to my machine shop network at home and process control at work?)


----------



## DJBecker (Nov 3, 2010)

valerun said:


> PS. Just installed the Torque app on my Galaxy Tab. Neat. Do you know if one can design their own TYPES of gauges, though? For example, I'd like to be able to create a bar chart of 20 bars corresponding to 4-groups of cells for voltage monitoring etc...
> 
> Thank you again for sharing! I'd love to learn more about your codebase, etc.


I don't think Torque can do that right now. But it may in the future. The developer keeps adding great new features, almost as fast as people suggest them. He obvious loves doing it, as it's free for the basic version and only $5 for the full version.

I have a few versions of the code.

The AVR versions are a little contorted to make it possible to add onto the Cougar controller. I would probably get a failing grade in any programming class for the "bad" design decisions. The code is in a single source file and one header (to make it easy to 'drop in'). Everything is done in polled mode (to avoid interfering with the real-time work). The initialization is done in the first call to the poll function (so we only have to add one line to the Cougar source). The SPI and MCP2515 code is mixed together (to make it as small as possible). Functions work on global variables and structures, with few passed parameters (smaller, faster compiled code with minimal stack use. We don't need to support threads, multiple devices or interrupts.)

Oh, I should note: the AVR versions are *not* written for the Arduino software environment. They are for a stand-alone C environment.

The ARM version is "cleaner", but grows in source and generated code size because of it.


----------



## valerun (Nov 12, 2010)

DJBecker said:


> I have a few versions of the code.


I'd love to take a look at the AVR code. Even if not directly usable in our environment, it would be super-helpful to see the most optimal way you found to do things!

Thanks!
V


----------

