ドローンの撃墜で白い火の玉が降ってくる画像、ドローンの残燃料(ガソリン)が燃えながら降ってきてる、とのことだけど、液体燃料があんなに持続的・安定的かつ真っ白に燃えるものなのかな? 素人考えだと迎撃ミサイルのサステナなりサイドスラスタなりの残りとかのほうが自然な気がするけど。ミサイルの運動量そのままに放出されているのも、ドローン側に乗っていたものが押し出されたというより、ミサイル側の破片のほうが自然な気がするけど。
SM-2の事故の写真だと、固体モーターが破裂すると比較的大きくて大きさが不均一な破片が放出されるみたいだから、数が多くて大きさが均一ならスラスタとか弾頭とかの可能性がありそう?
前回書いた、頭部の正面にある程度の重量物を装着するためにNVマウントを流用するやつ、はからずも本業の人たちの解決策が示されたわけだが、やっぱり金属加工できるとスマートに作れるのがうらやましい。光学設計も含めて小さく作れば大きなトルクに耐えなくていいから全体的に小さくできるというのもあるだろうし。
金属削れる5軸機使える環境ほしいなー。PocketNCとか、CompactMills+ロータリーテーブルとか。せめて卓上旋盤みたいな大きさでも鉄を削れる機械があればいろいろ部品作れて便利なんだけど。/* 去年だったかPentaMachineの新製品出すって話どうなってるんだ */
ある程度の時間をかけてエネルギーを吸収させる感じのレジンプリンタ。3Dデータを2次元平面に投影して照射し、姿勢(照射光)を変えれば励起が不十分な場所は硬化しないから、立体的(選択的)に一気に造形できる。という原理だと思うんだけど。
重力による影響が結構大きそうだけど、例えば先に床から天井までラティス(サポート構造)を造形したりすれば実データの造形中の移動を低減できそう。あるいは、底面からレーザーで重力に垂直な方向(重力で変形する方向)にピラーを何本か立ててやれば、短時間でサポート構造を作れそう。市販のレジンはある程度短い時間で一気にエネルギーを与えてやらないと硬化しないので、弱い光なら結構長時間晒していても硬化しないから取り扱いが楽だけど、そういうレジンだとこういう使い方ができないので、多少特殊な液体のはず。
https://www.jstage.jst.go.jp/article/ieiej/30/5/30_341/_pdf/-char/en
2010年。日本の電気設備の歴史とか。順に受配電、配線、照明、情報通信、監視制御、防災、感電保護、接地。
レッドドットをハイマウントするときに使うやつ
A4用紙に印刷するモックアップがPDFで配布されているのが面白い。実物大の模型を作れるのでどれくらいの大きさか買う前に確認してね、と。
高さ2.26"はレールトップからドットまでの距離かな。ボアからレールトップまでが1.215”とすると、ボアとドットの距離は3.475"になる。通常のAR-15は2.7"くらいなので0.775"(約20mm)高い。下に隙間があるので、通常の高さ(ボアから2.7"の位置)にもバックアップのアイアンサイトがついているのが面白い。基線短すぎだろって気もするけど、その場合はフロントサイトを外して通常のフロントサイトをつければ良いわけで。
GBRS Group Hydra Mount Kit – GBRS Group Gear
2.91"の製品もある。ボアから4.125"くらい、通常のアイアンサイトから36mmくらい高い。3Dプリンタで同じくらいの高さのアダプタを作ってレッドドットを載せてみたら、普通に使うには必要性を感じないくらい高い。ただ、ヘッドマウントのNV越しに見るとめちゃくちゃ見やすい。うちのNVは安物で視野が狭いので特に見やすい。やはりHydraマウントはNVを常用するようなSFとか民兵向けの製品っぽいな。
AmazonでUSBカメラを多数出品しているELP、かゆいところに手が届くような製品があるので好きなんだけど、時々Vine先取りで商品を全く見ていないような(少なくともその商品に関する話が出てこない、当たり障りのない)★5レビューが付いてたりして、微妙にアレ。
レビュアーのプロフィールを見ると当たり障りのない★5レビューばかり投稿していて、うがった見方をすると、無料で送られてくる商品をフリマ等に横流しして★5レビューだけ投稿している感じっぽい。
フィラメントを入れている箱、シリカゲルを入れていたんだけど、試しに湿度計を入れてみたら、70%前半で表示される。シリカゲルを交換したら40%代前半まで下がって、数日で上昇傾向に転じる。飽和するの早すぎでしょ。。。
シリカゲルのパッケージには「電子レンジで数分数セット加熱すれば復活するよ」と書いてあるけど、電子レンジって空焚きしたらマグネトロンの寿命ガリガリ削るんじゃなかったっけ…… だからといってコップに水入れて横においたらそれはそれでどうなんだって気もするし。シリカゲルに入ってる水分量なんてたかが知れてるだろうし、シリカゲル側をジップロックとかに入れておけばいいのか。
公称値10g/packで2袋が実測28gだったので、元の重量が正しく10gであれば40wt%くらいの吸水量。さすがにちょっと高いので元々少し多めに入ってるのかな? とはいえ、飽和したシリカゲルが500g位あれば中に100g程度の水が入っているはずだから電子レンジで加熱してもそれほど問題はなさそう? 結構な量だけど、10gパック20個入り1袋分弱と考えると、結構現実的な量か。とはいえ、シリカゲルを乾燥させるためなら安いホットプレート買ってくる方が楽そうな気がする。電子管に気を使わなくて済む。特に大量のシリカゲルを頻繁に脱水させるなら。
AnkerのPLA+、スパイラルタップでタップ立てたときに糸状の切り粉が出てくる。XYZのPLAは切り粉が粉状に砕けやすかったけど、AnkerのPLA+は粘り強い感じ。造形物が破断するまで力をかけるような使い方はほとんどしないけど、造形時にフィラメントが折れたりしなくて良さそう。
デフォルトのスライサーだと壁が薄いのか、Φ2.7mmくらいの穴に2.5mmのドリルで軽くさらってM3のタップを立ててるけど、少し深いところに行くと明らかに強度がなくなっている(タップの感触がフニャフニャ)。たぶん壁が膨らんで切り込んでいないかねじ切れてるみたいな感じだと思うんだけど。丸穴はFusionで簡単に使える反面、FDMだと全体に均一な厚さだから、ドリルやタップ加工でどんどん薄くなって強度が足りなくなる。
4.7mmくらいの穴を開けて4.5mmでさらってからインサートを入れるとかなり高強度なネジ穴を作れるけど、インサートも数を使うと結構な値段になるからなぁ。
造形物にタップ立てるならΦ2.8mmで造形して直接M3でタッピング、がちょうど良さそう。
精度要求の強い突起が2個ある部品、突起をベッドに垂直に配置したいが、上面に配置するとサポートに必要なフィラメントが多すぎるので、突起を下側にして造形。造形物本体はかなり狭い面積でベッドに定着して、大部分はサポートで支えている状態。剥がれるかと思ったけど全く問題なし。凹凸ヒートベッドってすごいな。造形中は全然剥がれない。
Avx2系の情報を探していて見かけたんだけど、オーディオ系のソフトで、通常の実装とSIMD実装で音質がだいぶ違う、という話があるらしい。それが本当なら実装ミスってるだけでは?という気もするけど。
開発側からの話だと、入出力に違いはないけど、通常実装とSIMD実装では命令セットが異なるから消費電力等にも影響があって、そのせいでGND等の変動が変わるから、結果として音質に違いが出るんじゃないか、というような話らしい。オーディオマニアの人たち耳良すぎでしょ…… そのうち人間の耳だけでAESのサイドチャネル攻撃とかできるようになるんじゃないだろうか。「DRMは復号処理で消費電力が増えてノイズが増えるからクソ」とか言ってそう(偏見)。
ビタビ復号をSIMDで実装したら3倍くらい早くなった。一番並列数が多いところだと例えばハミング距離(ブランチメトリック)の計算はsbyteの差を32並列で計算して、入力2bit分の距離を16並列で水平加算しているから、もう少し早くなって欲しいところではあるけど。並べ替えでExtractVector128とかを多用しているのでスループットがあまり出ていない感じ。最初からAvx2に最適化したアルゴリズム(データ配置)で考えればもう少し早くなると思うけど、それでも今の倍出るかどうかくらいだろうしなぁ。
可能な限りAvx2系命令をネストした書き方と、最大限varで変数に持ってくる書き方だと、明らかに前者のほうが早い。一旦変数に持ってくるとレジスタで直接やり取りできない分で遅いのかな? 前に別件でAvx2系を使ったときはvarを経由したほうが早いみたいな感じだった気がするので状況にもよるのかもしれないけど。
他にも、「こんなの絶対遅いでしょ」みたいな書き方(中間値を持たず、都度計算し直し)でも早くなったりして、かなり謎い。 あんまり再現性ないけど。
ビタビ復号はブロック単位で処理できて、フルセグ(モード3、12セグ、64QAM、3/4)なら2592block/frame、ワンセグ(モード3、1セグ、QPSK、2/3)なら64block/frameで送られてくるから、適当な単位でマルチスレッド処理させればさらに数倍早くなる。SIMDと合わせてそこそこの速度改善が見込める。とはいえ、まだ実速度の10倍程度の時間がかかっているけど。
ドングル3本で記録したバイナリから5フレーム分のTSP抜き出し
CPU使用率が高くなっているところがビタビ復調の処理。その他の処理がかなり重くて、特にGI相関とキャリア相関がかなり重い(その2つで全体の6割超)。GI相関は処理データ量がかなり多いし、キャリア相関は浮動小数点実装なので平均値の計算が重い。基本的にシーケンシャル処理なので並列化が難しいという点もある。どうせリアルタイム処理なんかできないんだから数秒くらいに区切って並列化させればそれなりに早くなりそうではあるけど。
最適化前はビタビ処理が一番重い処理だったけど、SIMD化と並列化で他の処理が相対的に効いてくる。あと、system.private.corelibが結構重いらしい。コア周りの機能、特に心当たりないけど、何がそんなに重いんだろうか。
0 件のコメント:
コメントを投稿