[clug] Canberra electric vehicles group - first contact

[David Cottrill]

Why not decentralize the capacitors and put them into the battery  
management system which typically has one module per battery or group  
of batteries. This means that the sudden surge of power stays within  
the existing power structures put there to deal with it.




On 03/02/2010, at 11:08 AM, jm <jeffm at ghostgun.com> wrote:

> 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.
>
>
> -- 
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux