すべて表示


[ホームページ][使い方説明][ツリー表示]

1ページに最大10件のツリーを表示します。
24時間以内の書込みにはNEWマークを表示します。

Nortonなど、アンチウイルスソフトの設定によっては書き込みできない場合があります
javaを理解してくれないブラウザ、海外からは書き込みできない可能性があります。詳しくはお問い合わせ下さい。
宣伝書き込み防止のためURIは不定期に変更します
↓次の記事の先頭へ↓

No.31624 RE:バッテリーの白い粉 mateba [MacOS/IntelMAC:Chrome/31.0.1650.63] 12/18(水) 20:45
↑この犯罪者をどうにかして下さい。

ngn-west-071-212-060-180.enjoy.ne.jp


No.31625 RE:バッテリーの白い粉 ほりこし [G:Windows/7:IE/7.0] 12/18(水) 20:51
サルフェーションは負極板の表面に出来るもので、それが外部に出てくるものなのでしょうか?
開放型バッテリだとかマイナス側電極の鉛にそれが付着するくらいは想像しましたが、電極は全く綺麗だったのです。

No.31626 RE:バッテリーの白い粉 TAS [f:Windows/XP:Chrome/31.0.1650.63] 12/18(水) 20:57
私も極板表面に付着する硫酸鉛のことだと思ってました<サルフェーション

116.43.30.125.dy.iij4u.or.jp


No.31627 RE:バッテリーの白い粉 うち [Windows/XP:FireFox/25.0] 12/19(木) 07:38
非常電源でバッテリメーカから直接説明を受けた事があるのですが、
私もサルフェーションはTAS氏の説明の通りと認識していました。
新説ですね。バッテリメーカに尋ねてみます。

No.31629 RE:バッテリーの白い粉 nobody [M:Windows/Vista:FireFox/25.0] 12/19(木) 22:56
中和すらしてないから、廃液には硫酸水素鉛が大量に含まれているわけで、環境中に
鉛を放出するわけですよね。

21世紀にやることではないと私も思います

No.31631 RE:バッテリーの白い粉 こね [Windows/XP:Chrome/31.0.1650.63] 12/23(月) 19:58
ま、ず、理解したら理解した後の謝罪の言葉が先です。
ご両親や小学校の担任の先生にこのBBSの書き込みを見て頂いては如何ですか?




未来永劫にインターネット上に残ってしまう事を考慮すると、削除して逃げるだけの人間として生きるかどうか? って話になるのです。

でもほりこしさん優しいからなぁ……

106.188.60.173


No.31632 RE:バッテリーの白い粉 ほりこし [G:Windows/7:IE/7.0] 12/23(月) 20:05
スレごと削除しますか?
でも勘違いや不明なことは誰にだってあるし、私も皆様に沢山教えて頂いていますから良いのではないでしょうか。
それにサルフェーションは負電極表面に付くものと思っているのですが、過充電などではガスと共にそれが外部に飛散しないとも限らないですしね。
いえ、あの白い粉の正体が分かればハッキリするのですがよく分かりません。

No.31633 RE:バッテリーの白い粉 もしもしも [Windows/7:Chrome/31.0.1650.63] 12/24(火) 14:38
鋳物のすを通して析出する云々は聞いたことがあります。

寄付を募って成分分析に出すのはいかがでしょう?
わたし気になります!

No.31638 RE:バッテリーの白い粉 通りすがり [Windows/Vista:Chrome/31.0.1650.63] 01/02(木) 03:11
白い粉、単純に硫酸の結晶ではないですかねー。

i223-216-130-37.s41.a022.ap.plala.or.jp


↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31584 坂道のグリップ ACBI [u:Windows/XP:FireFox/25.0] 11/23(土) 21:49
本日の雑記に関して、

>μの低い雨の坂道などでは前輪がスリップしやすくて怖い

とおっしゃっている方がいるとのことですが、これは上り坂の話でしょうか?
これは確かに事実なのですが、その理由を誤解している人が多いように思います。

「上り坂では荷重が後に移動するので、FFは駆動輪の荷重が抜けて、ホイールスピンし易い」という誤解です。
正しくは「上り坂では必要な駆動力が大きくなる(加えて、傾斜のためにタイヤの垂直荷重が減少する)ので、どの駆動方式でも同じ割合でホイールスピンし易くなる」なのです。だから、FFが悪いわけではないのです。
また、下り坂でも同じだけアクセルを踏めば、同じだけホイールスピンをするのですが、下り坂でアクセルを深く踏む人は少ないので、そのことにも気づきません。「下り坂では前荷重になるので、ドリフトし易い」なんて誤解もあります。下り坂でもブレーキを踏まない限り前荷重になりません。下り坂は単に失速しにくいからドリフトし易いだけなのです。上り坂でも同じだけブレーキを踏めば、同じだけ前荷重になります。

と、この説明で通じますでしょうか?
周りの人間にこのことを説明しても、いつもあまり理解されません。
もっとうまい説明があるといいのですが・・・

kd210174116001.ppp.dion.ne.jp


No.31585 RE:坂道のグリップ ほりこし [G:Windows/7:IE/7.0] 11/23(土) 22:25
加重が後方に移動すると思います。
上り坂ですから、重力のベクトルは真下ではなく斜め後ろになります。
(重力の方向に対して車が傾いているわけですから)
二輪車が急加速すると前輪が浮くのと同じ事が起きているわけです。

No.31586 RE:坂道のグリップ 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/23(土) 23:00
家具や冷蔵庫、洗濯機などを横にして二人で持ち、階段を上り下りする時のことを考えれば分かると思います。

ntkngw536031.kngw.nt.ftth.ppp.infoweb.ne.jp


No.31587 RE:坂道のグリップ 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/24(日) 02:06
当然ですが、自動車やオートバイは重心が地面より上にありますからね。
逆に重心が路面の下にあった場合を仮想してみると・・・。
いやいや、仮想じゃなくて現実にありました。
ゴムタイヤを使った懸垂式モノレールが。
急加速をすると後輪が浮く?

ntkngw536031.kngw.nt.ftth.ppp.infoweb.ne.jp


No.31588 RE:坂道のグリップ じる [Windows/XP:IE/8.0] 11/24(日) 11:30
子供の頃、家の前の坂で三輪車で遊んでいる時に、バックだと上れるのに前進だとスリップして上らないのは何でだ〜?
って悩んだのを思い出しました。
タイヤに掛かる過重に対して路面との摩擦係数が・・・ なんて保育園児には分からなかったですね(笑)

ntgifu206163.gifu.nt.ftth4.ppp.infoweb.ne.jp


No.31590 RE:坂道のグリップ ACBI [u:Windows/XP:FireFox/25.0] 11/24(日) 20:40
>上り坂ですから、重力のベクトルは真下ではなく斜め後ろになります。

ここが誤解のキモなのです。
車に働く力は、重力と慣性力の合力です。車に働く合力ベクトルの向きは、車の加速度に影響されます。
例えば、上り坂を一定速度で登っている時、確かに後ろ荷重になってます。ただ、そこでギヤをニュートラルにして自由滑走したとしますと、走行抵抗を無視すれば、その瞬間に後荷重は解消されます。この時、合力ベクトルの向きは"鉛直下向き"から、"路面に垂直"に変化します。自由滑走というのは「自由落下」なので、斜面前後方向の加速度は0になります(その証拠に、水の入った水槽を摩擦の無い斜面で自由滑走させると、水面は斜面と平行になります)。
また、その状態でブレーキを踏んでさらに減速度を大きくすると、今度は前荷重になります。

そもそも、前後荷重配分は車体に働くピッチングモーメントで決まります。このピッチングモーメントの原因は、車体重心に働く合力の斜面に平行な成分と、タイヤの摩擦力の軸線がずれるためです(ですので重心高さが0ならピッチングモーメントも働かない)。
このことから分かるのは、タイヤの摩擦力が0(例えばニュートラル滑走)なら、ピッチングモーメントは0だということです。傾斜がどうなっていようと、荷重移動は生じません。
このニュートラル滑走から、タイヤに駆動力がかかれば後転方向のピッチングモーメント(後ろ荷重)が、制動力がかかれば前転方向のピッチングモーメント(前荷重)が発生します。
つまり、タイヤにどちら向きにどれだけの摩擦力が生じているかを見れば、荷重移動量が分かります。

通りすがりのホイキタさん>

階段の例は不適切です。荷物の把持位置が重心より高いと、上の人の方が負担が大きくなります。傾斜面に立つのと、段違いとはいえ水平面に立つ階段とでは、力学条件(重心高さの定義)が異なります。
車でも、斜面に止まっているのと、前後段違いの水平面にタイヤが乗っている時では、前後荷重移動量が違います。

kd210174110046.ppp.dion.ne.jp


No.31591 RE:坂道のグリップ 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/24(日) 21:32
階段の例は経験的に誰でも知っていることを思い浮かべてもらうためです。細かいことに注目すれば重心の高さ等を指摘されると予想したので、懸垂式モノレールの例を追加しました。懸垂式のモノレールには当てはまらないから間違いだとか言う人が出てくると困るので。

静的、動的を区別して考える必要がありますが、学問的に考察すると自由落下が静的なんですね。私は坂道での停止または定速走行を静的として考えています。

クレーン車のブームを車両に対して垂直に高く伸ばした状態で坂道を上ることを想像してみて下さい。普通の人なら、「前輪が浮き上がって後方に倒れるからやめろ!」と言うと思いますが、ACBIさんは「問題ないから行け」って言うんでしょうか。

ntkngw536031.kngw.nt.ftth.ppp.infoweb.ne.jp


No.31592 RE:坂道のグリップ TAS [Windows/XP:Chrome/31.0.1650.57] 11/25(月) 14:58
>ACBIさん

ご自分で
>例えば、上り坂を一定速度で登っている時、確かに後ろ荷重になってます。

と仰っていますよね。水平時に一定速度で走っている時場合は静止時と同じ
で後ろ荷重にはなっていませんから、「上り坂のほうが後ろ荷重になる」というのは
当然なのでは?ですから、上り坂のほうが前輪がホイールスピンしやすいのは当然だと
思うのですが・・・

148.93.30.125.dy.iij4u.or.jp


No.31593 RE:坂道のグリップ TAS [Windows/XP:Chrome/31.0.1650.57] 11/25(月) 15:14
あ、なんとなく仰りたいことが分かってきました。

仰角が付くと車輪の荷重が抜けるのは前輪・後輪に関係なく同じ割合
だという事ですね。後輪駆動でも限界は低くなると。それはそうですが、
登坂時には一定速でも平地での加速状態と同じ状態になりますので、荷重は
後ろに移動しますよね。ですからアクセル踏んで「ホイールスピンしやすく
なる」と実感するのはやはり前輪駆動のほうと言えるのではないですか?

148.93.30.125.dy.iij4u.or.jp


No.31594 RE:坂道のグリップ ACBI [u:Windows/XP:FireFox/25.0] 11/25(月) 20:17
>私は坂道での停止または定速走行を静的として考えています。

それはまずいでしょう。
そもそも、水平と坂道の比較なのですから、水平と同じ条件にしなければ比較できません。
ですので、水平でタイヤに働く力が0(等速直線運動)なら、坂道でもタイヤに働く力が0(自由滑走)でなければいけません。
逆に坂道での等速直線運動では、タイヤに駆動力が働いているので、それに相当する水平状態は加速運動になります。

ですので、ブームを立てたクレーン車では、"上り坂を定速状態"="水平を加速状態”となりますので、倒れるのも当たり前です。逆に、ブームを立てていても、自由滑走させれば倒れません。

要点は、車体に働くピッチングモーメントです。
どうしても納得いかない人は、具体的に数値で荷重移動量を計算してみてください。

TASさん>

駆動方式は関係ありません。
水平では5kNの駆動力でホイールスピンする車(前輪駆動でも後輪駆動でも)は、20°の坂(上りでも下りでも)では4.7kNの駆動力でホイールスピンしてしまうということです。

kd210174113050.ppp.dion.ne.jp


No.31595 RE:坂道のグリップ TAS [Windows/XP:Chrome/31.0.1650.57] 11/25(月) 20:57
>"上り坂を定速状態"="水平を加速状態”となりますので

いや、だからホイールスピンしやすいよね(笑)

148.93.30.125.dy.iij4u.or.jp


No.31596 RE:坂道のグリップ じる [Windows/XP:IE/8.0] 11/25(月) 23:17
例えば、前後重量配分が50:50の車があるとして、
その車が坂道で、ギアはニュートラル。サイドブレーキをかけない状態で、つまり自由落下と言われる状態で坂を下ってる時に、前後タイヤにかかってくる車の重量配分は、50:50のままですよと言うことですか?

ntgifu206163.gifu.nt.ftth4.ppp.infoweb.ne.jp


No.31597 RE:坂道のグリップ ほりこし [G:Windows/7:IE/7.0] 11/25(月) 23:50
> 前後タイヤにかかってくる車の重量配分は、50:50のままですよと言うことですか?
>
そうなりますね。
上り坂における荷重のかかり方は平地で定加速状態にあるのと似ている(摩擦の状態は異なる)訳ですから、坂道を下って定加速状態を打ち消せば平地で停止している状態に近くなります。

平地においても停止状態の時には前後輪加重は同一ですが、わずかでも加速をし始めると後輪加重が増えます。
従って平坦路に於ける停止状態ではFFとFRの前後加重に差はありませんが、加速を開始した瞬間から後輪加重が増える訳です。

減速時にはこの逆の事が起きるので、多くの車両ではリアブレーキよりもフロントブレーキの方が容量が大きく作られています。

No.31599 RE:坂道のグリップ 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/26(火) 03:02
>逆に、ブームを立てていても、自由滑走させれば倒れません。

そのような返信がくると思っていました。学問的に考えればACBIさんの主張は正しいと思います。平地での定速走行は摩擦等のロスを除けばエネルギーを使いませんが、坂道での定速走行は摩擦等を除いてもエネルギーを使います。確かに比較の条件としてはふさわしくないです。遊園地のジェットコースターを思えばいいわけですが、それでは定速走行になりませんし、車やオートバイの話ですから受け入れがたいです。

>周りの人間にこのことを説明しても、いつもあまり理解されません。
もっとうまい説明があるといいのですが・・・

ジェットコースターで説明してあげれば良いと思いますが、別の乗り物だと言われるでしょうね。

>要点は、車体に働くピッチングモーメントです。
どうしても納得いかない人は、具体的に数値で荷重移動量を計算してみてください。

加速、減速で車体に加わる力は、エンジンによる駆動力とエンジンブレーキは車軸に、フット(ハンド)ブレーキはタイヤの路面接点に生じます。厳密にはそのことを考慮する必要があります。

ntkngw536031.kngw.nt.ftth.ppp.infoweb.ne.jp


No.31600 RE:坂道のグリップ じる [Windows/XP:IE/8.0] 11/26(火) 06:07
この場合、比較の考え方は相対的なモノなので、まず比較の基準を合わせないと議論が出来ないですね。
一般的な考え方(と言うか、イメージ的なわかりやすさ?)から言えば、同じ車で、平坦路での静止からの加速と、上り坂での静止からの同じだけの加速を比べるんじゃないでしょうか?
これをACBIさんは、それはダメだと言われるんですが、僕には何故その比較がダメなのかが理解できません。
止まっている状態から加速させると言う基準を合わせて話をすれば良いだけではないでしょうか?
ACBIさんは、
>そもそも、水平と坂道の比較なのですから、水平と同じ条件にしなければ比較できません。
と言われていますが、重量が1tの車があるとして、水平状態でのタイヤにかかる車の重量は1tですが、坂道で自由落下状態でのタイヤにかかる重量は1tですか?
傾斜がキツくなればなるほど小さくなって、90度になったところで0になりませんか?
すると、これはへりくつかもですが、そもそも同じ車で、水平状態と坂道では、どうやっても条件が合わないってことになりませんか?
でも、
>水平では5kNの駆動力でホイールスピンする車(前輪駆動でも後輪駆動でも)は、20°の坂(上りでも下りでも)では4.7kNの駆動力でホイールスピンしてしまうということです。
と言って、比較されている。
このあたりが僕にはイマイチ理解出来ないトコなんですが・・・

ntgifu206163.gifu.nt.ftth4.ppp.infoweb.ne.jp


No.31601 RE:坂道のグリップ こね [Windows/XP:Chrome/31.0.1650.57] 11/26(火) 20:27
私、馬鹿だから良く分からないけど、
「撓らないクレーンが坂道登る」
って考えると納得できるなぁ、と、泥酔一歩手前で感心してますがどうしたもんでしょ?


とりあえずパジェロミニはFR状態では冬の坂道はオーマイゴッド!
諦めてレバーを4DWに入れます

e0109-106-188-87-238.uqwimax.jp


No.31602 RE:坂道のグリップ ACBI [u:Windows/7:FireFox/25.0] 11/26(火) 23:15
少し論点がぶれてきているのではっきりさせましょう。

・「FF車は上り坂でスリップしやすい」その理由は?

理由:「上り坂では荷重配分が後ろに移動して、駆動輪にかかる荷重が減るから」→誤解

実際には、上り坂は関係ない。平地だろうが下り坂だろうが同じ駆動力をかければ、同じだけ後に荷重移動する。同じだけアクセルを踏めば、同じ傾斜の下り坂でも同様にホイールスピンする。上り坂であっても、駆動力をかけなければ荷重移動はしない。つまり、”上り坂だから”前輪の荷重が抜けやすいということは無いということです。

逆にFR車では、上り坂では後に荷重移動するからホイールスピンしにくくなるということもありません。同じ傾斜の下り坂でアクセルを50%踏み込んだ時点でホイールスピンしたなら、上り坂でも50%でホイールスピンします。

ちなみに、自由落下は下りだけでなく上りでも成り立ちます。例えば、トランポリンでは下降中だけでなく上昇中も無重力状態です。
下り坂しかイメージされていない様子でしたので。
ブームを立てたクレーン車に登坂させたいなら、平地で倒れない程度の緩加速で助走しておいて、ニュートラル滑走の惰性で登らせれば倒れません。

kd210174117143.ppp.dion.ne.jp


No.31603 RE:坂道のグリップ 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/27(水) 00:17
実体験からACBIさんの話は理解しがたいですが、このように考えたらどうでしょうか。

上り坂では車速ゼロの時点で既に駆動力または加速度が生じている。いわばバイアスのような物が。そこからエンジンの力で駆動力または加速度を加えれば、平地より大きい駆動力または加速度が得られる。したがって、平地ではホイールスピンすることがない非力な車でも上り坂ではホイールスピンすることがある。よって、上り坂はホイールスピンが起きやすい。

ntkngw536031.kngw.nt.ftth.ppp.infoweb.ne.jp


No.31604 RE:坂道のグリップ 通りすがり [Windows/Vista:Chrome/30.0.1599.101] 11/27(水) 02:52
なんだか面白いので通りすがりですが横やり失礼します。

ACBIさんはいろいろ知識も豊富で賢そうなのに何で結論を誤るんでしょうね。

「”上り坂だから”前輪の荷重が抜けやすいということは無い」ここ、間違ってますよ。

揃えるべき条件は車速で、駆動力ではないでしょう?
話の流れからして。

FF車の場合、前進で登れない坂がバックでなら登れることは往々にしてあります。
事実ですから、そもそも異論の余地はないのですよ。

i223-216-130-37.s41.a022.ap.plala.or.jp


No.31605 RE:坂道のグリップ 横やり+ [MacOS/IntelMAC:FireFox/25.0] 11/27(水) 12:05
上り坂だから(←ここが間違い)加重が後ろに移動
ということでしょう。
重心が接地面より上にある場合には上り坂でも下り坂でも
平地でも重力が小さくなっても加重は後ろに移動するので
前輪駆動の方がスリップしやすいという点は同じ
坂道で滑りやすいのは面圧が小さくなるからということでしょう

j096154.ppp.asahi-net.or.jp


No.31606 RE:坂道のグリップ 風風ながれ城 [Windows/7:FireFox/25.0] 11/27(水) 15:32
ACBIさんの説は全く正しいと思います。

通りすがりのホイキタです。 さん
上り坂では「平地より大きい駆動力または加速度が得られる」ではなく、「平地より大きな駆動力が必要になる」です。また平地でホイールスピンしない非力な車が上り坂でホイールスピンするとすれば、垂直抗力の減少が原因です。

通りすがりさん
>FF車の場合、前進で登れない坂がバックでなら登れることは往々にしてあります。
平地でも前進で空転する限界の加速度と後進で空転する限界は異なりますよね。

高校の物理を思い出して重力を斜面に垂直な方向と水平な方向に分解すれば何ということはない話だと思うのですが。

g8.115-65-155.ppp.wakwak.ne.jp


No.31607 RE:坂道のグリップ hirax.net http://www.hirax.net [MacOS/IntelMAC:Safari/537.71] 11/27(水) 19:02
> 「上り坂では荷重配分が後ろに移動して、駆動輪にかかる荷重が減るから」→誤解

 上り坂を普通の向きで上る姿勢だと、(ブームを立てたクレーン車なんて特に)後輪を軸に前輪を浮かせようとする力のモーメントが発生して・前輪の荷重が減るように思えます。車を「前輪と後輪が直線上にあって、重心もその上に位置する」みたいな、現実を大幅に単純化した場合でしょうか?

No.31608 RE:坂道のグリップ ACBI [u:Windows/7:FireFox/25.0] 11/27(水) 21:28
すみません、もっと単純に書きます。

「上り坂では無条件に後に荷重移動する」→ 間違い、傾斜は無関係

なぜなら、上り坂でも、惰性で上るなら荷重移動しない。さらにブレーキをかければ静的荷重配分より前荷重になる。
荷重移動(厳密には荷重配分"比"の変動)を支配するのは駆動・制動力だけです(力学的には、車体にかかるピッチングモーメント)。
同じ駆動力をかければ、平地でも上り坂でも下り坂でも荷重配分比は同じだけ変化する。傾斜がいくつだろうと全く関係ありません。

言いたいのは「前輪の荷重抜けは傾斜の所為ではない」です。

あと、FFとFRのトラクションを直接比べていません。
平地に対して上り坂でどれだけ低下するかを比べています。
FF車もFR車も共に、cosθに比例して低下します。駆動方式に関係なく同じです(4WDはセンターデフの条件次第で複雑なので割愛)。
FF車だけが上り坂で大幅にトラクションが低下するということはありません。

ちなみに、低μ路では加速による後ろへの荷重移動が非常に小さいので、元々の駆動輪荷重に優れるFF車の方がFR車よりトラクションに優れます。特に86のようなフロントヘビーで低重心な車は非常に劣ります(重心が低いと荷重移動しにくい)。


え〜と、FF車がバックですか?それはRR車の前進と同じでしょう。トラクションに優れるのは当たり前です(笑)

kd210174111051.ppp.dion.ne.jp


No.31609 RE:坂道のグリップ 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/27(水) 23:41
>実体験からACBIさんの話は理解しがたい

私がこのように言ったのは、理屈はその通りだが実体験からACBIさんの話は理解しがたい、と言う意味です。感覚のズレ、または錯覚のような物がどうして生じるのかです。

車の運転は路面方向の速度を目的としているし、前後の荷重移動は意識しても前後一様にかかる鉛直方向の荷重変動などはジャンプしそうな状況等でない限り考えないです。

私は理屈が好きな方なので興味深い話ですが、自由滑走が静的というのは世間一般には通用しないだろうし、正せは秩序が乱れます。

ntkngw536031.kngw.nt.ftth.ppp.infoweb.ne.jp


No.31610 RE:坂道のグリップ ほりこし [G:Windows/7:IE/10.0] 11/28(木) 07:25
> なぜなら、上り坂でも、惰性で上るなら荷重移動しない。
>
確かにその通りです。
しかしホイルスピンの話をしているのですから慣性での走行は考えなくても良いでしょう。

平地でも坂道(自由落下が可能で、その場合の走行抵抗や空気抵抗がゼロに出来る場合)でも静止状態であれば前後輪荷重に移動は起きません。
しかし移動しようと加速した瞬間に後輪に荷重が移ります。

元々はホイルスピンの話なので加速が前提です。
上り坂では静止時に於いても等価的に定加速状態に近い(この状態で既に後輪に荷重が移動している)訳で、そこから更に加速するのですから更に荷重が後輪に移動します。

自由落下状態を静止とするのではなく、止まれの標識の前で一時停止している状態で速度計がゼロを示している事を指します。
そうでないと、坂道に於ける制限速度の定義が変わってしまいます。

No.31611 RE:坂道のグリップ ACBI [u:Windows/7:FireFox/25.0] 11/28(木) 20:44
>感覚のズレ、または錯覚のような物がどうして生じるのかです。

これは目から入る速度情報のせいだと思います。

この話を考えてみて、坂道を走行中に、運転していない乗員が目を閉じ音と振動(つまり車速を伝える情報)も遮断すると、自分が上っているのか下っているのかを三半規管と加速感だけでは絶対に判断できないということに気付きました(ジェットコースターでも感じる浮遊感により「坂道」であることだけは分かる)。

止まっていたら傾斜が分かるのでは?
いいえ、車速に関する情報が遮断されているので、止まっているかどうか分かりません。なので、上り坂に停止しているのか、下り坂で加速しているのか、判断できません。

kd210174116129.ppp.dion.ne.jp


No.31612 RE:坂道のグリップ ACBI [u:Windows/7:FireFox/25.0] 11/28(木) 21:04
>上り坂では静止時に於いても等価的に定加速状態に近い(この状態で既に後輪に荷重が移動している)訳で、そこから更に加速するのですから更に荷重が後輪に移動します。

これを読んで私の言いたい要点がやっとまとまりました。

「上り坂では後輪への荷重移動が大きくなるので、前輪駆動より後輪駆動の方がトラクションで有利になる」と誤解する人がいるのが気になるということです(ほりこしさんがそう誤解してるかは、書き込みからは分かりませんが)。

私の主張は、

「平地でのトラクションの優劣は、上り坂だといって変動することはありません。」

です。
例えば、トヨタのFF車のオーリスとFR車の86は、路面のμが0.94だと、平地でのトラクション性能が互角になります。
そして、この路面条件で上り坂となったとしても、やはり互角なのです(当然、下り坂でも互角です)。
また、上記条件よりもμが下がるほど、オーリス有利になります。凍結路の登坂で、FFに勝てるFR車は(リヤヘビー傾向のスーパースポーツを除いて)まずいないでしょう。

kd210174116129.ppp.dion.ne.jp


No.31613 RE:坂道のグリップ izmi [Windows/7:Chrome/31.0.1650.57] 11/29(金) 17:25
申し訳ありませんが、理解不足なのでお教えください。
坂の下側車輪の荷重は、mgsinθsinθ分増加すると思うのですが
車が傾いても車輪の荷重は変化しないと言うご意見なのでしょうか?
荷重が変わらないのであれば、ACBIさんのご意見通りだと思いますが、
荷重が変わるのであればトラクションも変わると思いますが如何でしょう。
荷重が変わらないとすれば、何故変わらないかをお教え下さい。

em119-72-192-182.pool.e-mobile.ne.jp


No.31614 RE:坂道のグリップ ACBI [u:Windows/7:FireFox/25.0] 11/29(金) 19:20
izmiさん>

板の上に、ミニカーを乗せてください。その時のミニカーの荷重配分50:50だったとします。
次にその板の前端を持ち上げて坂道にします。やっぱり、ミニカーの荷重配分は50:50のままです。ただし、ミニカーは後へ滑り落ちていく状態になりますが。
ミニカーに水槽を乗せて実験すると、実際に確かめられます。水平では水面は板に平行です(荷重の偏りが無い)。板を傾けても、滑っていくミニカー上の水面は板に平行なままです(やはり荷重は偏らない)。

次に、ミニカーのタイヤに駆動力を与えます。板が水平だと、ミニカーは加速して荷重配分は後に移動します(水面は後に移動します)。
板をちょうど良い角度に持ち上げると、駆動力と重力が釣り合ってミニカーは斜面上に停止する状態にできます。この時も荷重配分は後に移動しています(水面は後に移動しますし、その移動分は水平時と全く同じです)。

傾斜に関係なく、与えた駆動力だけで荷重移動量が決まるのです。

kd210174117102.ppp.dion.ne.jp


No.31615 RE:坂道のグリップ hirax.net http://www.hirax.net [MacOS/IntelMAC:Safari/537.71] 11/29(金) 20:40
>ただし、ミニカーは後へ滑り落ちていく状態になりますが。

 言葉の使い方に尽きる話なのかもしれないですが…上り坂での”静止”状態を「自由落下してる」「滑り落ちていく」状態だというのは、少し一般的な捉え方ではなかったりしないでしょうか(人によって捉え方は違うのでしょうが…)。
 前後輪のタイヤと路面の間に摩擦があり・タイヤ接地面より路面から離れた方向に重量が配置されている車が上り坂で路面に対して停止しているという「坂道を上ろうとする車を思い浮かべた際に、ありがちな状況」では、少なくとも、後輪接地面を回転軸にする「前輪を浮かせようとする力のモーメント」が発生して・前輪の荷重が減るように思えますが…。

No.31616 RE:坂道のグリップ ほりこし [G:Windows/7:IE/7.0] 11/29(金) 20:57
荷重移動は坂道か否かではなく、その状態を維持(例えば坂道で止まろうとしているなど)するために力が働いているかどうかで決まる。

ですが、実際には坂道であるが故にそこに停止するためには必ず力が加わる事になり、よってその力の加わる理由は坂道だからで、坂道では荷重移動するのが実際です。

でも本当は坂が原因なのではなく止まっている事が原因なんだよと言う事ですね。
しかし止まっている事を前提とするなら、坂が原因になりますね。

No.31618 RE:坂道のグリップ ACBI [u:Windows/7:FireFox/25.0] 11/29(金) 22:12
>上り坂での”静止”状態を「自由落下してる」「滑り落ちていく」状態

ちょっと待ってください。他の方もこんなニュアンスのことを言われてますが、ニュートラル状態を静止状態としていると主張したつもりはありません。

先のミニカーの事例通り、ニュートラル状態、または駆動状態について述べています。
ニュートラル状態では、たまたま水平で静止できるだけで、本質は「何の力も出していない」ということです。
逆に、駆動状態では、たまたま釣り合う傾斜の時にだけ、静止できるだけで、本質は「常に一定の力を出している」ということです。

>前輪の荷重が減るように思えますが…

ここを疑問に思われる理由が分かりません。上り坂停止時に前輪の荷重が減ることは誰も全く否定していませんが。

kd210174117102.ppp.dion.ne.jp


No.31619 RE:坂道のグリップ izmi [Windows/7:Chrome/31.0.1650.57] 11/29(金) 23:58
ご返答ありがとうございます。
ニュートラル滑走状態での比較なんですね
それでしたらACBIさんの仰るとおり
FF、FRどちらであれ水平状態とホイールスピンの
し易さでの有利不利はないと思います。
ご説明ありがとうございました。

77.69.30.125.dy.iij4u.or.jp


No.31620 RE:坂道のグリップ 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/30(土) 11:58
太陽は東の方向から昇り、西の方向に沈みます。正確には正しくないです。
電流はプラスからマイナスに流れます。これも正確には正しくないです。

理由も知っているし、あえて間違った解釈をしていても、日常生活に何ら不都合はないです。むしろ正そうとすれば秩序が乱れます。

興味のある人には面白い話です。私は好きです。

そんな風に思いました。

ntkngw536031.kngw.nt.ftth.ppp.infoweb.ne.jp


No.31621 RE:坂道のグリップ 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/30(土) 15:01
今回はピッチングの話ですが、ローリングについても考えてみると。

そういえば、「遠心力というのは見かけ上の力であり現実には存在しない」というのがありますね。これに関しては私でも知っていることなので、ご存知の方も多いと思います。同じようなニュアンスで捉えれば受け入れやすいかと思います。

ntkngw536031.kngw.nt.ftth.ppp.infoweb.ne.jp


↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31570 440Hz こね [Windows/XP:Chrome/30.0.1599.69] 10/10(木) 14:21
10月10日の記事ですが、音感チェックをピアノの鍵盤でやる事自体間違ってるという風潮が出来て欲しいですなぁ。
たいして触ったことの無い器具でテストするというのはニャンともかんとも。

人間の耳に心地よい周波数の並びは結構滅茶苦茶な並びしてる(と思ってる)ので、単純に+30Hzずつ並んだ音階にはパーフェクトを見せる人間とか……居ても無意味ですね。

実際に図で見るとずっこけますね。ドレミファソラシドって。

こちら

e0109-106-188-48-59.uqwimax.jp


No.31571 RE:440Hz nobody [M:Windows/XP:FireFox/24.0] 10/10(木) 20:25
ハーモニーディレクターなんかで、440Hzと443Hzの違いを聞くと、最初は
全然わからないのですが、よくよく聞いていくとだんだんと違いがわかる
ようになります。絶対音感のある友人たちは、1Hz単位で確実に聞き分けて
いましたが、私はとてもそこまでは行きませんでした。

純正律と平均律の違いは、一発でわかりますね。純正律を聞いてから平均律
を聞くと、ビート妨害というか、うなりが出ているのがはっきりわかります。


しかしですね。実際の楽器は非整数倍音もいっぱい出ていますので、平均律
でも全然問題がないんです。基本成分が大きな割合を占める音色だとうなりが
不自然に聞こえるものでも、非整数倍音がいっぱい入ってればわからなくなります。

No.31583 RE:440Hz nobody [M:Windows/XP:FireFox/24.0] 11/09(土) 19:30
ちょっと間隔が空いてしまいましたが、現行のヤマハのハーモニーディレクター
HD-200の紹介の動画があります。
こちら

2分45秒付近から、平均律と、純正律の違いがわかりますが、こういう正弦波に
近い音だとはっきりうなりが出るのがわかります。
11分頃から、純正律のハーモニーが出ています。

ところで、前回の記事を書いた後に色々と調べていると、ファゴットなどはかなり
複雑な鳴り方をするんですね。オーボエが複雑なのは、聞いてて感覚的にわかって
いましたが。
こちら
>例えばC1の音を鳴らしてもC1の音は鳴らないw
>実際に鳴るのは第2倍音からの倍音成分だけです。

>C1(32Hz)=64Hz・96Hz・128Hz・160Hz…
>C2(64Hz)=64Hz・128Hz・256Hz…

>仮にC1の元の音(32Hz)が鳴らず64Hzから始まっても、
>C2(64Hz)の音とは倍音構成が違うので別の音になる。

>この上の倍音構成を見て本当は鳴っていない32Hzを想像し、
>結果としてC1の音が鳴っているように修正してしまう
>『差音』と言う特性を人間の耳は誰しも持っています。

↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31579 アロン強化 ロボット好き [Windows/XP:IE/6.0] 11/06(水) 19:46
最近、丸山さんのところや、FUSHIKIZさんのところで、とても興味深いトピックが連発で、かなり楽しませて
もらっています。色々、興味深い真実があるものです。

排気音が格別と言われるアルファ。ラテンの乗りなエンジンかと思いきや、計算し尽くした繊細な設計が
されていたとは。日本のアフターパーツのいい加減さと好対照というのも面白かったです。

プリウスの性能で色々あったFUSHIKIZさんに関して、ここの掲示板を使って書くのはどうかと思ったのですが、
あちらには掲示板がありませんので・・。
プリウスのメンバーのアロン補強とか、86のサスの欠点や改良方法など、とても興味深い内容でした。

その話題から関連することなのですが、不肖、このわたくしも、効果ありと思ったトピックを少し紹介します。


FUSHIKIZさんが、何度もボルトによる面結合には、強入力によるズレの可能性が付きまとう、と言われて
いますが、私もそう思います。
自分はホイールのハブボルトで実感したのですが(設計が古いので4本ナット)、たとえハブスペーサーを
入れてハブの中心を合わせても、ねじを締めなくてもしっかりとハブと結合していないと、普通の道を
ゆっくり走る程度の衝撃でもズレが頻発していると分かりました。

さすがにアロンアルファで結合すると外れなくなってしまうかもor外すときに根性がいりそうなので、
バスコーク(黒)でハブとホイール中心を密着させました。効果はもう、劇的でした。
さすがに今の車は、標準でホイールがしっかり固定される仕組みにしてあると思いますが、そうなっていない
方には、かなりオススメです。

もう一つは未検証なのですが、ダンパーの強度に付いての話題がありましたが、可動するためにピストンと
シールで強度を出さざるを得ないダンパーは、構造上、横入力に弱いと、わたしも思っていました。
バイクで事故ると、たいていフロントフォークが曲がります。
この入力方向に対する弱さは、ブレーキングの時も同じですから、フォークの曲がりがごく僅か発生し、
車体のブレとなります。
よく、フォークのブレを止めるためにスタビライザーを付けますが、その効果は左右のブレをそろえるぐらい
でしょう。
これを解消するために有効なのが、インナーチューブ、アウターチューブと言う構成のもう一つ外側に、
強度のあるアウターガードチューブを増設する、という方法です。
これだと、ピストンとシールによる強度に加え、アウターチューブ径のブレガード、という別次元の曲がり強度を
確保できます。これが上手くスライドしないと、動きが渋くなってしまいますけど。

実は昔のバイクは、ごく簡単な仕組みのアウターガードチューブを持っていて、それは、レトロカスタムで
おなじみのフォークブーツです。
このフォークブーツのゴムが固く、横方向の強度を持ち、アウターチューブとしっかり繋がっていれば、
かなりのブレを抑えることができるはずです。
現代の最新バイクも、この仕組みを偶然持っているものがあって、その一台が、オフでもブレーキの効きが
素晴らしいと評判の、ヤマハセロー250です。やはりブレーキローターは小さいので、限界はありますが・・・。

というわけで、そのほかのバイクも、格好を気にせずにフォークブーツで横強度を出すようにすれば
ブレーキ強化が簡単にできます。
近頃は、フォークを外さなくても取り付けられるフォークブーツもあるので、じつにお手軽なブレーキ強化です。
(自分は未検証・・・)
何とか、いずれ自分の乗るバイクにもアウターガードチューブを付けたいと考え続けて、この少しかっこ悪い
結論へ至りました。(果たして正解だろうか・・)
できれば近いうちにバイクを購入して、自分で確かめてみようと思っています。
今や4気筒は高嶺の花になってきているので、Vツイン、パラレルツイン、あたりを狙っています。


このサイトで提供されている、堀越さんのバイクに関する情報はとても多くて、勉強になっています。
とても便利、かつ長距離もこなせる大型スクーターなら、買い換えの機会はないとは思いますが、
一読者として、堀越さんの知識で、別のエンジン形式との付き合いも見たい気もします。

ドコドコと心躍るエンジン音、心地よい風を受けて走るハーレーが、ハイブリッドで静かになったら、
燃費がよくてもやはり味気ないはずです。(スティード400しか乗ったことありませんけど)
家族の誰かを、VIP待遇で送り迎えしたい人にとっては、後席が豪華で安楽なアルファードは、マストかも
しれません。(個人的にはミニバンに縁がありませんが、知らない人と乗り合わせるのにはいいかも)
家の近くを、ホンダの50ccエイプが爆音を響かせてとばすのに何度も遭遇している人にとっては、
バイクの爆音は腹立たしい(バイク嫌いになりそう)、モンキーの兄弟車エイプ(類人猿)は名前が
面白いと思っていたのに、エイプ嫌いになった、ということもあるでしょう。(私個人の感想です)

やっぱり、人はフラットに物事を見たいと思っていても、環境に左右されて、誰一人同じポジションには
立てません。
今まで乗った数台のバイクからすると、
ホンダのクオリティは別格、
ヤマハはクオリティは普通で、デザインとフレーム、操縦性が芸術、
スズキはクオリティは普通、チャレンジングなメーカー、
カワサキはクオリティは普通、先見性の高さと、重厚さと弱さが同居しているメーカー、
という感想になりますが、これも人によって違うと思います。
買い換える前に寿命を迎えたのはスズキだけですが・・。

時間も経ちましたし、FUSHIKIZさんの件も、そろそろ出入り解禁してもらうというのはどうでしょうか?。
第三者が出しゃばって、双方に失礼かもしれませんが・・。
個人の感想を変えさせようとするほどのプリウス話はナシ、ということで。

ここをFUSHIKIZさんが見ておられるかどうか分かりませんが、わたし以外にも、86のサスやアロン強化のことで
色々聞きたい方もおられそうな気がして。

出しゃばりかもしれませんが、良かったらお願いいたします。

g1-223-25-160-44.bmobile.ne.jp


No.31580 RE:アロン強化 ほりこし [G:Windows/7:IE/10.0] 11/06(水) 20:18
接着剤での強度確保はトヨタもやっていますね。
従来のスポット溶接だとスポットの間隔を狭くする事が出来ない(コストがかかる)。
レーザスポットは沢山打てるのですが鉄板の面精度が出ていないと失敗する。
鉄板の面精度を確保するのはコスト的に難しい。
そこで接着剤を塗って固定してしまうわけです。

鉄板を厚くするとコストも重量も嵩みますから、接着剤での固定はメリットがあると思います。
耐久性がどうなのかは分かりませんが。

フロントフォークですがシールの外側(上側)にベアリングを入れて(スラスト方向に動くヤツなのでベアリング自体も移動)固定すればいいのになと思った事がありました。
だってあれ、構造的にどう考えても弱いですよね。
ただ内部のメタルを見る限り片減りしているような感じでもないので、意外とそんなものなのかなと。
支点と作用点の距離がありますからね。

バイクは、スズキは生産性とコストを追求しているなと思います。
その一方でハイパワー思考、これは軽自動車もそうですが、コストをかけない部分は徹底したコストダウン、カタログ性能を飾れる部分は力を入れるみたいな感じがします。



FUSHIKIZさんの件は、古い事は忘れたので(笑)FUSHIKIZさんが良ければ自由に書いて貰ってかまいませんよ。

No.31581 RE:アロン強化 通りすがりのホイキタです。 [m:Windows/7:IE/9.0] 11/07(木) 03:34
オートバイのフロントフォークはインナーチューブの剛性云々以前に、インナーとアウターの遊びというかカダというか隙間が大きいいです。スプリングもオイルシールも取り付けない状態でインナーとアウターを組み合わせると、横方向にグラグラと動きます。隙間を小さく作ることは可能だと思いますが、車体に取り付ける時に左右のフォークの並行度に高い精度が必要になるので、市販車はそのようになっているのだと思います。私は自分でフロントフォークのオーバーホールをしたりもしますが、あのガタガタの隙間を極限まで小さくできたらなと思います。

間もなく東京モーターショーが開催されますね。二輪の展示車両は前輪のアクスルが床に固定されているので、またがってハンドルをこじるとフロント回りのねじり剛性が試せます。どれもこれもグニャグニャです。スーパースポーツでさえも。オフ車なんてグニャングニャンです。1本パイプのバーハンドルもパイプ自体が目に見えて曲がります。ハンドルがラバーマウントだと、もうフニャフニャです。

ntkngw376140.kngw.nt.ftth.ppp.infoweb.ne.jp


No.31582 RE:アロン強化 久立珍重 [Windows/XP:IE/8.0] 11/07(木) 11:23
>インナーとアウターの遊びというかカダというか隙間が大きいいです。

アレは恐らく転倒時等、双方の変形等に対する配慮だと思います。転倒を前提としたオフスポーツ系では結構重要です。

↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31574 携帯紛失 けん [Windows/7:Chrome/30.0.1599.101] 10/17(木) 23:10
携帯電話(ガラケー)を昨日夜紛失してしまいました。
朝の段階で携帯は鳴っていたので、電源は入りっぱなしだと思います。
一応遠隔ロックかけて、交番にも紛失届けを出しました。
サーチ機能は、携帯側の設定をおこなっていなかったので、検索不可能でした。


おそらく出てこないってのを前提で、次の携帯はどうしたら良いか、何か案出しがあったら、教えてください。

要望・現在の環境等は、
・今まで使っていたのはガラケーで、自宅wifiが使える物でした(今回紛失した機種は2年ちょい使っている)
・ドコモ歴18年
・wifiが使える機種が良い
・スマホでも良いが、パケット通信はしたくない
・自宅wifi環境下でしか、通信しない
・現在は、メールし放題ってコースに入っており、実質通話料金と基本料金のみ支払っていいる。出来ればこのコースを利用し続けたい(パケット代0円)
・次のキャリアもドコモを継続したい

以上のワガママで、何か良い案ありませんかね?

eatkyo348218.adsl.ppp.infoweb.ne.jp


No.31575 RE:携帯紛失 ほりこし [G:Windows/7:IE/10.0] 10/17(木) 23:41
メールし放題コースを継続しようとする限り、スマートフォンは対象外ですね。
WiFi対応だとF-01E(26,880円)だけです。

スマートフォンにした場合でも3Gを切っておけば通信はしませんが、2段階パケット料金の下限金額の2,100円を払う事になります。
なおドコモアプリのアップデートや初期設定などは3G通信を活かす必要があるので、初月は必ずパケット代が上限に行くと思います。

iPhone5c/sはタダですが、パケット代が定額になるので使わなくても高いです。
Androidも売れないモデルはタダのものもありますが、魅力は余り無いと思います。


No.31576 RE:携帯紛失 ひろ [DoCoMo/N02C:DoCoMo/DoCoMo2.0] 10/19(土) 15:03
古い機種ですが、N-02Cは良いですよ。
これ以降は(特にNのガラケーは)機能は縮小傾向なので、今でもハイエンドです。
あるとこには在庫あります。

位置提供はスマホでも電池の持ちに響かないので、オンにしておいたがいいでしょう。
たしか119番とかにも利用されてたはずです。

proxycg003.docomo.ne.jp


No.31577 RE:携帯紛失 とし [u:Windows/XP:FireFox/22.0] 10/20(日) 15:20
私も無くしたことがありますが、幸い前使っていた端末が残っていたのでそちらに機種変更してしまいました。auでしたが2100円取られましたが。

ヤフオクで使っていたのを探すか、希望の機能のあるのを探すか、ですかね。
なんかスマホは乗り換える気がしませんね。こちらのHP見てますが萎えるばかりです(笑)

No.31578 RE:携帯紛失 けん [FOMA/Browser:N05C/Gecko] 10/31(木) 10:55
お返事遅くなりまして、申し訳ございません。

スマホも若干考えましたが、料金コースが多すぎ、しかもドコモショップで買うのがいいのか、街の携帯屋でキャッシュバックを狙うのかいいのか、考えているうちに面倒になってきました。

迷っている時間を時給計算すると、スマホもタダになりそうな勢いだったので、同じ機種のガラケーをオクで買いました。

約3万弱でした。

未だにパケット代0円を続けています(汗)

eatkyo349051.adsl.ppp.infoweb.ne.jp


↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31572 プレゼント届きました! おやつパパ [Linux] 10/13(日) 00:03
憧れ(?)のキーホルダー!
ありがとうございます。早速、愛車のキーを着けました。
Snow PIctさんの絵も可愛いくて素敵ですね。

No.31573 RE:プレゼント届きました! けん [Windows/7:Chrome/30.0.1599.101] 10/17(木) 23:05
私もプレゼント届きました。
どうもありがとうございます。

思ったよりしっかりした作りで、良い感じの存在感のロゴでした。
そして愛猫家の僕としては、絵はがきも嬉しい限りでした。

くじ運がないので、当選メールが来たとき、失礼ですがスパムかと疑ってしまいました(汗)

これからもよろしくお願いします。

eatkyo348218.adsl.ppp.infoweb.ne.jp


↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31548 ロケーション履歴 CF化挫折者 https://play.google.com/store/apps/details?id=com.ryunos.ggl&hl=ja [n:Windows/7:Chrome/29.0.1547.76] 09/26(木) 20:03
長らくLatitude Syncや Backitude というアプリを使ってGoogleロケーション履歴をライフログして使っていたのですが、
Google Latitude API が8月にリタイアしてしまい、私も代わりの方法を探していたのですが、なかなかこれというものが
ありませんでした。

そこで、[Google+ GPS Locator]というアプリを作成してみました。

仕組みとしては Google+ の現在地送信機能にGPSによる現在地を「盗み見」してもらって、出来るだけ従来並の精度で
ロケーション履歴を利用しようというものです。

また、もし自分で作るなら実現したいと思っていた移動を検出したら測位頻度を上げ、しばらく動かなかったり、
連続して測位に失敗したら測位頻度をもとに戻す機能を実装してみました。

これによりバッテリーの消費を抑えつつ、移動経路をほぼ特定できる形でログを残すことができています。

Latitude API を使用したものに比べて
・送信頻度が1時間に一度程度 (Google+の動作)
・基地局の位置情報を排除するために[Googleの位置情報サービス]のチェックを外す必要がある
・たまに100~200メートル程度の大きなズレが記録される

というような差がありますが、送信頻度落ちたこともあり、従来よりバッテリーの持ちはよい気がしますし、
移動時の頻度が高いこともあり、総合的にはLatitude APIリタイア前より快適に感じています。

自分の希望に合わせて作ったものなので、必ずしもフィットするとは限りませんが、ロケーション履歴を
使っていたり、興味が有る方は是非試してみてください。


こちら

p119.net182021183.tokai.or.jp


No.31549 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/7.0] 09/27(金) 22:57
ご紹介ありがとうございます。
早速ダウンロードしてみました。

これはGoogle設定→現在値送信機能はOFFで使うのでしょうか。

現在色々実験中、後日Blogの方でレポートさせて頂きたいと思っています。

No.31550 RE:ロケーション履歴 CF化挫折者 http://https [n:Windows/7:Chrome/29.0.1547.76] 09/27(金) 23:54
> これはGoogle設定→現在値送信機能はOFFで使うのでしょうか。

自分はONにして使っています。

遺憾ながらGoogleのロケーション関連の個々の設定と動作の関係はまだ掴みきれていない事があり
調べなければならないと思っています。

お気づきの点、アイデア、不具合などありましたら色々と教えて下さい。

p119.net182021183.tokai.or.jp


No.31551 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/7.0] 09/28(土) 12:03
現在位置送信機能をOFFにすると位置送出自体が行われなくなるようでした。
現在位置送信機能をON、GPS以外での測位をONにするとGoogle+本来の(に、近い?)動作になるようで、通知インターバルも不定になりました。
従ってこのアプリの機能を発揮させる場合には、必ず「設定→位置情報サービス→Google位置情報サービス」のチェックを外す必要がありますね。

こうした設定によってアプリの通知インターバルによるGPS測位データが送出されます。
なかなか良く出来ています。

GPS測位精度の問題ですが、アルゴリズムの工夫か何かで改善出来ればベストですね。
設定によってある程度カバー出来ているのですが、他のGPSアプリに比較すると位置のばらつきが多いように思えます。

その設定に関しては、かなり自由度があって良いと思います。
GPSタイムアウト時間が秒単位(一般的には1分単位が多いようです)で設定出来るので、測位不能の時にさっさと諦めさせる事が出来、バッテリ消費量をコントロール出来ます。

WiFiや基地局による測位は個人的には不要(WiFiはともかくGoogleデータベースによる基地局測位は測位精度が良くない)だと思っています。
屋内に居る時などはWiFi測位は有効ですが、WiFiが入っていないと意味ないですしね。

基地局測位はドコモに限ってですが、移動機が基地局測位を行うのではなく基地局側が移動機の通信状態から位置を提供してくれます。
spモード契約必須ですが、アプリからの問い合わせに位置を答えてくれるオプション?があります。
Googleデータベースによる基地局測位だとkm単位で位置がずれる事がありますが、ドコモ側の測位だと200m〜300m程度の範囲には入るようです。
"いまどこ?"はこのオプションを使う設定があります。

GPS測位精度のみ改善の余地ありとは思うのですが、ここもバッテリ消費量とトレードオフですかね。
消費電力優先と測位精度優先の切り替えを持ったアプリもありますが、切り替えが必要なのかも知れません。

No.31553 RE:ロケーション履歴 CF化挫折者 http://https [n:Windows/7:Chrome/29.0.1547.76] 09/29(日) 11:19
仰るとおりこのアプリにとって現在位置送信機能ONとGoogle位置情報サービスOFFはマストですね。
このへんの調査が後手に回っていました。


GPSの精度に関しては思い当たるところがありまして、
Android 2.2の頃の機種のバグ対策とされる設定をとりいていたのですが、
それが悪影響を及ぼしていたようで、それをやめれば測位時間と精度が
改善されている印象です。現行機種では問題ないと思うので外してみようと思います。


> 測位不能の時にさっさと諦めさせる事が出来、バッテリ消費量をコントロール出来ます。

測位不能時の動作に関してはまだ改善の余地がないか調査中です。
常用するツールとしては測位の見込みのないビルの中でタイムアウトするまで電池を
消費するのは痛い、しかしタイムアウトを短くするとビルから出た後の測位ができない。

そこでNMEA値を直読みすることで、測位の見込みがない場合10秒程度で諦められないか調査中です。
(その辺りに明るい方、教えて下さい)


Android標準の基地局測位に関しては、LTEになってからは絶望的ですね。何とかならないものなのか。
当初のプランでは基地局変化をキッカケによる測位を併用するつもりだったので、ある程度調べたのですが
Android APIはGSMとCDMAにしか対応していないようでその辺りも関係有るのかもしれません。


しかしAndroidのサービスを初めて使ってみたのですが、システムの都合で突然終了させられることもあり、
(一定時間動作していると、取りあえず終了させられる)アプリと矛盾なくやりとりしながら信頼性を
確保するのはかなり大変です。殆どその辺りに時間を費やしました。
また、この種のアプリの動作周期が時々不正確になることが不満というか、デバッグが足りないのではなかいと
訝しがっていたのですが、自分がやってみると少なくともバッテリライフを重視する限り仕方がない事を
知りました。

やはり、やってみないと分からないことは多いな、と。

p119.net182021183.tokai.or.jp


No.31554 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/7.0] 09/29(日) 11:58
基地局測位は、CDMA方式の場合は確度を得やすいのですがLTEは難しいと思います。
TD-LTEで低位層からタイムアライメント値などを読み取れれば多少の精度アップは期待出来るかも知れないのですが、それ以外でマクロセルエリアとなると絶望的です。

通知インターバル(Google+ GPS Locatorの測位インターバルではなくGooglemapへの位置通知)に関しては調査というか検証中です。
Google+のAPIが公開されていない以上、Google+ GPS Locatorから位置情報送信を行わせる事は不可能に近いでしょうね。

Google+アプリを起動して自位置を更新すれば即座に通知出来るんですけどね。
静止時と移動時その他の場合、移動後静止していたエリアに戻った場合なども含めて検証しています。
結果は今週中にはBlogに書こうと思っています。

No.31555 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/10.0] 09/30(月) 13:49
測位精度が上がりましたね。
移動中の測位ポイントが道路から外れる事が少なくなりました。

要望というか希望なのですが、アプリ立ち上げと同時に現在地を送信するオプションが設定出来たらいいなと思いました。
設定された位置送出時間を待つことなく、ビルに入る前で一度アプリを立ち上げればその時点の位置が送信されるというような使い方です。

No.31557 RE:ロケーション履歴 CF化挫折者 http://https [n:Windows/7:Chrome/29.0.1547.76] 10/01(火) 22:13
アプリ立ち上げと同時に現在地を送信するオプションを追加したアプリをリリースしました。
数時間以内に公開されると思います。

今できることはあらかた実装した感じです。

自分は通知タイミングは1時間毎でも構わないこともあって機能面では概ね満足なのですが、思ったほどダウンロード数が伸びない。
ライフログ的な需要自体が少ないのか? 単に知られていないだけなのか?

p003.net220148047.tokai.or.jp


No.31558 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/7.0] 10/01(火) 22:25
バージョンアップしました。
ありがとうございます。

GoogleLatitudeに関して書かれているページもあるので、それの廃止で代替策を探している人も少なからず居ると思います。
アプリ紹介サイトなどに積極的に働きかけている作者さんも居るように、いかに世間に知らせるかが大切なのかも知れません。

blogの方でも使用感レポートを連載しますが、世間の人は一体どんなワードで検索してくるんでしょうね。
Google+は範囲が広くて引っかからないだろうし、LatitudeやLatitudesyncで検索してくれればGoogle+ GPS Locatorは知られる事になると思います。
PLAYへのリンク付けておこうかな。

No.31559 RE:ロケーション履歴 CF化挫折者 http://https [n:Windows/7:Chrome/30.0.1599.66] 10/02(水) 22:51
> PLAYへのリンク付けておこうかな。

ありがとうございます。
ここで取り上げていただくだけで嬉しいですし、参考になります。


> そこで次にLocation Spooferアプリを使用して無線ネットワークの位置情報を誤魔化してみた。
> すると10分ごとに位置通知が行われるようになった。
> この事からGoogle+は基地局による位置情報を元に静止と移動を判断しているのではないかと推測出来る。

上記実験は[Google+ GPS Locator]が意図通り動作する [Googleの位置情報サービス] が OFF の状態ですか?

実は応用の可能性を探るため、早速test codeを作り実験してみたのですが、擬似位置を設定するAPIに対して基地局やWiFiを対象とする[NETWORK PROVIDER]の
位置を、本来の位置から移動させるようにしてもGoogle+の送信周期に変化は見られませんでした。

[Location Spoofer]も[GPS_PROVIDER]を偽装することは間違いないと思うのですが、NETWORKの方を操作しているのかは分かりません。
GPSを偽装すると意味がなくなってしまうし。

p003.net220148047.tokai.or.jp


No.31560 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/10.0] 10/03(木) 07:10
> 上記実験は[Google+ GPS Locator]が意図通り動作する [Googleの位置情報サービス] が OFF の状態ですか?

その通りです。
ですので、基地局測位による位置情報を使うのみではなく位置情報の送信インターバルを決めるのにも使っているのではないかと思ったわけです。

ただ、

> 位置を、本来の位置から移動させるようにしてもGoogle+の送信周期に変化は見られませんでした。

と言う事ですので、また追試してみたいと思います。
私の実験方法は、特定の場所にスマートフォンを置いてGoogle+が静止と判断して位置通知インターバルが毎時1回になった事を2度確認(つまり、3時間放置)、その後Location Spooferでとんでもない場所まで移動した事にして位置通知が起きるかどうかを見ました。

通知された位置は、その"とんでもない場所"になりました。

No.31561 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/7.0] 10/03(木) 18:18
すみません、誤りがありました。

> 上記実験は[Google+ GPS Locator]が意図通り動作する [Googleの位置情報サービス] が OFF の状態ですか?

これはONの状態でした。
ONにしないとアプリが起動しないようで、ONにしたのでした。

No.31562 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/7.0] 10/03(木) 20:59
現在静止中の測位インターバルを300秒にして様子を見ているのですが、ログを見ると測位間隔が5分から9分くらいまでばらついています。
10分間隔でテストしたときは10〜11分ごとに測位が起きていたのですが、何か変わったのでしょうか。
それとも10分以下だとGoogle+が嫌がるとか??

今から10分間隔に戻してチェックします。

No.31564 RE:ロケーション履歴 CF化挫折者 http://https [u:Windows/7:Chrome/30.0.1599.66] 10/04(金) 19:41
測位周期のばらつきに関してですが、現在公開中のものはスリープ中に「自らはCPUを起こさない」タイプのタイマー(?)を使っています。
これすなわち、他の何かがCPUを動かした時に便乗するものなので電池の消費は最小になるはずです。
ですから長時間操作をしない深夜など特に頻度が下がる傾向があります。

そのため原理上数十秒から数分のばらつきがでるのは元々のつくりです。
ただ、これは説明がなければわからないですね。

これでは(自分はいいのですが)やはり不便なことも多いだろうと思いまして、「自らCPUを起こす」タイプのタイマー(?)を選べるようにしまして、動作確認中です。

ちなみにこのAPIは周期動作するアプリではほぼ必ず必要になるもので、AlarmManagerというのですが、面白いのはNTT DoCoMoがAlarmManagerに関してかなり詳細な解説をしたPDFを公開しています。この件に関しての説明では群を抜いており、とても親切で私もこれで詳細を理解しました。
こちら

少し見ていただくとわかるのですが、通信が集中することを防ぐためとはいえ、こんなに親切な解説資料を公開していたのは以外でした。

p003.net220148047.tokai.or.jp


No.31565 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/7.0] 10/04(金) 21:06
なるほど、そう言う事だったんですね。
今日何度か試していたのですが、決まって毎時15分頃に5分間隔にしているにもかかわらずインターバルが10分前後になっていました。
たまたまこの時に起き上がるプロセスがなかったんですね。

バッテリ消費量は後日まとめますが、3%/h程度(3分間隔測位)なので少ないです。

No.31566 RE:ロケーション履歴 bluefinder [MacOS/IntelMAC:FireFox/23.0] 10/05(土) 09:33
需要がないというか、Google+ということで二の足を踏むというか・・・

というわけで放置中のアカウントに久しぶりにログインして
使ってみようかな・・というところです。

決して興味が無いわけでは無いんですけど。
「いまどこ?」はずっと使ってましたし、F&Fで紹介されたので
山旅ロガーを今はそれなりに便利に使ってます。

No.31567 RE:ロケーション履歴 ほりこし [G:Windows/7:IE/7.0] 10/05(土) 20:28
Google+を便利に使っている人もいるとは思いますが、私はどうも好きではないなぁ。
何でもかんでも共有させようとする、公開させようとする、通知して来るなど面倒だと思ってしまいます。

No.31569 RE:ロケーション履歴 CF化挫折者 http://https [u:Windows/7:Chrome/30.0.1599.69] 10/08(火) 20:17
あまり詳細な記録を求めなければロケーション履歴はちょうどいいサービスなんですが、
やっぱりGoogleに詳細な位置情報が渡ることに抵抗があるのは当然ですよね。
自分もメリットが勝っているだけで、抵抗が無いわけではないです。


スリープ中のバッテリー消費に関しては、1回あたりのCPUの動作時間が

> 測位開始30ms + 測位後1秒につき30ms ( + タイムアウト時 30ms )

となっており、GPS測位精度を100m程度にしておけば60ms程度起きるだけで
済んでいることが比較的良い結果につながっているようです。

当初はGPSの受信状態から室内のように測位の可能性がない場合は早めに切り上げる
仕組みを実装しようとしていたのですが、そんなことよりCPUを寝かせていることが
省エネになると判断しました。


今、ビルから出た時の測位時間短縮のためにA-GPSデータを利用するバージョンを
リリースしました。
最後の測位から指定時間経過するとA-GPSデータをダウンロードします。

自分で試した範囲ではハッキリした差がなかったのですが、宜しければ試してみてください。

p003.net220148047.tokai.or.jp


↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31544 影響は無い。 スルメ [DoCoMo/N03A:DoCoMo/DoCoMo2.0] 09/07(土) 16:29
NTTドコモがアップルのiPhoneを販売するという非公式情報が流れている。
これに関してどこかのアナリストが、グローバルで通用する端末を開発できない国内の端末メーカは生き残れない、という内容をコメントしていた。
私はこれは正しくないと思う。iPhoneは初心者向けなのである。スマートフォンの黎明期ならば初心者も多いだろうが、もはや初心者のほうが少ない。
ドコモから発売されるiPhoneの仕様がわからない現在では確実なことは言いづらいが、おサイフ、NOTTV、dショッピングくらいは対応していないと売れない。なぜなら、スタイルモデル止まりでプライムモデルやプロモデルにならないから。
カタログの一覧表に全部丸が付くのがハイエンドということだ。

顧客が何を求めているのか、経営とは何なのか。一度、孫さんに頼んで教えてもらった方が良い。

proxycg003.docomo.ne.jp


No.31545 RE:影響は無い。 ほりこし [G:Windows/7:IE/7.0] 09/07(土) 20:28
リテラシーの高いユーザはAndroidに流れたと思われ、現在従来型ケータイを使っている人たちの半分くらいはAndroidは難しい、スマートフォンは難しいと思っているのではないでしょうか。
iPhoneならば、確かに機能は少ないですが何となく使えそう。
そう思う人たちがSBMやauに出ていく。

なのでiPhoneを扱えば、そのようなユーザを取り込める可能性があると思います。
個人的にはFelicaは欲しいのですが、その他のドコモアプリやサービスは要らないなぁ。
NOTTVのプロセスもdマーケットも無効化出来ずに動き続けますから、邪魔です。
勿論NOTTVを観たい人も居るとは思いますが、それはAndroidスマートフォンを買えば良いわけです。

↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31538 A-XGPの基地局設置 98Dispo [Windows/7:IE/10.0] 08/18(日) 14:20
都心に住んでいる実家から相談を受けました。
現在 ウイルコムの基地局3Gの設置をビルの屋上で運用しています。契約 平成11年
設置場所使用料6万電気使用料10,800円です。今回A-XGPの基地局の増設を行いたいとの
申し入れを受けました。3Gと込みで設置料72,000円電気使用量45,000円となります。
3Gの時間当たりの電力使用量は、電源ケーブルにワットメーターを付けた実測値ですと
30〜50W/hくらいですので損はしていないと思います。しかし今回設置するA-XGPの基地局の場合8本アンテナ・GPS付、制御装置最大消費電力200W、無線装置最大消費電力271Wとなり最大消費電力で471Wと約10倍以上の電力消費量になります。常時最大出力ではないと思いますがこの契約条件は不利なので、止める方向で話を進めるように助言しました。
しかし実家は、契約解除できないとの説明を受け(実家では契約書を紛失しているようです)困っています。実家としては設置しても良いが不利になる条件(電気使用量の持ち出し)は受けたくないことなので電気使用量としてはどのくらいが妥当な線なのでしょうかお教え頂きたくお願いいたします。私としては、14年間も設置場所使用料の値上げもなく
突然の申し入れに対して基地局の撤去を申し出したい(相手方の不誠実)と考えております。電気使用量に関しては電事連の過去のデータから算出しても、3Gの場合 妥当な金額であると思えるので値上げに対してのの損得勘定はありません。ちなみに今回の基地局増設時の電力量単価は23円/Kwhで算出しているそうです。

No.31539 RE:A-XGPの基地局設置 無口 [Windows/7:IE/10.0] 08/20(火) 08:00
詳しくは言えませんが同じように旧ウィルコム→SBM変更で電気代が大幅に上がったことによりSBMと揉めたことがあります。
相手を不誠実だとお考えなら契約解除が一番いいと思います。(もし相手の会社がつぶれたら負債のみのこってしまいますよ)

どうしても契約を更新するのであれば
1)東京電力と直接契約してもらい、設置場所使用料のみを受け取る
2)新たに専用電力メータを設置させて完全従量制として電気代は実費を受け取る
いずれかの条件にすることをお勧めします
電力単価も今後値上がりすることはほぼ間違いないでしょうから固定金額での
契約は不利でしょう

ところで
>制御装置最大消費電力200W、無線装置最大消費電力271Wとなり最大消費電力で471W
この情報は相手から開示された情報ですか?
私の経験ではもっと大きな電力になるように思います。

あと、契約ブレーカーに消費電力が増える分をまかなう余裕がありますか?

ntaich306196.aich.nt.ftth4.ppp.infoweb.ne.jp


No.31540 RE:A-XGPの基地局設置 ほりこし [G:Windows/7:IE/10.0] 08/20(火) 08:39
仕様書の最大消費電力は、決してこの値を超える事がないという電力値です。
3G設備の実測が50W程度は、たぶん接続してくる人がいないか少なかったのでしょう。
総合電力利用効率は10%以下になるのが普通なので、出力20WのBTSの場合だと消費電力は200Wとか300W位になります。
マイクロ局であれば当然消費電力は下がりますし、マルチバンドの高出力局だとkW級の電力を消費しますし冷却設備が必要になる場合もあります。

基地局の設置場所は取り合い状態です。
設置場所を変更するとエリア設計をやり直す必要があり、周辺局にも影響するので大変な事です。
このため契約条件として、場所提供者側からの契約解除に多額の解約料が設定されるなどするわけです。
3Gの契約書がないのは困りましたね。
いったんAXGPの契約を短期で受け入れて新たな契約書を作成して貰うのも一つの方法だとは思います。
電力料金のこの先が不透明だとして2年ごとの条件見直しとしても良いかもしれません。

いずれにしても場所提供者の方が強い(特に都市部では)ので、相手の言いなりになる事はありません。

契約上で大切なのは、設備の撤去に関する事です。
支払いが滞った場合は設備の所有権に関わらず強制撤去出来る事を明確にして、その場合の費用が払えない場合は基地局設備を(所有権に関わらず)売却する(担保に取る)権利を確保する事が必要です。

電柱や駅のホームに電線の切られたASTELの基地局がぶら下がっていますよね。
ASTELから事業を買い取った某社(!)は、それらの撤去費用を受け取りながら他に流用してしまったので撤去が出来なくなったのです。
場所提供者側はその撤去権を持っていないために手が出せないわけです。

No.31541 RE:A-XGPの基地局設置 98Dispo [Windows/7:IE/10.0] 08/20(火) 23:41
色々とご助言ありがとうございます。
契約書が見つかりました。契約先はDDI東京ポケット電話鰍ナした。
これが、変更になりWireless City Pianning鰍ニなります。
内容的には、非常に緩い契約条項でした。(解約料の発生も書いてありません)
解約条項は、3ヵ月前までに書面をもって通知し、甲乙協議の上云々
明け渡しは、乙は設置した施設を遅滞なく撤去し、設置場所を現状に回復し云々
とありますので内容証明付きの解約書を相手方に送ってみます。

>制御装置最大消費電力200W、無線装置最大消費電力271Wとなり最大消費電力で471W
この数字は、相手から設置する機器についての概要書で書かれていた数字です。
光回線を新設し、どうやら無線制御装置(BBU)を設置するようです。
電源は、ビルの共用ラインから引きますので緑のブレーカー30Aが付いてます。

No.31542 RE:A-XGPの基地局設置 jerrybird [M:Windows/NT:FireFox/22.0] 08/21(水) 22:13
消費電力監視用に、積算子メーター設置してはどうですか?
材料・工賃込みで3万円程度かな?

もっとお手軽には、→ こちら
なんてのも1万円少々であります。

No.31543 RE:A-XGPの基地局設置 98Dispo [Windows/7:IE/10.0] 08/26(月) 00:32
jerrybirdさま ご助言ありがとうございます。実家は老夫婦が住んでおります。
電気には詳しくなく、長男の私に相談されました。私自身実家の屋上にPHSのアンテナ
が設置されていることも知らず、相談されて気が付いた次第です。
なるべく手間をかけず、PHS基地局にお引き取り願えればと考えております。
相手もWireless City Pianning鰍ゥら委託を受けている業者なので、話がなかなか
進まず気長にやります。ご紹介のワットメータの取り付けも考えましたが
そこまでお金をかける気にはなりません。

↓次の記事の先頭へ↓↑前の記事の先頭へ↑

No.31536 ゴールドレーンへの憧れ スルメ [DoCoMo/N03A:DoCoMo/DoCoMo2.0] 07/25(木) 20:13
ゴールドレーンを使う人=ゴールドカードを持てるハイクラスの人ですよね。とても憧れます。
料金プランは真似できても、このようなサービスやステータスは無理だろうな〜
近々タイゼン端末もドコモから出るはずですし、他社がどう真似をしようとも、時代の先端を行くのはドコモ以外ないですね。

自動車も同じです。メルセデス並の性能は作れてもホテルに行ってもサマになるのはメルセデスだけなのです。

proxycg067.docomo.ne.jp


No.31537 RE:ゴールドレーンへの憧れ 除草 [Windows/Vista:Chrome/28.0.1500.95] 08/12(月) 14:39
ゴールドカードくらいでひがみなさんな。
この板を見てるくらいの人なら何とでもなるでしょうに。

メルセデスでは安っぽくて?ダメという世界もありますよ。

この板の過去ログをよく読んで少し行動すれば
メルセデス1台くらい買えるネタはいくらもあると思います。

ページ指定:01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
81 82 83 84 85 86 87 88 89 90 91


mbbs.cgi v5.00 by suzukyu 2000.12