[clug] Canberra electric vehicles group - first contact

Paul Wayper paulway at mabula.net
Tue Feb 2 02:25:51 MST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/02/10 09:13, David Cottrill wrote:
> There are several electric cars in Canberra, two registered that I know of.
> I'm also looking at the motorbike option.
> I'm a member of both groups and the similarities are wide ranging,
> though unlike us the techies are in even numbers with those lobbying
> goverment.
> There is little interest in component development in that group because
> there are so many components needed to create a vehicle, and a shortage
> of experience in high power electronics. I can design and build a 200W
> audio amplifier but nothing on the scale of a 20kW switchmode controller.

That's generally true, but one guy at the meeting mentioned a $350 circuit
that you could put together which was a microprocessor battery management
system and charger.  It's $350 for the kit (and he has one spare if someone
wants it) to solder it together yourself.  It was equivalent to about a $1500
off-the-shelf circuit.

My impression from talking about the hardware hacking that some of the CLUG
members are doing was that generally the Canberra EV group is pretty keen on
DIY stuff like that.  Having a motor controller or BMS that is a kit that
hobbyists could put together for cheap, and possibly tinker with and improve,
was a good thing, and they were very keen to talk to the more knowledgeable
bods in CLUG about the possible applications for Arduinos and similar
microprocessors.

As you say, though, there's a world of difference between designing (even) a
20W amplifier and designing something that switches and regulates 400 amps (!)
at 144V or more (!!) and has to do so reliably and without fail across a range
of battery charge levels, temperatures and other conditions.

Dave Rowe has designed a (simple) BMS (http://www.rowetel.com/blog/?p=141) for
his own electric car - circuit and PIC assembly code are open source.  He
links to the very interesting Tumanako project (http://www.tumanako.net/),
which is aiming at open sourcing the whole drive and recharge control hardware
and software, and although they only have the BMS done so far it's much more
advanced than the standard battery management - they monitor each cell
individually and control charging, although I'm not sure what else it does.

My crazy ideas lobe has come up with the following thoughts on battery management:

Fundamentally pretty much all batteries are fast to discharge and slower to
charge.  This is improving with Lithium batteries but taking the load from
regenerative braking is still dumping too much power into the batteries too
quickly.  A couple of multi-farad capacitors in the charging system can grab
this power in the short term, though.  Including a battery charging circuit so
that all you have to do is plug in an extension cable makes the vehicle simple
to charge wherever you go.  Feeding both the big capacitor bank and the
charger circuit into the battery management system makes sense.  Using the big
capacitor bank to power the vehicle as it takes off in preference to using
battery power will also save battery life.  The BMS can also have an emergency
resistor bank to dump power on if regenerative braking is generating too much
power for the system to deal with.

Individual cell management starts to make sense at this point.  This is what
Tesla does - each (battery of cells) / cell is individually addressed and
charged (and possibly discharged) by the BMS / motor controller.  Normal
battery chemistry means that one (varying) cell is always going to be the
lowest charged; if you draw too much charge from this cell you're going to
kill it, if you charge the whole battery so that every cell is at maximum then
you've just cooked every cell but the lowest.  By addressing each cell
individually you can avoid most of the worst of these problems.  It might also
make sense for the motor controller to be given selective access to the cells
- - the BMS doesn't route power to the controller from the lowest cell, thus
extending cell and battery life.

After the meeting Misha, Peter and I talked in the car park about some of
these details.  Peter said he was generally against complicated computer
controlled things, but that he was manually turning the air conditioning off
when he needed power and on when he wanted to slow down more than just
coasting.  My feeling is that there's yet another thing that you can regulate
with software to get the best out of your car.  You could have a bunch of
switches - "maximise range", "maximise power", "maximise ride smoothness",
etc. - which then back onto a set of tunable controls - maximum acceleration,
accessory usage, regenerative braking cut off point, etc. - which might also
be controlled with external data - the GPS determines you're a long way from
home and sets you up for increased range, etc.  It's a huge scope for green
fields stuff.

The best part, to me, is that no commercial car manufacturer is _ever_ going
to attempt these things.  This is just too out there, too clever, too
demanding on the user to understand what the car is capable of doing - the
amount of detail you get in the Prius control panel (you see what it's doing,
but you can't change any aspect of its behaviour) is the most you're going to
get, maybe with a 'long range' button.  We've got the opportunity to make
things that are going to add so much value that everyone wants one, and we can
make it open source.

By Stallman's Beard, I'm stoked about this!

Have fun,

Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAktn758ACgkQu7W0U8VsXYLYoQCfQFtcSR1hT0pXpyHdZQ0tLht4
msMAoI3G1jvdnrfwNpQraWAbXbiZ4J/x
=e56N
-----END PGP SIGNATURE-----


More information about the linux mailing list