Dynamixel Workbenchを触ってみた #02

前回、Dynamixel Workbenchにたくさんのパッケージとノードがあることが分かり、戸惑ったものの…なんとなくそれぞれの位置が見えてみました。

残るは、 dynamixel_controllerとOperatorsなのですが、e-Manualのチュートリアルを眺めていると、これらはDynamixelを”まさにROS”という使い方で制御するために、なんとなく重要なポジションにあるようです。

dynamixel_workbench_controllerを立ち上げてみる

さっそく dynamixel_workbench_controller から試していきます。

まず、dynamixel_workbench_controllerには、ロボットの関節として扱うjointモードと、足回りの車輪などに用いるwheelモードの2種類があり、定義ファイル(yaml)の中のOperating_Modeの記述で切り替えるようです。

とりあえず、dynamixel_workbench_controllerに用意されたjointモードのサンプル[joint_2_0.yaml]の定義を使って立ち上げてみて、チュートリアルに従ってrqt_serviceから適当にcallしてみます。

チュートリアルの通り、dynamixel controllerを走らせて、rqt_service_callerからサーボにコマンドを送ってみる。
回った！ pic.twitter.com/UmQBEfnfFO

— みっちー (@Dream_Drive) July 14, 2019

rqt_serviceからDynamixelCommand topicに、サーボに送る”Goal_Position”の値を直接callして、回転させてみました。

どうやら、このノードがゲートウェイ的な位置づけで、このノードと通信することでdynamixelをROSから制御出来るようです。

面白いのは、”サーボID”を使って”Goal_Position”の送信とは別に、このノード内で、関節ごとの名前(joint_name)を定義しており、joint_nameを用いてラジアン角を使った制御にも対応していることです。
これだと、解像度の違うサーボなどに取り替えても、モデルが共通であればそのままプログラムが活かせそうな設計ですね。

[7/17追記] ソースコードを眺めると、この仕組みは、ROSのJointTrajectoryやJointStateというtopicを用いて実現しているようなので、おそらくこのtopicを理解しないと使いこなせないようです。

joint_operatorを立ち上げてみる

joint_operatorは、dynamixel_workbench_controllerに接続するノードのようなので、[joint_2_0.yaml]をセットしたdynamixel_workbench_controllerを立ち上げてから、joint_operatorを起動してみます。

joint_operator 側には、[motion.yaml]に”モーション(一連のロボットの動き)”が記述されており、/executionをservice callすることで、あらかじめ作成した動作を実行出来るようになっている様です。

チュートリアルに従って、joint_operatorを動作テスト。このノードで「モーション」を記述出来るのね！
joint_nameはここで生きてくるのか。
モーションの値がradianなのは、サーボが変わってもモデルが同じなら使えるようにの配慮かな。 pic.twitter.com/kaN0WXt1sY

— みっちー (@Dream_Drive) July 14, 2019

ばっちりモーションが動いてますね！

[motion.yaml]を編集してモーションを増やせば、そのまま二足歩行ロボットのモーション再生ノードに使えそうですね。

しかし、どうやってモーションを記述するか…という部分に関しては、Dynamixelの角度値を取得してティーチングする部分を自作するか、もしくは既存のROBOTISのツールを使って…という感じでしょうか。ちょっと大変そうな気もします。

また、IMUなどのセンサも重ね合わせをしたり、IKを取り入れたりという話になってくると、joint_operatorには手を入れたりする必要がありそうです。
ここは、勉強会で深掘りする必要がありますね。
また、MoveIt!なども使うとなると…、分からないことだらけで、まだまだ課題は多いです。

[7/17追記] ちなみにjoint_operatorのソースを眺めると、モーション実行は、ノード内で時間分割しているのではなく、目標点だけを送っているので、そのままだとIMUなどの重ね合わせは無理そうです。そういう用途では、根本的な設計も見直す必要がありそうですね。

また、ここでいう目標点がJointTrajectoryというtopicであり、それに時間軸を与えてモーションを定義するものがJointTrajectoryPointというtopicらしいです。これもチェックしないといけないですね。

ROSの形式でインプットしてROBOTISサーボが回転する…dynamixel_workbench_controllerは本当にゲートウェイ的なノードですね！

wheel_operatorを立ち上げてみる

wheel_operatorは、[wheel_2_0.yaml]をセットしたdynamixel_workbench_controllerを立ち上げてから、wheel_operatorを起動します。
このノードでは、接続されたdynamixelの2つは、turtlebot3に接続されていると仮定して定義されています、a,w,s,d,xのキーボード入力に対応して、前転／後転を速度制御しながら動作します。

チュートリアルに従って、wheel operatorのデモを実行
移動ロボット製作のなんと簡単なこと…Σ(￣。￣ﾉ)ﾉ
これもすごくテンション上がりますね。 pic.twitter.com/1cohKhVxHa

— みっちー (@Dream_Drive) July 14, 2019

すごいなと思ったのは、内部がgeometry_msgs/Twistの形式で制御されていることです。

Twist での速度は、[m/sec]単位と思うのですが、タイヤ径やギア比で変わるものをどうやって定義しているのかなと思ったら、launchで起動するときにパラメータをちゃんと持っていました。

とりあえず、turtlebotと同じ二輪のモデルならこのまま使えますが、4輪やオムニホイールなど、機体のモデルに合わせてwheel_operatorには手を入れる必要がありそうですね。

というわけで、ROBOTISのWorkbenchを使うとしたら、とりあえずdynamixel_workbench_controllerのノードはそのまま利用させてもらって、その先のノードを自作すれば良さそうですね。
次回は、Workbenchを使った、自作ノードを作る実験をしてみようと思います。

---

(補足) Dynamixelの更新周期について

ちなみに余談ですが、ちょっとDynamixelの更新周期について実験してみました。
FTDIのシリアルのレイテンシタイマの設定を
/sys/bus/usb-serial/devices/ttyUSB0/latency_timer
の値を16(msec)から1(msec)に設定したうえで、通信速度を3Mbpsまで上げてみました。

どうも上限が100Hzに固定されているようです。
1Mbpsでも3Mbpsでも周期が変わりませんでした。