[clug] Canberra electric vehicles group - first contact

[jm]

On 3/02/10 10:17 AM, Alex Satrapa wrote:
> Other alternatives that have been explored elsewhere involve using a hydraulic motor to drive the wheels. You have one big-arse electric motor powering the hydraulic pump, which then drives the wheels. You then have a closed can full of compressed air with a hydraulic piston, which is used to store the energy from slowing the car down.
>
> When starting the car up again, the energy from the compressed air tank is used to drive the hydraulic motors.  Alternately, use a flywheel.
>    
I think Paul really wants a super-capacitor not a normal capacitor. Not 
much of a difference in the name, but a big difference in how they function.

I have heard of compressed air being used on buses for regenerative 
braking successfully.

> 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. However, 
these parameters are still likely to be available for tuning through a 
engineer's/mechanic's interface. The modern car actually has more 
variables that are tunable than those of twenty years ago. You just 
don't see them. The early IC car had a manual timing advance which was 
replaced by vacuum advance and now computer control. The modern car 
however has more variables which are controlled by the engine management 
system that the early car. You still get the "sports mode" button on 
cars with automatic transmission, and the ability to turn traction 
control, etc on and off. This is no different than Paul's mode button.
>>   This is just too out there, too clever, too
>> demanding on the user to understand what the car is capable of doing
>>      
> 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.
>    
This must explain why people can't even seem to change a tyre these days.

> A computer user shouldn't have to know about microprocessor architecture in order to look up recipes for apple crumble.
>    

They do need to know how the program functions (at a high level) though.
> Do we expect all book readers to have an intimate understanding of the paper-making and binding process?
>
>    
I would expect them to be able to read the lanuage the book is written 
in and to be able to turn the pages, etc.

>> 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.
>>      
> 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."
>
>    

You know better that the car, at least at the moment, what the road 
ahead holds.

>> By Stallman's Beard, I'm stoked about this!
>>      
> 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.
>    

True, it just confuses people. This is why once your done exploring the 
options as mentioned above you trim down the presented options as much 
as possible. Presenting differing numbers of options at each layer, eg 
drive, mechanic, enginneering interfaces, with raising complexity at the 
lower levels. The drive may still be given a "sports mode" option. For 
comparing various configurations having five or so global settings, ie 
mode 1,2, .., or 5, would be about right. Allowing you to tune gear 
selection, throttle curves, regenerative braking, tracking control, etc.
> 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.
>
> As we move into a "drive-by-wire" future for automobiles, there's going to be more focus on safe software. The walled garden will be necessary to ensure public safety. Such regulation will probably take a few fatal deaths by lithium-fuelled fire, but it's inevitable. Lithium batteries are dangerous. High voltage electricity is dangerous. Make sure to take into account the process of loading new software into the car, and the mechanisms by which you can prevent malware from sabotaging vehicle or public safety.
>    

For public roads it's likely that there will have to be some form of 
certification for the software as part of the ADRs that already exist.

Jeff.