[clug] Canberra electric vehicles group - first contact

Wed Feb 3 14:02:02 MST 2010

I think that was the idea I was talking about - have the supercapacitors as
part of the battery management system.  They would receive power dumped to
them from regenerative braking, and that would be used in preference to
battery power when starting up again.  Then the BMS would recharge the
batteries from this excess power if you'd just pulled up and switched off the car.

BTW, most battery packs I've seen are simply cells linked in series.  What
about if each cell was linked to the BMS directly?  More cables, and you'd
have to some kind of in-BMS switching of large amps to either switchmode the
voltage from cell volts up to motor volts, but then you could control charging
directly, you could isolate bad and preserve low cells, and a bunch of other
smarts to make the cells as a whole last longer.  Is this electrically
feasible?  Or is making something that switches ten 3.2V 200A sources plain
ludicrous?  Or just too bulky or expensive?

> On 03/02/2010, at 11:08 AM, jm <jeffm at ghostgun.com> wrote:
> 
>> On 3/02/10 10:17 AM, Alex Satrapa wrote:
>>> Fewer controls. Focus on software that is smarter. If the driver
>>> pushes the pedal to the floor, *that* is when you switch to the
>>> "maximum power" programme. Once the pedal comes up and stays at a low
>>> setting, *that* is when you switch to the "economy" mode.
>>>
>>
>> yes and no. We're still in the exporation phase. Here more option are
>> better for tuning and selecting the optimal configuration. Once you
>> know what the optimal configurations are and how to detect
>> automatically which ones to use then you start to eliminate tuning
>> options.

Which is why I proposed the idea of having a set of simple switches as the
first interface, which could then be opened up to the intermediate set of
knobs, which would then give way to the advanced set of editable parameters.

I'm all for simplicity of interface, but as Jeff says this is the time when
we're still learning what works and what doesn't - and for this time we need
more control.

>>> The user shouldn't need to understand what the car is doing. The car
>>> should understand what the user is asking of it, and deliver to the
>>> best of its abilities.

Both of those are one side of the problem.  What you need is an understood
interface that both car and driver use to communicate to eachother.

Any driver of a manual car quickly learns (after the bunny hops and stalls)
that you have to get the revs up, ease the clutch out gradually, and then
control your speed when it grabs completely.  The driver learns what the
operating parameters of the car are.  The accelerator pedal isn't really an
acceleration control - it's more like a 'how much power do I want the engine
to put out' control.  When you've done accelerating and want to coast you
don't put the pedal back to zero, you ease up so it maintains the power output
equal to the drag on the car.

Cars in turn are becoming smarter.  And, yes, when we build the controls we
can design a car that can turn off the air conditioning when you want to
accelerate and control your wheel traction when it detects slippage and so
forth.  But how does the car know what the driver wants?  The three main
controls are brake, acceleration and steering wheel - after the obvious
slower, faster, left or right, it's actually guesswork.  Is the driver pushing
the accelerator hard and for a long time because she's a rev-head or because
she's towing a heavy load up a hill?  And so what?  What should the car do in
one of those scenarios that it shouldn't do in the other?

So where I'm going here is that the car has to do some work of interpreting
the signals from the driver, and the driver has to know that the car is going
to do that.  If the driver knows that the car is going to interpret "flat to
the floor" as different from "90% full on" (while both, in a petrol driven
car, might mean the same actual amount of acceleration), then she's going to
use that level of communication to signal to the car when she wants to get
away from some moron at the lights, and when she wants to get up the steep
driveway.  If the car makers don't tell her that there is a difference, she's
never going to guess unless the car tells her.

Just by fitting a GPS the car can work out a bunch of extra information.  Am I
far away from home and heading in that direction?  Am I going to one of my
owners regular destinations?  Am I going somewhere where I've been charged up
in the past?  Am I on a piece of 100 km/hr road?  But IMO the car still needs
to communicate some of the decisions based on this information back to the
driver, who still needs to be able to override it based on her own plans of
where she's going.  The car doesn't know that she has different plans, or
might not know that there's roadworks up ahead.

>>> Do we expect all book readers to have an intimate understanding of
>>> the paper-making and binding process?

See that point?  That point was where you let yourself go a bit too far :-)

I mean, yes, I expect most people able to read for themselves to know not to
tear pages out of books once they've read them.  If they want their books to
last they don't bend the spines back, they don't cut those little threads you
sometimes see in the middle, they know that cheap paperbacks and
encyclopaedias are handled differently, and they don't try to pull the cover
away from the spine.  You don't need to know paper-making and book-binding,
but it sure helps if you want a book to last.

The problem there is that you're talking about the users knowing about the
manufacturing process, rather than the details behind the 'turning pages over'
interface.

Jasper Fforde often includes errata and extra information about his books on
his website.  So that's an extra interface which most readers won't have
tried.  Should we expect the book to carry around a SIM card and an internet
connection just so that no user ever has to understand the interface between
his books and his website?

(There's a frightening side-thought.  "1984" in the age of the Kindle - your
dictionary is just upgraded silently and automatically, so that words you
thought were there yesterday just don't exist anymore.  And your dictionary no
longer contains stuck-together pages of a hidden manifesto; all contents are
scanned and reported by Big Brother.  Even what words you look up can be
reported.  Yay. :-( )

>>> The "value" in the future is going to be cars that take care of
>>> themselves and tell the user when stuff needs to be done. Estimate
>>> the range at current usage, and point out to the user, "if you slow
>>> down by 5km/h, you'll get 20km more range from this charge."

That kind of thing is a great idea.  That's the car communicating with the user.

>>> Which brings me to another point: generally speaking, more choice is
>>> bad. Giving people too many options to make in any decision will
>>> hamper the decision making process.

Where is the point of 'too many options'?  How do we even know where that is
when we're building a new device?  All I'm saying here is that we can provide
any interface we like, from the most simple to the most complex, but we have
to have one.  Experimenting with our own things is the only way we find out
what will work and what won't.  And I'm in favour of providing an initial
simple interface (a few switches) with gradually increasing layers of
complexity underneath.

>>> At some point, we're going to have cars on the road that are powered
>>> by open source systems, and we're going to have to start legislating
>>> about who has authority to authorise particular software to be used
>>> in cars on public roads - and indeed, to restrict who is allowed to
>>> load new software onto a car controller.

And there are already really well understood processes there in the automive
world.  You can't just strap a new air intake or exhaust system on - or more
relevantly plug in a new timing and injector chip - you have to either get it
approved or it's an illegal modification to the car.  But I see it as a very
"Apple" way of looking at the world to say that therefore we need to only
allow authorised software on cars, and the car hardware needs to be
specifically locked down to prevent 'unauthorised' software.

Besides, the automotive manufacturers are already going to do that.  Let's
proceed as if they're completely irrelevant to building our own EVs and see
how we go, eh? :-)

Have fun,

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

iEYEARECAAYFAktp5EoACgkQu7W0U8VsXYKlNACfc3DshnhjyMiLnDdamcZXkHEo
Ka0AoJfPcEvOYXOIDc9IKN9Zq8FqX7/y
=K7ZL
-----END PGP SIGNATURE-----