小さいボトルのラベルに「ブレーキ液」とだけ書いてあって、いやいやいくらなんでもここまでダサい商品もないでしょ……と思ってモノタロウで探してみたら、一番上に出てきたモノタロウPBのブレーキフルードの缶が結構ダサくて感心してしまった。
カップ麺の容器もだいぶダサいけど、地元の祭りで買った麺類とかが入っていたスチロール容器と考えればまあわからんこともない。
行動範囲は関東近郊だけなんだろうか? それとも日本の広い範囲をギュッと凝縮してマップ化するんだろうか。拡張コンテンツでもいいから北海道フィールドが欲しいなー。四季表現で変化に富んだマップになりそう。とはいえ、紅葉なら日本の広い範囲で見られるし、雪にしても北海道より本州の日本海側とかのほうが積雪も深いしなぁ。季節表現だけ見ればFH4と似たような結果にもなりそうだし。
やっぱり過去作との差別化を考えると富士山周辺+アーバンキャニオンがメインになるのかな。
Call of Duty: Black Ops 7 | How Japan Inspired Multiplayer Maps | Tokyo Game Show 2025 - YouTube
CoD BO7のマルチプレイヤーモードに日本インスパイアのマップが多く追加されたよ。
例のごとく日本語版は日本語字幕をつけて1080Pで再エンコードしてるので、日本語版で話の雰囲気を掴んだらオリジナルの4Kを見るのがおすすめ。映像めっちゃきれい。
都市部はあちこちに漢字、ひらがな、カタカナ、アルファベットが混在していいて、だいぶ日本っぽい気がする。字面やフォント、書いてある文字なんかを見ると違和感はあるけども。
アーケードのお土産屋の対面にある本屋っぽい店のロゴがすごいな「SHIORI」とアルファベットで表記して、そのOの中に栞の漢字があしらわれている。どっかからデザインを盗んだわけじゃなくて、デザイナーがCoD用に作ったロゴならすごい。通りの奥にあるカエルモチーフの店はタピオカ屋らしくて、2035年世界線で店舗を構えてるってことは、もう一度タピオカブームが来るってことかな? その横にあるのが交番だから、おそらく駅前の一等地みたいな場所のはず。そこでタピオカ専門店を開けるのはだいぶ人気な店なんだろう。
モノレールの駅も実際の駅(湘南モノレールや千葉都市モノレールみたいな懸垂式モノレールの画像検索で出てくる写真)とかなり雰囲気が似てる。
「TOSHIN - 都心 -」エリアは、駅から出たすぐの場所に平和のモニュメントがあって、その向こう側に交番、その横がタピオカの店、その正面のアーケード街に観光客が来るお土産屋や地元民が来る本屋があって、駅から出てすぐの場所にはカラオケ屋もあって、駅から離れると高層ビル群があって、みたいな感じか。都心と言うよりはちょっと開発が遅れている郊外という感じもするな。
屋上にあるテレビのアンテナはVHFも残っている感じ。VHFのアンテナの新設は2005年とかそのあたりで終わっているはずだから、30年モノの建物か。まあ、この街の雰囲気からすれば妥当なところか。
「旧市街のような地区から中心部の都市エリアへ」みたいな発言があるから、やはり地理と時代をグラデーションに作ってるんだろうな。
遠景に高いタワーがあるけど、アンテナの向きはその方向を向いていないから、電波塔ではなく単に観光用の施設のはず。ある程度無線通信の方向にも興味がある僕としては、色々なゲームの中でテレビアンテナや衛星アンテナの向きがバラバラなのはちょっともにょる。
「DEN - デン -」マップは宮殿や神殿とかの殿だろうけど、あんまりトラディショナルな城という雰囲気はないな。最新の防空システムみたいなものも置いてあったり、建物も天窓を追加したり、結構改造してある。日本で古くからある城(orそれに見立てた城)をこういうふうに改造するのは結構大変そうだ。美術館みたいなデザイン重視の建物で城っぽい建物と現代的なデザインを融合させる、みたいなのはあるかもしれないけど。中のサイバーチックな設備も合わせて、外資系が最近建てた建築物って感じがする。それに外観はともかく、内装のデザインは和というより中華っぽい感じ。
違和感はありつつ、よく作られてるマップだと思う。普通に見て歩くだけでも面白そう。特に市街地の商業施設のデザインはところどころかなりすごい。日本を好きな人がデザインしたのか、あるいは日本人がデザインチームにいるのか。でも日本マップを作るうえでスタッフに日本人がいるならもう少し違和感の少ないデザインになるようにコントロールするだろうし。
自分はCoD BOは1作目だけシナリオをちょろっと遊んで以降は触ってないからなー。最初は冷戦時代だったはずなのにいつの間にかSF世界感になってる。
そういえばCoD BO7のトレーラーでも東京が出てきてたな。たぶんシナリオモードのシーンだと思うんだけど。
映像が綺麗だしBGV用にレンダリングシーンマシマシなPVが欲しいなー。
この手のエクステンションアダプタ、トルクレンチみたいに静的なトルクならともかく、インパクトレンチみたいに動的なトルクはだいぶ減衰しそうだけど、問題ないんだろうか。エアコンのボルトとかだとよほど振動するような場所でもない限りは問題ないだろうけど、単管足場みたいに上を歩いてガタガタ振動して、しかも人命に関わるような場所だと、そのあたりは心配なところ。
解析しながら別データを測定可能 テクトロニクスの新オシロ：「7シリーズDPO」 - EE Times Japan
10G SFP+でデータを転送することで、オシロでのサンプリングとPCでの解析を同時並行で処理できる。AMDのCPUやNVIDIAのGPUを積んであるらしいけど、サンプリングと独立して解析/描画ができないなら何に使ってるんだろう。
5/6シリーズだと2Uラックマウント型でアナログ周りだけ切り出してデータの取得だけできるような製品が売ってるけど、今のところ7シリーズではそういう製品はなさそう(少なくとも日本サイトでは)。そのうち売るんだろうけど、ネットワーク連携前提なら最初から(or優先して)ラックマウント型を得ればいいのにな。
将来出すシリーズで、GPUをAMDに置き換えたりすることはあるんだろうか。低レベル信号を処理するFPGAはXilinxだろうし、CPUはAMDだし。GPUもAMDになれば上から下まで全部AMDでフルコンボ。
ガジェット系の分野で部品名等の接頭辞としてついているe、例えばeMMCやeGPU、全く逆の意味なのに同じ接頭辞なのどうにかならなかったのかな。eMMCのeはEmbeddedのE、eGPUのeはExternalのE。同じEでも「内蔵」と「外付け」の両方の意味がある。大抵は文脈というか字面で区別できるけど。
ゲーム系ニュースメディアのIGN、記事の背景が半透明の白でその後ろに広告の画像が表示される。僕はこういう表示をされると非常に気が散って文字が読めないので、IGNにしかない記事以外はできるだけ避けている。
どうしてもIGNで読まなきゃいけないときは読まざるを得ないけど、とはいえ記事の中身はほとんど頭に入ってこない。例えば記事を読もうと思ってスクロールしたら透過度が下がって背景の広告がほぼ見えなくなる、みたいなデザインもできるはずだし、そもそも画像は一部しか見えていないから広告効果だってほとんどないだろうし。記事の背景に常にカラフルな画像を表示するのを許可したのは一体どこの馬鹿だ?って感じ。
試しにChromeのリーディングモードを使ってみたら、画面を半分弱に分割して狭い方にテキストだけが表示されるとかいう、これこそ本当に馬鹿が考えた機能って感じ。Google Lensもそうだけど、Chromeの組み込み機能って本当にクソだよな。Googleの稼ぎに埋め込み広告とかもあるわけだから、それらが見えないリーディングモードはGoogleの稼ぎを落とすからダメ、みたいなことなんだろうけど。
EdgeのAIも右側に追加したペインで表示されるけど、とはいえURLでオンラインサイトを読み込めばブラウザ全画面でCopilotを使えるからまだマシ。
C#で用意されてるTryParse系のやつ、outを引数に取るけど、refを取るやつがほしい時がある。if(double.TryParse(input,out var tmp)){value=tmp;}みたいな処理を、double.TryParse(input,ref value);で済ませられる。
C#のQueueってforeachで回せば順番にPeekしてくれるけど、逆順に取り出すのっていい感じにできないものかな。LINQで反転させればいいんだけど、回数が多いとパフォーマンスが気になるというか。カリカリまで切り詰めなきゃいけないなら自分で必要なアルゴリズムのバッファを組むんだけど、そこまでするほどでもないというか……
https://www.jahep.org/hepnews/2009/Vol28No1-2009.4.5.6OkumuraShiozawaNakayamaHayatoYamada.pdf
2009年。スーパーカミオカンデのDAQの更新について。
約1.3万本のPMTから出てくる実イベントレート数kHzの信号を、可能な限り低エネルギーまで漏らさずに記録する必要がある。PMTから出てくるアナログ信号をASICやFPGAでデジタイズして、100BASEでワークステーションへ転送し、信号を時分割して各ワークステーションでソフト的にトリガ処理を行い、バックグラウンドノイズを除去して記録。
最大で7.2万イベント/10秒の信号を捉えることができるので、我々の銀河系中心付近で発生した超新星爆発でもデータを逃さず取得できる。
https://www.qst.go.jp/uploaded/attachment/37821.pdf
SK全体の概要とか。
J-PARKとのT2K実験では2拠点間をGPSコモンビュー(NICTソース)で時刻同期してるんだとか。単純に時刻を合わせるだけならUTC(NICT)に同期する必要はないはずだけど、2拠点間同期用のGPS受信機より、UTC同期用GPS受信機のほうが安く用意できるんだろう。受信機のパネルにNICTのロゴが入ってるけど、これってNICTが売ってるものなんだろうか? それともあくまでもNICTのサーバーにアクセスしてUTC(NICT)に同期しますよ、という意思表示なんだろうか。
最後にハイパーカミオカンデの話も少し。SKではPMTからのアナログ信号を同軸線で1箇所に集めてデジタル化しているけど、HKではPMTのすぐ近くでデジタル化することで、信号品質を改善するんだそうだ。電子回路が故障すると水を抜かない限り修理できないので、信頼性が重要。高さ70m、26万トンもの水槽の中で長期間稼働できる耐圧容器が必要になる。
非修理系に近いという点で人工衛星っぽさもあるけど、むしろ耐圧容器に入れて水中で使うことを考えると光海底ケーブルの中継機とかのほうが近そう。修理できないことはないけどめちゃくちゃ高コスト、という部分も含めて。水深数千mで四半世紀、とかに比べれば、水深100mで10年～くらいだと、そこまで厳しくはないかな? あまり変わらないか。複雑な信号処理が必要とか、過去に作ったノウハウが無いものをいきなり高信頼で作らなきゃいけない難しさもあるし。
2016年。カミオカンデとかニュートリノの説明とか。例によってカミオカンデのデータ処理は富士通が関わってるんだろうか?
この時点でHKはSKの20倍の有効体積を想定していたらしい(現在8倍で建設中)。
カミオカンデ、スーパーカミオカンデ、ハイパーカミオカンデ、と来て、その次ってどうするんだろうか。語感とか考えるとウルトラカミオカンデとか? うーん…… 日本で「ウルトラ」はちょっと安易すぎるという気がしないでもない。
そもそもHKよりさらに大きくすることってあるんだろうか。理学要求より土木側で実現できるかどうかの制限が強そう。2,30年後に土木技術がどれくらい発達しているかによるか。これ以上体積を大きくするならIceCubeみたいにその場にあるシンチレータを使うような方向になるんだろうか。HKで淡水中に設置したエレキが動くことを確認できれば、それを海水中に持っていって…… 宇宙線や電磁波(太陽光)を十分に遮蔽することを考えるとかなり深い部分に設置しなくちゃいけないから、耐圧性が厳しそうだな。普通の海だと発光生物が入ってくることも考えなきゃいけないし。
首都圏外郭放水路の調圧水槽は容量が70万トン弱だから、HKの有効体積19万トンの3.5倍くらいある。深さが全く違うから単純に比較することはできないにしても。支柱を作っていいならHKより巨大なタンクも作れるんだろうけど、それによってどれくらい信号が遮蔽されるのか。あるいは、柱にもPMTを貼り付けて、円錐の放射点を3次元的に計測することも考えられそうだけど。まあ、その程度のことは東大の頭のいい人たちが寄って集って考え尽くしてるだろうし。
SKみたいに中央集権的にデータを集めるとタンクの大型化やPMTの数にはエレキ側から制約が出てくるけど、HKみたいに分散型でデータをハンドリングするならそのあたりの制限はある程度少なくなりそう。
GNSSの測位信号、いままでC/Aしか触ってなかったから他のコードはよくわからないんだけど、例えばL1 C/AとL2Cは別の符号を使っているわけだから、L1/L2をコヒーレントな局発で同じ周波数にダウンコンバートして、それを加算してからADCでデジタル化したあとで相関器で符号を分離して、元の複数周波数の測位信号を高いタイミング精度で測位信号を得る(複数のADCの同期が不要)、みたいなものってあるんだろうか?
そもそも2周波(or more)対応なGNSS受信機自体ほとんど情報が出てこないのがな。
アナログ段で混合して相関器で分離できるなら、L1/L2を適当な周波数(数十～数百MHz付近)にダウンコンバートして加算するアダプタをつかって、その後ろはR820T/RTL2832でPCに取り込む、みたいな感じにして、安価に2周波をコヒーレントにサンプリングする、みたいなことも可能なんだろうか(そういう特殊なダウンコンバータが安く作れるかは別として)。
あるいは、適当なドングルを改造して、2つのドングルをコヒーレントに並べて、R820Tから出てきたIF(数MHz帯)を単純な回路で加算して、片方のRTL2832でサンプリングする、みたいな感じも考えられるか。下手に専用のアナログ回路を作るよりこっちのほうが楽かも。
ヒーター内蔵GPSアンテナってググっても1個も出てこないんだけど、そういう需要ってないんだろうか?
小さいアンテナに4℃付近のサーモスタットがついていて、低温時にはヒーターがONになる、みたいな物があれば冬でも使いやすそうだけど、とはいえBias-Teeの0.4W程度じゃ温めるよりも冷えるほうが早そうな気もする。単純に空気中に放熱するだけじゃなくて、グランドプレーンの金属面からもどんどん熱が逃げていくから、温めるなら相当な電力を突っ込まないとダメそう。
https://www.gsi.go.jp/common/000046725.pdf
電子基準点の凍結対策。アンテナ周りは全く触れていなくて、地盤の凍結(凍上)が問題らしい。
コンクリートパイルで地下深くの地盤へ固定して、地表付近の基礎は断熱材で覆って凍上を防ぐ、みたいな対策らしい。凍結で土の体積が変わるのが問題なら土と物理的にアイソレートする必要があるんだろうけど、基本的に凍結は等方的だから水平方向はあまり問題ないのかな?
https://www.gsi.go.jp/common/000228079.pdf
たぶん最近のGEONETの近代化の話。GEONETの資料は数年毎に区切ってその中で「第N年次」という書き方をしているので、それがいつなのか全くわからないな。
最後の方にレドームにヒータを追加して雪を溶かすための実験を始めた、みたいなことが書いてある。今後はON/OFFの自動化も、みたいな感じだから、現状は手動でON/OFFして雪が溶けるか実験している、といったところか。最近になるまでこういう実験をやっていなかったということは、高精度化してようやく影響が見えてきた、ということなのか、あるいはそこまで手が回っていなかったということなのか。
https://www.gsi.go.jp/common/000025593.pdf
2006年。「したがって、急激な座標値の変動を地殻変動のシグナルと誤認するような事態を防ぐためにも、レドームへの着雪防止の対策が望まれる」。結構前から認識されていたっぽい。
着雪対策として超撥水塗装を行うとか、凍上対策として断熱材を入れたり、砂を入れたり。/* この超撥水塗料、メーカーWebサイトには屋外で使うなと明記してあるけどな */
https://www.nra.go.jp/data/000410380.pdf
原子力規制委員会の資料。前の方に冬季の基線解析で見られる影響の具体例とか。
凍上で上昇が見られたり、あるいは逆に下降が見られる基準点もある。下降については、冬季に融雪を目的として地下水の汲み上げが行われる影響ではないか、とのこと。
最近の電子基準点は原子力設備の安全確保に使われたりもするから大変だねぇ。
https://www.jsece.or.jp/event/conf/abstract/2020/pdf/312.pdf
2020年
PPK(後解析キネマティック)GPSに対応したドローンで雪面を撮影して、積雪量を推定する。火山での融雪型火山泥流による災害の規模の推定とかに使える。
PPK対応かつカメラ付きのドローンとしてInspire2を使用。RAW画像を解析することで、特徴点の少ない雪面でも必要な精度で地形モデルを作れる。積雪のない時期での地形との差分を取れば積雪量が得られる。
***
GPSの受信のやつ
色々機能が増えてきて手狭になってきた。かろうじてFHD画面に収まるくらいの大きさ。
一番左側がデータソース。rtl_tcp経由でRTL2832を使うか、WAVファイルからIQファイルを読み込むか、あるいはNMEA0183形式でプロプライエタリなセンテンスで保存したメッセージ/擬似距離を使うか。NMEAで読み込めば60倍速とかで処理できるから、アナログ信号を扱わなくていい範囲のデバッグはかなり楽になる。
その右側は解析結果をNMEA0183で保存したり、IQファイルを保存したり、細々したコマンドを操作したり。一番下に測位演算の結果を表示している。
さらにその右側に天球上に衛星配置や電離層遅延の表示と、測位演算での擬似距離残差のグラフ。下には測位演算の結果を3Dで描画する領域があるけど、これは謎のバグが発生していて動作していない(新しく確保したBitmapのインスタンスでGraphicsを作ってもobject is currently in use elsewhereが出る不思議な挙動)。
その右には受信するPRNを選択するチェックボックスが大量に並んでいるのと、世界地図上に衛星や電離層遅延モデルを表示している。
一番右側はDCRで送られてくるメッセージの一部を表示しているけど、ここはだいぶ手抜きなので、丸ごと作り変えたい。でもDCRのメッセージ複雑すぎて手を入れるの大変。。。
衛星選択/世界地図を非表示にするとかなりコンパクトになる。
衛星が放送しているLNAV/SBASメッセージはせいぜい1Hzとか1/6Hzだから全部保存しても大したデータ量ではない。プロプライエタリな擬似距離は10Hzで保存していて、かなり大量のデータを保存しているから、1日あたり400MB(gzip圧縮時)くらいある。
擬似距離残差は通常は±30mに収まる。測位演算の精度も水平面は10mとかそれくらいのオーダーに入る。が、たまに擬似距離残差がkm単位まで大きくなることがある。そういう場合は相関器をリセットすれば収束するから、相関器の問題だと思うけど、アナログ的な部分だからデバッグが面倒。
あと、場合によって相関器をリセットしても収束しない(かつ測位結果が大きくズレる)場合もある。この場合の原因は全く不明。十中八九相関器周りだろうけど。
通常時に擬似距離残差が±30m位になるのは、ちょっと誤差が大きいような気もする。1桁とまでは言わずとも、もう少し小さくまとまってもいいと思うんだけど。現状、測位演算はサニャック効果だけ考慮して、電離層とか各種遅延は組み込んでいない(AF0/AF1/AF2はもちろん組み込んでいるが)。ただ、電離層遅延はせいぜい数m程度(特に夜間)だし、実際、電離層のモデルをON/OFFするような適当なコードを書いても、擬似距離残差で見えるほどの影響は無い。擬似距離残差のpeak to peakより大きいバイアスがあるから、何らかのバイアスエラーがあると思うんだけど。放送歴に誤差があるならSLASでそれに応じた補正値が放送されるはずだけど、SLASを見てもせいぜい5m程度しか無いから、ちょっと足りない。
DCRもどうにかしたいのだが。特にDC9 Ash Fallが難解。同じ地域の同じ時刻の異なるステータスがいくつも出てくる。実際に警報が出ているときに気象庁とかに見に行けばどうやって表示するべきかわかるんだろうけど、そのためにはまず警報が出ていることを確認する必要があって、そのためにはDCRの表示機能を作って……
0 件のコメント:
コメントを投稿