水没世界オープンワールドFPS『The Last Caretaker』11月6日に早期アクセス配信へ。ひとりぼっち機械による、人類の未来を賭けた廃墟探索 - AUTOMATON
オブジェクトのデザインとか色使いがだいぶ好みに近い。
極端に未来感のあるデザインじゃなくて、例えばスクショのアサルトライフルは普通に現行の銃のカラバリって感じがする。銃に照準器がついていないのは、自身がロボットであると考えれば、自身で座標を管理すればいいわけだから、全く問題ない(ロボットのinstinctive shooting能力は人間とは桁違いだからな)。ただ、銃に残弾表示のモニタがついているのはちょっと違和感があるな。銃のデザインに対してミスマッチ。そういうガジェットを作った人は実際に存在しているから、その延長線上で、ありえないというほどのものでもないけど。とはいえ、ロボットであれば自身で残弾数の管理(記憶)もできるわけだから、むしろAR(拡張現実)的に残弾数を銃にオーバーレイする表示のほうが世界観にあっている気がする。
チョップスティック付きの発射台から打上げられる巨大なロケットはちょっと未来感があるけど、とはいえ我々の世界だってあと10年もあれば運用されてそうだしねぇ。
デモ版を少し触った感じ、画面が若干揺れるので酔いやすいのと、ゲームシステムとしてはRustとR.E.P.O.を足してシナリオメインのソロ専用にした感じかな。どっちもやったことないけど。
デモ版では目が覚めた施設を出たところで終了。その範囲ではあまりシステムは進まないので、クラフトとかの要素はあまりわからない。手間を掛けて施設内のリソースを全部使えばかなりのところまでは行けそうだけど、時間はだいぶ掛かりそう。
時間をかけてゆっくり進めていく感じのゲームという感じ。
出口は見えたか、DMG森精機担当役員が語る欧州市場の行方と工作機械の将来：EMOハノーバー2025（1/2 ページ） - MONOist
公式のYouTubeの動画だとドローンで飛び回ってる映像とかあるけど、展示場の建物一つ丸ごと全体を使って、ほんとにドローンで飛ばないと紹介できないくらいデカいブースを構えてるのよな。
「もう1つは、ソフトウェアデファインドだ。将来的には例えばギア加工のソフトウェアを購入することで、既存の工作機械にも機能追加できるようにしたい」
言うは易しだし、そうしたいんだろうけど、しかし既存の工作機械にも追加するってのは結構大変そうだけどなぁ。ここで言う「既存」がどれくらいのタイムラインを考えているのかわからないけど。「今現在設置してある」のか、「このサービスを開始した時点で設置してある」なのか。ハードウェア依存度の高い機能だってあるだろうし(例えばAIチップリムーバルとか、3Dスキャナとか、工具スキャナとか)、そういう機能が不要なユーザーまで「将来使うかもしれませんよね?」でハードウェア全部盛りの機械を売るのもどうかと思うが。まあ、そういうユーザーにこそ「必要になったときはライセンスを買うだけで使えますよ」という売り文句が効くのかもしれないけど。
ミドル帯の計器(徹底的に低コスト化する必要はなくて、かといって高価な部品を山積みしているわけではない)とか、特に解析機能とかはライセンスだけ後から売るみたいな構成も多いけど、ある程度価格競争力が必要な場合とか、あるいは基本構成では使わないハードウェアのコストが高い場合、ライセンスだけ後売りモデルは厳しそうな気がする。DMGの場合前者の問題はないだろうけど、後者はどうだろうか。水分や油分の飛沫が多い機械の中で何年も動いてなかったハードウェアをいきなりノートラブルで100%動かさなきゃいけない分で信頼性を確保するためのコストもかかるし。
あるいは、ハードウェアが必要な機能は注文時に指定して、そうでない機能(CAD/CAMを内蔵して歯車加工とか)だけライセンスで売ることを考えているのかもしれないけど。
とある日に受信した謎のリプライ
とある日とか言いながらガッツリ日付見えてるけど。
Mode-Cに矛盾しないリプライが1個、それ以外の従来型リプライが3個、それとMode-S応答が出ている。
Mode-Cにコーディングされていない応答のうち、一つはA列(1桁目)だけセットされていて、それ以外はABD列(1,2,4桁)あるいはBD列(2,4桁)がセットされている。さらにA列だけの応答とBD列の応答は周期が低い。
この時間帯をFr24で見てみると、旭川空港(RJEC)周辺でC-2が飛んでいたらしい。珍しい。飛び方も変な感じ。空自の機体であれば、Mode-1,2,3/A,C,Sに対応している可能性はありそう。ただしこの推定が正しいとして、1,2応答と3/A,C応答は周波数特性が若干異なる。もしかしたら汎用の3/A,Cトランスポンダと、主に軍用でしか使われていない1,2トランスポンダは機材が別なのかもしれない。Mode-Sはサンプリングレートが足りないので特性は不明。
四半世紀くらい前にENRIが取得したデータによると、陸自駐屯地付近でMode-1/2のインテロゲーションを検出したらしい。例えば旭川駐屯地(800m級の滑走路が1本ある)のレーダーが1,2,3/A,Cの質問を出していて、それに応答しているという可能性はありえる。
4月に取ったF-15らしい機体の応答を記録したファイルを再度見てみると、トータルで10個のMode-1,2,3/A,C応答と1個のMode-S応答が取得できていて、その内で、Mode-Cに矛盾しない応答が3個あって、Mode-1に矛盾しない応答が2個ある。この時、2機のF-15と1機の民間機が飛んでいたはずだから、F-15がMode-1,2,3/A,Cを1個ずつ8個、民間機がMode-3/A,C,Sと考えると矛盾しない。
空自機はMode-1,2応答も返して、陸自の対空レーダーも常時Mode-1,2の問い合わせを行っている、というような感じなのかな?
先日受信したUH-60(千歳救難?)は2種類(おそらくMode-3/A,C)の応答しか出していないから、正面に出る機材か否かではなくて、機体規模(ある程度複雑なアビオを積めるかどうか)によるんだろうけど。あるいは、F-15は設計が古いから搭載、C-2は機体規模に余裕があるから搭載、みたいな可能性もあるけど、それなら同様に設計が古いUH-60だって積んでいてもいいだろうし。あるいは、位置関係の問題でMode-1,2の質問が届いていないだけかもしれないけど。
別の日
1200(Mode-3/A)とMode-C応答(FL20台前半)が出ていて、時々フレーミングパルス(赤枠で囲った部分)も低頻度で出している機体。Mode-Sは無く、Fr24にも機影なし。
1秒程度の間にMode-Cとフレーミングパルスがランダムに多数出ているタイミングもあるので、一時的に気圧計とトランスポンダの接続が失われている、という感じでもない。もしも振動で接触不良になるような場合、全ビットがクリアされるわけではなく、もっと乱雑なパターンになるはず。それに、たぶんGillhamコードは主に負論理で接続するはずだから、接触不良はクリアされる方向ではなくセットされる方向になるはず。Gillhamコードとして不正なビットパターンはトランスポンダが全ビットクリアに上書きする挙動があるとしても、もう少し乱雑なビット列が出てもいい気がする。
こういう機体って航空管制官からはどういうふうに見えるんだろうか? Mode-C質問でフレーミングパルスを返す場合、Gillhamコードとして正しくないから、レーダースクリーンには映らないはず。Mode-3/A質問でフレーミングパルスを返していた場合は同一の場所に複数の(異なるスコークの)機体が存在しているわけだから、目立つような表示になりそう。もしも管制官から見えるような状態(状況認識に支障をきたすような表示)であれば、トランスポンダの不調として何らかのルートで運用者に連絡が行くはずだから、フレーミングパルスを出すようなトランスポンダが放置されているとすると、管制官からは見えない状態な気がする。
ATCトランスポンダの応答は統計とか取ったら色々面白そうだけど、ウチは地形的にあまり多くの応答が得られないからなー。高高度を飛んでいる国際線(アジア欧米間とか)の機体だと結構遠くまでかすかに受信できることがあるから、国内線の受信数があまり稼げないのは地形の問題だと思うんだけど。
https://www.jstage.jst.go.jp/article/ieiej/32/7/32_474/_pdf/-char/ja
2012年。首都圏外郭放水路の概要。
200m³/sの排水能力があるので、50m³/sのポンプを4台並べている。14mを揚げる必要があるから、航空機用エンジンのガスタービンエンジンを流用してポンプを駆動しているんだそう。
送水は圧送で行っているので、排水ポンプのOFF等でのサージングが問題になる。調圧水槽はその圧力を逃がすためのもので、だから「調圧」と言うんだそうだ。
https://www.jstage.jst.go.jp/article/tsj/32/6/32_6_337/_pdf/-char/ja
2004年。首都圏外郭放水路の、特にポンプとか排水周りの話。
解析で水路を最適化することでコンパクト化したりとか。動力は従来はディーゼルエンジン(水冷)を使っていたが、ガスタービン化で空冷化ができ、130トンから30トンまで軽量化でき、低振動なので基礎も簡易化できる。
https://www.jstage.jst.go.jp/article/tsj1973/17/2/17_2_93/_pdf
1989年。下水設備のポンプに関して。ガスタービンエンジンが使われ始めた頃かな。いろいろな利点や欠点など。起動時の回転数とか排気温度とかの図も。1軸型はクラッチ(油圧クラッチ等)が必要、2軸型はクラッチ不要、みたいな話はヘリコプター用のターボシャフトエンジンと同じ感じ(この時点では2軸型は開発中といったあたりらしいけど)。
道路が舗装されることで雨水が下水に流れ込んで、流量が急激に変動することが増えてきて、その対策とか。
あとは軸受周りの話とか、冷却の話とか。一次冷却水・二次冷却水・クーリングタワーとかは、あちこちで使われてる用語なんだろうけどな。
https://dl.ndl.go.jp/view/prepareDownload?itemId=info%3Andljp%2Fpid%2F3527103&contentNo=1
1999年。MHIのポンプ用ガスタービン。
P&Wのガス発生機を使用し、ガスをL字に折り曲げて垂直な軸で出力し、減速したうえでポンプを駆動するのに使う。
長さのあるジェットエンジンは寝せたまま、出力軸は垂直で使いたい、みたいな用途かな。ただ、結局ベベルギアで減速機を組むならそこで軸を曲げればいいんじゃね?という気はする。あくまでもこの減速機は試験用のコンフィグレーションであって、実際には平行軸減速機だけで減速するつもりなのかもしれないけど(平衡軸と書いてあるのはたぶん平行軸の誤変換だと思うんだけど、平衡と誤変換するあたりいかにも熱屋さんって感じがする)。
https://www.jstage.jst.go.jp/article/jime1966/8/8/8_8_513/_pdf
1973年。船舶用ガスタービンの特集。
船舶用ガスタービンはどういう方向性がいいか。航空機用を転用するか、地上用を流用するか。航空機用は信頼性は高いがいささか過剰である。ところで、技術の将来性をどのように見極めるか。例えば昭和初期に航空機用のエンジンは空冷か水冷かという問題があった。空冷は500PSあたりが限界であって、それ以上は水冷が必要であると考えられていた。ところが大戦末期には水冷は1500PS程度までしか実現せず、空冷は3500PSまで実現できた。学術研究と違って応用では様々なファクターが影響するから、簡単に予測することができない。経済性が要求される商船は陸上用、高速性が要求される艦艇は航空機用のガスタービンを転用するようになるのではないか。
そういう寄稿が数人分でいろいろな見方が書かれている。
日本での船舶周りの技術開発。戦前は海軍がリソースを提供して技術開発を行っていた(魚雷艇みたいな速力が必要な用途を想定)。戦後は防衛庁がその役割を担っているが、ディーゼルエンジンの高性能化(過給器の搭載とか)で性能の向上が続いているため、ガスタービンの民間への採用はほとんど行われず、専ら艦艇に搭載されるのみ。
クローズドサイクルのガスタービン。原子力船に応用が効く技術として開発していたらしい。なんとなく日本の核(原子力)アレルギーから考えれば日本で原子力船ってあり得ないだろとか思ってしまうけど、とはいえ日本だって原子力船を建造した実績はあるわけだしな(その船体は現役で(あと数ヶ月は)使われているわけだし)。昔は今みたいに原子力に対するアレルギーはそれほど強くなかったのかも(時代によっては核廃絶を訴える組織でも「共産主義の核は人類平和に資するから反対すべきではない」みたいな論調があったみたいだし)。時代を経るごとに様々な原子力事故があって、どんどん拒否反応が強くなっていったんだろうな。あるいはマスコミが不適切な報道を行ってそれを増幅していった、というような話もあるだろうし、それを読む側も不適切な報道を鵜呑みにしているということもあるだろうし。
戦時中の船舶用ガスタービンの開発。この話は当時の随想があるらしいんだけど、j-stage内には無いっぽい。後続誌の公式サイトから見れる目次のPDFからタイトルはわかるけど、そのPDFに含まれているリンクはすでにドメインが売られていてリンク切れ、タイトルで検索しても出てこない。
https://www.jstage.jst.go.jp/article/jime/47/2/47_213/_pdf/-char/ja
飛鳥II(客船)の機関系の解説。ディーゼル発電機(主x4、補x1)で発電し、モーターで可変ピッチプロペラ(低速時65rpm～巡航時最大132rpm)を回す。巡航18ktで重油90t/d、全速力(21kt)で120t/d。
飛鳥IIIについては、検索すると燃料にLNG・軽油・重油の3種類を使用できる、みたいなことは書いてあるけど、じゃあそれをどうやって燃やしているんだ、という話は全く出てこない。柔軟性の高さという点ではガスタービンで燃やしていそうな気もするけど、とはいえ適当な燃料をボイラーで燃やして水蒸気でタービンを回して発電する、みたいなやり方でも燃料の自由度は高そうだしなぁ。
https://www.jstage.jst.go.jp/article/ieejjournal/129/2/129_2_97/_pdf
2009年。船舶の電気推進について。歴史とか、実際の構成例とか、その際の負荷の計算とか。
結局、民間の船舶では一部を除いて現在でもディーゼルが主力なのかな。LNG運搬船みたいに気化ガス(BOG)が出る場合はそれを燃やすこともできるが、その場合もボイラーを炊いて蒸気でタービンを回すか、あるいはガスジェネレータ(ガスタービン)に使うかは別れるっぽいし。
ディーゼルの欠点は広い出力範囲での燃費の悪さだけど、輸送船であれば最適な燃費で巡航するからデメリットにはならない。旅客船は頻繁な入出港やスケジュール管理上最適な燃費を維持することは難しいが、電気推進化でエンジン負荷をある程度一定に維持できるようになった以上、ディーゼルのデメリットは少なくなってきた。ガスタービンの利点は出力に対して軽量な点で、軽量化が最重要な航空機や、軽量化のインセンティブのある艦艇(戦闘艦)には利点だが、大型船では軽量化の要求はさほど大きくない(巨大で堅牢なディーゼルエンジンを積んでいることからもうかがえる)。軽くないと浮かぶことができない飛行機とか、飛行機ほどではないにしても傾斜で位置エネルギーを稼がなければならない陸上車両に比べれば、船は出力あたりの軽量化はさほど要求されなくて、ガスタービンの利点はあまり活かせないのかも。複雑なサイクルで燃費を改善したガスタービンもあるけど、そこまで複雑なものを積むくらいならディーゼルのままでもいいじゃん、みたいな。
関係ないけど、タービンつながりの最近のニュース
AIブームの意外な勝者、キャタピラーに脚光－隠れた主役はタービン - Bloomberg
鉱山向けの採掘機械や建設機械から、発電機までを手広く扱うキャタピラーは、最近のAI関連で業績が伸びるのではないか、という話。
CATのディーゼルエンジンの発電機はYouTubeで見たことあるような気もするけど、ガスタービンエンジンの発電機も作ってるんだな。ディーゼルは建機用のエンジンと共通化ができるだろうけど、ガスタービンってどっから出てきたヤツなんだろう?
データセンターみたいに莫大な電力を使う場合、熱効率のスケールメリットが強烈に効いてくるだろうから、現地で発電するより電力会社の巨大な発電機を使ったほうが効率が良さそうな気もするけど、そんなこと言ってられないくらいに需要が逼迫してるのかな。
https://www.jstage.jst.go.jp/article/micromechatronics/42/1/42_KJ00001887636/_pdf/-char/ja
1998年。JRCの人がGPSの小型化技術について解説したもの。JRCが'84年に作った船舶用の受信機から、'97年の車載用まで、例えばアンテナ容積13分の1、受信機容積300分の1、そのためにどういう技術が使われたか、等。
一番最後に「現在のGPSはここまで小型化できた」というイメージとして、カシオの腕時計PROTREKと並べた写真がある。腕時計のケースより一回り大きいサイズでアンテナも内蔵できるようになったぞ、と。なお、GPS受信機能を内蔵したPROTREKが発売されるのはこの翌年だから、カシオ社内では腕時計にGPSを内蔵する試みはある程度形になっていたはず。/* ぐぐるとPROTREKの変遷の話も出てくるけど、これも面白い。ユーザーの視点をどうやって得るかとか。GPSの話が全く出てこないのも興味深い */
https://www.jstage.jst.go.jp/article/micromechatronics/59/213/59_9/_pdf/-char/ja
2015年。GPSハイブリッドソーラー電波時計。11x11x3mmのアンテナとか、ソニーの受信チップとか。省電力化の工夫。測位を行うのはタイムゾーンの判定時だけ。それ以外は一つの衛星のword2のTOW狙い撃ちで受信時間を極限化する(パリティ含めて1ワード分受信するのかな?)。自動受信を行う場合は太陽電池で屋外にいるかどうかの判定を行う。屋内にいる場合は標準電波の受信を試みる(消費電力がGPSの数百分の1で済む)。
GPSと標準電波の違いで、標準電波は周波数が低いから回折しやすい、と説明しているけど、長波あたりだと家の中で受信できるのは回折とは別の原理のような気もするのだが、どうなんだろうか。
GPSを使用した腕時計の省電力化の工夫では衛星1個で時刻だけ受信するという場合が多い気がするけど、その場合の時刻精度ってどれくらいあるんだろう? 衛星の位置関係によって10ms台くらいはズレそう。アナログ腕時計で10ms程度の確度が得られるなら十分だろ、という話だけど。
https://www.jstage.jst.go.jp/article/micromechatronics/65/224/65_2/_pdf
2021年。女性向けGPSソーラーウォッチの話。特にアンテナ周り。
小径・薄型でありながらアーバンキャニオンで測位しなきゃいけないので大変そうだ。測位演算はあくまでもタイムゾーンの自動設定が目的であって、時刻同期は衛星1個でやるっぽいけど。人体をGNDに使いつつ、腕につけたときに12時方向が上を向くので、その方向に指向性を持たせているらしい。
アンテナ、直径28mm、厚さ1.25mm。五百円硬貨より0.6mm薄いくらい。
https://www.jstage.jst.go.jp/article/jin/98/0/98_KJ00004696943/_pdf
1997年。衛星EPIRBに搭載するGPSアンテナのフィージビリティモデル。GPS受信用の円偏波アンテナの中心に穴を開けてEPRIB送信用のモノポールアンテナを立てる感じ。両アンテナを1箇所で設置できるので、実装面積を小さくできる。
V/Uのグランドプレーンがやたらとデカイ。実際にEPIRB送信機を作るならGPはもっと小さくしそうだけど、そうするとGPSアンテナの特性も変わりそうだが。とりあえず真ん中にアンテナ立てて動作できることを実証した、という感じなのかな。
https://www.jstage.jst.go.jp/article/jinnavib/98/0/98_KJ00004997681/_pdf
1988年。測位システム(Loran-C、NNSS、GPS、等)の小型化について。昭和63年ですって。GPSって昭和の時代に作られたシステムなんだよなぁ。
マイコンを使ったり、チップ部品を使ったり、カスタムLSI(フラットパッケージ)を使ったり。
ロックウェル・コリンズのハンディ型GPS受信機の写真。
調べ物をしているときにたまに出てくる大学院生とかが書いた資料、なんだかなぁ、って内容が結構多くて、なんだかなぁ。その結論は正しいのかもしれないけど、でもそこにいたる前提条件は違うんじゃない?みたいな。もうちょっと真面目に検討してから発表資料を作ればいいのに。大学院生はそんなに暇じゃねえよ、と言われると返す言葉もないけど。
外部同期のできないSDR受信機でGPSの時刻に、IFにローカルで作った疑似信号を注入して同期するやつ、実際に受信したGPS信号から測位した結果をSBASエフェメリスで出して、AF0,1,2を0にして、擬似距離残差がゼロになるようにローカルを動かせば、GPSに時刻同期したクロックになるんだろうか? その擬似衛星を測位演算から除外するロジックが必要になるけど、今のところ自作の受信機はSBAS衛星は測位には使っていないから問題ない。あるいは、定期的にMT0を出しておけば除外してくれるはずだし。
GPS C/A SBASをマイコンから出力するのってどれくらい大変なんだろうか。相対静止な信号でいいからドップラーは気にする必要はなくて、信号の生成はわりと簡単そうな気もするけど、とはいえコアクロックが144MHzとかだと1.023MHzにコヒーレントなクロックが作れないから、シンプルなクロックツリーでSDRドングルにコヒーレントなC/A信号を出すのは大変そうだ。
外観や内装の図。DS2000の内側が細かくレンダリングされている図って意外と珍しい気がする。外から見える白い円筒(TWTAの冷却器)がその内側ではどうなっているか、とか。
GPSのAF0,1,2成分
とりあえず手元に航法メッセージがある5月前半以降。
大きくジャンプしているやつはPRN35とかPRN36とか、正式運用ではない衛星。
PRN20が途中で長期間止まったあとに誤差ゼロ付近を放送してすぐにジャンプしている。PRN21は放送開始直後に大きな傾斜があって、だんだん収束していっている感じ。
PRN26は途中で傾斜が大きく変わっているけど、クロックの設定を変えたのかな?
GPSは0.8ms以下で運用しているけど、QZSは数百ナノ秒とか数マイクロ秒を超えない範囲で運用している感じ。QZSはGEO機がSBASと共有でこれはクロック誤差の許容幅が非常に狭いから、それに対応した制御になっていて、他の非静止衛星でも同様に制御している、という感じかな。
GPSのクロックエラー、試しにグラフ化してみたけど、見ても大して面白い感じではないかなー。もうちょっと頻繁にクロックの調整を行っているのかな、と思っていたけど、意外と低頻度というか、安定している。
全く再現できないけど、C#で個別のBitmap/Graphicsインスタンスにマルチスレッドで並行して触るとInvalidOperationException(Object is currently in use elsewhere.)が出る気がする。Formに表示する複数の画像を生成したい場合、マルチスレッドで同時に作るのではなくて、シングルスレッドで作るほうがいいのかもしれない。できればGUIスレッドで作るほうがForm側(C#ライブラリ側)と衝突しなくていいんだろうけど、それだと時間がかかる描画処理が難しくなるから、せいぜい描画周りだけを一つのTaskに切り出す、程度で。
ここで言うobjectってBitmapとかGraphicsのインスタンスのことだと思ってたけど、実際はGDI+のことを言っていたんだろうか?
0 件のコメント:
コメントを投稿