ubutnu マイクの調子が悪い時の対処法
概要
ある日ミーティングで私が喋ってたときにみんな揃いに揃って、うるさいよって言ってきました。 どうやら、凄いノイズが入ってるようで自分でも聞いた所半端なかったですw。windowsでは問題はなかったのでドライバに問題があることがわかりました。ということでドライバの更新方法を備ボリます。
オーデイオドライバの更新方法
以下のコマンドを順番に実行していくだけです。
~$ sudo alsa force-reload ~$ sudo apt-get remove --purge alsa-base pulseaudio ~$ sudo apt-get install alsa-base pulseaudio
おわりに
ドライバの更新で解決してよかった。
dockerを用いたCIでのエラーについて(Process completed with exit code 137.)
概要
dockerを使ってCI回せば、CIで回ってるdockerコンテナは自分のPC環境でも試せるし良いことたくさんですよね。しかし、何も知らずに使うとエラー(Process completed with exit code 137.)に悩まされます。。。ということで、Process completed with exit code 137.について備ぼります。
エラー(Process completed with exit code 137.)について
このエラーは
docker start hogehoge docker ps docker exec 123456 /bash -c "roslaunch hoge hoge; sleep15"
とかをGitHub Actions上で実行すると出てきます。(hogeは例です。execのid番号も例です。)
エラーについて調べると、メモリー不足やら何やら出てきます。 そこで使用メモリーについてコマンドにて確認してみましたが、十分余裕が有り問題ありませでした。
他に調べていると、どうやらdocker runだとPID1で実行したいコマンドを実行できて、docker execだとPID1で実行したいコマンドが実行できないことから、GitHub Actionsでは勝手に異常終了させられる事がわかりました。(多分)
なので異常終了させられないためには、docker run のみを使用してPID1でスクリプト等を実行する。 あるいは、docker execでもPID1でコマンドを実行できるようにする必要が有ります。
おわりに
何か間違っていたり有益な情報をお持ちでしたら教えて頂けると助かります。
解決法
何気にアクセス数が多かったので、追記します。 --initオプションをつけると怒られなくなります。
docker run --init
確率ロボティクス(青本) 自己位置推定
概要
自己位置推定に関するアルゴリズムを把握するために読んだことを備忘る。
自己位置推定
- 格子位置推定
- 細かい格子だと計算量が大きくなる
- 荒い格子だと離散化による情報の損失が大きくなりフィルタに悪影響を与える
- モンテカルロ位置推定(MCL)
- 最も人気のある位置推定アルゴリズム
- ロボット姿勢に対する事後信念を推定をするためにパーティクルフィルタを用いる
格子位置推定
姿勢空間を格子状に離散化し、ヒストグラムフィルタを適用して事後信念を近似する手法。
ヒストグラムフィルタ
ヒストグラムフィルタは、連続状態空間における近似推定のために、離散ベイズフィルタを利用する。 ロボットの存在確率を評価するのに各グリッドに対して行う。二次元平面上のX-Y位置のみを推定したい場合などに利用される。
格子の解像度
トポロジカル・・・ある特徴のみで表現
- 極端に荒いものになる
- グラフ状の粗い離散化表現
メトリック・・・細かい粒度での表現
- 状態空間の解像度がトポロジカルよりずっと高くなる
- 格子表現
計算量の考慮
三次元格子の場合、動作の更新は分布の積の積分により六次元の計算になる。 計測更新は3次元の演算であるが、スキャン全ての尤度を計算する負荷は大きい。
これらのことから、以下のような格子位置推定の計算複雑性を減少させるテクニックがある。
- モデルキャッシング・・・各格子地図に正しい距離計測値をキャッシュしておくことで、計測モデルの計算負荷が高いことに対処するための方法
- センササブサンプリング・・・計測値の一部だけについて計測モデルを評価することによっ て、処理スピードのアップが可能にする方法(ただし、情報量の減少により期待されない結果が求められる可能性がある)
- 遅延動作更新・・・動作更新をロボットの制御や計測の頻度よりも少ない頻度で適用して、格子位置推定の実行速度を上げる方法
- 選択的更新・・・格子セルの確率を更新するとき、閾値を超える事後確率を有する一部の格子セルしか更新を行わないことで計算負荷を小さくする方法(ただし誘拐ロボット問題では低確率の格子セルも直ぐに反応できるように注意を払う必要がある)
格子位置推定まとめ
離散化表現の解像度は、格子マルコフ位置推定において重要なパラメータである。十分な CPUとメモリが与えられれば、細かい離散化は粗い離散化よりも通常望ましい。また、細かい離散化による近似は、ロボットの信念が真の姿勢から大幅に異なってしまう致命的誤りが起こる頻度を低く抑える。
モンテカルロ位置推定(MCL)
パーティクルフィルタ
- パーティクル
- ガウス分布に従う確率変数 X から選ばれる標本
- 事後確率分布の標本
- 時刻 t における真の状態に対する仮説
参考資料
USB有線LANでLiDAR(北陽URG)使用する方法
概要
LANケーブル系のLiDARを使うとき、いつも通信させるセッティングを忘れがちなので備忘ることにした。
(後で書き直す)
やり方
LANケーブル直でつなぐ場合は以下のサイトを参考にすればできる。 beike.hatenablog.jp
なぜか、USB変換LANケーブルの場合は、なぜか上手くいかず手こずった。
こういうタイプのやつ
ubuntuで上手くできなかった場合、windowsで一回やって動作確認やセットアップの流れを抑えると ubuntuでもできるようになる。(体験談)
windows編
まず、まともに使える奴かもわからないってことで北陽のwindows用のアプリケーションを使って LiDARのIPの変更とLiDARの動作確認を行う。
今回は以下の2つのようなアプリケーションを使用した。
LiDARのIPの変更用とLiDARの動作確認用である。
LiDARのIPはデフォルトの192.168.0.10から10.42.0.200に変更した。
10.42.XX.XXにした理由は、10.42.XX.XXでラズパイとPCで通信しているからである。
まず通信の準備として、LiDARのIPを変更する。
USB有線LANの場合は、ネットマスクを255.0.0.0にするのが肝。
その次に 下記のブログを参考にPCのIPを変更する。 beike.hatenablog.jp
PCのIPは今回LiDARのIPが10.42.0.200なので、10.42.0.100とかにした。
そうすると、動作確認側のアプリケーションにLiDARのIPを打ち込んでみると。。。
とりあえずデータ見れた！IPのセッティングの要領も掴んだぞ。。
ubuntu編
ubuntuでのセッティングは結構簡単です。
有線LANの設定を開きます。下の写真のような画面を開きます。
今回も、LiDARのIPが10.42.0.200なので、PCのIPを10.42.0.10とかに設定しました。
ここで肝心なのがWindows同様、ネットマスクを255.0.0.0に設定することです。
あとは、使えるかどうかrosのurg_node、rvizおよびarp-scan等で通信でできているか確認すればよいと思います。
rosのコマンド
~$ roscore ~$ rosrun urg_node urg_node _ip_address:="10.42.0.200" ←LiDARのIP ~$ rosrun rviz rviz
ros navigationのRecovery behaviorについて
概要
ros navigationのRecovery behaviorについてメモ。
Recovery behaviorモードになる条件
Recovery behaviorってたまに、コンソール画面で見たりしますよね。
たとえば、以下のようなROS_INFOですね。ロボットがスタックした時のある条件になった際に切り替わるモードですね。
[ WARN] [1622255733.929612884, 158.241000000]: Rotate recovery behavior started.
move_baseのコードを読んでいて、切り替わる条件ってなんだってググったら出てきた。。
精読の手間が省けました。
感謝、感謝。
記事を見ると。。
- max_planning_retries回，ローカルプランニング試行しても経路が得られなかった場合
- oscillation_timeout秒，振動行動が継続した場合
- controller_patience秒，停止状態が継続した場合
上記の3つの条件うち、どれか一つでも満たされた場合CLEARINGモードに移行し、runBehaviorメソッドが呼び出されて、Recovery behaviorモードになります。
