半裸の鳥頭に比べればまだ常識的な格好よな。
最近のFormlabsってホビー向け(個人で買える価格帯)からは撤退していたけど、また戻ってきたんかな? /* ホビー向けの樹脂SLSを開発中だった会社を買収したアレはどうなったんだ */
コールドガスでジャンプしたり軟着陸したりできる車だそうだ。化学エネルギーを使わないので特別な推進剤が不要、コンプレッサーも内蔵していて外部支援無しに(電力ライン程度で)再充填できる、みたいなことなんだろう。これだけの推力を出そうとするとアホみたいな超高圧大容量タンクが必要だろうから、再充填にはめちゃくちゃ時間がかかりそうだが(外部からLN2を「給油」したりできるのかもしれないけど)。
こういうバカみたいな遊びも大真面目にできるのは純粋に羨ましいな。仮にトヨタとかホンダがこういうコンセプトで試作だけでもしようと思ったら何が必要だろう? トヨタなら水素用に超高圧ガスタンクのベースラインは持ってるかもしれないけど、大容量のバルブやノズルの設計まですぐできるとは思えない。テスラ/SpaceXならその辺に座ってる技術者に「こういうやつを作りたいんだけど」って声をかけたら「じゃあこの部品を使えばいいよ」位の話はすぐ通りそう。本田技研ならRCSの制御はできるだろうけど、だからといってそれを車に積めるかというとなぁ。そもそも日本国内で合法的に試作できるかという点もあるだろうし。
しかし、これが「空飛ぶクルマ」と紹介されているのを見るとちょっとアレだな。第二次世界大戦の潜水艦みたいな感じ。「空飛ぶクルマ」って、地上を走る車両を空に飛ばすわけじゃなくて、車のように気軽に使える航空機を意図しているものだと思うんだけど。スポーツカー的なレンジだとHondaJetとかだろうし、SUVみたいなあたりだとR-44あたりだろうし、徹底的に切り詰めるとウクライナのアレみたいなやつになるんだろうし。
もうちょっと発表が早ければ、ワイスピで出てきそうな感じではあるか。でも、あの作品だと市販車でビル間を飛んだり、あるいは普通の車にロケットを追加して極端な使い方をするから面白いのであって、「空を飛べますよ」と言って売ってる車で空を飛んだりしても、F-150でホームセンターに買い物へ行くような、何の面白みもないシーンにしかならないんだろうな。「(テスラ)ロードスターで空を飛ぶの? メーカーの想定用途じゃん」。
そういう意味では、ロードスターはFalcon Heavyで飛んだ時から、SF的な大衆作品では使えなくなってしまったんだろうな。まるでSFみたいなことをやるとSFに使えなくなるのか。そりゃ、SFが面白いのはフィクションの世界を見せるからであって、我々の世界をそのまま「サイエンスフィクションです」と提供したって面白いわけがないか。それで言うと、今後アクション映画でロケット付きの車を登場させると「あー、テスラのやつね……」ってことにもなるのか。
Boom Tech.のCEOの子どもの話とかもそうだけど、今後数年くらいで映画を見始めるような世代はワイスピを楽しむのも難しくなってしまったんだな。まあ、技術革新の歴史としては、創作物を時代遅れにしていくのが正しい方向ではあるんだけど。日本の場合、鉄腕アトムとかドラえもんとかガンダムとか、わりと振り切ったものが多いから、その点では当面は安心して見ていられるかな? ドラえもんの道具くらいの感じだと、一部は実際にそれらしいものが作られ始めてはいるし、人型ロボットもだいぶ近づいてきた感はあるけど。
うるう時間で調整が数千年単位になると、その時代では、例えば我々の時代の朝8時が9時だったり、1時間ズレて生活しているのが当たり前だから、いきなり「明日から社会を1時間早くします」とか「1時間遅くします」ってのはさすがに影響が大きすぎる気がする。1時間の移動は夏時間の調整程度ではあるとはいえ。
グリニッジ子午面の太陽通過で正午を決めなくなると時刻の定義は天文時から純粋に原子時に変わるだけで、それ以降もわざわざ天文時に合わせる必要はなさそう。そのまま時間のズレが増えていけば、数千年、数万年後には0時頃に日の出や日の入りが観測される、みたいな。コールドスリープで1万年後とかに飛んだ人間は時計の読み方に困るけど、連続的に生きている人からすればそれが日常になる。
数字全体を移動する(例えば正午を12時ではなくする)のは、現代を生きる我々からすればそんなことは許容できない、みたいなことになるだろうけど、何千年も経てば気にしないはず。我々(主に英語圏の人類)が使ってるカレンダーだって10月がOctだし12月がDecだぞ? 2ヶ月もズレてるのに誰も文句を言わないだろ。2000年も経てばそんなものよ。慣習として「歴史的にこの数字はこの時刻に割り当てられている」として記憶されていれば良い方で、多分その時代になれば誰も何も気にせず14時とかに昼食を食べたりするはず。学校で「今日はやけに腹が減って13時に早弁しちゃったよ」とか、歴史に詳しい友達が「おまえ紀元前の人間かよ」と突っ込んだりとか。
あるいは、現在でも巨大なダムで地球の自転が変わるみたいな話もあるわけだから、数千年くらいのタイムスケールなら地球の回転速度をうまいこと調整する技術を人類が作るという可能性もあるが。角運動量を直接出し入れするのは大変だから、質量の標高分布を変えて角運動量を保存したまま回転速度を調整する感じになるのかな。遅くするには質量を上げればいいわけだけど、長期的に見れば地球の自転は減速方向だから、加速するように調整しなきゃいけない。となると、山を崩して海を埋め立てる、みたいな話になる。核融合でエネルギー問題を解決してAIで無人土木工事が実用化すれば、数千mの山を切り崩して埋立地を作る、くらいは可能だろうけど、とはいえ。
電波で直結できなかったアジアは国際原子時に接続されるようになったかなり最近まで天文観測で時刻を決めていたわけだけど、UTCも結局天文観測でTAIとオフセットしていたわけだから、閏秒の廃止によって人類は有史以来続いた太陽で時間を決めていた歴史が終わるのかな。VLBIで時計を結合するみたいなことは続くのかもしれないけど、それはあくまでも間接的に参照しているだけであって、絶対的な時刻を決定する基準にしているわけではない。X線パルサー航法みたいなのが実用化されればまた天文で時刻や位置を決める時代が再来するんだろうけど。
ダイハツがアンモニア燃料の軽エンジンを開発、プラズマで水素を生成し燃焼促進：Japan Mobility Show Bizweek 2026 - MONOist
燃焼ベースのゼロエミッション化。トヨタは水素を燃やしているけど、液体水素は極低温かつかなり高い圧力でハンドリングしている。アンモニアなら2MPa弱で常温で液化できる。このエンジンは燃焼をアシストするために水素を混ぜるが、アンモニアの分解で作れる。始動時は外部からのエネルギー供給で、エンジンが温まればその熱を触媒に与えて。
小型車のゼロエミッション化だとコンパクトに作りやすいアンモニアは便利そう。もうちょっと小さくして、バイクくらいの小さいモビリティのゼロエミッション化でアンモニアを使うみたいなことってできないんだろうか? でもそれくらいの規模なら手で持てるくらいのバッテリーパックを交換すれば済むから、液体燃料を使う利点はあまりなさそうだな。
逆に航空機向けとか? いくらLH2よりはハンドリングしやすいとはいえ、MPaオーダーの燃料タンクかぁ…… 航空機の電動化を批判する文脈では「燃料は燃やせば機体は軽くなるが、電池は消費してもデッドウエイトになるだけ」というのがあって、そういう意味ではアンモニアは便利そうではある(LH2は極端に軽いしタンクがめちゃくちゃ重たいから、本質的には電池と同じ)。
2001年に建設中のアムンゼン・スコット基地の階段室でフーコーの振り子の実験を行ったときの記録。
振り子にエネルギーを与える機構がなかったから、数時間ごとに振り直す必要があって、回転速度の観測値は24時間±50分だそうだ。この記事では24時間というのが出てくるけど、実際には太陽日ではなく恒星日だからおよそ23時間56分のはず。
フーコーの振り子で安定化した機械式時計って作れないんだろうか? 通常の振り子時計は振り子からシンプルなメカニカルリンクでガンギ車と接続しているから、1次元的な振り子(平面振り子)にしか対応できない。フーコーの振り子のように球面振り子で時を刻むためには何らかの工夫が必要になる。あと、振り子へのエネルギーの供給も問題になる。
とはいえ、別にさほど苦労せず作れそうな気もする。例えば支点の真上に磁石を置いておいて、振り子の延長線上の磁石が接近して引っ張られるとガンギ車が回る、程度のものでいい。一定以上の力が加わって下に引っ張られるとそれに反応して磁石が引っ込むような形になっていれば、振り子が中心に向かって進むときには磁石が引き合って、一定以上の範囲に近づくと片方の磁石が離れるから、中心から離れる動きの場合は磁石による引力が少なくなる。球面振り子に対応したタイミングの測定とエネルギーの供給はこれでできるはず。磁石の引力みたいな微妙な力を検出しなきゃいけないのが面倒そうではあるけど。あとは、磁石を使うと渦電流でエネルギーが散るから効率が悪い(頻繁におもりを巻き直さなきゃいけない)とかは懸念される?
フーコーの振り子に連動して文字盤が回転しても面白そうだけど、それは機構が面倒になるだろうし、1日より少し遅い周期で1周する文字盤は見づらそうだ。ビッグベンみたいに4面とかの文字盤を回転させて見やすくさせるとかも可能ではあるだろうけど。しかし振り子に影響を与えずに位相を調整するのはちょっと大変そう。下手にプローブを当てるとそれで振り子の垂直軸の角速度が影響を受ける。なんだか量子論じみた話になってくる。
比較的小さいフーコーの振り子なら支点の上に時計をつけてもいいし、支点を見上げるのが大変なくらい巨大なら振り子の下に時計を置いてもいい。ただ、下に時計を置く場合は振り子自体を磁石に反応させるわけだけど、その場合は磁石の運動と地磁気が変な相互作用をする怖さはある。エネルギーを与えるためには少なくとも振り子は磁性体で作らなくてはいけないから、完全に影響を排除するのは難しい(磁石が上にある場合は支点との距離が短い分で移動距離(∝速度)が小さくなるから地磁気との相互作用は少なくなるはず)。
フーコーの振り子は決まった速度で垂直軸周りに回転するから、それを時計の長周期成分として使うことは考えられる。とはいえ、回転速度はsin(lat)で決まるから、自由に使えるわけではない。1周回ったら12時間、みたいな綺麗な表示は難しい(緯度30度線上だとできる)。
日本だと屋久島の南西にある口之島がちょうど北緯30度に土地がある。
戦後、北緯30度以南が米統治下になり、口之島もアメリカが統治していたので、日本復帰後に30度線のモニュメントを置いたらしい。
フーコーの振り子を極点に設置すると約23時間56分で1周するけど、時計として(短針代わりに)使おうとすると24時間で1周してほしい。これを緯度に換算すると85.7度くらいになる。このくらいの微妙な緯度にはちょうど良さそうな基地はなさそう。
Beast of Reincarnationをプレイ中。
こういうゲーム(銃メインじゃないやつ)は慣れていないので操作がちょっと違和感。まあ、慣れるしかない。
慣れている人からすれば問題ないんだろうけど、こういうゲームに不慣れでいきなり触ると操作方法が全くわからなくて詰む。攻撃ボタンを押す回数には意味があるとか、防御ボタンを押すタイミングには意味があるとか、そういう基礎知識が皆無でいきなりフィールドに放り出されると、ボコられ続けるし、わからないままに敵の攻撃3連撃を受けて死に戻りする。
難易度NORMALだと全く進めないけど、とはいえSTORYだと簡単すぎる。というか、STORYの場合はボタンをガチャガチャ押すだけで進めてしまうので、成長が得られない。STORYとNORMALの間にTRAININGみたいな難易度が欲しい。
例えばスト6のトレモみたいな感じで、タイムラインが表示されて、回避やパリィのボタンを押していた期間と敵の攻撃判定のタイミングがわかる、みたいな機能があれば、超初心者が始めるのは便利な気がする。このゲームの世界観なら世界観に沿ってトレモを作ったり、あるいは、武器選択で刃引きした剣を持ったらクゥと模擬戦ができる(時系列のメーターが表示される)みたいな感じでトレモ的な機能がほしかった。
プレイヤーの操作中、ずっと抜刀して歩いているのがあまり好みじゃない。あと、フィールドでもモフモフと触れ合えるようなギミックが欲しかったな。欲望を垂れ流すならどこかで20式を拾いたかった。
作品としては、いろいろな作品のフレーバーが感じられる。でも極端に寄りすぎることもなく、元の作品の尖った部分は削ぎ落として、バランスはかなり良い。
ゲームシステムに不満がないわけではないけど(主に細かい快適性の部分)、ゲームとしては良かった。
ネタバレというような内容でも無いと思うので気にせずに書くけど、途中で太陽、月、地球がどの順番で生まれたか、というような謎解きがある。多分こうだろ、というような順番で適当に並べたらうまく行ったのでそれが正解だったんだろうけど、しかし恒星進化(含惑星)の順番としてそれは正しいんか?という疑問。そもそも天体がどの時点で「生まれた」とするかにもよるけど。
物理的に質量がある程度集まった時点で考えるなら、中心に濃集した水素が太陽(の種)として生まれ、残りカスのディスクが濃集して惑星(の種)が生まれ、その後軌道が安定化する前に惑星衝突で衛星が生まれ、という順番なら、太陽→地球→月という順番になる。
一方で、ディスクの残りカスが存在していた時点(惑星が形成された時点)ではディスク中心では恒星活動はいまだ始まっていないはず(強い放射が始まるとガスが吹き飛ばされるから惑星が作れない)。そう考えれば、地球→太陽→月という順番になる。
ある程度安定した状態、つまり太陽であれば核融合反応による放射が表面から発生し、地球や月であれば重力エネルギーの発散が終わり、という段階を指すのであれば、ジャイアントインパクト後のドロドロした地球よりも先に月のほうが冷えるはずだから、太陽→月→地球という順番になる(ジャイアントインパクト以前の地球を現在の地球と別と区別した場合)。
このあたり(恒星進化論)はだいぶ曖昧に覚えているから、あちこち間違ってそうな気もするけど。/* 宇宙論的な本は結構売ってるけど、恒星進化論みたいな本ってあんまり無い気がする */
3本のNVMeの健康状態、CrystalDiskInfoで48%、86%、92%。最初の2本はRAID1でCドライブに、3本目は単独で最近はゲームのインストールドライブに使用している。RAID1の片方がやたら削れてる。たぶんコイツは書き込みキャッシュを使わず高頻度で書き込んで、システムがクラッシュしたらこっちをプライマリにしてスキャン、みたいなことなんだと思う。
過去のエントリを見ると、去年の6月時点で62％、一昨年10月時点で70%未満、だそう。16ヶ月で14%だから、当時の見立て1%/月相当で経過している。
元々ページファイルがCドライブに入っていたが、今回これを単独のNVMeに移動した。ページファイルは本来の用途としてはある程度頻繁な書き込みが発生するから、RAIDに置くのは適切ではないはず。ということで、移動した次第。もっとも、このドライブが故障するとページファイルの置き場所が壊れるから、危険ではある。ブートドライブの寿命を削ってRAIDの再構成の危険との天秤(Windowsは起動時にページファイルを置いているドライブが見当たらない場合はCドライブにページファイルを作り直すらしいので、ページファイルを置いているドライブが壊れても、Cドライブ自体が壊れるほどの悪影響はないはず)。
そもそも、このPCはRAMが比較的安い時代に組んだもので、動画編集とかをやらない個人が使うにしては結構大きめの容量を積んでいる。RAMの容量はあまり厳しくないので、たぶんページファイルはあまり使っていないはず。じゃあRAIDに置いていても良いんじゃないの?という気はするけど、とはいえただでさえ容量に余裕のないCドライブにほとんど使わない巨大なページファイルがあるのも邪魔なので、移動した次第。
半年とか1年とか様子を見て、プライマリのストレージがどれくらい削れるか見てみよう。
RAIDはMBのチップセットの機能だけど、AI曰くこのチップセットはRAIDの拡張に対応しているらしいから、OSの再インストールとかをせずとも拡張できるはず。とはいえ、2TBとしても2本買うと10万円だからなぁ。PCを組んだときに買ったやつは1TBで1.2万円だったのに、今では1TBも3万円弱まで高くなってる。ストレージの値上がりもすごいや。半導体がムーアの法則で安くなろうとしても、それ以上に需要が旺盛で札束を積む会社がいくつもあるとどんどん値上がりしていく。
先日の緊急地震速報の際、ISDB-Tのサンプリング忘れてました。たぶんAC1で出てたと思うんだけど。そこまで手が回らなかったというか、頭が回らなかったというか。スマホの緊急地震速報が出なかったからそもそも緊急地震速報が出ていたことを知らなかった、という言い訳。
GPSの測位演算、30秒くらいのデータを解析して、GGA/ZDAをGoogle Earthに突っ込むと、ほぼ正確な位置に平べったい回転楕円体が突き刺さる。15mくらい高めに出ているかな、という感じはあるけど、とはいえ回転楕円体の長軸が上下方向だし、誤差の範囲という気もする。ジオイドの符号を逆にすると完全に空中に浮くから、おそらくジオイドの補正は正しい。電離層・対流圏は未補正でサニャック効果だけ適用しているけど、アンテナを置いた建物にきれいに突き刺さるから、かなり高い確度で測位できている。ループフィルタが超広帯域だから、精度はさほど良くないけど。それでも短軸は端から端までで35m程度だが。
累計のサンプル数をサンプリングレートで割った、受信機クロックベースの時刻と、測位演算で求めたGPS時刻から、1次を引いて、つまりクロックエーラ成分だけを取り出してグラフ化すると、3.1e-7くらいの傾斜になる。フリーランしているTCXOが0.3ppmというのは十分に妥当な気がする(Airspy R2のTCXOはある程度特性の良いものが乗っているはず)。
対して、衛星のドプラからユーザの4次元速度を推定して、クロックの速度を見ると240m/s程度に見える。光速で割れば無次元になって、これが実際のクロックエラーに相当するはずだが、240/299e6でだいたい0.803e-6くらいになる。推定値が2倍以上ずれるのはちょっと腑に落ちない。
ドプラは搬送波のズレを見るから、LOの誤差がそのまま乗る。時刻の微分なら純粋に受信機のクロックエラー(ADCのサンプリングレート誤差)だけが見えるはず。そもそもR820T2/R860のLOってどれくらいの確度なんだろう? 0.8-0.3=0.5ppm程度とすると、L1で750Hz程度、UHFなら250Hz程度になる。ちょっと大きい気もするけど、元々がワンセグ受信用(あるいはせいぜい地上波テレビ用)であることを考えると、その程度の誤差はしょうがない気もしないでもない。
R820T2のレジスタマップを見てみると、PLLに関連しそうなレジスタは24bit分の割り当てがある。PLLの精度が24bitとすれば10進で7.2桁の精度しかないから、Lバンドでは100Hz程度の分解能しかない。先の推定に比べるとまだ7倍程度の差があるけど。
SDR#でWAVに保存すると、指定した周波数から若干(L1の場合1582Hz)ずれるけど、これってR860のLOを加味した中心周波数を表示しているんだろうか? 1.6kHzは先の100Hzに比べて10倍以上大きいけど、これは24bitが綺麗に使われている前提だから、例えば20bitしか有効に使われていないなら、1575.42M/2^20=1502Hz程度で、実際のズレとはわりと近い値になる。
Airspyt R2に適当な周波数を周波数を設定してairspy_r820t_readでレジスタを読んでみると、4箇所くらいが書き換わっているらしい。1個がPLLの整数分周、2個がPLLの分数分周、もう1個がミキサ前の分周らしい。全体として26,7bitくらいで設定できるっぽい。ただ、rtl-sdr blogが公開しているレジスタマップとは合わない箇所がある。librtlsdrのコードを追えば良いんだろうけど、さすがにそこまでは面倒で。。。
もしもR860のPLL分解能が足りない場合、GPSのドプラやISDB-TのCPを見て受信機のクロックエラーを補正するというのは意味がない可能性が出てきた。それが目的で始めたんだけど…… GPSやISDB-Tとクロックを比較する場合、GPSならGPS時刻得て、ISDB-Tならフレーム等価でシンボル窓のオフセットを求めて、それを微分してクロックエラーを見るしか無いのかな? あるいは、R860のPLLのループが分かれば、そこで発生する差をオフセットして直接CPを見るということもできるかもしれないけど。
もしSDR#が内部的にクロックを補正しているのであれば、SDR#でISDB-TのCPをCWで受信して、位置を調整するというのは、意味がある。線幅が数百Hz程度あるから1ppm程度までしか追い込めないけど。R2が1ppm未満の誤差なら、意味がないということになる。通常の(例えばR820T/RTL2832Uの)ドングルだと指定した周波数ジャストのWAVが出てくるから、多分内部クロックの補正はしていなくて、SDR#でスペクトルを調整するのもあまり意味は無いかもしれない。あるいは、R2はR860のクロックが10MHzでRTLは28.8MHzだから、これがPLL分解能に影響して、RTLベースでは綺麗なクロックが設定できるという可能性もあるけど、中途半端な周波数を設定しても1Hzの誤差もなく生成されるから、fc推定の処理を省いているだけだと思う。librtlsdrはR820TとE4000分岐しているから、SDR#もRTLの先に何がいるかはわかっているはずで、それならPLLの誤差を推定しても良さそうな気もするが。
櫛形フィルタのFIR型とIIR型の比較。適当に乱数を突っ込んでフーリエ変換。
FIR型の櫛形フィルタは馴染みのある形というか、そういう雰囲気。IIR型は対称的な形になる。
FIRは安定なので係数は自由に設定できる。IIRは|k|<1じゃないと安定しない。
CICフィルタはIIR型を積分器として、FIRを微分器として使って、係数は1あるいは-1で固定されている。なので、状況によってはIIRでも|k|に1を与えても安定な場合もある(CICは2進数の整数演算でごまかしてる感じもあるけど)。
高周波成分をカットしたいならFIR型でHCF的に、低周波成分を通したいならIIR型でLPF的に、みたいな使い方になるのかな。
ちなみに、FIR0.5+とIIR0.5をカスケードすると
みたいな感じで、FIRとIIRの非線形特性が打ち消し合って、直線な特性になる(片対数グラフで直線とか議論してもアレだけど)。
NCO(キャリア/コード)のフィードバックループにIIR Combフィルタ(k=1弱)を入れても、精度(雲の大きさ)にはあまり影響はなさそうな気がする。少なくとも、Google Earthでぱっと見てわかるような差は無い。それよりはフィードバックゲインを下げるほうが圧倒的に効く。ゲインが小さすぎると収束できず衛星をロストするけど。
本格的にやるなら、キャリアやコードの位相をカルマンフィルタみたいなもので推定してやるのがいいんだろうけど。
現状、観測量は50Hzで出しているから、10サンプルを平均して測位演算すれば、それだけでも雲はかなり小さくなる(たぶん10サンプル平均なら3倍くらいは改善するはず)。下手なループフィルタを入れるより、ほとんどフィルタを通さずノイズの多い観測値を高レートで吐き出して、後ろで(オープンループで)フィルタに通したほうが楽。クローズドループの中にフィルタが入らなければ安定性の面でも有利だし、どこでフィルタを通そうが結局違いは無いはず。実用的な受信機なら、軌道モデルに忠実なループフィルタを作ればスプーフィング耐性が上がる、とかはあるにしろ。
GPSのリアルタイム測位を走らせていると、PCがかなりうるさくなる。普段UPSの負荷はディスプレイ等も含めて250W弱だけど、測位中は350Wくらいまで増えるから、GPSの受信だけで100Wくらい食ってることになる。実際には、チャンネルスキャンをとめどなく回しているから、それの負荷が大きいんだろうけど。
思いつきで作った画像
2500x2500なのでブログではリサイズされて本来の意図通りに表示されない可能性もあるけど。
QRコードのドットの中に、さらにQRコードを埋め込んでいる形の画像。用途としては、画像認識(姿勢推定)みたいな場合に、引きで撮影すれば外側のQRコードが見えて、寄りで撮影すれば内側のQRコードが見えて、という感じで、マーカーへの距離に対するロバスト性を確保することを目的としている。
通常のQRコードの場合、21x21pxだから、大きなコードと小さいコードの大きさの差がちょっと大きすぎる気もする。
DataMatrixの場合、10x10pxから作れる(QRコードも小さいコードは仕様化されているけど、普及しているんだろうか?)。
コードのフォーマットとして、外側はID単体、内側はID+座標、というフォーマットを考えて、外側が10x10にクワイエットゾーンを足して12x12pxとした場合、内側には座標として3桁の数字が必要になる。外側が10x10だと数字は6桁まで、内側が12x12だと数字は10桁まで含めることができるから、例えばIDを6桁、それに座標を足して9桁、というようなフォーマットは作れる。
内側も10x10にすると、6桁の中でやりくりする必要があって、例えばIDを0から5000未満の範囲で、座標は5000倍して上位桁に挿入し、読み取った数字が5000未満なら大きい方のマーカー、5000以上なら内側のマーカーだから、5000で割ったあまりがドットの位置、というように読むこともできる。
そういうフォーマットで作ると、こんな感じ
ただ、10倍のダイナミックレンジはちょっとレンジが狭い気もする。16x16とかのほうが便利かも?
こういうコードの場合、隙間を開けずに連続して大量に貼るような使い方をするだろうから、大量に生成できるもう少し大きいDataMatrixのほうが良いかも。
元々は3段階くらいでスケールできるようにしたかったんだけど、コントラストを稼ごうとすると2段くらいが限界っぽい感じ。これでも結構厳しい。大きさ的なダイナミックレンジを広げても輝度方向のダイナミックレンジが狭くなって画像認識精度が悪くなれば意味ないし。
しかしまあ、こういう画像認識用のコードって見かけない気がする。普通のコードでも、認識できる範囲で引いた状態であれば複数のコードが視野に入るから統計的に処理できる、少数のコードに寄った場合は高空間分解能で撮影できる、というような理由もありそう。そもそも論として、そこまで極端に距離の差が大きい環境で画像認識を使う需要もないだろうし。ローバー系の研究室なら床や天井にマーカーを貼ってマーカーとローバーの距離は一定で使うとか、ドローンみたいに極端に動き回るやつはそもそも画像解析が難しいから精度を求めるならIRマーカーを追尾するとか。
