二足歩行ロボットのレポート
https://gyazo.com/4cfcb53acf7a95e215d7d20d7cc9a2d4
このマシンに入っているシステムについて解説する。
スタビはパッケージ化してこのbsgに詰め込んである。スタブロとほぼ同じ大きさ。多分このロボット以降も使いまわす。
なおここでは論理ブロックを以下のようにプログラミング言語っぽく表すことにする。 入力をA、B、出力をCとする、トグルオフのロジックゲートAND→C=And(A, B, toggle=false)
入力をA、出力をBとする、待ち時間w、出力時間eでトグルオンのループ無しタイマー→B=Timer(A, wait=w, emulate=e, toggle=true, loop=false)
他にもあるが、フィーリングでよしなに理解してほしい。
https://gyazo.com/a9a7fd63d3f447f228280d27fb101bc9
歩行時に強制的にオンになる。飛行時に起動すると推進をやめる。
基本構造
これをピッチ・ロール・ヨーにそれぞれ配置している。
オーバーフロー水砲
これやべー。感動した。ダイチさんありがとう。
簡単に説明すると、水砲のパワーを-10e+30くらいにして起動すると、なぜか推進せずに強力な空気抵抗を発生させる。これを利用することで、スイッチで抵抗を変更可能な空力ブロックのように扱うことができる。適当に実験した結果、パワーの指数部を8~9くらい増減させても効果は変わらないようだ(公式wikiによれば閾値は10e+21)。それ以外のオーダーでは水砲が吹っ飛んでマシンがどっかにいく。
ちなみに水砲だけじゃなくてキノコでも可能。可燃性のみ異なる。バキュームでも応用できるらしいけど試してない。
オーバーフロー水砲はロボットの角度が目標値に近いときに限り作動するようにした。これでダンパーができたことになる。
問題点
水砲の抵抗が強すぎる場面が多い。
水砲をもってしてもやはりグワングワンすることがある。完全に無くしたければスタビmod使いなさいという感じ。
歩行システム
使っているタイマーはwiki構造図鑑を基本として、膝関節用のタイマーを追加している。タイマーはわかりやすいようにロボットの初期位置後ろに基地を設けてそこに置いている。こうしないと頭がおかしくなる。 基本はステヒン2対とサス1対になると思っていて、追加するなら足首関節1つかなと思う。実際の人間の足にも関節部分とかに伸縮して衝撃を緩和する部分があるらしいので、サスも必須な気がする。
問題点
歩行と走行みたいな複数の運動を実現することがほぼ不可能。可変速のステヒンとかありませんかね。
でも股関節と膝関節のエミュレートタイミングを変えることはできる。これは覚えておきたい。
周期の変更が面倒。おおもとのタイマーのエミュレート周期を変えたらスケールごと変えられるようになると整備が楽。
強制的にオン(オフ)にするスイッチ
Aボタンを押したら、Bボタンを元の値にかかわらずオン(オフ)にするスイッチ。いずれも2ブロックと中間変数Cが必要。
強制オンの場合
C=Not(B, toggle=false)
B=And(A, C, toggle=true)
CはBが押されていないなら常にエミュレートするので、Bがオフの場合Aを押したらBがオンになる。Bがオンの場合はCがオフなのでAを押してもAndが起動しない。
歩行ボタンをオンにしたら自動でスタビもかかるようにする時に使用。
強制オフの場合
C=And(A, B, toggle=true)
B=Timer(C, wait=0, emulate=any, toggle=false, loop=false)
CはAとBがオンなら起動し、それを受けてBをオフにするタイマーが働く。一見B=And(A, B, toggle=true)だけでよくないかと思えるが、フレームをまたがないのはよくないっぽい。泣く泣くタイマーを挟んだ。
スタビを押したら推進をやめるようにする時に使用。
問題点
Bを押したらAが決まった値になるようにしたい場合、同じ回路を2つ組んでもうまくいかない。なので、AとBを排他的なトグルにしたい場合はもうちょっと頭を使う必要がある(まだうまいのが思いつけてない)。
落下時のみ反応する高度計
着地寸前にスタビを起動したかったので導入。同じやり方で上昇時のみ反応も可。最終出力Aに加えて中間変数Bが必要。
B=Alt(20)
A=Alt(B, 20, reverse=true)
ようするに、高度が20以上かつ、次のフレームで高度が20以下になれば反応する。論理ブロックのエミュレートが入力の次のフレームに持ち越されることを利用した。
問題点
指定した高さ以上・以下しか判断できないので、いつでも起動できるわけではない。ベクトルの速度系を誰かが作ってたけど、空力ブロックを使って判断してたような気がするので、全体の空力バランスを考えると渋い。
飛行
https://gyazo.com/4fadd863844365bbff413cf1ef3ee156
飛行部の意地。将来的には可変機飛ばしたいんじゃ。
飛行用ナイブス使用時のみ機体下部のオーバーフロー水砲が起動して疑似的な空力ブロックになる。これを用いて安定をとる。頭にはウイングパネルが仕込んであり、そのままだと頭のほうに空力中心が行くようになる。これを使って足から着陸するようにする。
姿勢制御は反トルクであり、飛行用に歩行時とは違うキーアサインが設定されている。本当はここを高度計か何かを使って同じキーで出力が変わるようにしたい(手を移動させるのが面倒)。
問題点
空力バランスの取り方がわからん。ABSはこんなの対応してないぞ。対応できるかすらわからないぞ。
小ジャンプ
脳天のタケコプターみたいなやつはマニュアル操作でいつでも起動できるので、歩行時の障害物よけとか、落下時の速度緩和に使えるかもしれない。そもそもこの辺も自動でやれという話である。
これからの展望
自動化とか着地がまだまだアヤシイところがあるので改善したい。
飛行までは行けたので可変機作れそう。
ガウォークとロボット時で別の歩行モーションを作ろうかと思ってたけど、だいぶ頑張らないと難しいな。
ロジックゲートとか水砲をトグルモードにするかどうかは統一した方がいいような気がしてきた。ロジックゲートを片方だけトグルモードオンにできればいいのだが、そんなにうまい話はないのですこぶる面倒。ロジックゲートがトグルモードでは無くても、入力との間にトグルタイマーを挟めば同じ挙動になるので、マシン全体でトグルモードを使うかどうか統一することは一応可能。具体的には、スタビ起動中であることを示すエミュレートでトグルじゃないやつが欲しくなった(スタビ起動中に〇〇するみたいなのがよくあったから)。
ロボットを作っていると、回路系で使うキーが増えてくるので、これも何とかしたい。アサインでキーボードで使わないやつを適当に当てていけばいいのだが、bsg外部編集は骨が折れまくるのでやりたくない。ゲーム中で全部のアサインを割り振れるようにしたいので、そのうちmod開発に戻ることになりそうだ。
それと、2つの回路に対して別のセンサを使う無駄がどうにも気になってきた。というのも、配線が無いので単純に頭の中でどれが何をしているかわからなくなる。ので、実際のロボットでも使われている「出版購読モデル」というのを紹介だけしておいて、これからBesiege内でのこのモデルの有用性を試してみることにする。
出版購読モデル
基本的なプログラミングでセンサの値を読んでモータの出力を出そうとすると、上述したように出力ごとに別の入力用センサが必要になる。Besiege的には入出力系ごとにキーの管理が面倒になるがよろしくない。出版購読モデルは読んで字のごとく、ある情報空間上にセンサがセンサ値を広く「出版」(購読相手のことは知らない)し、アクチュエータが目的に沿った値を「購読」してそれに沿った行動をすることで、センサとアクチュエータを接続せずに制御が行えるというプログラミングモデルのことである。出版購読モデルの良いところは、アクチュエータを追加しても動かせることにある。これは要素をどんどん追加していく本機の開発にはぴったりではないだろうか。
蜘蛛が意図したかはわからないが、実はBesiegeでは既に出版購読モデルを採用していて、それはブロックのエミュレートと入力の関係である。両者は直接的な関係にはなく、あくまで決められたキーを介したやり取りをしているに過ぎない。なんだ、もう追加されてるんじゃないか、と突っ込まれそうなところだが、私がやりたいのは出版購読モデルの徹底だ。
すなわち、角度系や高度計などのセンサはキーで作動させるのをやめて、いつでも測定値に沿って一定のキーをエミュレートしているものとする。また、ステヒンなどはなるべくセンサから直接値をとることがないようにする。そして、両者をロジックゲートやタイマー等で接続する。この時に問題になるのはロジックゲートやタイマーの配線だけである(本当に?)
こうなるといたずらにキーが増えていくのだが、Unityでは300キー程度アサインを振れるのでいいかなーと思っている(詳しくは雑多な情報置き場参照)。はじめに全てのセンサのエミュレートキーの配置を厳密に決めておいて、その値をロジックゲートで読んで、最終的に出力をステヒンなどに反映させる。 このモデルを利用するとセンサ配置が簡単になって、例えば自動戻り角度計スタビで条件によって出力の強さを変えたい場合、1組のセンサー系だけで対応できる。なんならスタビ以外の用途にも使えるようになる。また、高度計も特定の高さのもの1つで複数の条件に合わせることができるようになる。
いやこれびみょいな…ぶっちゃけ労力的には変わらないような気がする。どちらかというとマシンじゃなくてACMとかのmodに出版購読モデルを採用してもらって、他のmodで海の高さを取得できるようになる方が便利そうだ(唐突なSUKEPINさんへの無茶ぶり)