VR環境を…整えろ、と?!
めっちゃ推進剤吹いてるなー。楽しそう。しかしまぁ、惑星間・恒星間に出ていく時代なら小惑星くらい画像認識で自動ドッキングできるだろうに、とも思うけど、それを言い出したらゲームとして成り立たないか。
ブレイクポイントは一通りのミッションが終わって、ソロプレイだとあんまり楽しくない時期。時々追加ミッション配信されるけども。ブレイクポイントでも、馬で移動したり、釣りしたり、ロッククライミングしたり、ラペリングしたり、もう少し遊べると楽しそうなんだけどなぁ。
***
AHRS、苦戦中。RTOSの変なバグ踏んだっぽい。割り込みで頻繁にメッセージを流すと、無関係のタスクで行っている浮動小数点演算に誤差が出る。FPU周りの問題? それっぽいフラグが設定ファイルにあるけど、誰もそれ参照してないんだよなぁ。謎い。
直接的にはコンテキストスイッチの頻発、間接的にはUART受信で頻繁に割り込みかけてメッセージ流すのが原因っぽいので、UARTをDMAで受信する方向で考え中。とりあえずDMA用の適当な長さの受信バッファと、行バッファを複数用意して、その間を取り持つタスクを作る方向で実装してみた。が、作り終わってから考え直したら、長いDMAバッファ1本だけ用意しておいても良さそうな気がする。バッファオーバーランの解決をどうするか、という問題はあるけど。間にタスク1本おいておけば、ある程度のタイミングでそいつが処理してくれるから、DMAが扱うバッファはさほど長くなくて済む利点がある。行バッファに空きがなければ、そのタスクが責任を持って受信データを破棄してくれる。
参考までに、中間タスク方式の考え方をメモ。DMAのHTとTCで割り込みをかけ、さらにUSART.SR.IDLEでも割り込みをかける。この3個の割り込みでは、DMA.NDTRをキューに送る。NDTRは16bit幅なので、キューは16bitの2-4本程度でいい。このキューは優先度高めのタスクで監視させる(待ち時間無限で待たせておく)。タスクでは、前回読んだ位置からNDTRまでをなめるように拾っていく。途中で\nが出たら行を分割させるとか、必要に応じて\rを置換するとか、いろいろやりつつ。割り込みの優先度はDMA>USARTとしておく。これによって、DMAバッファの後端を経由するときに確実にNDTRが送られてくるので、受信タスクでバッファオーバーランを気にしなくて済む。中間タスクは改行コードの検出くらいまでを行い、以降は別のタスクへ受け渡す。中間タスクの処理内容が軽いのであれば、直接処理しちゃってもいいけど。実際のところ、処理が結構面倒で、行バッファにメモリがある程度大量に必要だったり、利点欠点がいろいろ。どうするのがいいか悩ましい。
リムーバブルメディアのドライバも少しずつ書きつつ、ロジアナで見つつ。やっぱLAP-C Pro欲しいなぁ。LAP-Cだと圧縮使ってもファイルアクセス全体を見れないのでいまいちデバッグがしずらい。
***
youtubeの動画の合間合間に入るCM、なんでこうも狙いすましたように興味ないやつばっかり出してくるのかねぇ。「こんなCM見たくないでしょ? 有料アカウントにすれば見なくて済むよ??」ってこと? そんなインセンティブで有料にはしたくねぇ。。。
最近はUniversal Robotsのチュートリアルとか事例紹介とか漁ってる。海外のCNCガチ勢が使ってるヤツ。結構いろんなところで使われてるのね。有名どころだと、日産とか、雪見だいふくとか。
映像コンテンツだと、KUKAがよく使われてるイメージ。Mayaのアドインで逆運動やってカメラや光源動かしたりしてるらしい。KUKAはデカイやつが使えるのでカメラワークの自由度は高いだろうなぁ。URは協働ロボットという性質上、ある程度の大きさまでしかないから、大きく振り回す用途には使いづらそう。KUKAは大きさのバリエーションが豊富なので、大型のアームの先端に小型のアームを数個つけて、みたいな使い方もあるらしい。もっとも、Mayaの画面だけしか出てないので、実際にそういう使い方してるのか、提案だけなのかは不明。
***
ここ最近、ネット回線がかなり細い。ここ数ヶ月同じような傾向だけど、さらに細くなってきた。まぁ、田舎でブロードバンド接続使いたいとか言ってるのが悪いんだろうけど。
なんか、10年くらいのスケールで見ると、年を追うごとに回線品質悪くなってる気がするんだよなぁ。あと5年位したら移動体通信よりISDNのほうがマシかもしれんね。と思ったけど、5年後だとISDNも廃止されてるんか。。。それまでに光通るのかなぁ。Starlinkのほうが有望そう。
0 件のコメント:
コメントを投稿