電気に関する知識はあまりないので、可能かどうか分かる方お教え願います。
　�@急速充電　現在のガソリン補給と同時間程度でできないか？　コンデンサー・・・
　�A電波を電気に変換して充電できないか？　　鉱石ラジオ・・・
　�Bリチウムイオン電池より高性能な電池はあるか？　温度差・・・　
　

�@急速充電　現在のガソリン補給と同時間程度でできないか？　コンデンサー・・・

ガソリン補給と同じかどうか判りませんが、スーパーキャパシタ（コンデンサ）なら大幅に時間短縮できると思います。

�A電波を電気に変換して充電できないか？　　鉱石ラジオ・・・

電磁誘導を利用した非接触充電はすでにあります。この場合、距離はかなり近くに限定されますが、共鳴方式というのがあって、走行中の自動車に充電できる可能性があるそうです。
http://techon.nikkeibp.co.jp/article/WORD/20090501/169640/
それが実現すれば、充電スタンドで一気にフル充電する必要もなくなりますね。

�Bリチウムイオン電池より高性能な電池はあるか？　温度差・・・　

確かに、エネルギー密度、メモリ効果の少なさの点から、現在はリチウムイオン電池が主流ですが、一方で充電時に極めて精緻な電流制御が必要である（一気に充電できない）ことや、満充電時の電極の分子構造の不安定さと言う弱点もあります。

なので今後は、金属リチウム電池や、スーパーキャパシタのエネルギー密度を更に上げた次世代キャパシタの開発に期待されます。
http://www.projectev.info/2009-06-26-20-28-36/37-basic/83-battery

ありがとうございます。
皆さんの知識の豊富さに圧倒されそうですが、とても楽しいです。
フリーエネルギーで検索すると結構面白い？半分？？というような内容のものが見られ
ます。　エジソンに敗れたニコラ・テスラが今復活したら電気事情は変わるかも・・・

間違っていたらご指摘欲しいです。他の方の意見が気になります。
> 　�@急速充電　現在のガソリン補給と同時間程度でできないか？　コンデンサー・・・
出来ない。現状の急速充電では発熱が問題になるのでエアコンで冷却しながら充電している。
思うに、５０Ａ以上の大電流なので電線での発熱が多いのか。電線の発熱はコンデンサでもかわりないハズ。
倍速充電では、エアコンは動いてなかった。
ちなみに、燃料電池車でも７０ＭＰａの急速充填では発熱が問題になるので、水素ガスを冷やす対策をしている。
> 　�A電波を電気に変換して充電できないか？　　鉱石ラジオ・・・
出来ない。電波は１００万分の１Ｗくらい。充電には１００〜１０００Wくらいたぶん必要。
太陽電池だと、屋根、トランク、ボンネットくらいの面積があれば、何とかなるやも。
> 　�Bリチウムイオン電池より高性能な電池はあるか？　温度差・・・　
無い。
質量あたりのエネルギー密度、体積あたりのエネルギー密度、価格あたりのエネルギー密度、メンテナンス性、動作温度範囲、耐久性、安全性などそれぞれの性質でリチウムイオン電池より高性能な電池は有る気がしますが、車載用としてはリチウムが最適だと思います。

ありがとうございます。
人工衛星の太陽電池でつくられた電気はどうやって地上へ送るのでしょうか？　
××計画って何かあったような気がするんですが・・・
電線を使わず電磁誘導での急速充電も同じように発熱で無理でしょうか？　　
電気かみそりとか・・・　　常温超伝導が可能になったら・・・・

> 人工衛星の太陽電池でつくられた電気はどうやって地上へ送るのでしょうか？　
ググったら宇宙太陽発電計画と出ました（ｗ
マイクロウェーブで送信するんじゃありませんでしたっけ？
あとはレーザーを使う方式とか。

> 電線を使わず電磁誘導での急速充電も同じように発熱で無理でしょうか？　　
急速充電での発熱って、結局蓄電する物やその経路の抵抗が大電流で発熱するからでは。
つまり導線は常温超伝導の物質で作成し、内部抵抗の無いような蓄電池が無いと発熱は必ず起こるのではないでしょうか。

> 電気かみそりとか・・・
MCタイチ様の「電磁誘導を利用した非接触充電はすでにあります」と言う奴ですね。
道路全てに非接触型送電装置が埋め込まれればそもそも充電スタンドや急速充電の必要も無くなって…。
工事費は幾らかかり、税金はどれほどになるのか（ｗ
でもいずれこうなってくれると給油の必要性が無くなっていいと思うのですが。

> 常温超伝導が可能になったら・・・・
そもそも12Vの電池を10個直列して120Vを得るなんて事をしなくてもよいモーターができそうですね。
知人に電気自動車の話をしたら、「冷やせば幾らでも電流流せるから電圧高くする必要ないし」と言われました。いわゆる（昔の？）リニアモーターカーと同じ考え方ですかね。
どうやって冷やすのかと聞いたら自分で考えろと言われてしまいましたが（ｗ
常温超伝導物質ができれば冷やす必要の無いモーターが作れるわけですから、60Ah20Kgの鉛蓄電池でも5個並列300Ah100Kgのシステムを組む事ができるわけで。
と言うか電圧気にしなくてよいのですから、リチウム電池で3.5V700Ah20Kgなんてのが売ってますよ！これならミラEVより航続距離が出せそうです！

次のキーは新型の電池より常温超電導物質かもしれませんね。

電気に詳しい方、おかしなところはツッコミお願いします。

私も電気に詳しい訳ではありませんが、流す電流が高ければ高いほど損失は大きくなります。
だから同じ電力を使うのであれば、できるだけ電圧を高く、電流を低く抑える設計をします。
例えば、コンバートミラは240Vまで直列に繋いでいますし、i-MiEVは確か300V台まで上げています。送電線が一旦高圧にしてから流すのも同じ理由です。

抵抗が0の場合、電流が大きくてもロスは無いのではと思ったのですが。
それと、コンバートEVで高い電圧を必要とするのはモーターに大電流を流すためで、ロスを減らすためではないと思います。
モーターは電磁石を使用しますが、電磁石の磁力は電圧ではなく電流によるので、その電流を得るための電圧なのだと思っていました。

ただ、モーターは普通の抵抗扱いするべきものでは無い様で、超電導物質ができても、やっぱり高い電圧は必要そうです。

抵抗ゼロといういうのは、絶対零度とかじゃないとありえないと思うんですが（＾＾；

私が損失と言ったのは、モーターにたどり着く前の経路（例えばバッテリーやモーターのコントローラ）を念頭においての話です。
ただ、三菱自動車によれば、モータ自体も高い電圧をかけたほうが効率は良いらしいですね。
http://www.ev-life.com/allofev/vol05/index02.html

> 抵抗ゼロといういうのは、絶対零度とかじゃないとありえないと思うんですが（＾＾；
従来の超電導物質は、ヘリウムが液化する温度である、「絶対零度に近い低温」で超伝導状態でした。
最近は常温超電導物質というのが発見・開発されています。ただし、送れるエネルギーが低いとか曲げに弱いとかが開発課題らしいです。
> 私が損失と言ったのは、モーターにたどり着く前の経路（例えばバッテリーやモーターのコントローラ）を念頭においての話です。
> ただ、三菱自動車によれば、モータ自体も高い電圧をかけたほうが効率は良いらしいですね。
あまり電圧を高くすると、絶縁がもたなくなるのも問題です。
汎用の電線の仕様は絶縁耐圧は６００V、それを超えると６ｋVです。
ヨーロッパかどこかがＥＶの電圧を４００Ｖと主張しているのは、
このあたりが一つの根拠なのかも知れませんね。

リニアモーターカーのような自動車(空中に浮く：SF映画でよくみるような）が
できる可能性はあるのでしょうか？
ただし、電磁波は身体にはよくないでしょうけどねぇ・・・

少なくとも地磁気と反発させて浮かぶような車は作らないのではないかと思います。
浮いていると言う事は、装置が故障した際落下する危険性がありますし、磁気浮上で浮く場合、接地していないのでブレーキをどうするかが問題になりそうです。
もし浮かぶような車ができるとすれば、全く違う原理ではないでしょうか。

趣味人が作る可能性はあるかも知れませんが（ｗ
利用するのが地磁気とかになると、物を浮かべるには弱そうなイメージがありますが、実際はどうなのでしょう？

> 少なくとも地磁気と反発させて浮かぶような車は作らないのではないかと思います。
> 浮いていると言う事は、装置が故障した際落下する危険性がありますし、磁気浮上で浮く場合、接地していないのでブレーキをどうするかが問題になりそうです。
リニアモーターカーは、浮上する力の他に、前進する力があります。
ブレーキは逆向きにかければ良いです。
普通のモーターは回転力を発生しますが、「リニアモーター」は前後の力を発生します。
リニアモーターカーが浮上するのは時速５００ｋｍくらいになると車輪で走行するよりも効率とか安定性とかで優れるからです。
リニアモーターを用いた移動体が浮上する必然性は無く、
リニアモーターを駆動力とする地下鉄は、相対的に低速ですので浮上せず鉄輪で走行します。
余談ですが、リニアモーター車両は通常より車高が低いので、トンネルの断面積を小さく出来るというのが地下鉄には適しているらしいです。
> もし浮かぶような車ができるとすれば、全く違う原理ではないでしょうか。
同感です。
>
> 趣味人が作る可能性はあるかも知れませんが（ｗ
これにも同感です。
> 利用するのが地磁気とかになると、物を浮かべるには弱そうなイメージがありますが、実際はどうなのでしょう？
地磁気では、１グラム程度のコンパスの針を水平方向に回転させる程度の力です。
１トンの車を動かすには、６ケタほどパワーが不足している様に思います。

確かに　　飛行機と違って今みたいな点検頻度では危ないですね。
故障した瞬間にエアーバックみたいなのが出て衝撃を吸収したりして・・・制動方法も
リニアモーターカーからヒントはないでしょうかね。・・・これはもう趣味の域。
車の自動走行というのも結構進んでいると思うのですが、新幹線みたいに電気が止まったら
おかしなことになるんでしょうか？　

落っこちた場合、エアーバックがあっても、中の人は助かっても外の車の下の人は・・・☆♪

リニアモーターカーの場合、レールと車体の電磁石をうまく使う事により位置を固定できるのですが、レールが無い場合で磁気の反作用で浮こうとすると、どこかに跳ね飛んで行きます。
永久磁石のN極とS極を近づけて浮かべようとした場合と同じです。

ただ空を飛ぶ車と言うのであれば、アメリカだったかイギリスだったかで飛ぶ車を作ったと言うニュースをどこかで見ました。
確かジェットかプロペラ機でした（ｗ
安全性から見て市販はできないんじゃないかと・・・。

結局ジェットやプロペラ機ではブレーキが問題になりそうです。
反重力装置とかが実現されるまでは車は空を飛ばないんじゃないでしょうか。
と言うかそれって車って言うのでしょうか？（ｗ
なにせタイヤがないからどの方向にも進めるはずですし、そうなるとどの方向にも空気抵抗を減らすようなフォルムとなって、いわゆるUFOなフォルムに近くなるのでは。

確かに　車とはいえない範囲ですね。「バックトゥーザフューチャー」とか「フィフスエレメント」
「ブレードランナー」のイメージでした。　まさしく妄想の暴走です。
プリウスのブレーキに問題があるとのニュースが流れていますが、あれは発電効率を
あげるための構造でそのようになっているんでしょうか？それとも単にトヨタいじめで
しょうかね？
　

> プリウスのブレーキに問題があるとのニュースが流れていますが、あれは発電効率を
> あげるための構造でそのようになっているんでしょうか？それとも単にトヨタいじめで
> しょうかね？

ABS作動に伴い、ABS機能のない回生ブレーキからABS機能のあるメカ（油圧）ブレーキへの切替にタイムラグがあり、
その間ノンブレーキで空走してしまうらしいです。
１月からの新車はファームウェアのバージョンアップによって解消済みとのことです。

常にドライバが期待するブレーキトルクが得られるようマイコンで高速演算して
回生と油圧（ただし回生優先）に割り振っていますが、
これってHVだけでなくEVにも共通する話ですね。

いずれにしても自動車におけるECUソフトウェアの品質（開発・デバッグ）問題は
いよいよ来るところまで来ている感がします。なにしろコーディング量が
一人のプログラマが見通せる規模をはるかに超越してさらに増大中ですから。
先日も基本ソフトは各社共通化しようなんて話が出てましたね。
でもそこにバグが判明したら、全メーカ一斉リコールで乗れる車がない！
なんてことになりませんか？

それよりも、安全に直結する制御部分はもっと処理をシンプルにする方が得策ではないでしょうか。
（一人のプログラマが見通せる範囲、MISRA-C準拠で○○行以内、実行モジュール○○kbyte以内とか）
ユーザとしても、バグが潜む余地満載の巨大プログラムに命を預ける気にはなれません。 　

> ABS作動に伴い、ABS機能のない回生ブレーキからABS機能のあるメカ（油圧）ブレーキへの切替にタイムラグがあり、その間ノンブレーキで空走してしまうらしいです。

http://ow.ly/144V7　これだとABS自体の不具合のように読めますが、詳しい記事ではやはり回生ブレーキとメカブレーキの協調制御の問題とありますね。

> いずれにしても自動車におけるECUソフトウェアの品質（開発・デバッグ）問題は
> いよいよ来るところまで来ている感がします。なにしろコーディング量が
> 一人のプログラマが見通せる規模をはるかに超越してさらに増大中ですから。
> 先日も基本ソフトは各社共通化しようなんて話が出てましたね。
> でもそこにバグが判明したら、全メーカ一斉リコールで乗れる車がない！
> なんてことになりませんか？
>
> それよりも、安全に直結する制御部分はもっと処理をシンプルにする方が得策ではないでしょうか。（一人のプログラマが見通せる範囲、MISRA-C準拠で○○行以内、実行モジュール○○kbyte以内とか）

興味深いお話ですね。現在の車の電子制御は、問題を解決するための制御がまた別の問題を引き起こすという、パッチワーク的なプログラムになっていると聞きます。なので仰るとおり、制御ロジックそのものをもっとシンプルにすべきだと思います。

一方で、コスト削減やコードの再利用性の観点から、「オブジェクト指向」と言いますか、基本部分（OS)と各機能（アプリケーション）は明確に分けた方が良いと思います。確かにOSにバグがあったら全車改修になりますが、そこはPCみたいにパッチプログラムを配布してバージョンアップみたいな時代に来ているのではないでしょうか？

> 一方で、コスト削減やコードの再利用性の観点から、「オブジェクト指向」と言いますか、
> 基本部分（OS)と各機能（アプリケーション）は明確に分けた方が良いと思います。
> 確かにOSにバグがあったら全車改修になりますが、
> そこはPCみたいにパッチプログラムを配布してバージョンアップみたいな時代に来ているのではないでしょうか？

現状でもVxWorks等のOSは導入されていますが、共通化の話はアプリ層を含めてのことのようです。

PCと車では要求される信頼性が格段に異なりますから同列には語れませんが、
やはり複雑化やむなしでPC的になっていくか、発想を転換して極力シンプルにするか、
どちらかを選択する時期に差し掛かっていると思います。

また前者の場合、現行法では制御ソフトを入れ替えると形式認定上別の車になってしまう
（車検取り直し）という問題があるように思いますが、どうなのでしょうか。
これは手造りEVにおいても、CPU搭載コントローラを使用した場合に言えることです。

お返事ありがとうございます。

> 現状でもは導入されていますが、共通化の話はアプリ層を含めてのことのようです。

組込み系については全く素人なのでイメージが沸き難いですが、VxWorks等のOSはかなり汎用的なもののようですから、多分自動車特有の制御となると全てアプリ層になるんですかね。

> PCと車では要求される信頼性が格段に異なりますから同列には語れませんが、
> やはり複雑化やむなしでPC的になっていくか、発想を転換して極力シンプルにするか、
> どちらかを選択する時期に差し掛かっていると思います。

なるほど、悩ましい問題ですね。戦闘機のシステムなどは「一人の天才が書き上げた方が良い」なんて話も聞きますが、民生品については機能の順次追加や担当者の入れ替わりは避けられないと思います。つまり、嫌でもドンドン複雑化するでしょうね。そして、あるところまで行ったら、思い切ってシステムの総入れ替えが必要になると思います。

> また前者の場合、現行法では制御ソフトを入れ替えると形式認定上別の車になってしまう
> （車検取り直し）という問題があるように思いますが、どうなのでしょうか。
> これは手造りEVにおいても、CPU搭載コントローラを使用した場合に言えることです。

その点は仰るとおりで、私も同じ事を考えていました。ただ、今話題のプリウスのABSプログラムのアップデートは、他の変更と含めて後日国交省に届け出るとの事でしたので、型式認定云々の話にはならないのだと思います。手作りEVに関しては、元々型式認証ではなく個別に車検を通してると思うので、少なくとも運用上はスルーではないでしょうか。

ただし今後EV化するにつれ、プログラム変更で車の性能が大幅に変わるとしたら、認証基準も変わる可能性が大いにありますね。

皆さんの知識量に感心するばかりです。　近い将来ナイト２０００のような車も出てくる
事とは思いますが、気をつけないといけませんね。　便利になればなるほど退化していく人
とより上へと進歩する人に２極化していくでしょう。すでにその兆候はみえていますが・・

> ABS作動に伴い、ABS機能のない回生ブレーキからABS機能のあるメカ（油圧）ブレーキへの切替にタイムラグがあり、
> その間ノンブレーキで空走してしまうらしいです。
寒冷地で路面凍結している時の交差点とかで問題になりそうですね。
思ったのですが、燃費を気にするプリウス乗りは多いのでしょうが、ドライで限界走行するプリウス乗りは少ないので、冬になるまで誰も気がつかなかったのかも知れませんねー。
ワンメイクレースをやれば一発で判るのに。
トヨタはレースしないから、限界状態に弱いですねー。
> １月からの新車はファームウェアのバージョンアップによって解消済みとのことです。
公表して無かったんでしょうかねー。
>
> 常にドライバが期待するブレーキトルクが得られるようマイコンで高速演算して
> 回生と油圧（ただし回生優先）に割り振っていますが、
> これってHVだけでなくEVにも共通する話ですね。
同感です。
>
> いずれにしても自動車におけるECUソフトウェアの品質（開発・デバッグ）問題は
> いよいよ来るところまで来ている感がします。なにしろコーディング量が
> 一人のプログラマが見通せる規模をはるかに超越してさらに増大中ですから。
> 先日も基本ソフトは各社共通化しようなんて話が出てましたね。
> でもそこにバグが判明したら、全メーカ一斉リコールで乗れる車がない！
> なんてことになりませんか？
それは怖い。しかも、競争が無くなるので進歩がストップする気がしました。
>
> それよりも、安全に直結する制御部分はもっと処理をシンプルにする方が得策ではないでしょうか。
シンプルにすると、ＡＢＳとか使えなくなると思いますので、難しい気がしました。
> （一人のプログラマが見通せる範囲、MISRA-C準拠で○○行以内、実行モジュール○○kbyte以内とか）
コードよりもドキュメントが１０倍以上必要にする、とか。ＣＡＮがらみでコーディングした事が無いので、偉そうに言えませんが。
> ユーザとしても、バグが潜む余地満載の巨大プログラムに命を預ける気にはなれません。
深く同感。　

> > いずれにしても自動車におけるECUソフトウェアの品質（開発・デバッグ）問題は
> > いよいよ来るところまで来ている感がします。なにしろコーディング量が
> > 一人のプログラマが見通せる規模をはるかに超越してさらに増大中ですから。
こういう話に関しては、車以外でもやっぱり同じことが言えますね。
プログラマの能力はいかに素晴らしいロジックを組むかよりも、いかに効率的に漏れなくデバッグするかを求められてきたりして（ｗ

> > それよりも、安全に直結する制御部分はもっと処理をシンプルにする方が得策ではないでしょうか。
シンプルにすれば部品点数も減らせてコストダウンとなるので、いつでも追求すべき点でしょう。
難しい構造のものを同等の機能を持たせたまま単純化するというのは、実に難しいです。
商業的には、これが成功すると簡単に真似されてしまい、開発費が回収できなくなる恐れもありますよね。

> コードよりもドキュメントが１０倍以上必要にする、とか。ＣＡＮがらみでコーディングした事が無いので、偉そうに言えませんが。
私も車がらみのコーディングは全くやったことがないのでほぼ何も言えませんが、ドキュメントもまたシンプルである必要があります。仕様書って読んでて意味がわからなくなることが結構ありますから。
シンプルにして十分。正直、見果てぬの夢って感じです。

> > ユーザとしても、バグが潜む余地満載の巨大プログラムに命を預ける気にはなれません。
> 深く同感。　
プリウス乗りなので、既に預けてしまっています。。。

ソフトウェアの問題ですか。そう考えるとモデルチェンジしてすぐ乗り換えなんて
ことは、ちょっとリスクが高いものですね。技術の積み重ねといっても基本は安全
ですからね。