僕が住んでいるのはもっと田舎の方で、周りに北海道弁の人もいないので、1話を見た感じではあんまり地元感は無いな。まあ、北海道も広いからな。
どんどん目新しさのない古典的なヘリコプターみたいな方向になって行ってる感じがする。僕はこういうコンセプトは好きだけど。
荷物の自動接続機能とかほしいよねー。自動で積荷ができれば輸送効率がかなり上がるはず。ダウンウォッシュの空力を利用して画像認識でフィンを制御してプローブに突っ込むみたいなシステム作れないものかな。地面付近だと気流が厳しいのであれば、ワイヤー経由で給電してプローブの接続時にだけプローブ横に着けたプロペラを回して位置制御を行うみたいなシステムも作れそうだし。まあ、そのうちそういうシステムも出てくるであろう。
DJIのやつはウインチがついていて、プローブをドローンの根本まで引き込めるから、荷積みする場所に障害物がなければドローン単体で位置制御ができるのが強そう。狭い場所でピックアップするなら人間が必要かもしれないけど、平地から山岳地へ輸送する場合は駐車場とか広い場所に荷物をおいておいて勝手にピックアップさせるみたいなことができそう。川崎のやつは長さ固定のケーブルだから、先端のプローブ側で頑張らざるを得ない。
ドップラーLiDARって小型化の方向はどれくらい進んでいるんだろう? 固定型だと長距離特化で小型化は進んでいなさそうなイメージ。製品としては最大レンジ10kmで230kgとか300mで45kgとかそのあたりかな。さすがにデカいか。ドローンに乗るくらいの大きさ、1kg弱くらいでレンジ50mくらいまで小型化できれば1秒程度先の通過空域の風速がわかるからフィードフォワード制御に使ったり、ホバリング中に数秒先の気流を推定して吊り荷が暴れるのを防いだり、いろいろできそうだけど。光学デバイスの進化は著しいし近いうちに1kg未満で100mくらいのレンジは作れそうな気もするけど、製品としての需要が見えないと商品化は難しそう。
風ベクトルの計測を目的にするならドップラーLiDARに拘る必要もないしな。小さなドローンを風上に浮かべておいて推定加速度と実測加速度の差を取れば風速ベクトルをある程度推定できる。精密なベクトルがほしいなら超音波風速計でも載せておけばいいわけだし。これならLiDARの指向性に関係なく常に風上に浮かべられるし、スウォームというほどの数じゃないから制御もそれほど面倒じゃないだろうし。
航空自衛隊にもJPADS的なシステムほしいよねーとか思ったり。そこそこの広さの場所があれば一気に数トンから数十トンの荷物を下ろせる。まあ、日本の山間部でどうやって場所を確保するんだと言う話ではあるけど。
そういえば、空中投下用のシステムで、直径1m弱くらいのダンボール製の六角柱を使うようなシステムってなかったっけか。六角柱を落とせば横から3枚の羽が展開して、位置エネルギーを回転エネルギーに変換する形で適当な速度で落ちて行って、最終的に底部のダンボールをクラッシャブルゾーンに使って着地させる、みたいなやつ。ダンボールを折りたたんで多少の金具を付ける程度だから低コスト。軽くググっても出てこないんで別の何かと混同している可能性もあるけど(airdorop、ググラビリティ悪すぎ)。
これは単に落とすだけの減速デバイスだけど、小さいアクチュエータを1個追加したら落下位置を制御できそうよね。パラシュートだと位置エネルギーは空気中に放出してしまうけど、このタイプだと運動エネルギーの形である程度のエネルギーを保持しているから制御性も良さそう。回転させる以上は直径や高さに制限がかかるけど、逆に言えば1個1個が小さいから扱いやすそうではある。2トンの塊が落ちてくるよりは100kgの塊が落ちてくる方がまだ威圧感が少ない。大量の物資を必要とするような用途には不向きだけど、少量のペイロード(数十kg程度)なら大型のドローンから投下してもいいし、量がほしいなら100kgクラスを輸送機から一気に吐き出せばいいし。通常の空中投下だとパレット1枚の大きさだからパレットごと投下できるけど、小さいものをまとめて落とそうとするとハンドリングが大変そう。まあ、需要があれば技術的な問題はある程度どうにでもできる。逆に言えば、需要があるかどうか。
サイクリック制御だけならアクチュエータは1個でいいけど、3個あるとコレクティブ制御もできるから、落下速度をある程度制御できる。適当な対地センサがあれば着陸時のダメージを軽減できて良さそう。誘導にGPSを使うからGPSで高度が得られるけど、安価なGPS受信機だと高度の精度が悪そう。気圧センサを載せて、例えば投下時に母機の気圧高度計とGPS高度計で減速位置のQFEを設定してやれば、少なくとも目的地に誘導できた場合はソフトランディングが期待できる。
小さなスケールモデル(投下重量1,2kgくらい)なら作れそうではあるけど、とはいえ作ったところでテスト手段がないからなぁ。まず巨大なカタパルトを作るところから始めないと…… 1kgの質量をある程度の高さに放り投げる程度でもウエイトは100kgくらい必要になるはず。それを持ち上げる手間もある。実験支援設備が本体みたいな様相。1kg持ち上げられるドローンを買うよりは安いだろうけど、とはいえ。
改めてそれっぽいワードでググったら出てきた
US5947419A - Aerial cargo container - Google Patents
1998年に特許申請されて2018年に特許切れ。思ったより古い。元の会社はもうこれに関しては開発・販売は行っていないようだけども(というか会社があるか自体不明)。youtubeにも動画があるけど、全体はダンボールでできていて、底部と上部に金属の枠をはめ込む。このフレームは焚き火台として使ってダンボールを燃料に調理もできるよ、とのこと。落下の衝撃に耐えられるなら何でも入れて落とせるけど、主にサバイバルキットを想定している。
当時の製品としてはDropMaster社のCopterBoxみたいな感じかな。
別のコンセプト。2021年頃に開発していたやつ?
Airdrop Service Dash Delivers Proof of Concept - Los Angeles Business Journal
50lb程度の荷物を誘導するシステム(将来的に100-200lbまで拡大予定)。4枚のグリッドフィンで位置制御を行い、パラシュートで減速。上述のコンセプトとはだいぶ違うシステム。最近はあまり活発に活動しているという感じではなさそう。フィン自体は位置制御を目的にしていて、エネルギー変換には主眼を置いていない。最終的にはパラシュートで減速するから、大なり小なり風の影響は受ける。
しかしまあ、ダンボールのやつも、この誘導できるやつも、使い所が難しそう。大抵の用途はこれからの時代ならドローンで置き配すれば済むだろうし、ドローンを安心して飛ばせないような治安の悪い場所だと上から落としたって駄目だろうし。量を落としたいならアメリカならC-17でパレット落とせば済むだろうし。
機器の排熱でウナギ養殖 北海道、サーバー管理会社 - 産経ニュース
液浸冷却サーバーの隙間に潜り込んだデンキウナギの電力でサーバーを稼働させて……
とりあえず1巻だけ読了(5冊刊行済み)。
前半の地球パートはかなり好みでサクサク読めたけど、後半はストーリー上多数の恒星を並行して探査するから、場面がコロコロ変わって読むのが大変だった。著者と同年代の人は楽しめそうだけど、若い(orにわか)SFファンにとってはとっつきにくい内容な気がする。
しっかし、この表紙絵、絶対本文を無視して書いてるよな、と思って英語版を見てみたら、英語版の方も似たりよったりだった。ふーむ…… 彼らが使う宇宙船は反作用で飛ぶわけじゃないからノズルは必要ないはずなんだけどなぁ。
AFOPの武器、溜めが必要な重弓より連射ができる短弓のほうが1発のダメージが大きいのが納得行かない(もちろんライフルより短弓のほうが高威力)。単弓は矢の製造効率も高いし、重弓で1発で撃破できない敵は攻撃されるとアラートを出すけど、単弓ならアラートを出す前に2発目を撃って無力化できるし。
簡単にに終わるサイドミッション(素材の納品で手持ちがあるやつとか)は一通り処理して、あとは素材集めとか生産系とかのサイドミッションがちらほら。時系列的に後の方に出てきたクラフト系ミッションだと必要な素材の品質も高いから、素材を集めるだけでも大変。ゲームシステム(マップとか素材のピン止め)も使いづらいし。
差集合巡回符号、パリティを含めてビットシフトした場合、シンドロームを計算しても多数決を取ると誤りが無しという結果になってしまう? 全ビット(例えば273ビット)を計算に使うと、右シフトの場合は最下位ビットがエラーになる一方、左シフトの場合はエラーなしになる。短縮化(例えば184ビット)の場合はどちらもエラーなしになる(データによるかも)。
ISDB-Tのフレーム同期の確認を行うには、パリティではだめで、ちゃんと同期信号を見るか、あるいはTMCCを復調する必要がある。
NHK(GおよびE)のISDB-T AC1の低周波側の2本に、フレームごとに変化するデータが乗っている(続く6本にも固定パターンの情報が乗っている)。204bitの内、後ろの方の32bitはパリティっぽい変化の仕方(パリティの後ろにさらに7bitの1埋め)。固定パターンの6本はこの32bitが固定値で、それ以外は1で埋められている。AC1の低周波側の8本を独自の情報伝送に使用して、普段はそのうちの2本だけ使う、という感じかな。IDはすべてのAC(104本)で0h。
固定パターンの6本のパリティらしい値は、160bit(20バイト)をFFhで埋めてCRC32を計算したものに一致するから、データ長160bit、パリティCRC32、で間違いなさそう。ただ、データが入っている2本のCRCを同様に求めると、実際の値と違う値になる。ACには203bitが入るから、160+32+7を引くと4bitが余るから、データ部を0-3bitシフトさせてCRCを求めても、パリティの値にはならない。
AC1の復調はSPで等価した後に行っているから、BERはかなり低いはず。ただ。固定ビットらしい場所にも時々1bit反転がある。誤って復調しているのか、データとしてビット反転しているのかは不明。全ビット1埋めであろう96本は全部1埋めとして見えているし、AC1と同様に1キャリアずつTMCCを取り出すとすべてのキャリアで同じ値が取れるから、ビットエラー率は無視できるほど低いはずなんだけど。CRCの計算に使用するビット列は規則正しく並んでいるはずだ、という想定に基づいて、CRCを逆算しながらビット列を探していくと、テストデータ(乱数を規則的に並べてCRCを付加したビット列)は正常に復元できる一方、実際のAC1のデータを逆算しても、それらしい結果が得られない。さすがにCRCの計算時に入力ビットをシャッフルする、みたいな意地悪な実装ではないと思うんだけどなぁ。ノーヒントで解読するのは難しそう。さすがに160bit総当りでCRCを確認するなんてことも大変だし。そもそもパリティがわかったとしてもデータの内容は相変わらず意味不明だし。
民放をざっと見た感じだと、AC1はすべてのキャリアでFFh埋め(IDは7h)だった。局の運用によるだろうけど、うちのあたりではAC1を定常的に使っているのはNHKだけっぽい。実用的な用途(高精度なJSTの放送とか)に使っているのであればググれば出てきそうだけど、軽くググっても出てこないので、汎用的な放送用途ではなさそう。一体どんな用途で使っているんだろうか。
ISDB-TのAC、せっかくタイミング精度高く情報を送れるんだから、JSTの放送とかやってくれたらいいのいな。ISDB-T単体でサブPPMレベルの周波数を供給できるのに、時刻が無いのがもったいない。もっとも、GPSが普及したせいでアナログ放送が終了する前にテレビ電波を使用した周波数・時刻の供給は終了してしまったので、わざわざISDB-Tで引き継ぐ必要はなかったわけだけど。とはいえ、昨今の精密な時刻の重要性を考えると、GNSSより精度は悪いとはいえ、信号強度で数千倍から数万倍くらい強い電波を使えるのは便利そうな気がするけどなあ。精度が悪いとは言ってもミリ秒程度の精度は出るだろうし。まぁ、帯に短し襷に長し感はあるけど。
ISDB-TのTTLに関する2000年頃の卒論、FFTとかフレーム同期とかの一連の機能を「回路規模が大きくなる」という理由で避けてるのがなんだかなぁ。ISDB-Tのフル機能の復調なんてたかだかテレビ1台分未満の回路規模じゃんかよ。
卒論は「そんなところまで説明するのかよ」と呆れるくらい基礎的な部分まで書いてあったりすることもあって、網羅性という意味では良いんだけど、とはいえ「それは間違いじゃない?」あるいは「これは明らかに間違っている」みたいな部分も色々あって、差し引くと結局「暇なら読む」程度の情報価値になってしまうんだよなー。まあ、卒論はその分野の最先端を記録・公開するというような内容ではないからしょうがないとはいえ。
GitHub - siddolo/R820T-breakout-board: Rafael Micro R820T Breakout Board
R82xx系ブレークアウトボード、もう少し種類あっても良さそうな気がするけど、ぐぐってもほとんど出てこない。AdafruitとかSparkFunとかその手のメーカーから出てても良さそうな気がするんだけどなぁ。R82xxのボードがあればI2Cでコマンドぽちぽち叩いたらVHFからLバンドあたりまでを扱いやすい帯域にダウンコンバートして、狭帯域で出せばArduinoのADCで直接サンプリングして復調して、みたいに遊べて遊べそうな気がするんだけど。さすがにATmega328でFMステレオの復調は荷が重そうだけど、とはいえエアバンド(AM)の復調くらいはできるだろうし、頑張ればFMモノラルなら復調できるかもしれないし、日本ならCM4Fと組み合わせてワンセグの音声を受信するとか、いろいろできそうだが。もちろん高帯域幅でダウンコンバートして高spsのADCとFPGAなりを組み合わせたっていいし。まあ、そういう使い方をしたいのであれば、たいていは安いワンセグドングルを買ってきて基板を半分に割ってRTL2832U側を捨てれば済む話か。RTL側は捨てずともクロックを外付けしたら2.5Msps8bitのADCとしても使えるしな。
rtl_tcp、今まではIPv4で接続していたけど、なぜか接続できなくなった。IPv6だと接続できる。v4だとローカルでSDR#を走らせても接続できない。どんな現象なんだ。。。
C#のasyncなメソッドの中でMemory<T>で持ってる配列を処理するのってどうやるんだろう? 特にforeachで回すような時。Lengthでforループ回していちいちmem.Span[i];とかで取らなきゃいけないんだろうか。
Google IMEで日本語入力中に頻繁にEnterが2度押しされる謎の現象が発生。MS IMEだと発生しないから、おそらくGoogle IMEが原因だと思う。テキストエディタで日本語入力を行うと、入力中の文字(あるいは変換中であれば変換している文字)が確定し、次の行へ移動する。Webブラウザ等だと、入力中の文字に対してEnterが2度押しされるので、確定した上で直ちに検索が実行される。日本語入力ができないから、かなり不便。OS再起動で治ったので、当面様子見。
0 件のコメント:
コメントを投稿