本シリーズ前回の記事 SwitchBot を ROS から利用する – データ取得編 掲載以降,手元にある SwitchBot デバイスの種類が増えてきました.
そこで今回の記事では switchbot_ros でまだ対応していないデバイスのデータを取得・パブリッシュするためにコードを追加する様子を紹介します.追加例としてデバイス「SwitchBot CO2センサー(温湿度計)」のデータを取得して ROS Topic としてパブリッシュできるようにします.
追加したいデバイスが SwitchBot API で対応していないと switchbot_ros 側でも対応はできないので最初に SwitchBot API のドキュメントを調べます.
SwitchBot API v1.1 ドキュメント にデバイスのリスト取得とステータス取得の項目に「Meter Pro CO2」の記述があり,これが今回追加してみたデバイス「SwitchBot CO2センサー(温湿度計)」に対応したものとなっていました.
制御コマンドの一覧には CO2 センサーらしき記述が(少なくとも本記事執筆時には)ありませんので「SwitchBot CO2センサー(温湿度計)」には取得系コマンドのみが対応していて,制御系コマンドは無いようです.
SwitchBot API ドキュメントにある「SwitchBot CO2センサー(温湿度計)」のステータス取得で返されるデータの表を下に抜粋しましたので確認してみます.
Key | Value Type | Description |
---|---|---|
deviceId | String | device ID |
deviceType | String | device type. MeterPro(CO2) |
hubDeviceId | String | device’s parent Hub ID |
battery | Integer | the current battery level, 0-100 |
version | String | the current firmware version, e.g. V4.2 |
temperature | Float | temperature in celsius |
humidity | Integer | humidity percentage |
CO2 | Integer | CO2 ppm value, 0-9999 |
二酸化炭素濃度が単位 [ppm](百万分率)で範囲 0〜9999 の整数型データとして返されることが分かります.他は SwitchBot の温湿度計と同じように各測定値が得られるようです.
switchbot_ros に機能追加したいデバイス「SwitchBot CO2センサー(温湿度計)」について SwitchBot API が対応していることと API により取得できる測定値が分かりましたので実装してゆきます.もう少し具体化すると「SwitchBot CO2センサー(温湿度計)」から API 経由で得られた
の4つの値を ROS Topic としてパブリッシュします.
SwitchBot API によるデータの取得と ROS Topic のパブリッシュプロセスは switchbot_ros にある既存のルーチンをそのまま利用できますので今回新たに実装する部分は大まかには次の2つです.
先に結論としてコードの追加部分を下に記載してしまいます.ファイルとしては3点,追加箇所としては5点です.
今回追加する「SwitchBot CO2センサー(温湿度計)」に対応したメッセージ型 MeterProCO2.msg を定義します.
パブリッシュする4つのデータ「温度」「湿度」「バッテリーレベル」「CO2濃度」のうち3つ 温度,湿度,バッテリーレベル は Meter.msg と同じなので Meter.msg を複製してファイル名を MeterProCO2.msg に変更して CO2濃度 のデータ型を追加する方法で作成しました.
switchbot_ros / msg / MeterProCO2.msg
Header header # timestamp float64 temperature # temperature in celsius float64 humidity # humidity percentage float64 battery # the current battery level, 0-100 int64 co2ppm # CO2 ppm value, 0-9999
新しいメッセージ型を定義した場合はパッケージの CMakeLists.txt 内の add_message_files()
に追記する必要があります.
switchbot_ros / CMakeLists.txt
add_message_files( FILES Device.msg DeviceArray.msg Meter.msg MeterProCO2.msg PlugMini.msg Hub2.msg Bot.msg StripLight.msg )
新しいメッセージ型 MeterProCO2.msg の準備ができましたので取得データの代入などの機能をパブリッシャーの Python のプログラムファイル switchbot_ros / scripts / switchbot_status_publisher.py に追加記述します.
追加した MeterProCO2.msg を switchbot_status_publisher.py 内で利用するためにメッセージクラス MeterProCO2
を import
しておきます.
switchbot_ros / scripts / switchbot_status_publisher.py
#!/usr/bin/env python import os.path from requests import ConnectionError import rospy from switchbot_ros.switchbot import SwitchBotAPIClient from switchbot_ros.switchbot import DeviceError, SwitchBotAPIError from switchbot_ros.msg import Meter, PlugMini, Hub2, Bot, StripLight, MeterProCO2
初期化関数定義 def __init__(self):
内のパブリッシャーのメッセージクラス設定を行う部分にデバイスタイプ MeterPro(CO2)
の場合の条件分岐を追加して MeterProCO2
をメッセージクラスとして設定します.
switchbot_ros / scripts / switchbot_status_publisher.py
# Publisher Message Class for each device type if self.device_type == 'Remote': rospy.logerr('Device Type: "' + self.device_type + '" has no status in specifications.') return else: if self.device_type == 'Meter': self.msg_class = Meter elif self.device_type == 'MeterPlus': self.msg_class = Meter elif self.device_type == 'WoIOSensor': self.msg_class = Meter elif self.device_type == 'Hub 2': self.msg_class = Hub2 elif self.device_type == 'Plug Mini (JP)': self.msg_class = PlugMini elif self.device_type == 'Plug Mini (US)': self.msg_class = PlugMini elif self.device_type == 'Bot': self.msg_class = Bot elif self.device_type == 'Strip Light': self.msg_class = StripLight elif self.device_type == 'MeterPro(CO2)': self.msg_class = MeterProCO2 else: rospy.logerr('No publisher process for "' + self.device_type + '" in switchbot_status_publisher.py') return
繰り返し関数定義 def spin(self):
内のパブリッシュするメッセージクラスごとの場合分けに MeterProCO2
を追加して SwitchBot API により取得した各データを MeterProCO2
メッセージの各要素に代入します.
switchbot_ros / scripts / switchbot_status_publisher.py
if status: time = rospy.get_rostime() if self.msg_class == Meter: msg = Meter() msg.header.stamp = time msg.temperature = status['temperature'] msg.humidity = status['humidity'] msg.battery = status['battery'] elif self.msg_class == Hub2: msg = Hub2() msg.header.stamp = time msg.temperature = status['temperature'] msg.humidity = status['humidity'] msg.light_level = status['lightLevel'] elif self.msg_class == PlugMini: msg = PlugMini() msg.header.stamp = time msg.voltage = status['voltage'] msg.weight = status['weight'] msg.current = status['electricCurrent'] msg.minutes_day = status['electricityOfDay'] elif self.msg_class == Bot: msg = Bot() msg.header.stamp = time msg.battery = status['battery'] if status['power'] == 'on': msg.power = True else: msg.power = False msg.device_mode = status['deviceMode'] elif self.msg_class == StripLight: msg = StripLight() msg.header.stamp = time if status['power'] == 'on': msg.power = True else: msg.power = False msg.brightness = status['brightness'] rgb_string = status['color'] r, g, b = map(int, rgb_string.split(':')) msg.color_r = r msg.color_g = g msg.color_b = b elif self.msg_class == MeterProCO2: msg = MeterProCO2() msg.header.stamp = time msg.temperature = status['temperature'] msg.humidity = status['humidity'] msg.battery = status['battery'] msg.co2ppm = status['CO2'] else: return
今回の「SwitchBot CO2センサー(温湿度計)」のデータ取得とその ROS Topic へのパブリッシュに関するファイルの追加・コード変更は以上です.
今回の変更で新しいメッセージ型を定義して導入していますのでパッケージのビルドを行い,環境設定を改めて行います.
switchbot_ros を含む jsk_3rdparty のビルド
$ source /opt/ros/noetic/setup.bash $ cd ~/switchbot_ws $ catkin build $ source ~/switchbot_ws/devel/setup.bash
まず利用可能な SwitchBot デバイス名リストを取得・確認してから,得られた新規追加したデバイス名を指定して SwitchBot デバイスのステータスデータの取得と ROS Topic へのパブリッシュを行い,実際にパブリッシュされているかを ROS Topic を表示して確認します.
実行方法は今回機能追加するより前の方法と同じで,launch 時にオプション指定するデバイス名を変えるだけです.
ターミナル 1 : switchbot_ros の実行
SwitchBot API 経由で今回追加した「SwitchBot CO2センサー(温湿度計)」の「デバイス名」と「デバイスタイプ」が取得できることを確認します.ユーザの SwitchBot アカウントで登録されているデバイスの「デバイス名」と「デバイスタイプ」は switchbot.launch を実行すると表示されます.
(下記 launch オプションの YOUR_TOKEN
と YOUR_SECRET
をそれぞれユーザアカウントのトークンとシークレットに置き換えて実行)
switchbot.launch 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ roslaunch switchbot_ros switchbot.launch token:=YOUR_TOKEN secret:=YOUR_SECRET
switchbot.launch 実行出力例
... logging to /home/robotuser/.ros/log/999f113c-b07d-11ef-9b82-a11b8fd4bdd2/roslaunch-robotuser-PC-7718.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:43087/ SUMMARY ======== PARAMETERS * /rosdistro: noetic * /rosversion: 1.17.0 * /switchbot_ros/secret: (シークレットの上位数桁が表示)... * /switchbot_ros/token: (トークンの上位数桁が表示)... NODES / switchbot_ros (switchbot_ros/switchbot_ros_server.py) auto-starting new master process[master]: started with pid [7726] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 999f113c-b07d-11ef-9b82-a11b8fd4bdd2 process[rosout-1]: started with pid [7736] started core service [/rosout] process[switchbot_ros-2]: started with pid [7743] [INFO] [1733123900.102425]: Switchbot API Client initialized. [INFO] [1733123900.104175]: Using SwitchBot API v1.1 [INFO] [1733123900.106131]: Switchbot Device List: 9 Item(s) deviceName: bot74a, deviceID: (固有のID番号が表示), deviceType: Bot deviceName: cam-entrance01, deviceID: (固有のID番号が表示), deviceType: None deviceName: co2sensor-ba1, deviceID: (固有のID番号が表示), deviceType: MeterPro(CO2) deviceName: hub2a, deviceID: (固有のID番号が表示), deviceType: Hub 2 deviceName: plugmini7a1, deviceID: (固有のID番号が表示), deviceType: Plug Mini (JP) deviceName: remote-button10a, deviceID: (固有のID番号が表示), deviceType: Remote deviceName: tapelight7a1, deviceID: (固有のID番号が表示), deviceType: Strip Light deviceName: thermo-hygrometer-f7a, deviceID: (固有のID番号が表示), deviceType: Meter deviceName: trackcard01, deviceID: (固有のID番号が表示), deviceType: None [INFO] [1733123900.107799]: Switchbot Remote List: 2 Item(s) deviceName: air-conditioner, deviceID: (固有のID番号が表示), remoteType: Air Conditioner deviceName: pendant-light, deviceID: (固有のID番号が表示), remoteType: DIY Light [INFO] [1733123900.109488]: Switchbot Scene List: 2 Item(s) sceneName: turnoff-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) [INFO] [1733123900.139015]: Ready.
追加した「SwitchBot CO2センサー(温湿度計)」のデバイス名 co2sensor-ba1
がコンソール出力されたので一旦 Ctrl-C にて switchbot.launch を終了します.
「SwitchBot CO2センサー(温湿度計)」のステータスデータを取得してパブリッシュされている ROS Topic を表示して確認してみます.前述の switchbot.launch の実行出力例からデバイス名が co2sensor-ba1
となっています.
ステータスデータを取得する場合は switchbot.launch 実行時に次の2つのオプションを追加します.
pub_status:=true
ステータスを取得・パブリッシュを実行するオプション true/falsepub_device_name:=
デバイス名の指定(今回の例 co2sensor-ba1
)ターミナル 1 : switchbot_ros の実行
switchbot.launch 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ roslaunch switchbot_ros switchbot.launch token:=YOUR_TOKEN secret:=YOUR_SECRET pub_status:=true pub_device_name:=co2sensor-ba1 pub_status_rate:=0.016666
YOUR_TOKEN
と YOUR_SECRET
は各々の SwitchBot アカウントのトークンとシークレットに置き換えて実行してください.pub_status:=true
でステータスを取得・パブリッシュを実行します.pub_device_name:=co2sensor-ba1
の co2sensor-ba1
は各ユーザ利用のデバイス名に変更してください.pub_status_rate:=0.016666
でステータスを取得・パブリッシュする周波数 [Hz] を設定します.(本例では 0.016666[Hz] = 約60秒に1回)switchbot.launch 実行出力例
... logging to /home/robotuser/.ros/log/e454822a-b07d-11ef-9b82-a11b8fd4bdd2/roslaunch-robotuser-PC-7804.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:36557/ SUMMARY ======== PARAMETERS * /rosdistro: noetic * /rosversion: 1.17.0 * /switchbot_ros/secret: (シークレットの上位数桁が表示)... * /switchbot_ros/token: (トークンの上位数桁が表示)... * /switchbot_status_publisher/device_name: co2sensor-ba1 * /switchbot_status_publisher/rate: 0.016666 * /switchbot_status_publisher/secret: (シークレットの上位数桁が表示)... * /switchbot_status_publisher/token: (トークンの上位数桁が表示)... NODES / switchbot_ros (switchbot_ros/switchbot_ros_server.py) switchbot_status_publisher (switchbot_ros/switchbot_status_publisher.py) auto-starting new master process[master]: started with pid [7812] ROS_MASTER_URI=http://localhost:11311 setting /run_id to e454822a-b07d-11ef-9b82-a11b8fd4bdd2 process[rosout-1]: started with pid [7822] started core service [/rosout] process[switchbot_ros-2]: started with pid [7829] process[switchbot_status_publisher-3]: started with pid [7830] [INFO] [1733124025.952044]: Switchbot API Client initialized. [INFO] [1733124025.953872]: Using SwitchBot API v1.1 [INFO] [1733124025.955817]: Switchbot Device List: 9 Item(s) deviceName: bot74a, deviceID: (固有のID番号が表示), deviceType: Bot deviceName: cam-entrance01, deviceID: (固有のID番号が表示), deviceType: None deviceName: co2sensor-ba1, deviceID: (固有のID番号が表示), deviceType: MeterPro(CO2) deviceName: hub2a, deviceID: (固有のID番号が表示), deviceType: Hub 2 deviceName: plugmini7a1, deviceID: (固有のID番号が表示), deviceType: Plug Mini (JP) deviceName: remote-button10a, deviceID: (固有のID番号が表示), deviceType: Remote deviceName: tapelight7a1, deviceID: (固有のID番号が表示), deviceType: Strip Light deviceName: thermo-hygrometer-f7a, deviceID: (固有のID番号が表示), deviceType: Meter deviceName: trackcard01, deviceID: (固有のID番号が表示), deviceType: None [INFO] [1733124025.957387]: Switchbot Remote List: 2 Item(s) deviceName: air-conditioner, deviceID: (固有のID番号が表示), remoteType: Air Conditioner deviceName: pendant-light, deviceID: (固有のID番号が表示), remoteType: DIY Light [INFO] [1733124025.959085]: Switchbot Scene List: 2 Item(s) sceneName: turnoff-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) [INFO] [1733124025.981926]: Ready. [INFO] [1733124026.191206]: Switchbot API Client initialized. [INFO] [1733124026.192948]: Using SwitchBot API v1.1 [INFO] [1733124026.195299]: Rate: 0.016666 [INFO] [1733124026.197702]: deviceName: co2sensor-ba1 / deviceType: MeterPro(CO2) [INFO] [1733124026.200537]: Ready: SwitchBot Status Publisher for co2sensor-ba1
ターミナル 2 : ROS Topic の確認
rostopic list の実行入力
$ source ~/switchbot_ws/devel/setup.bash $ rostopic list
rostopic list の実行出力例
/rosout /rosout_agg /switchbot_ros/devices /switchbot_ros/switch/cancel /switchbot_ros/switch/feedback /switchbot_ros/switch/goal /switchbot_ros/switch/result /switchbot_ros/switch/status /switchbot_status_publisher/co2sensor_ba1
rostopic echo 実行入力
$ rostopic echo /switchbot_status_publisher/co2sensor_ba1
rostopic echo の実行出力例
header: seq: 1 stamp: secs: 1733124088 nsecs: 5677223 frame_id: '' temperature: 25.4 humidity: 35.0 battery: 100.0 co2ppm: 562 --- header: seq: 2 stamp: secs: 1733124147 nsecs: 910016298 frame_id: '' temperature: 25.4 humidity: 35.0 battery: 100.0 co2ppm: 562 ---
「SwitchBot CO2センサー(温湿度計)」のステータスデータとして CO2濃度 などが取得されて ROS Topic にパブリッシュされている様子が見て取れるかと思います.
今回の記事はここまでです.
本シリーズ前回の記事では 900 シリーズのルンバと Ubuntu PC を USB ケーブルで 接続して ROS からルンバを有線操縦する方法を紹介しました.
今回の記事ではルンバが独立して動きやすいようにバッテリー駆動のラズベリーパイ(ラズパイ・Raspberry Pi)をルンバと USB 接続し,併せて USB カメラもそのラズパイに接続することで,ルンバ 900 シリーズを WiFi を介した ROS 遠隔操作ロボットのようにしてみる様子を紹介します.
前回の記事においてルンバを Ubuntu PC から ROS を使って USB 有線操縦することを目的としたハードウェア・ソフトウェア構成は以下のようになっていました.
今回はこれらのハードウェアに加えて下記のラズパイとその周辺機器のセットをルンバに接続したシステムも使用します.
OS などの環境については本記事執筆直近の動作検証では Ubuntu 24.04 と ROS Jazzy (ROS2) の組み合わせで行っていますが,過去に行った検証では Ubuntu 22.04 と ROS Humble の組み合わせでも動作確認しています.
使用コードについては前回の記事と同様に今回のシステム構成において使いやすいように Create Robot のソフトウェア GitHub リポジトリ https://github.com/AutonomyLab/create_robot からフォーク https://github.com/y-yosuke/create_robot/tree/humble-add-setmode して利用しています.
今回追加した Raspberry Pi 4B に Ubuntu 24.04 + ROS Jazzy と必要なソフトウェアをインストール・ビルドします.
Ubuntu 24.04 ディスクイメージを microSD カードに書き込みます.
Install Ubuntu on a Raspberry Pi を参照して microSD カードに Ubuntu 24.04.1 以降ののインストーライメージを書き込みます.
Raspberry Pi への ROS Jazzy と必要なパッケージのインストール・ビルドについては基本的に前回の記事のインストール手順 ルンバ 900 シリーズを ROS で遠隔操作ロボットに – USB 有線操縦編 : インストール・ビルド と同じですのでそちらを参照して進めてください.
1ヶ所 libcreate/include/create/packet.h
を編集するときに gnome-text-editor
がコマンドラインから起動できないことがありました.
$ gnome-text-editor ~/roomba_ws/src/libcreate/include/create/packet.h
その場合は本記事最後にあるトラブルシューティングの項目を参考に nano
や gedit
その他お好みの gnome-text-editor
以外のテキストエディタを使用してください.
Ubuntu 24.04.1 インストール時点では ssh サーバが入っていないのでインストールして「設定(Settings)」で ssh 接続を有効化してください.
$ sudo apt update $ sudo apt install openssh-server
今回使用するパッケージで依存関係記述から漏れていたパッケージ v4l2_camera
をインストールします.
$ sudo apt install ros-jazzy-v4l2-camera
Raspberry Pi にルンバ,USB カメラ,バッテリーを接続します.Ubuntu PC 側にはゲームコントローラなどを接続します.
次の画像はルンバ側のハードウェアを接続した様子です.
次の画像は Ubuntu PC 側のハードウェアを接続した様子です.この画像内の PC ディスプレイには後述する「ソフトウェアの実行」を行ったときのルンバに設置した USB カメラからの映像が映し出されています.
Ubuntu PC のターミナルからルンバと USB 接続されている Raspberry Pi に ssh 接続します.
下記の例では robotuser-rp4b
というホスト名をつけた Raspberry Pi に robotuser
というユーザ名で接続しています.ホスト名やユーザ名,接続時のパスワードは適宜読者の環境に沿ったもので実行してください.
ssh 接続ができたらルンバとのシリアル通信ポートの権限を chmod
で変更します.
Ubuntu PC: Raspberry Pi に ssh 接続するターミナル
$ ssh robotuser@robotuser-rp4b.local robotuser@robotuser-rp4b:~$ sudo chmod 777 /dev/ttyACM0
このターミナルの ssh は接続したままににします.
Raspberry Pi に ssh 接続したターミナルで次のコマンドを実行して create_1_camera.launch
を起動します.
Ubuntu PC: Raspberry Pi に ssh 接続したターミナル
robotuser@robotuser-rp4b:~$ source ~/roomba_ws/install/setup.bash robotuser@robotuser-rp4b:~$ ros2 launch create_bringup create_1_camera.launch
次にルンバを遠隔操作する側の Ubuntu PC 上の2つのターミナルで次のコマンドを実行してルンバに接続した Raspberry Pi のカメラ映像を表示しながらゲームパッドノードからルンバへの速度指令のトピックを発行します.
Ubuntu PC: ターミナル 1(カメラ映像の表示)
$ source ~/roomba_ws/install/setup.bash $ ros2 run rqt_image_view rqt_image_view
画像トピック名に image_raw
を選択するとウィンドウ内に映像が表示されます.
Ubuntu PC: ターミナル 2(速度指令発行ノードの実行)
ルンバへの速度指令を出すためのゲームパッドもしくは 3D マウスのノードを実行するためにターミナルをもう1つ開いて実行します.
< Xbox360 互換ゲームパッド使用の場合 >
joy_teleop.launch
を起動します.
$ source ~/roomba_ws/install/setup.bash $ ros2 launch create_bringup joy_teleop.launch
< 3Dマウス( 3DConnexion SpaceMouse Wireless )使用の場合 >
spacenav_telelop.launch
を起動します.
$ source ~/roomba_ws/install/setup.bash $ ros2 launch create_bringup spacenav_teleop.launch
次の動画ではルンバとラズパイのシステムが外部接続ケーブルが無く独立しており,Ubuntu PC 側のゲームパッドで操縦されルンバ上の USB カメラの映像も取得できている様子が見て取れると思います.
この動画内では撮影の都合で Ubuntu PC で操作を行っている操縦者の有視界内にルンバもありますが,Ubuntu PC とルンバは WiFi ネットワークを介してつながっているので例えば別の部屋などの視界外からもルンバ上の USB カメラからの映像や他の ROS トピックを参照しながら遠隔操縦できそうであることは想像できるのではないでしょうか.
ルンバ操作を終了するときは各ターミナルで実行しているプロセスを Ctrl+C で終了してください.
ルンバから派生した趣味や教育用をターゲットとした Create Robot は掃除機能を廃してしまっていますが今回使用しているのはお掃除ロボットのルンバそのものです.
ルンバが普通に掃除している間もその状態を Roomba Open Interface (ROI) を通じて取得できるのが ROI のパッシブモードです.
create_1_camera.launch
でも launch オプションで control_mode:=passive
を指定すると,ROI のパッシブモードでルンバを操作せずに通信してその状態を ROS トピックとして発行します.
Ubuntu PC: Raspberry Pi に ssh 接続したターミナル
robotuser@robotuser-rp4b:~$ source ~/roomba_ws/install/setup.bash robotuser@robotuser-rp4b:~$ ros2 launch create_bringup create_1_camera.launch control_mode:=passive
パッシブモードを実行中にルンバの CLEAN ボタンを押すか iRobot アプリから開始することで掃除が始まります.
create_1_camera.launch
パッシブモード時に発行される ROS トピックのリスト出力は次の様になっています.
Ubuntu PC: ターミナル 1
$ source ~/roomba_ws/install/setup.bash $ ros2 topic list /battery/capacity /battery/charge /battery/charge_ratio /battery/charging_state /battery/current /battery/temperature /battery/voltage /bumper /camera_info /check_led /clean_button /cliff /cmd_vel /day_button /debris_led /define_song /diagnostics /dock /dock_button /dock_led /hour_button /image_raw /ir_omni /joint_states /main_brush_motor /minute_button /mode /odom /parameter_events /play_song /power_led /robot_description /rosout /set_ascii /side_brush_motor /spot_button /spot_led /tf /tf_static /undock /vacuum_motor /wheeldrop
Ubuntu 24.04.1 でターミナルが起動しなかったのですが,その時は /etc/default/locale の内容を LANG="en_US.UTF-8"
に修正したら起動するようになりました.
/etc/default/locale
LANG="en_US.UTF-8"
gnome-text-editor がコマンドラインから起動できない場合は他のテキストエディタ nano や gedit などを使用してください.
$ nano ~/roomba_ws/src/libcreate/include/create/packet.h
$ sudo apt update $ sudo apt install gedit $ gedit ~/roomba_ws/src/libcreate/include/create/packet.h
今回の記事はここまでです.
iRobot 社のお掃除ロボット「ルンバ(Roomba)」は 700 シリーズ以前のモデルでは mini-DIN のインターフェースポートがありシリアル通信にて外部からルンバを操作するためのインタフェース Roomba Open Interface (ROI) が提供されていました.またルンバ 900 シリーズではシリアルポートが micro USB となり USB ケーブル経由で外部コンピュータと簡単につなげて ROI が利用できるようになっていました.
そしてルンバから派生した掃除機能を廃して趣味や教育用をターゲットとした Create ロボットもルンバと共通の ROI で操作可能です.なおかつ Create 向けとして ROI の ROS インタフェースが GitHub で提供されているので この ROI-ROS インタフェースを用いることでシリアルポートの付いているルンバを ROS から操作することが可能となっています.
本シリーズの記事では PC やラズパイから USB ケーブルで 900 シリーズのルンバに接続して ROS からルンバを操縦する方法を紹介します.
記事のシリーズ構成は次のようになる予定です.
ルンバを Ubuntu PC から ROS を使って USB 有線操縦することを目的とした今回の記事におけるハードウェア・ソフトウェア構成は以下のようになっています.
OS などの環境については本記事執筆直近の動作検証では Ubuntu 24.04 と ROS Jazzy (ROS2) の組み合わせで行っていますが,過去に行った検証では Ubuntu 22.04 + ROS Humble の組み合わせでも動作確認しています.
使用コードについては今回のシステム構成において使いやすいように Create Robot のソフトウェア GitHub リポジトリ https://github.com/AutonomyLab/create_robot から
フォーク https://github.com/y-yosuke/create_robot/tree/humble-add-setmode して利用しています.
Ubuntu 24.04 に ROS Jazzy のインストールする手順は下記リンク先の ROS 2 Documentation: Jazzy – Installation Ubuntu (deb packages) を参照して実行してください.
依存パッケージをインストールできるように rosdep をセットアップしておきます.
$ sudo apt install python3-rosdep $ sudo rosdep init $ rosdep update
ビルドのために colcon 関連パッケージをインストールします.
$ sudo apt install python3-colcon-common-extensions
ROS ワークスペースを作成して GitHub からコードをクローンし,インストール・ビルドを実行します.
$ source /opt/ros/jazzy/setup.bash $ mkdir -p ~/roomba_ws/src $ cd ~/roomba_ws/src/ $ git clone -b humble-add-setmode https://github.com/y-yosuke/create_robot.git $ git clone https://github.com/AutonomyLab/libcreate.git $ gnome-text-editor ~/roomba_ws/src/libcreate/include/create/packet.h $ cd ~/roomba_ws/ $ rosdep install -r -y --from-paths src --ignore-src $ colcon build $ source ~/roomba_ws/install/setup.bash
上記手順の libcreate を git clone したあとに下記コマンドを追加しています.
$ gnome-text-editor ~/roomba_ws/src/libcreate/include/create/packet.h
本コマンドを実行するとテキストエディタが起動して修正が必要なファイル packet.h が開かれます.
下のように packet.h の 35行目 に #include <string>
を挿入してファイルを保存してからテキストエディタを閉じます.
libcreate / include / create / packet.h
#define CREATE_PACKET_H #include <mutex> #include <string> namespace create { class Packet {
これはビルドするのに必要な下記リンク先の修正のプルリクエストがまだ反映されていないための修正作業です.今後このプルリクエストが libcreate の master ブランチにマージされた後は不要となります.
Ubuntu PC のソフトウェアのセットアップが終了したら Ubuntu PC にルンバとゲームパッドもしくは 3D マウスを接続します.
ルンバ 900 シリーズの micro USB ソケットは上面右側にある細長いカバーを外すとあります.このカバーは工具なしで手で外すことができます.
ルンバが接続されているシリアルポートの権限を変更してユーザからもアクセス可能な状態にします.
$ sudo chmod a+rw /dev/ttyACM0 $ sudo usermod -a -G dialout $USER
ターミナル 1
$ source ~/roomba_ws/install/setup.bash $ ros2 launch create_bringup create_1.launch
launch 後,正常に Ubuntu PC からルンバに通信が確立されているとルンバ側で短いビープ音が鳴ります.
ターミナル 2
ルンバへの速度指令を出すためのゲームパッドもしくは 3D マウスのノードを実行するためにターミナルをもう1つ開いて実行します.
< Xbox360 互換ゲームパッド使用の場合 >
$ source ~/roomba_ws/install/setup.bash $ ros2 launch create_bringup joy_teleop.launch
< 3Dマウス( 3DConnexion SpaceMouse Wireless )使用の場合 >
$ source ~/roomba_ws/install/setup.bash $ ros2 launch create_bringup spacenav_teleop.launch
spacenav_teleop.launch においてはデッドマン・スイッチの設定はないので SpaceMouse の前後・ヨー軸のねじり入力がそのままルンバへの速度指令として出力されます.
次の動画はゲームパットを用いてルンバを動かしたときのものです.デッドマン・スイッチの L1 を押しながらアナログスティック R を操作することでルンバへの速度指令が出力されている様子が見て取れるかと思います.
ルンバ操作を終了するときは各ターミナルで実行しているプロセスを Ctrl+C で終了してください.
今回の記事はここまでです.
本シリーズ次回の記事ではルンバが動きやすいようにバッテリー駆動のラズベリーパイをルンバと USB 接続し,カメラも併せてラズパイに接続することで,ルンバ 900 シリーズを WiFi を介した ROS 遠隔操作ロボットのようにしてみる様子を紹介する予定です.
本シリーズ前回の記事 SwitchBot を ROS から利用する – コマンド操作編2 では SwitchBot を ROS から利用する switchbot_ros のサンプルのソースコードで扱われていた SwitchBot デバイス以外のものを ROS から操作するために SwitchBot API のコマンドセットを調べて control_switchbot.py に実装する過程について紹介しました.
今回は SwitchBot デバイスのステータスデータの取得と ROS トピックへのパブリッシュを行ってみます.
前回の記事 SwitchBot を ROS から利用する – コマンド操作編2 を公開した後に GitHub 上の switchbot_ros が更新されて SwitchBot デバイスのステータスデータの取得とパブリッシュを行うソフトウェアソースコードが追加されました.
更新された switchbot_ros を実際に動作させる Ubuntu PC 内の switchbot_ros に適用してビルドします.
既に前回の記事の時点の switchbot_ros を含む jsk_3rdparty をクローンして利用している場合は次の手順で更新された GitHub 上の jsk_3rdparty を git でプル(ダウンロード更新)してビルドします.
switchbot_ros を含む jsk_3rdparty の更新とビルド
$ source ~/switchbot_ws/devel/setup.bash $ cd ~/switchbot_ws/src/jsk_3rdparty $ git checkout master $ git pull origin master $ catkin build $ source ~/switchbot_ws/devel/setup.bash
ターミナル 1 : switchbot_ros の実行
前回記事と同じですがユーザの SwitchBot アカウントで登録されているデバイスの「デバイス名」と「デバイスタイプ」は switchbot.launch を実行すると表示されます.
(下記 launch オプションの YOUR_TOKEN
と YOUR_SECRET
をそれぞれユーザアカウントのトークンとシークレットに置き換えて実行)
switchbot.launch 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ roslaunch switchbot_ros switchbot.launch token:=YOUR_TOKEN secret:=YOUR_SECRET
switchbot.launch 実行出力例
... logging to /home/robotuser/.ros/log/87b6e5c8-c1a2-11ee-bce7-1d89a9d14e1f/roslaunch-robotuser-PC-62866.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:40731/ SUMMARY ======== PARAMETERS * /rosdistro: noetic * /rosversion: 1.16.0 * /switchbot_ros/secret: (シークレットの上位数桁が表示)... * /switchbot_ros/token: (トークンの上位数桁が表示)... NODES / switchbot_ros (switchbot_ros/switchbot_ros_server.py) auto-starting new master process[master]: started with pid [62874] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 87b6e5c8-c1a2-11ee-bce7-1d89a9d14e1f process[rosout-1]: started with pid [62884] started core service [/rosout] process[switchbot_ros-2]: started with pid [62891] [INFO] [1706861436.195243]: Switchbot API Client initialized. [INFO] [1706861436.199678]: Using SwitchBot API v1.1 [INFO] [1706861436.204957]: Switchbot Device List: 6 Item(s) deviceName: bot74a, deviceID: (固有のID番号が表示), deviceType: Bot deviceName: hub2a, deviceID: (固有のID番号が表示), deviceType: Hub 2 deviceName: plugmini7a1, deviceID: (固有のID番号が表示), deviceType: Plug Mini (JP) deviceName: remote-button10a, deviceID: (固有のID番号が表示), deviceType: Remote deviceName: tapelight7a1, deviceID: (固有のID番号が表示), deviceType: Strip Light deviceName: thermo-hygrometer-f7a, deviceID: (固有のID番号が表示), deviceType: Meter [INFO] [1706861436.208853]: Switchbot Remote List: 2 Item(s) deviceName: air-conditioner, deviceID: (固有のID番号が表示), remoteType: Air Conditioner deviceName: pendant-light, deviceID: (固有のID番号が表示), remoteType: DIY Light [INFO] [1706861436.214168]: Switchbot Scene List: 3 Item(s) sceneName: turnoff-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) [INFO] [1706861436.254126]: Ready.
利用可能なデバイス名がコンソール出力されたので一旦 Ctrl-C にて switchbot.launch を終了します.
上記の switchbot.launch 実行出力例にある SwitchBot デバイスのうち取得するステータスがない Remote 以外の次のデバイスタイプは switchbot_ros にてステータスデータを取得することができます.
また上記リスト以外のデータ取得 API 提供がされている SwitchBot デバイスについては switchbot_ros のコードに組み込まれていませんが適宜情報をコードに加えれば switchbot_ros からもデータ取得できるようになると思います.
実行例として今回は SwitchBot の温湿度計(デバイスタイプ Meter)のステータスデータを取得してパブリッシュされている ROS トピックを表示してみます.先述の switchbot.launch の実行出力例から読み取ると,該当するデバイス名が thermo-hygrometer-f7a
となっています.
ステータスデータを取得する場合は switchbot.launch 実行時に次の2つのオプションを追加します.
pub_status:=true
ステータスを取得・パブリッシュを実行するオプション true/falsepub_device_name:=thermo-hygrometer-f7a
デバイス名の指定(本例では thermo-hygrometer-f7a)ターミナル 1 : switchbot_ros の実行
switchbot.launch 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ roslaunch switchbot_ros switchbot.launch token:=YOUR_TOKEN secret:=YOUR_SECRET pub_status:=true pub_device_name:=thermo-hygrometer-f7a
YOUR_TOKEN
と YOUR_SECRET
は各々の SwitchBot アカウントのトークンとシークレットに置き換えて実行してください.pub_status:=true
でステータスを取得・パブリッシュを実行します.pub_device_name:=thermo-hygrometer-f7a
の thermo-hygrometer-f7a
は各ユーザ利用のデバイス名に変更してください.switchbot.launch 実行出力例
... logging to /home/robotuser/.ros/log/81bc64b6-faf2-11ee-8dad-e57ee950b51d/roslaunch-robotuser-PC-28197.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:35371/ SUMMARY ======== PARAMETERS * /rosdistro: noetic * /rosversion: 1.16.0 * /switchbot_ros/secret: (シークレットの上位数桁が表示)... * /switchbot_ros/token: (トークンの上位数桁が表示)... * /switchbot_status_publisher/device_name: thermo-hygrometer... * /switchbot_status_publisher/rate: 0.1 * /switchbot_status_publisher/secret: (シークレットの上位数桁が表示)... * /switchbot_status_publisher/token: (トークンの上位数桁が表示)... NODES / switchbot_ros (switchbot_ros/switchbot_ros_server.py) switchbot_status_publisher (switchbot_ros/switchbot_status_publisher.py) auto-starting new master process[master]: started with pid [28205] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 81bc64b6-faf2-11ee-8dad-e57ee950b51d process[rosout-1]: started with pid [28215] started core service [/rosout] process[switchbot_ros-2]: started with pid [28222] process[switchbot_status_publisher-3]: started with pid [28223] [INFO] [1713163000.937913]: Switchbot API Client initialized. [INFO] [1713163000.938005]: Switchbot API Client initialized. [INFO] [1713163000.940084]: Using SwitchBot API v1.1 [INFO] [1713163000.940382]: Using SwitchBot API v1.1 [INFO] [1713163000.942545]: Switchbot Device List: 6 Item(s) deviceName: bot74a, deviceID: (固有のID番号が表示), deviceType: Bot deviceName: hub2a, deviceID: (固有のID番号が表示), deviceType: Hub 2 deviceName: plugmini7a1, deviceID: (固有のID番号が表示), deviceType: Plug Mini (JP) deviceName: remote-button10a, deviceID: (固有のID番号が表示), deviceType: Remote deviceName: tapelight7a1, deviceID: (固有のID番号が表示), deviceType: Strip Light deviceName: thermo-hygrometer-f7a, deviceID: (固有のID番号が表示), deviceType: Meter [INFO] [1713163000.944131]: Switchbot Remote List: 2 Item(s) deviceName: air-conditioner, deviceID: (固有のID番号が表示), remoteType: Air Conditioner deviceName: pendant-light, deviceID: (固有のID番号が表示), remoteType: DIY Light [INFO] [1713163000.944268]: Rate: 0.1 [INFO] [1713163000.945732]: Switchbot Scene List: 2 Item(s) sceneName: turnoff-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) [INFO] [1713163000.947428]: deviceName: thermo-hygrometer-f7a / deviceType: Meter [INFO] [1713163000.951801]: Ready: SwitchBot Status Publisher for thermo-hygrometer-f7a [INFO] [1713163000.966800]: Ready.
ターミナル 2 : ROS トピックの確認
rostopic list の実行入力
$ source ~/switchbot_ws/devel/setup.bash $ rostopic list
rostopic list の実行出力例
/rosout /rosout_agg /switchbot_ros/devices /switchbot_ros/switch/cancel /switchbot_ros/switch/feedback /switchbot_ros/switch/goal /switchbot_ros/switch/result /switchbot_ros/switch/status /switchbot_status_publisher/thermo_hygrometer_f7a
rostopic echo 実行入力
$ rostopic echo /switchbot_status_publisher/thermo_hygrometer_f7a
rostopic echo の実行出力例
header: seq: 1 stamp: secs: 1713163093 nsecs: 412018775 frame_id: '' temperature: 26.9 humidity: 36.0 battery: 100.0 --- header: seq: 2 stamp: secs: 1713163103 nsecs: 447003364 frame_id: '' temperature: 26.9 humidity: 36.0 battery: 100.0 --- header: seq: 3 stamp: secs: 1713163113 nsecs: 380291700 frame_id: '' temperature: 26.9 humidity: 36.0 battery: 100.0
SwitchBot 温湿度計 Meter のステータスデータとして温度・湿度などが取得されて ROS トピックにパブリッシュされている様子がわかるかと思います.
ステータスの取得とパブリッシュの間隔は switchbot.launch のデフォルト設定で 0.1 [Hz] = 10秒間隔 になっています.これを変更する場合には switchbot.launch のオプションで pub_status_rate:=0.05
のように追加します.温湿度のように急に変化しなさそうなデータの場合はもっと長めの間隔でも良いかもしれません.
今回の記事はここまでです.
本シリーズ前回の記事 SwitchBot を ROS から利用する – コマンド操作編1 では SwitchBot を ROS から利用する switchbot_ros の導入とサンプル Python コードの実行の様子を紹介しました.
今回は前回の記事の続きとしてサンプルのソースコードで扱われていた SwitchBot デバイス以外のものを ROS から操作するために SwitchBot API のコマンドセットを調べて control_switchbot.py に実装する過程について紹介します.
switchbot_ros のサンプル Python コード control_switchbot.py においてボット(スイッチ)をオンにする命令は次のようになっていて「デバイス名」とそれに対する「コマンド」の2つを指定する必要があります.
client.control_device('bot74a', 'turnOn')
client.control_device('デバイス名', 'コマンド')
このうち「コマンド」は SwitchBot API にてデバイスタイプごとに設定されているので「デバイスタイプ」が何かを知る必要があります.
ユーザのアカウントで登録されているデバイスの「デバイス名」と「デバイスタイプ」は switchbot.launch を実行すると表示されます.
(下記 launch オプションの YOUR_TOKEN と YOUR_SECRET をそれぞれユーザアカウントのトークンとシークレットに置き換えて実行)
switchbot.launch 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ roslaunch switchbot_ros switchbot.launch token:=YOUR_TOKEN secret:=YOUR_SECRET
switchbot.launch 実行出力例
... logging to /home/robotuser/.ros/log/87b6e5c8-c1a2-11ee-bce7-1d89a9d14e1f/roslaunch-robotuser-PC-62866.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:40731/ SUMMARY ======== PARAMETERS * /rosdistro: noetic * /rosversion: 1.16.0 * /switchbot_ros/secret: (シークレットの上位数桁が表示)... * /switchbot_ros/token: (トークンの上位数桁が表示)... NODES / switchbot_ros (switchbot_ros/switchbot_ros_server.py) auto-starting new master process[master]: started with pid [62874] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 87b6e5c8-c1a2-11ee-bce7-1d89a9d14e1f process[rosout-1]: started with pid [62884] started core service [/rosout] process[switchbot_ros-2]: started with pid [62891] [INFO] [1706861436.195243]: Switchbot API Client initialized. [INFO] [1706861436.199678]: Using SwitchBot API v1.1 [INFO] [1706861436.204957]: Switchbot Device List: 6 Item(s) deviceName: bot74a, deviceID: (固有のID番号が表示), deviceType: Bot deviceName: hub2a, deviceID: (固有のID番号が表示), deviceType: Hub 2 deviceName: plugmini7a1, deviceID: (固有のID番号が表示), deviceType: Plug Mini (JP) deviceName: remote-button10a, deviceID: (固有のID番号が表示), deviceType: Remote deviceName: tapelight7a1, deviceID: (固有のID番号が表示), deviceType: Strip Light deviceName: thermo-hygrometer-f7a, deviceID: (固有のID番号が表示), deviceType: Meter [INFO] [1706861436.208853]: Switchbot Remote List: 2 Item(s) deviceName: air-conditioner, deviceID: (固有のID番号が表示), remoteType: Air Conditioner deviceName: pendant-light, deviceID: (固有のID番号が表示), remoteType: DIY Light [INFO] [1706861436.214168]: Switchbot Scene List: 3 Item(s) sceneName: turnoff-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) [INFO] [1706861436.254126]: Ready.
switchbot.launch 実行出力から次の1行を例にとると「デバイス名」が plugmini7a1
で「デバイスタイプ」が Plug Mini (JP)
です.
deviceName: plugmini7a1, deviceID: (固有のID番号が表示), deviceType: Plug Mini (JP)
操作したい SwitchBot デバイスタイプが分かればそのコマンドセットを調べます.SwitchBot API のコマンドセットは下記の Web ページで知ることができます.
今回はデバイスタイプ Plug Mini (JP) と Strip Light のデバイスを操作したいのでそれらのコマンドセットについて調べます.
電源プラグの On/Off を行う SwitchBot デバイスである Plug Mini (JP) のコマンドセットの説明は次のリンク先にあります.
上記 Web ページの Plug Mini (JP) コマンドセットの表をそのまま貼り付けたものが次の表です.
deviceType | commandType | Command | command parameter | Description |
---|---|---|---|---|
Plug Mini (JP) | command | turnOn | default | set to ON state |
Plug Mini (JP) | command | turnOff | default | set to OFF state |
Plug Mini (JP) | command | toggle | default | toggle state |
デバイスの機能どおりに電源入 turnOn
,電源切 turnOff
,電源入切の切替 toggle
の3つのコマンドにより構成されています.
テープライト形状の SwitchBot デバイスである Strip Light のコマンドセットの説明は次のリンク先にあります.
上記 Web ページの Strip Light コマンドセットの表をそのまま貼り付けたものが次の表です.
deviceType | commandType | Command | command parameter | Description |
---|---|---|---|---|
Strip Light | command | turnOn | default | set to ON state |
Strip Light | command | turnOff | default | set to OFF state |
Strip Light | command | toggle | default | toggle state |
Strip Light | command | setBrightness | {1-100} |
set brightness |
Strip Light | command | setColor | "{0-255}:{0-255}:{0-255}" |
set RGB color value |
点灯 turnOn
,消灯 turnOff
,明滅切替 toggle
,輝度設定 setBrightness
,色設定 setColor
の5つのコマンドにより構成されていて,そのうち輝度設定では{1-100}
の範囲で輝度設定, "{0-255}:{0-255}:{0-255}"
の値で RGB 色設定を行います.
デバイス名 plugmini7a1
の Plug Mini (JP) を操作します. ROS からコマンドを送って On/Off の切り替え toggle
をしてみます.
サンプルコード control_switchbot.py に client.control_device('plugmini7a1', 'toggle')
を追加します.(下記ソースコードの 16行目)
control_switchbot.py
#!/usr/bin/env python import rospy from switchbot_ros.switchbot_ros_client import SwitchBotROSClient rospy.init_node('controler_node') client = SwitchBotROSClient() devices = client.get_devices() print(devices) # client.control_device('pendant-light', 'turnOn') # client.control_device('bot74a', 'turnOn') client.control_device('plugmini7a1', 'toggle')
ここでは元々サンプルコードにあったペンダントライトとボット(スイッチ)の操作をする行(上記ソースコードの12,14行目)は行頭に #
を入れてコメントアウトして実行されないようにしています.
変更を加えた control_switchbot.py ファイルを保存してから実行します.
ターミナル 1 : switchbot.launch 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ roslaunch switchbot_ros switchbot.launch token:=YOUR_TOKEN secret:=YOUR_SECRET
ターミナル 2 : control_switchbot.py 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ rosrun switchbot_ros control_switchbot.py
デバイス名 tapelight7a1
の Strip Light (テープライト)を操作します. ROS からコマンドを送って次の動作をしてみます.
'255:255:255'
に設定'255:0:0'
に設定'0:255:0'
に設定'0:0:255'
に設定サンプルコード control_switchbot.py に下記ソースコードの18行目以降を追加します.
値を設定する setBrightness
や setColor
といったコマンドでは各数値を control_device()
の引数 parameter
に文字列として渡します.
また control_device()
の中ではコマンドを Action サーバにゴールとして送っているので新しいコマンドが前のコマンドに置き換わらないように1つ1つのコマンド実行を終えるのを待つように引数 wait
に True
を渡しています.
control_switchbot.py
#!/usr/bin/env python import rospy from switchbot_ros.switchbot_ros_client import SwitchBotROSClient rospy.init_node('controler_node') client = SwitchBotROSClient() devices = client.get_devices() print(devices) # client.control_device('pendant-light', 'turnOn') # client.control_device('bot74a', 'turnOn') # client.control_device('plugmini7a1', 'toggle') client.control_device('tapelight7a1', 'turnOff', wait=True) client.control_device('tapelight7a1', 'turnOn', wait=True) client.control_device('tapelight7a1', 'setBrightness', parameter='100', wait=True) client.control_device('tapelight7a1', 'setColor', parameter='255:255:255', wait=True) client.control_device('tapelight7a1', 'setColor', parameter='255:0:0', wait=True) client.control_device('tapelight7a1', 'setColor', parameter='0:255:0', wait=True) client.control_device('tapelight7a1', 'setColor', parameter='0:0:255', wait=True) client.control_device('tapelight7a1', 'setBrightness', parameter='1', wait=True) client.control_device('tapelight7a1', 'turnOff', wait=True)
前述の Plug Mini (JP) のときと同様に変更を加えた control_switchbot.py ファイルを保存してから実行します.
筆者が試した範囲では時々 client.control_device()
が実行されない不具合が見受けられ,それが SwitchBotROSClient インスタンス作成時 client = SwitchBotROSClient()
に Action サーバの起動やサーバへの接続が不十分であることが原因のように思われました.
そこで下記の switchbot_ros_client.py の21行目のように self.action_client.wait_for_server()
を入れて Action サーバが起動して接続されるのを待つようにしたところ,現状では安定して client.control_device()
が実行されているように感じます.
switchbot_ros_client.py
import rospy import actionlib from switchbot_ros.msg import SwitchBotCommandAction from switchbot_ros.msg import SwitchBotCommandGoal from switchbot_ros.msg import DeviceArray class SwitchBotROSClient(object): def __init__(self, actionname='switchbot_ros/switch', topicname='switchbot_ros/devices'): self.actionname = actionname self.topicname = topicname self.action_client = actionlib.SimpleActionClient( actionname, SwitchBotCommandAction ) rospy.loginfo("Waiting for action server to start.") self.action_client.wait_for_server() def get_devices(self, timeout=None): return rospy.wait_for_message( self.topicname, DeviceArray, timeout=timeout ) def control_device(self, device_name, command, parameter='', command_type='', wait=False ): goal = SwitchBotCommandGoal() goal.device_name = device_name goal.command = command goal.parameter = parameter goal.command_type = command_type self.action_client.send_goal(goal) if wait: self.action_client.wait_for_result() return self.action_client.get_result()
今回の記事はここまでです.
本記事では SwitchBot を ROS から利用できるソフトウェア switchbot_ros の使い方を紹介します.
SwitchBot は多くの IoT スマートホームデバイス製品を提供しているブランドで,既にそれらを日常生活の中で活用されている方も多いのではないでしょうか.
SwitchBot からはソフトウェアインターフェースとして WebAPI が提供されていて,2024年2月はじめの時点での最新バージョンが v1.1 となっています.
SwitchBot の WebAPI を ROS から利用する switchbot_ros は下記のリポジトリで公開されていて SwitchBot API v1.1 にも対応しています.
SwitchBot の機器を ROS のシステムに組み込むことによりロボットとスマートホームデバイスを組み合わせた動作システムを簡単に実現することが可能となります.
今回は switchbot_ros を含む jsk_3rdparty リポジトリを Ubuntu PC 内の ROS ワークスペースにクローン・ビルドして ROS から SwitchBot デバイスを動作させます.
本記事では次の環境で switchbot_ros を利用しています.
Ubuntu や ROS のインストールが済んだ状態で次のように switchbot_ros を利用するためのワークスペースを作成して jsk_3rdparty リポジトリをクローンしてビルドします.
$ source /opt/ros/noetic/setup.bash $ mkdir -p ~/switchbot_ws/src $ cd ~/switchbot_ws $ catkin build $ source ~/switchbot_ws/devel/setup.bash $ cd ~/switchbot_ws/src $ git clone https://github.com/jsk-ros-pkg/jsk_3rdparty.git $ cd ~/switchbot_ws $ rosdep install -y -r --from-paths src --ignore-src $ catkin build $ source ~/switchbot_ws/devel/setup.bash
switchbot_ros は SwitchBot API を利用していますので SwitchBot API にアクセスするための SwitchBot アカウント各々に固有の「トークン(token)」と「シークレット(secret)」の2つの情報が必要になります.
SwitchBot Magazine – 【API】新バージョンAPI v1.1を公開しました にトークンとシークレットの取得方法などが書かれています.この記事から引用・まとめをするとトークンとシークレットの取得方法はつぎのようになっています.
switchbot_ros の中にあるコマンドを発する Python コード例 control_switchbot.py を実行して ROS から SwitchBot デバイスのハブの赤外線リモコン発信で部屋の電気を点灯した後にボット(スイッチ)を動作させます.
control_switchbot.py の中身はシンプルで 12行目 で照明を点灯させて,14行目 でボット(スイッチ)を On しています.
control_switchbot.py
#!/usr/bin/env python import rospy from switchbot_ros.switchbot_ros_client import SwitchBotROSClient rospy.init_node('controler_node') client = SwitchBotROSClient() devices = client.get_devices() print(devices) client.control_device('pendant-light', 'turnOff') client.control_device('bot74a', 'turnOn')
client.control_device('pendant-light', 'turnOff')
で 'turnOff'
となっているのに点灯?と思いますが筆者のペンダントライトのリモコンを SwitchBot アプリで登録する際に電源の On/Off ボタンが1つのものとして扱われていて 'turnOn'
も 'turnOff'
も On/Off の切り替えボタンとして機能してしまっているためです. ( = もう一度 client.control_device('pendant-light', 'turnOff')
を実行すると消灯になる) このように特に登録するリモコンについてはどのようにマッピングができたかに挙動が依存するのでコマンドに対する各々のデバイスの挙動を確認してから利用する必要があります.
操作コマンドの SwitchBot デバイスに至るまでの大まかな流れは次のようになっています.
それでは実際に実行してみます. SwitchBot ROS アクションサーバを起動してから別ターミナルで control_switchbot.py を実行します.
ターミナル 1 : SwitchBot ROS アクションサーバの起動
下記コマンドの SwichBot ROS アクションサーバの起動実行時に launch オプションの token:=YOUR_TOKEN
の YOUR_TOKEN
を SwitchBot アプリで取得したトークンに置き換えて, secret:=YOUR_SECRET
の YOUR_SECRET
を取得したシークレットに置き換えて書いて実行します.
switchbot.launch 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ roslaunch switchbot_ros switchbot.launch token:=YOUR_TOKEN secret:=YOUR_SECRET
switchbot.launch 実行出力例
... logging to /home/robotuser/.ros/log/87b6e5c8-c1a2-11ee-bce7-1d89a9d14e1f/roslaunch-robotuser-PC-62866.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:40731/ SUMMARY ======== PARAMETERS * /rosdistro: noetic * /rosversion: 1.16.0 * /switchbot_ros/secret: (シークレットの上位数桁が表示)... * /switchbot_ros/token: (トークンの上位数桁が表示)... NODES / switchbot_ros (switchbot_ros/switchbot_ros_server.py) auto-starting new master process[master]: started with pid [62874] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 87b6e5c8-c1a2-11ee-bce7-1d89a9d14e1f process[rosout-1]: started with pid [62884] started core service [/rosout] process[switchbot_ros-2]: started with pid [62891] [INFO] [1706861436.195243]: Switchbot API Client initialized. [INFO] [1706861436.199678]: Using SwitchBot API v1.1 [INFO] [1706861436.204957]: Switchbot Device List: 6 Item(s) deviceName: bot74a, deviceID: (固有のID番号が表示), deviceType: Bot deviceName: hub2a, deviceID: (固有のID番号が表示), deviceType: Hub 2 deviceName: plugmini7a1, deviceID: (固有のID番号が表示), deviceType: Plug Mini (JP) deviceName: remote-button10a, deviceID: (固有のID番号が表示), deviceType: Remote deviceName: tapelight7a1, deviceID: (固有のID番号が表示), deviceType: Strip Light deviceName: thermo-hygrometer-f7a, deviceID: (固有のID番号が表示), deviceType: Meter [INFO] [1706861436.208853]: Switchbot Remote List: 2 Item(s) deviceName: air-conditioner, deviceID: (固有のID番号が表示), remoteType: Air Conditioner deviceName: pendant-light, deviceID: (固有のID番号が表示), remoteType: DIY Light [INFO] [1706861436.214168]: Switchbot Scene List: 3 Item(s) sceneName: turnoff-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) sceneName: turnon-all-lights, sceneID: (固有のID番号が表示) [INFO] [1706861436.254126]: Ready.
ターミナル 2 : control_switchbot.py の実行
ターミナル1 の switchbot.launch を起動したままの状態で別のターミナルで control_switchbot.py を実行します.
control_switchbot.py 実行入力
$ source ~/switchbot_ws/devel/setup.bash $ rosrun switchbot_ros control_switchbot.py
control_switchbot.py 実行出力例
devices: - name: "bot74a" type: "Bot" - name: "hub2a" type: "None" - name: "plugmini7a1" type: "Plug Mini (JP)" - name: "remote-button10a" type: "Remote" - name: "tapelight7a1" type: "Strip Light" - name: "thermo-hygrometer-f7a" type: "Meter" - name: "air-conditioner" type: "Air Conditioner" - name: "pendant-light" type: "DIY Light"
control_switchbot.py 実行出力時の SwitchBot デバイス動作の様子
SwitchBot を ROS から操作する感じが伝わりましたでしょうか?
今回の記事はここまでです.
本シリーズ次回の記事では今回実行した Python コード例で扱われていたもの以外の SwitchBot デバイスを ROS から操作するために SwitchBot API を調べて control_switchbot.py にコマンドを追加する様子についてお伝えする予定です.
本シリーズ前回の記事 1. ROS Service プログラムの文脈をふまえたチャット対応 では OpenAI の Chat Completion API を利用して過去のチャット履歴もふまえたチャットを行える ROS Service プログラムを作成した様子をお伝えしました.
今回の記事では Chat Completion API を利用した「文脈をふまえたチャット」をする ROS ソフトウェアを実装してみた2つ目の方法「2. ROS Topic を介した ChatGPT チャットプログラム」を作成した様子を紹介します.
前回,比較的短文のチャットを扱う Chat Completion API へのアクセスであれば ROS Service よりも ROS Topic を介したメッセージのやり取りの方が ROS ノード内でのチャット会話に限られず,より ROS に親和的でよりシンプルな構成になるのでは?という反省がありました.
今回の ROS Topic を用いたチャットプログラムの作成方針は次のようにしました.
/request
を購読してユーザの発言を得る/response
としてパブリッシュする/request
にパブリッシュする/response
を購読して得るROS Service プログラムの場合はチャット履歴をふまえたとしてもチャット機能提供側とユーザとの1者対1者でのやり取りでしたが,ROS Topic にすることでチャット機能提供側と複数のユーザの1者対他者でのやり取りも可能になる利点もあります.
ROS Topic を介した文脈をふまえたチャットプログラムで追加したファイルは次の2つです.
サービスの定義など考慮しなくて良いので非常にシンプルです.
以下,それぞれのファイル内のコードを記載して少し説明をします.
scripts / openai_chat_rostopic.py
#!/usr/bin/env python3 import rospy import openai from std_msgs.msg import String class Chatter: """ Chat with ChatGPT on ROS topics """ def __init__(self): # Get ROS parameters prompt = rospy.get_param('~prompt') self.model = rospy.get_param('~model') openai.api_key = rospy.get_param('~key') rospy.loginfo("For \'system\': %s" % (prompt)) # Set initial message with a prompt self.messages = [] self.messages.append({"role": "system", "content": str(prompt)}) self.sub = rospy.Subscriber('request', String, self.callback) self.pub = rospy.Publisher('response', String, queue_size=10) rospy.spin() def callback(self, data): rospy.loginfo("request: %s", data.data) # Add user's input to the history self.messages.append({"role": "user", "content": str(data.data)}) response = openai.ChatCompletion.create( model=self.model, messages=self.messages ) content = response["choices"][0]["message"]["content"] role = response["choices"][0]["message"]["role"] token = response["usage"]["total_tokens"] # Add GPT's response to the history self.messages.append({"role": str(role), "content": str(content)}) rospy.loginfo("%s(token:%d): %s" % (role, token, content)) self.pub.publish(content) if __name__ == "__main__": rospy.init_node('chat_rostopic', anonymous=True) chatter = Chatter()
/request
を購読(Subscribe)してトピックを受け取ったら callback()
メソッドを呼び出すcallback()
メソッド内で新たなリクエストをチャット履歴に追加/response
としてパブリッシュlaunch / openai_chat.launch
launch オプション service
を用いて前回の記事で紹介した ROS Service によるチャットプログラムと今回の ROS Topic を介したチャットプログラムのどちらを実行するかを切り替えるようにしています.
<launch> <arg name="key" default="$(env OPENAI_API_KEY)" /> <arg name="model" default="gpt-3.5-turbo" /> <arg name="service" default="false" /> <arg name="prompt" default="You are a helpful assistant." /> <node if="$(arg service)" pkg="openai_ros" type="openai_chat_server.py" name="openai_chat_service" output="screen"> <param name="key" value="$(arg key)" /> <param name="model" value="$(arg model)" /> </node> <node unless="$(arg service)" pkg="openai_ros" type="openai_chat_rostopic.py" name="openai_chat_topic" output="screen"> <param name="key" value="$(arg key)" /> <param name="model" value="$(arg model)" /> <param name="prompt" value="$(arg prompt)" /> </node> </launch>
文脈をふまえた ROS Topic を介したチャットプログラムを実行した例を以下に記載します.
ターミナル 1 : チャットノードの起動
Chat Completion API にアクセスして ROS Topic でやり取りする ROS Node を openai_chat.launch で起動しています.
robotuser@robotuser-PC:~$ source ~/openai_ws/devel/setup.bash robotuser@robotuser-PC:~$ export OPENAI_API_KEY="sk-..." robotuser@robotuser-PC:~$ roslaunch openai_ros openai_chat.launch ... logging to /home/robotuser/.ros/log/609f8d12-52cd-11ee-9968-6b3ff6703622/roslaunch-robotuser-PC-5035.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:40257/ SUMMARY ======== PARAMETERS * /openai_chat/key: sk-3JDluBbxsNuIhi... * /openai_chat/model: gpt-3.5-turbo * /openai_chat/prompt: You are a helpful... * /rosdistro: noetic * /rosversion: 1.16.0 NODES / openai_chat (openai_ros/openai_chat_rostopic.py) auto-starting new master process[master]: started with pid [5043] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 609f8d12-52cd-11ee-9968-6b3ff6703622 process[rosout-1]: started with pid [5053] started core service [/rosout] process[openai_chat-2]: started with pid [5060] [INFO] [1694675254.662674]: For 'system': You are a helpful assistant. [INFO] [1694675266.017788]: request: Hello [INFO] [1694675267.401076]: assistant(token:27): Hello! How can I assist you today? [INFO] [1694675292.897892]: request: インターネットはどこにありますか? [INFO] [1694675300.168180]: assistant(token:183): インターネットは物理的な場所にあるのではなく,世界中のコンピューターがネットワークで結ばれている仮想的な空間です.インターネットは,データを送信し受け取るためのプロトコルとパケット交換技術を使用しています.つまり,インターネットは世界中のコンピューターネットワークの集合体です. [INFO] [1694675347.975610]: request: 世界中とは地球のことですか? [INFO] [1694675354.647098]: assistant(token:324): はい,正確に言えば,インターネットは地球上のコンピューターネットワークの集合体です.このネットワークには,地球上の様々な場所に設置されたサーバーやルーターなどの機器が含まれます.インターネットのデータ通信は,これらの機器を介して行われます. [INFO] [1694675387.510775]: request: あなたは誰ですか? [INFO] [1694675391.409440]: assistant(token:407): 私はAI(人工知能)ベースのヘルプフルなアシスタントです.質問や問題解決,情報の提供など,お手伝いできることがありましたらお知らせください. [INFO] [1694675436.047036]: request: どのようにヘルプフルですか? [INFO] [1694675447.019485]: assistant(token:645): 私は多くの情報と知識を持つAIですので,様々な質問や問題に対してお答えすることができます.例えば,旅行の予約や天気予報の確認,翻訳や研究のサポート,一般的な知識の提供など,さまざまな分野でお手伝いすることができます.また,自然言語処理の技術を利用して,あなたの質問や要求を理解し,最適な回答やソリューションを提供することも可能です.お困りのことや疑問があれば,いつでもお気軽にお知らせください. [INFO] [1694675485.687087]: request: 東京の明日の天気もわかりますか? [INFO] [1694675507.944942]: assistant(token:1064): もちろんです!東京の天気予報を調べてみましょう. 私はリアルタイムのデータにアクセスできるわけではありませんが,一般的に天気予報を提供する公式のウェブサイトやアプリを利用して,詳細な天気予報を確認することができます.天気予報は頻繁に更新されるため,事前に確認することをおすすめします.以下は一般的な天気予報サービスの利用方法です. - インターネット検索エンジンで「東京の天気予報」と検索すると,現在の天気情報と明日の天気予報を含む結果が表示されます. - スマートフォンやタブレットを使用している場合は,天気予報を提供するアプリをダウンロードしてインストールすることもできます.定番のアプリには「Weather」や「Weather Underground」などがあります. これらの方法を使用して,明日の東京の天気を確認してみてください.天気予報に関する詳細な情報を入手するためには,地元の気象庁や天気予報サービスの公式ウェブサイトを参照することもおすすめです. ^C[openai_chat-2] killing on exit [rosout-1] killing on exit [master] killing on exit shutting down processing monitor... ... shutting down processing monitor complete done robotuser@robotuser-PC:~$
ターミナル 2 : ROS Topic に発言をパブリッシュ
1つ目のターミナルで openai_chat.launch を起動したままの状態で2つ目のターミナルから ROS Topic をパブリッシュします.
robotuser@robotuser-PC:~$ rostopic pub -1 /request std_msgs/String "Hello" publishing and latching message for 3.0 seconds robotuser@robotuser-PC:~$ rostopic pub -1 /request std_msgs/String "インターネットはどこにありますか ?" publishing and latching message for 3.0 seconds robotuser@robotuser-PC:~$ rostopic pub -1 /request std_msgs/String "世界中とは地球のことですか?" publishing and latching message for 3.0 seconds robotuser@robotuser-PC:~$ rostopic pub -1 /request std_msgs/String "あなたは誰ですか?" publishing and latching message for 3.0 seconds robotuser@robotuser-PC:~$ rostopic pub -1 /request std_msgs/String "どのようにヘルプフルですか?" publishing and latching message for 3.0 seconds robotuser@robotuser-PC:~$ rostopic pub -1 /request std_msgs/String "東京の明日の天気もわかりますか?" publishing and latching message for 3.0 seconds robotuser@robotuser-PC:~$
ターミナル 3 : チャットノードからの応答の ROS Topic を確認
3つ目のターミナルで ROS Topic /response
に Chat Completion API からの応答がパブリッシュされているかを確認します.コンソール出力では文字コード化して可読性がないですが Python で print()
や rospy.loginfo()
で出力すると ターミナル 1 のような読める日本語で表示されます.
robotuser@robotuser-PC:~$ rostopic echo /response data: "\u79C1\u306FAI\uFF08\u4EBA\u5DE5\u77E5\u80FD\uFF09\u30D9\u30FC\u30B9\u306E\u30D8\u30EB\ \u30D7\u30D5\u30EB\u306A\u30A2\u30B7\u30B9\u30BF\u30F3\u30C8\u3067\u3059\u3002\u8CEA\ \u554F\u3084\u554F\u984C\u89E3\u6C7A\u3001\u60C5\u5831\u306E\u63D0\u4F9B\u306A\u3069\ \u3001\u304A\u624B\u4F1D\u3044\u3067\u304D\u308B\u3053\u3068\u304C\u3042\u308A\u307E\ \u3057\u305F\u3089\u304A\u77E5\u3089\u305B\u304F\u3060\u3055\u3044\u3002" --- data: "\u79C1\u306F\u591A\u304F\u306E\u60C5\u5831\u3068\u77E5\u8B58\u3092\u6301\u3064AI\u3067\ \u3059\u306E\u3067\u3001\u69D8\u3005\u306A\u8CEA\u554F\u3084\u554F\u984C\u306B\u5BFE\ \u3057\u3066\u304A\u7B54\u3048\u3059\u308B\u3053\u3068\u304C\u3067\u304D\u307E\u3059\ \u3002\u4F8B\u3048\u3070\u3001\u65C5\u884C\u306E\u4E88\u7D04\u3084\u5929\u6C17\u4E88\ \u5831\u306E\u78BA\u8A8D\u3001\u7FFB\u8A33\u3084\u7814\u7A76\u306E\u30B5\u30DD\u30FC\ \u30C8\u3001\u4E00\u822C\u7684\u306A\u77E5\u8B58\u306E\u63D0\u4F9B\u306A\u3069\u3001\ \u3055\u307E\u3056\u307E\u306A\u5206\u91CE\u3067\u304A\u624B\u4F1D\u3044\u3059\u308B\ \u3053\u3068\u304C\u3067\u304D\u307E\u3059\u3002\u307E\u305F\u3001\u81EA\u7136\u8A00\ \u8A9E\u51E6\u7406\u306E\u6280\u8853\u3092\u5229\u7528\u3057\u3066\u3001\u3042\u306A\ \u305F\u306E\u8CEA\u554F\u3084\u8981\u6C42\u3092\u7406\u89E3\u3057\u3001\u6700\u9069\ \u306A\u56DE\u7B54\u3084\u30BD\u30EA\u30E5\u30FC\u30B7\u30E7\u30F3\u3092\u63D0\u4F9B\ \u3059\u308B\u3053\u3068\u3082\u53EF\u80FD\u3067\u3059\u3002\u304A\u56F0\u308A\u306E\ \u3053\u3068\u3084\u7591\u554F\u304C\u3042\u308C\u3070\u3001\u3044\u3064\u3067\u3082\ \u304A\u6C17\u8EFD\u306B\u304A\u77E5\u3089\u305B\u304F\u3060\u3055\u3044\u3002" --- data: "\u3082\u3061\u308D\u3093\u3067\u3059\uFF01\u6771\u4EAC\u306E\u5929\u6C17\u4E88\u5831\ \u3092\u8ABF\u3079\u3066\u307F\u307E\u3057\u3087\u3046\u3002\n\n\u79C1\u306F\u30EA\ \u30A2\u30EB\u30BF\u30A4\u30E0\u306E\u30C7\u30FC\u30BF\u306B\u30A2\u30AF\u30BB\u30B9\ \u3067\u304D\u308B\u308F\u3051\u3067\u306F\u3042\u308A\u307E\u305B\u3093\u304C\u3001\ \u4E00\u822C\u7684\u306B\u5929\u6C17\u4E88\u5831\u3092\u63D0\u4F9B\u3059\u308B\u516C\ \u5F0F\u306E\u30A6\u30A7\u30D6\u30B5\u30A4\u30C8\u3084\u30A2\u30D7\u30EA\u3092\u5229\ \u7528\u3057\u3066\u3001\u8A73\u7D30\u306A\u5929\u6C17\u4E88\u5831\u3092\u78BA\u8A8D\ \u3059\u308B\u3053\u3068\u304C\u3067\u304D\u307E\u3059\u3002\u5929\u6C17\u4E88\u5831\ \u306F\u983B\u7E41\u306B\u66F4\u65B0\u3055\u308C\u308B\u305F\u3081\u3001\u4E8B\u524D\ \u306B\u78BA\u8A8D\u3059\u308B\u3053\u3068\u3092\u304A\u3059\u3059\u3081\u3057\u307E\ \u3059\u3002\u4EE5\u4E0B\u306F\u4E00\u822C\u7684\u306A\u5929\u6C17\u4E88\u5831\u30B5\ \u30FC\u30D3\u30B9\u306E\u5229\u7528\u65B9\u6CD5\u3067\u3059\u3002\n\n- \u30A4\u30F3\ \u30BF\u30FC\u30CD\u30C3\u30C8\u691C\u7D22\u30A8\u30F3\u30B8\u30F3\u3067\u300C\u6771\ \u4EAC\u306E\u5929\u6C17\u4E88\u5831\u300D\u3068\u691C\u7D22\u3059\u308B\u3068\u3001\ \u73FE\u5728\u306E\u5929\u6C17\u60C5\u5831\u3068\u660E\u65E5\u306E\u5929\u6C17\u4E88\ \u5831\u3092\u542B\u3080\u7D50\u679C\u304C\u8868\u793A\u3055\u308C\u307E\u3059\u3002\ \n- \u30B9\u30DE\u30FC\u30C8\u30D5\u30A9\u30F3\u3084\u30BF\u30D6\u30EC\u30C3\u30C8\ \u3092\u4F7F\u7528\u3057\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u5929\u6C17\u4E88\ \u5831\u3092\u63D0\u4F9B\u3059\u308B\u30A2\u30D7\u30EA\u3092\u30C0\u30A6\u30F3\u30ED\ \u30FC\u30C9\u3057\u3066\u30A4\u30F3\u30B9\u30C8\u30FC\u30EB\u3059\u308B\u3053\u3068\ \u3082\u3067\u304D\u307E\u3059\u3002\u5B9A\u756A\u306E\u30A2\u30D7\u30EA\u306B\u306F\ \u300CWeather\u300D\u3084\u300CWeather Underground\u300D\u306A\u3069\u304C\u3042\ \u308A\u307E\u3059\u3002\n\n\u3053\u308C\u3089\u306E\u65B9\u6CD5\u3092\u4F7F\u7528\ \u3057\u3066\u3001\u660E\u65E5\u306E\u6771\u4EAC\u306E\u5929\u6C17\u3092\u78BA\u8A8D\ \u3057\u3066\u307F\u3066\u304F\u3060\u3055\u3044\u3002\u5929\u6C17\u4E88\u5831\u306B\ \u95A2\u3059\u308B\u8A73\u7D30\u306A\u60C5\u5831\u3092\u5165\u624B\u3059\u308B\u305F\ \u3081\u306B\u306F\u3001\u5730\u5143\u306E\u6C17\u8C61\u5E81\u3084\u5929\u6C17\u4E88\ \u5831\u30B5\u30FC\u30D3\u30B9\u306E\u516C\u5F0F\u30A6\u30A7\u30D6\u30B5\u30A4\u30C8\ \u3092\u53C2\u7167\u3059\u308B\u3053\u3068\u3082\u304A\u3059\u3059\u3081\u3067\u3059\ \u3002" ---
ChatGPT に対して問い合わせる側が人間であれば応答から自分で文脈をふまえて次の会話をすると思いますが,クライアントプログラムの場合は文脈をふまえた会話をしたければクライアント側のソフトウェアも ROS Topic を拾って自分で文脈を記録して解釈する必要があります.
Chat Completion API との応答を ROS Topic を介してやり取りしているので,複数の Chat ノード(openai_chat_rostopic.py)を実行してトピックの remap
をして互いのノードの応答を自らのノードの入力にすれば ChatGPT 同士で会話を続けるようにすることも簡単にできます.
そのために openai_chat.launch を次のように変更しました.
<launch> <arg name="key" default="$(env OPENAI_API_KEY)" /> <arg name="model" default="gpt-3.5-turbo" /> <arg name="service" default="false" /> <arg name="opponent" default="false" /> <arg name="prompt" default="You are a helpful assistant." /> <node if="$(arg service)" pkg="openai_ros" type="openai_chat_server.py" name="openai_chat_service" output="screen"> <param name="key" value="$(arg key)" /> <param name="model" value="$(arg model)" /> </node> <group unless="$(arg service)"> <node pkg="openai_ros" type="openai_chat_rostopic.py" name="openai_chat_topic" output="screen"> <param name="key" value="$(arg key)" /> <param name="model" value="$(arg model)" /> <param name="prompt" value="$(arg prompt)" /> </node> <group ns="opponent" if="$(arg opponent)"> <node pkg="openai_ros" type="openai_chat_rostopic.py" name="openai_chat_topic"> <param name="key" value="$(arg key)" /> <param name="model" value="$(arg model)" /> <param name="prompt" value="You are a good talker." /> <remap from="/opponent/request" to="/response" /> <remap from="/opponent/response" to="/request" /> </node> </group> </group> </launch>
opponent
で ChatGPT 同士の会話にするかを指定
output="screen"
はなしprompt
の設定でアシスタント同士だと会話が不自然な感じがしたので(とりあえず)2つ目のプロンプトは “You are a good talker.” としてみたremap
で /request
と /response
を入れ替えターミナル 1 : 2つのチャットノードの起動
openai_chat.launch の起動オプション opponent:=true
で2つのチャットノード実行とトピックの remap
を行います.
起動した状態では応答は何もないですが ターミナル 2 から ROS トピック /request
に最初のリクエストを1つパブリッシュすることで以後 ChatGPT 同士の会話が始まります.
robotuser@robotuser-PC:~$ roslaunch openai_ros openai_chat.launch opponent:=true ... logging to /home/robotuser/.ros/log/9cc9a1be-5dc8-11ee-9968-6b3ff6703622/roslaunch-robotuser-PC-35705.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:42615/ SUMMARY ======== PARAMETERS * /openai_chat_topic/key: sk-3JDluBbxsNuIhi... * /openai_chat_topic/model: gpt-3.5-turbo * /openai_chat_topic/prompt: You are a helpful... * /opponent/openai_chat_topic/key: sk-3JDluBbxsNuIhi... * /opponent/openai_chat_topic/model: gpt-3.5-turbo * /opponent/openai_chat_topic/prompt: You are a good ta... * /rosdistro: noetic * /rosversion: 1.16.0 NODES / openai_chat_topic (openai_ros/openai_chat_rostopic.py) /opponent/ openai_chat_topic (openai_ros/openai_chat_rostopic.py) auto-starting new master process[master]: started with pid [35714] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 9cc9a1be-5dc8-11ee-9968-6b3ff6703622 process[rosout-1]: started with pid [35724] started core service [/rosout] process[openai_chat_topic-2]: started with pid [35731] process[opponent/openai_chat_topic-3]: started with pid [35732] [INFO] [1695882670.941923]: For 'system': You are a helpful assistant. [INFO] [1695882677.451265]: request: サッカーの盛んな国を1つ挙げてください. [INFO] [1695882679.335665]: assistant(token:60): ブラジルはサッカーの盛んな国として知られています. [INFO] [1695882705.653403]: request: そうですね,ブラジルは世界でも有名なサッカーの強豪国として知られています.ブラジルではサッカーは国民的なスポーツであり,多くの人々が熱狂的に応援しています. ブラジル代表チームは過去に5回のワールドカップ優勝を果たし,サッカーの歴史においても最も成功した国の一つです.有名な選手も多く輩出しており,ペレやジーコ,ロナウド,ロナウジーニョ,ネイマールなど,数々の伝説的なプレーヤーがブラジルから生まれています. ブラジルではサッカーの試合が行われると,町中が一体となって応援に熱が入ります.カラフルな応援旗やドラム,歌声,そして華麗なサンバの踊りなど,独特のエネルギーと情熱が試合会場を包みます. また,ブラジルには多くの有名なサッカークラブがあります.サンパウロのサンパウロFC,リオデジャネイロのフラメンゴ,サントス,リオグランデ・ド・スールのグレミオ,コリンチャンスなど,これらのクラブは強豪として名高いだけでなく,ファンの熱心さも有名です. ブラジルのサッカーは単なるスポーツ以上のものであり,国民の誇りやアイデンティティの一部となっています.サッカーを通じて,ブラジルの文化や人々の情熱を感じることができるでしょう. [INFO] [1695882713.741564]: assistant(token:754): その通りです.ブラジルのサッカーは国民の誇りであり,文化の一部として重要な役割を果たしています.多くの人々がサッカーに情熱を注ぎ,試合を熱狂的に応援する様子は見る価値があります.ブラジルのサッカーは世界中で愛され,その魅力は他の国にも広まっています.それだけに,ブラジルはサッカーの盛んな国として有名です. [INFO] [1695882744.670979]: request: そうですね,ブラジルのサッカーの魅力は世界中に広まっており,多くの人々がその情熱に共感しています.ブラジル代表チームやクラブチームの試合は,テレビやインターネットを通じて世界中に配信されており,多くのサッカーファンがその魅力に触れることができます. さらに,ブラジルのサッカー文化は技術,創造性,スピード,そしてリズム感を特徴としています.ブラジルのサッカー選手は驚くほど優れたテクニックを持ち,美しいプレーを見せることで知られています.彼らのキレのあるドリブル,正確なパス,そして豪快なシュートは,多くの人々に感動を与えます. ブラジルのサッカーの成功は,その国の熱狂的なサッカーカルチャーとも関連しています.子供たちは幼い頃からサッカーボールを蹴り,街角やビーチでプレーする様子をよく見かけます.サッカースクールやアカデミーも充実しており,若い才能は早いうちから育成されています. ブラジルのサッカーは単なるスポーツの一環ではなく,国民の誇りやアイデンティティの一部です.多くの人々が試合を通じて喜びや感動を共有し,サッカーを通じて結びついています.ブラジルのサッカー文化は他の国々にも影響を与え,彼らのスタイルやプレースタイルが憧れとなっています. ブラジルのサッカーは確かに盛んな国であり,その魅力は世界中に広がっています.それはブラジルの人々の情熱と才能,そしてサッカー文化の豊かさによるものです. [INFO] [1695882752.038028]: assistant(token:1519): 完全に同意します.ブラジルのサッカーカルチャーは,国民の情熱と才能,そして豊かなサッカー文化によって支えられています.その魅力は世界中に広まり,多くの人々がブラジルのサッカーに感動を覚えています.ブラジルのサッカーは間違いなく世界的な影響力を持っており,多くの国々で愛される存在です. [INFO] [1695882760.235372]: request: ありがとうございます.ブラジルのサッカーは確かに世界的な影響力を持っており,多くの人々に愛されています.その独特のスタイルと情熱は,他の国々のサッカーカルチャーにも大きな影響を与えています.ブラジルのサッカーは常に進化し,新たな才能が次々に生まれることで,さらなる魅力と成功を築いていくでしょう. ^C[opponent/openai_chat_topic-3] killing on exit [openai_chat_topic-2] killing on exit [rosout-1] killing on exit [master] killing on exit shutting down processing monitor... ... shutting down processing monitor complete done robotuser@robotuser-PC:~$
ターミナル 2 : 最初の話題投下
robotuser@robotuser-PC:~$ rostopic pub -1 /request std_msgs/String "サッカーの盛んな国を1つ挙げてください." publishing and latching message for 3.0 seconds robotuser@robotuser-PC:~$
ROS ノードグラフ
rqt の ROS Node Graph でノードとトピックの様子を確認してみると,2つのノード /openai_chat_topic
と /opponent/openai_chat_topic
とが互いの応答トピックを参照して循環していることが見て取れます.
ターミナル 1 の出力にも現れていますが段々と応答の文字数が互いに多くなる傾向があります.ChatGPT の token 数の上限に達して終わったりしますが,そうでない限りはずっと ChatGPT 同士で応答を続けるので終わらせたい場合は Ctrl-C で終わらせます.
文脈のデータを蓄積して多くなると Chat Completion API の token を消費してしまいますし,応答に時間がかかったりもします.一定時間会話がなかった場合やそれまでの文脈からがらりと話題を変える場合のために文脈を含めたメッセージデータを初期化するメソッドも運用上は必要かもしれません.
また,OpenAI 以外の大規模言語モデル(LLM)の API の ROS Topic ラッパがあれば(or を作れば)異なる LLM 間での会話も可能であろうと思います.
今回の記事はここまでです.
本シリーズ前回の記事 ChatGPT と ROS – 文書生成 ROS ラッパー生成編(Chat Completion API) では OpenAI の Chat Completion API を利用した ROS Service ラッパ Python プログラムを Web の方の ChatGPT の助けを借りて作成した様子を紹介しました.
しかし,前回のプログラムは Chat Completion API を用いているものの使い方は「1問1答」形式で,それは Completion API を利用しているのと大きく変わらず,「文脈をふまえたチャット」形式ではありませんでした.
そこで前回から発展させて Chat Completion API を利用した「文脈をふまえたチャット」をする ROS ソフトウェアを次の2つの方法で実装してみました.
今回の記事ではこれらのうち「1. ROS Service プログラムの文脈をふまえたチャット対応」を行った様子をお伝えします.
前回作成した Chat Completion API を利用しながらも「1問1答」形式だった ROS Service プログラムを「チャット」形式に対応させるて会話ができるように作り直します.
Chat Completion API を用いたチャット機能の実装については下記の Web 記事が ROS ではない Python プログラムですが大変参考になりました.
この記事によると Chat Completion API の応答を「チャット」の結果として機能させるためには「新しい問い」に一連の「チャットの全履歴」も含めて新たなメッセージとしたものを API に送ってリクエストする必要があります.
前回作成した ROS Service プログラムを発展させて,Chat Completion API を利用し履歴をふまえた ROS チャットソフトウェアを作成する場合,チャットの履歴を ROS Service のサーバ側で保持するか,サービスの呼び出し側で保持するか,システム的な最適解はさておき,プログラム的にはどちらの方法もあるかと思います.
今回作成した文脈をふまえたチャットに対応する ROS Service プログラムは Chat Completion API のシンプルな ROS ラッパーとしての位置づけは変えずにそのサービスを呼び出す ROS Node 側で履歴を保持して ROS Service にリクエストを送り Chat Completion API にアクセスする方法を採ってみました.
今回も Web サービスの ChatGPT の助けを借りてプログラムを作成したのですが,まるごと Python コードを作成するための問いの仕方が下手だったのか,ChatGPT の応答でしっくり来るようなソースコードは得られませんでした.そこで Python コードを記述する際の個別具体的な問題について ChatGPT の力を借りました.
例えば Chat Completion API へのメッセージやレスポンスを文字列(string)にしてやり取りする方法を聞きました.
User
Chat Completion API Python における引数 messages に渡すのは json 形式の text 文字列であっていますか?
ChatGPT
Chat Completion APIのmessages
引数に渡すものは,Pythonのリストとしてのデータ構造です.このリストは辞書のオブジェクトを要素として持ちます.通常,直接JSON形式のテキスト文字列を渡すのではなく,Pythonのデータ構造を使用します.
以下は,APIに渡すためのmessages
の例です:
messages = [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Who won the world series in 2020?"} ]
もし,このリストがJSON形式の文字列として提供されている場合,Pythonのjson
モジュールを使ってデコードすることで,上記のようなPythonのデータ構造に変換することができます:
import json json_string = '[{"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Who won the world series in 2020?"}]' messages = json.loads(json_string)
OpenAIのAPIを直接使用する際や,HTTPリクエストを行う場合,リクエストのボディとしてJSON文字列を送信することがあります.その際には,上記のようにPythonのデータ構造をJSON文字列に変換(エンコード)したり,逆にJSON文字列からPythonのデータ構造に変換(デコード)したりする必要があります.しかし,多くのライブラリやSDKは,この変換を自動的に行ってくれるので,ユーザーが直接JSON文字列を扱う必要は少ないです.
User
json の python list を string に変換する場合はどうしますか?
ChatGPT
PythonのリストをJSON形式の文字列に変換するには,Pythonの標準ライブラリであるjson
モジュールのdumps
関数を使用します.
以下に具体的な手順を示します.
1. json
モジュールをインポートします.
import json
1. json.dumps
関数を使用してPythonのリストをJSON形式の文字列に変換します.
data = [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Who won the world series in 2020?"} ] json_string = json.dumps(data) print(json_string)
この例では,data
という名前のPythonリストをJSON形式の文字列に変換し,それをjson_string
という変数に保存しています.
また,json.dumps
関数にはいくつかのオプション引数があります.例えば,indent
を指定することで,整形された(インデントされた)JSON文字列を取得することができます:
json_string_pretty = json.dumps(data, indent=4) print(json_string_pretty)
これにより,出力は読みやすい形式で表示されます.
User
単純に str(data) とするのと異なりますか?
ChatGPT
str(data)
とjson.dumps(data)
は,多くの場合において似た結果を返すことがありますが,実際には異なる振る舞いを持ち,それぞれ異なる目的に最適化されています.以下にその主な違いをいくつか示します.
1. Unicode Handling:
json.dumps()
は,Unicode文字列を適切にエンコードしてJSON互換のエスケープシーケンスにします.一方,str()
はPythonのUnicode文字列の内部表現をそのまま返すことがあります.
data = {"key": "あいうえお"} print(str(data)) # Python 2では "{'key': u'\u3042\u3044\u3046\u3048\u304a'}" print(json.dumps(data)) # '{"key": "あいうえお"}'
2. Boolean Values:
json.dumps()
は,PythonのTrue
とFalse
をそれぞれtrue
とfalse
としてJSONに変換します.str()
は,Pythonの表現をそのまま返します.
data = {"key": True} print(str(data)) # "{'key': True}" print(json.dumps(data)) # '{"key": true}'
3. Single vs Double Quotes:
Pythonの辞書を文字列として表現するとき,str()
はシングルクォート(‘)を使用します.しかし,JSON標準はプロパティ名や文字列値にダブルクォート(“)を使用するため,json.dumps()
はダブルクォートを使用します.
data = {"key": "value"} print(str(data)) # "{'key': 'value'}" print(json.dumps(data)) # '{"key": "value"}'
これらの違いから,PythonのデータをJSONとして扱いたい場合や,他のシステムとの互換性を確保したい場合は,json.dumps()
を使用するのが最適です.一方,デバッグ目的などでPythonの内部表現を文字列として見たいだけの場合は,str()
を使用することができます.
また,Chat Completion API へ送るメッセージデータの中のrole
の使い方についても ChatGPT に質問してみました.
Chat Completion API の渡し値の role における system と assistant の違いをおしえて?
ChatGPT
Chat Completion APIの文脈におけるrole
の値system
とassistant
は,入力メッセージのコンテキストを形成するためのものです.各role
は以下のような意味を持ちます:
1. system:
system
の役割は,環境やセッションの全体的な指示やコンテキストを設定するためのものです.{"role": "system", "content": "You are an assistant that speaks like Shakespeare."}
2. assistant:
assistant
の役割は,モデル自体の前の発言やレスポンスを示すためのものです.各役割は,APIを通じてモデルとの対話を形成するためのコンテキストを提供する役割を果たします.たとえば,モデルにシェイクスピアのように話すように指示するsystem
メッセージの後,ユーザーの質問に対するモデルの回答はシェイクスピアのスタイルで形成される可能性があります.
このように,role
の値を使用して,モデルとの対話のコンテキストや動作を微調整することができます.
文脈をふまえたチャット対応を行った ROS Service プログラムの作成や変更を行ったファイルは次のとおりです.
以下,それぞれのファイル内のコードを記載して少し説明をします.
srv / ChatCompletion.srv
messages
,受取るデータをresponse
というstring
型にしています.
string messages --- string response
scripts / openai_chat_server.py
chat_service
としてデータを JSON 形式の文字列として授受し,Chat Completion API へのアクセスを行っています.
#!/usr/bin/env python3 import rospy import openai import json from openai_ros.srv import ChatCompletion, ChatCompletionResponse def handle_chat_request(req): openai.api_key = rospy.get_param('~key') model = rospy.get_param('~model') res = ChatCompletionResponse() messages = json.loads(req.messages) response = openai.ChatCompletion.create( model=model, messages=messages ) return json.dumps(response) def chat_service(): rospy.init_node('chat_service') rospy.Service('chat_service', ChatCompletion, handle_chat_request) rospy.spin() if __name__ == "__main__": chat_service()
scripts / openai_chat_client.py
role
の「環境やセッションの全体的な指示やコンテキストを設定する」 system
に prompt
の内容を設定します.
ROS Node 内でユーザからのインプットを受け取り,これまでのメッセージ履歴に追加して,メッセージデータを JSON 文字列として ROS Service chat_service
に送っています.サービスからの応答データは JSON 文字列から Python リストに変換されて含まれていた返答メッセージはprint()
してメッセージ履歴にも追加することを繰り返しています.
#!/usr/bin/env python3 import sys, json import rospy from openai_ros.srv import ChatCompletion, ChatCompletionResponse def chat_client(prompt="You are a helpful assistant."): messages = [] messages.append({"role": "system", "content": str(prompt)}) rospy.wait_for_service('chat_service') try: chat_service_client = rospy.ServiceProxy('chat_service', ChatCompletion) except rospy.ServiceException as e: print ("Service call failed: %s" % e) while not rospy.is_shutdown(): # Get input from the user user_input = input("You: ") if user_input == "quit": exit() # Add user's input to the history messages.append({"role": "user", "content": user_input}) msg_string = json.dumps(messages) # Call the service try: res_msg = chat_service_client(msg_string) except rospy.ServiceException as e: print ("Service call failed: %s" % e) response = json.loads(res_msg.response) content = response["choices"][0]["message"]["content"] role = response["choices"][0]["message"]["role"] token = response["usage"]["total_tokens"] print("\n%s(token:%d): %s\n" % (role, token, content)) # Add GPT's response to the history messages.append({"role": str(role), "content": str(content)}) if __name__ == "__main__": if len(sys.argv) == 2: prompt = str(sys.argv[1]) else: prompt = "You are a helpful assistant." print("Type \'quit\' to quit.\n") print("For \'system\': %s\n" % (prompt)) rospy.init_node('chat_client') chat_client(prompt=prompt)
launch / openai_chat.launch
<launch> <arg name="key" default="$(env OPENAI_API_KEY)" /> <arg name="model" default="gpt-3.5-turbo" /> <node pkg="openai_ros" type="openai_chat_server.py" name="openai_chat" output="screen"> <param name="key" value="$(arg key)" /> <param name="model" value="$(arg model)" /> </node> </launch>
CMakeLists.txt
add_service_files( FILES Completion.srv ChatCompletion.srv ) generate_messages(
文脈をふまえたチャットへ対応させた ROS Service プログラムの実行例が次になります.
ターミナル1 : ROS Service サーバの起動
robotuser@robotuser-PC:~/openai_ws$ source ~/openai_ws/devel/setup.bash robotuser@robotuser-PC:~/openai_ws$ export OPENAI_API_KEY="sk-..." robotuser@robotuser-PC:~/openai_ws$ roslaunch openai_ros openai_chat.launch
ターミナル2 : ROS チャットノードの実行
robotuser@robotuser-PC:~/openai_ws$ source ~/openai_ws/devel/setup.bash robotuser@robotuser-PC:~/openai_ws$ rosrun openai_ros openai_chat_client.py Type 'quit' to quit. For 'system': You are a helpful assistant. You: hello assistant(token:27): Hello! How can I assist you today? You: ハロー assistant(token:56): こんにちは!どのようにお手伝いできますか? You: ボン・ニュイ assistant(token:115): ボン・ニュイ!夜にちょっと早い挨拶ですね.何かお手伝いできることはありますか? You: こんばんは をフランス語で言うと? assistant(token:163): 「こんばんは」をフランス語で言うと「Bonsoir」となります. You: bon nuit は日本語では? assistant(token:224): 「bon nuit」はフランス語で「良い夜」を意味しますが,日本語では「おやすみなさい」と訳されます. You: 間違えていました.ボンソワール assistant(token:338): 間違いありません.「ボンソワール」はフランス語で「こんばんは」という意味です.おやすみなさいの言い方は「ボンヌィ」となります.ごめんなさい,混乱を招いてしまいました.どうかお許しください. You: quit robotuser@robotuser-PC:~/openai_ws$
このように今回は ROS Node 内でのチャット会話になっています.
前回ベースにしている https://github.com/davesarmoury/openai_ros が1問1答形式の Completion API にアクセスする ROS Service を提供していたことから Chat Completion API にアクセスする ROS ソフトウェアも ROS Service 形式で作成してみました.
比較的長文で1問1答を行う Completion API であれば ROS Service や ROS Action (actionlib) のソフトウェアにするのも一理あるように思えます.しかし短文のチャットを扱う Chat Completion API へのアクセスであれば ROS Topic を介したメッセージのやり取りの方が ROS ノード内のチャット会話に限られず,より ROS 親和的かつよりシンプルな構成になるのでは?と思いました.
本シリーズ次回の記事では冒頭で述べました文脈をふまえたチャットを実現する2つの方法のもう一方の「ChatGPT と ROS – ROS Topic を介した ChatGPT チャットプログラム」を作成した様子を紹介する予定です.
今回の記事はここまでです.
本シリーズ前回の記事 ChatGPT と ROS – 文書生成 ROS ラッパー利用編(Completion API) では OpenAI API の ROS ラッパーの中で Completion API を利用している ROS1 の Python ラッパ https://github.com/davesarmoury/openai_ros を使ってみました.
今回は OpenAI の Chat Completion API を利用した ROS ラッパ Python プログラムを Web サービスの方の ChatGPT の助けをかりながら作成した様子を紹介します.
本シリーズ第1回の記事 ChatGPT と ROS – 調査編 でもふれましたが OpenAI の文書生成 API について簡単にまとめますと,「1問1答形式」の Completion API と,「対話した文脈を含むチャット対話形式」の Chat Completion API の2つがあります.
前回の記事ではこの2つのうち「1問1答」形式の Completion API を利用ました.今回の記事ではもう一方の「チャット対話」形式のインタフェースである Chat Completion API を ROS から利用してみます.
今回は Web サービスの ChatGPT に Chat Completion API を使ったプログラムを生成してもらいながら進めましたのでそれも含めて開発・実行環境の構成は次のようになっています.
まずは ChatGPT の Web サービスに ChatGPT の Python API にアクセスするための Python プログラムを書いてもらいました.
ChatGPT の Python API を用いたアクセスプログラムを書いてください.
ChatGPT
まず,OpenAIのPythonクライアントライブラリをインストールする必要があります.次のコマンドでインストールできます.
pip install openai
そして,以下はOpenAIのGPTを使用するための基本的なPythonコードです.この例では,プロンプトとして”Translate the following English text to French: ‘{}'”を使用し,その'{}’の部分に翻訳したい英文を挿入しています.
import openai openai.api_key = 'your-api-key' response = openai.ChatCompletion.create( model="gpt-4.0-turbo", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Translate the following English text to French: '{}'"} ] ) print(response['choices'][0]['message']['content'])
上記のコードは,APIキーを設定し,特定のモデル(この場合は”gpt-4.0-turbo”)を指定して,ChatCompletion APIを呼び出す基本的な構造を示しています.messagesパラメータは会話の履歴を表し,最初のメッセージは通常,モデルに役割(この場合は”helpful assistant”)を設定するためのシステムメッセージです.ユーザーメッセージはその後に続きます.
注意: ‘your-api-key’の部分は,OpenAIから提供される実際のAPIキーに置き換える必要があります.また,APIの使用は料金が発生しますので,公式ドキュメンテーションを確認して使用制限とコストを理解することが重要です.
なお,GPT-4のリリース後もAPIの基本的な使い方はこれまでと同様ですが,詳細な情報や更新内容についてはOpenAIの公式ドキュメンテーションをご覧ください.
次にこの ChatGPT にアクセスする Python コードを ROS の Service に対応させたプログラムを作成してもらいました.
この Python プログラムから ROS の service プログラムラッパーを作成してください.
ChatGPT
ROS (Robot Operating System)は,ロボットのためのフレームワークで,様々なハードウェアやソフトウェアの要素を組み合わせて使うことができます.ここでは,PythonのOpenAI GPT-4クライアントをROSサービスとしてラップする基本的な例を示します.
まず,適切なメッセージタイプを使用するためのsrvファイルを作成します.この例では,リクエストとレスポンスが共に一つの文字列を持つシンプルなサービスを定義します.
# GptService.srv string input --- string output
次に,このサービスを実装するPythonのROSノードを作成します.このノードは,指定された文字列を翻訳するサービスを提供します.
#!/usr/bin/env python import rospy from openai_ros.srv import GptService, GptServiceResponse import openai def handle_gpt_request(req): openai.api_key = 'your-api-key' response = openai.ChatCompletion.create( model="gpt-4.0-turbo", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Translate the following English text to French: '{}'".format(req.input)} ] ) return GptServiceResponse(response['choices'][0]['message']['content']) def gpt_service(): rospy.init_node('gpt_service') s = rospy.Service('gpt_service', GptService, handle_gpt_request) print("Ready to translate English text to French.") rospy.spin() if __name__ == "__main__": gpt_service()
このPythonスクリプトは,ROSノードgpt_serviceを作成し,それがGptServiceサービスを提供するようにします.サービスリクエストが来ると,handle_gpt_request関数が呼び出され,その中でOpenAIのGPT-4クライアントが使われてリクエストされたテキストを翻訳します.
このスクリプトをROSノードとして実行するためには,そのファイルに実行可能なパーミッションを与える必要があります.以下のコマンドで実行可能なパーミッションを与えることができます:
chmod +x gpt_service.py
また,OpenAIのAPIキーを設定する部分では,実際のキーに’your-api-key’を置き換える必要があります.そして,APIの使用は料金が発生しますので,公式ドキュメンテーションを確認して使用制限とコストを理解することが重要です.
なお,上記のコードはあくまで一例であり,具体的な使用シーンや要件によりますので,適宜修正や拡張を行ってください.
ChatGPT に最初に生成してもらった Python プログラムにおいてプロンプトの内容が固定されているため,それを基に生成した ROS ラッパープログラムも固定プロンプトへの応答結果を出すだけになってしまいました.
そこでプロンプトを変更可能なようにプログラムを変更してもらいました.
ChatGPT に問うプロンプトを変えられるようにプログラムを変更してください.
ChatGPT
もちろんです.以下に,GPTサービスリクエストにプロンプトを含めるように改変したROSサービスの例を示します.
まず,新たなsrvファイルを作成します.この例では,リクエストにプロンプトとインプットの2つの文字列を持つサービスを定義します.
# GptService.srv string prompt string input --- string output
次に,このサービスを実装するPythonのROSノードを作成します.
#!/usr/bin/env python import rospy from openai_ros.srv import GptService, GptServiceResponse import openai def handle_gpt_request(req): openai.api_key = 'your-api-key' response = openai.ChatCompletion.create( model="gpt-4.0-turbo", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "{} '{}'".format(req.prompt, req.input)} ] ) return GptServiceResponse(response['choices'][0]['message']['content']) def gpt_service(): rospy.init_node('gpt_service') s = rospy.Service('gpt_service', GptService, handle_gpt_request) print("Ready to handle GPT-4 requests.") rospy.spin() if __name__ == "__main__": gpt_service()
このPythonスクリプトは,ROSノードgpt_serviceを作成し,それがGptServiceサービスを提供するようにします.サービスリクエストが来ると,handle_gpt_request関数が呼び出され,その中でOpenAIのGPT-4クライアントが使われてリクエストされたプロンプトとテキストを処理します.
上記のコードを実行する前に,Pythonスクリプトに実行可能なパーミッションを与えることを忘れないでください.
ここまでの ChatGPT の応答で ROS の Python プログラムとして動きそうな感じのソースコードが生成されたように思いましたので実際に実行しながら修正してみることにしました.
今回は ChatGPT と ROS – 文書生成 ROS ラッパー利用編(Completion API) で利用した ROS パッケージ https://github.com/davesarmoury/openai_ros をベースに Chat Completion API を利用する機能を付け加えるかたちで進めました.
ChatGPT が生成した Chat Completion API を利用する ROS Python プログラムを使って Chat Completion API を利用できるよう ROS パッケージに変更を加えた箇所をまとめると次のようになります.
#!/usr/bin/env python
#!/usr/bin/env python3
openai.api_key = 'your-api-key'
openai.api_key = rospy.get_param('~key')
model="gpt-4.0-turbo",
model="gpt-3.5-turbo",
print("Ready to handle GPT-4 requests.")
print("Ready to handle GPT-3.5 requests.")
GptService.srv
の記述追加openai_chat_node.py
#!/usr/bin/env python3 import rospy from openai_ros.srv import GptService, GptServiceResponse import openai def handle_gpt_request(req): # openai.api_key = 'your-api-key' openai.api_key = rospy.get_param('~key') response = openai.ChatCompletion.create( # model="gpt-4.0-turbo", model="gpt-3.5-turbo", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "{} '{}'".format(req.prompt, req.input)} ] ) return GptServiceResponse(response['choices'][0]['message']['content']) def gpt_service(): rospy.init_node('gpt_service') s = rospy.Service('gpt_service', GptService, handle_gpt_request) # print("Ready to handle GPT-4 requests.") print("Ready to handle GPT-3.5 requests.") rospy.spin() if __name__ == "__main__": gpt_service()
プログラムの本筋の部分は ChatGPT が生成したコードから修正の必要はありませんでした.
GptService.srv
# GptService.srv string prompt string input --- string output
CMakeLists.txt
add_service_files( FILES Completion.srv GptService.srv )
GptService.srv のサービスが利用できるように CMakeLists.txt に加筆しました.このあたりの修正箇所の洗い出しも ChatGPT に問うてみるのも修正規模が大きい場合にはありかもしれません.
openai_chat.launch
<launch> <arg name="key" default="$(env OPENAI_API_KEY)" /> <arg name="max_tokens" default="256" /> <arg name="model" default="gpt-4.0-turbo" /> <node pkg="openai_ros" type="openai_chat_node.py" name="openai_chat" output="screen"> <param name="key" value="$(arg key)" /> <param name="max_tokens" value="$(arg max_tokens)" /> <param name="model" value="$(arg model)" /> </node> </launch>
モデルを GPT-3.5 と GPT-4 で launch オプションで切り替えて使おうかと思っていたのですが,Web と API への課金は別らしく今回は API では GPT-3.5 のみ利用可能な状況でしたので openai_chat_node.py にモデル名を直書きしたまま使ってしまいました.
roslaunch openai_ros openai_chat.launch
を起動してからもう1つのターミナルで ROS サービスで rosservice call /gpt_service '{prompt: "(プロンプト)", input: "(内容)"}'
のように利用します.
output: "Mon nom est Robotuser."
ターミナル1
robotuser@robotuser-PC:~/openai_ws$ source ~/openai_ws/devel/setup.bash robotuser@robotuser-PC:~/openai_ws$ roslaunch openai_ros openai_chat.launch ... logging to /home/robotuser/.ros/log/9d61ced2-f54d-11ed-b5ca-c10df8d90fa9/roslaunch-robotuser-PC-41157.log Checking log directory for disk usage. This may take a while. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://robotuser-PC:35595/ SUMMARY ======== PARAMETERS * /openai_chat/key: sk-3JDluBbxsNuIhi... * /openai_chat/max_tokens: 256 * /openai_chat/model: gpt-4.0-turbo * /rosdistro: noetic * /rosversion: 1.16.0 NODES / openai_chat (openai_ros/openai_chat_node.py) auto-starting new master process[master]: started with pid [41165] ROS_MASTER_URI=http://localhost:11311 setting /run_id to 9d61ced2-f54d-11ed-b5ca-c10df8d90fa9 process[rosout-1]: started with pid [41175] started core service [/rosout] process[openai_chat-2]: started with pid [41182] Ready to handle GPT-3.5 requests.
ターミナル2
robotuser@robotuser-PC:~/openai_ws$ source ~/openai_ws/devel/setup.bash robotuser@robotuser-PC:~/openai_ws$ rosservice call /gpt_service '{prompt: "Translate following to French:", input: "My name is Robotuser."}' output: "Mon nom est Robotuser." robotuser@robotuser-PC:~/openai_ws$ rosservice call /gpt_service '{prompt: "Translate following to Spanish:", input: "My name is Robotuser."}' output: "Mi nombre es Robotuser." robotuser@robotuser-PC:~/openai_ws$ rosservice call /gpt_service '{prompt: "Translate following to Japanese:", input: "My name is Robotuser."}' output: "\u79C1\u306E\u540D\u524D\u306F\u30ED\u30DC\u30C3\u30C8\u30E6\u30FC\u30B6\u30FC\u3067\ \u3059\u3002" robotuser@robotuser-PC:~/openai_ws$
このサービス利用例では “My name is Robotuser.” をフランス語,スペイン語,日本語に翻訳するよう各プロンプトを送りました.
日本語への翻訳指示した output が文字コード化していたので Unicode 変換すると次のようになりました.
私の名前はロボットユーザーです.
このように ChatGPT の Web サービスを利用してコードを生成してもらい,OpenAI の Chat Completion API を ROS から利用できるようになりました.
しかし今回のプログラムは Chat Completion API を用いているものの「1問1答」形式の使い方をしていて,それは Completion API を利用している場合と大きく変わらず, “文脈” をふまえた「チャット」形式ではありませんでした.
本シリーズ次回の記事では今回の Chat Completion API を利用する ROS サービスプログラムを文脈をふまえた「チャット」をする ROS プログラムに改造した様子をお伝えする予定です.
本シリーズ前回の記事 ChatGPT と ROS – 調査編 では ChatGPT の ROS を介した利用について少し調べてみたことをお伝えしました.
今回は OpenAI API の ROS ラッパーの中で Completion API を利用している ROS1 の Python ラッパ https://github.com/davesarmoury/openai_ros を使ってみた様子を紹介します.
今回は次の環境で OpenAI API の ROS を介した実行を行っています.
OpenAI API は新規登録後 3ヶ月 の期限がありますが 5ドル分 の無料クレジットが付与されるのでお試し利用することができます.(2023年8月中旬時点)
API Key の取得は OpenAI API の Web ページでログインした状態で下記リンク先の API keys のページから取得します.
実行環境の準備が整いましたらインストールとビルドを行います.
ROS は既にインストールされているようでしたら改めてインストールする必要はありません.
加えて下記の catkin ツール関係もインストールしておきます.
$ sudo apt install python3-osrf-pycommon python3-catkin-tools
OpenAI の Python ライブラリが必要ですので pip からインストールします.
$ sudo apt install python3-pip $ pip install --upgrade openai
今回は openai_ws という名前のワークスペースを作成してソースコードのクローンとビルドを行っています.
$ mkdir -p ~/openai_ws/src $ cd ~/openai_ws/src/ $ git clone https://github.com/davesarmoury/openai_ros.git $ cd ~/openai_ws/ $ rosdep install -y -r --from-paths src --ignore-src $ catkin build $ source ~/openai_ws/devel/setup.bash
ワークスペースでビルドした openai_ros の ROS プロセスを実行します.
まず1つ目のターミナルで API Key を環境変数 OPENAI_API_KEY
として export で設定しておきます.$ export OPENAI_API_KEY="sk-..."
の sk-...
の部分は各自の OpenAI API アカウントで作成した API Key の内容に置き換えてください.
OpenAI の Completion API を利用するための ROS サービスサーバを実行するために openai.launch を起動します.
$ source ~/openai_ws/devel/setup.bash $ export OPENAI_API_KEY="sk-..." $ roslaunch openai_ros openai.launch max_tokens:=256
2つ目のターミナルから1つ目のターミナルで実行している OpenAI Completion API の ROS サービスにプロンプトを “Write a poem about OpenAI” としてサービスコールを行います.
$ source ~/openai_ws/devel/setup.bash $ rosservice call /get_response '{prompt: "Write a poem about OpenAI"}' finish_reason: "stop" text: "\n\nOpenAI, a force of nature,\nA tool of the future,\nA way to explore the unknown,\n\ A way to make the world better.\n\nA way to make machines smarter,\nA way to make\ \ them think,\nA way to make them learn,\nA way to make them act.\n\nA way to make\ \ them understand,\nA way to make them act,\nA way to make them do,\nA way to make\ \ them react.\n\nOpenAI, a force of nature,\nA tool of the future,\nA way to explore\ \ the unknown,\nA way to make the world better." model: "text-davinci-003" completion_tokens: 134 prompt_tokens: 6 total_tokens: 140
Completion API から ROS サービス経由で応答が帰ってきました.text:
に応答内容があります.
text 部分の改行コードなどを除くと次のようになっています.
OpenAI, a force of nature,
A tool of the future,
A way to explore the unknown,
A way to make the world better.
A way to make machines smarter,
A way to make them think,
A way to make them learn,
A way to make them act.
A way to make them understand,
A way to make them act,
A way to make them do,
A way to make them react.
OpenAI, a force of nature,
A tool of the future,
A way to explore the unknown,
A way to make the world better.
…だそうです.
プロンプトを日本語で例えば '{prompt: "OpenAI についての40字以 内のポエムを書いてください"}'
記述しても応答はありますが rosservice のコールの応答をそのままコンソール出力した状態ですと text:
内は文字コード化されていて可読性がありませんでした.
注)コマンド全文は枠内を横スクロールして表示してください.
$ rosservice call /get_response '{prompt: "OpenAI についての40字以 内のポエムを書いてください"}' finish_reason: "stop" text: "\n\nOpenAI\u306F\u3001\u4EBA\u985E\u306E\u672A\u6765\u3092\u5B88\u308B\u305F\u3081\ \u306B\u3001AI\u3092\u4F7F\u3063\u3066\u6280\u8853\u3092\u767A\u5C55\u3055\u305B\ \u308B\u3002\u79C1\u305F\u3061\u306F\u3001AI\u3092\u4F7F\u3063\u3066\u3001\u3088\ \u308A\u826F\u3044\u672A\u6765\u3092\u5275\u9020\u3057\u3088\u3046\u3002" model: "text-davinci-003" completion_tokens: 81 prompt_tokens: 31 total_tokens: 112 $
文字コード表示を文字コード変換の ascii2uni で解決してみます.ascii2uni を使うため uni2ascii をインストールします.
$ sudo apt install uni2ascii
ROS サービスコールの結果に対して | ascii2uni -a U -q
をパイプしてコード変換を行います.
注)コマンド全文は枠内を横スクロールして表示してください.
$ rosservice call /get_response '{prompt: "OpenAI についての40字以 内のポエムを書いてください"}' | ascii2uni -a U -q finish_reason: "stop" text: "\n\nOpenAIは,人類の未来を守るため\ に𰀚Iを使って技術を発展させ\ る.私たちは𰀚Iを使って,よ\ り良い未来を創造しよう." model: "text-davinci-003" completion_tokens: 81 prompt_tokens: 31 total_tokens: 112 $
一部文字化けしてしまっているようです.おそらく \u3001
(=読点「,」) + AI
を \u3001A
+ I
と判断して違う文字を表示しようとしているようです.「文字コードの”読点”」+「平文英数字」の組み合わせ以外は大体 ascii2uni で表示できそうです.
文字コード化されたものは Python の print()
内で解決されて可読性のある日本語の状態で出力されますので,今回の openai_ros の ROS サービスを Python からコールするプログラム openni_get_completion.py を書きました.
#!/usr/bin/env python3 import sys import rospy from openai_ros.srv import Completion, CompletionResponse def get_response_client(prompt): request = '{prompt: ' + str(prompt) +'}' rospy.wait_for_service('get_response') try: get_response = rospy.ServiceProxy('get_response', Completion) response = get_response(request, 0) return response except rospy.ServiceException as e: print ("Service call failed: %s"%e) if __name__ == "__main__": if len(sys.argv) == 2: prompt = str(sys.argv[1]) else: prompt = "Write a poem about OpenAI" print("Prompt: %s\n" % (prompt)) response = get_response_client(prompt) print("Response: \n%s\n" % (response)) print("Text: %s\n" % (response.text))
先程の ターミナル1 で openai.launch を実行している状態で ターミナル2 から openni_get_completion.py を実行します.
$ source ~/openai_ws/devel/setup.bash $ rosrun openai_ros openai_get_completion.py Prompt: Write a poem about OpenAI Response: finish_reason: "stop" text: "\n\nOpenAI, a force of nature,\nA powerful tool of creation,\nAble to learn and adapt,\n\ Able to think and create.\n\nA tool of the future,\nA tool of the present,\nA tool\ \ of the past,\nA tool of the ages.\n\nA tool of the people,\nA tool of the world,\n\ A tool of the universe,\nA tool of the gods.\n\nOpenAI, a force of nature,\nA powerful\ \ tool of creation,\nAble to learn and adapt,\nAble to think and create." model: "text-davinci-003" completion_tokens: 124 prompt_tokens: 11 total_tokens: 135 Text: OpenAI, a force of nature, A powerful tool of creation, Able to learn and adapt, Able to think and create. A tool of the future, A tool of the present, A tool of the past, A tool of the ages. A tool of the people, A tool of the world, A tool of the universe, A tool of the gods. OpenAI, a force of nature, A powerful tool of creation, Able to learn and adapt, Able to think and create. $
実行時にプロンプトの引数を渡していないのでプログラム内に書かれてるデフォルトのプロンプト “Write a poem about OpenAI” に対する英語のポエムが返ってきています.英語でも Python の print()
で出力すると改行コードが見えなくなるので読みやすくなっています.
次は引数として日本語のプロンプト “OpenAI についての40字以内のポエムを書いてください.” を渡して openni_get_completion.py を実行します.
$ rosrun openai_ros openai_get_completion.py "OpenAI についての40字以内のポエムを書いてください." Prompt: OpenAI についての40字以内のポエムを書いてください. Response: finish_reason: "stop" text: "\n\nOpenAI\u306F\u672A\u6765\u3092\u7167\u3089\u3059\u5149\u3001\u672A\u6765\u3092\ \u5207\u308A\u958B\u304F\u92ED\u3044\u5203\u3002\u79C1\u305F\u3061\u306E\u672A\u6765\ \u3092\u8C4A\u304B\u306B\u3057\u3066\u304F\u308C\u308B\u3002" model: "text-davinci-003" completion_tokens: 58 prompt_tokens: 39 total_tokens: 97 Text: OpenAIは未来を照らす光,未来を切り開く鋭い刃.私たちの未来を豊かにしてくれる. $
日本語でも可読性のある整形された状態で読めました.そうなんですね…
ポエムはさておき,openai_ros パッケージを利用して OpenAI の Completion API を ROS から英語と日本語のどちらでも利用することができました.
今回の記事はここまでです.
本シリーズ次回の記事は OpenAI の Chat Completion API を ROS から利用する Python プログラムを OpenAI の ChatGPT に教えてもらいながら作成した様子を紹介する予定です.
文書生成などで何かと話題の ChatGPT の ROS を介した利用について少し調べてみました.
本記事の筆者は AI に興味はあるものの利用したことがほとんどない立場ですが,ChatGPT などについて調べてみると AI 初心者でも OpenAI の API と ROS を介して文章を生成することができました.加えて ChatGPT の文章生成機能の力を借りてその API を使った ROS ラッパープログラムも作ることができました.その様子を次のようなトピックで複数回に分けて記事にします.
ChatGPT を提供しているのは OpenAI 社ですので “OpenAI” や “ChatGPT” でネット検索してみると OpenAI Gym の利用だったり,ChatGPT だったりといろいろとあるようでした.全く体系的・網羅的ではないと思うのですが,今回調査してみて得られた情報を大まかに分類してみると次のような構成になりました.
まず OpenAI Gym というのは強化学習を行うためのものでロボットの動作経路の学習などに用いられていて,今回の目的としていた文書生成とは異なる機能を提供しているようです.文書生成 API も Completion API と Chat Completion API と複数に分かれていました.
Web ページから ChatGPT-4 に Completion と Chat Completion の API の違いを聞いてみました.
Completion APIとChat Completion APIは,OpenAIのGPT(Generative Pretrained Transformer)をベースとしたテキスト生成APIです.しかし,それぞれの使用方法や特性は少し異なります.
Completion API:
Chat Completion API:
使用するAPIは,あなたがどのようなタスクを実行したいか,またはどのような出力を期待しているかによって異なります.
Chat Completion は名前の「チャット」のとおり文脈を含む対話形式で,Completion は1問1答形式のようです.
Completion と Chat Completion の違いについて対比的に解説されている記事もあり参考になりました.
ROS では OpenAI/ChatGPT がどのように使われているのか?ということで調べてみると,まず ROS Wiki にある openai_ros は強化学習の OpenAI Gym の機能を利用するパッケージのようでした.
また GitHub 内で “openai” と “ros” を組み合わせて検索してみると https://github.com/search?q=openai+ros&type=repositories&p=1 かなりヒットします.そのうち文書生成に関するリポジトリをピックアップしてリストにします.
これらの既存の OpenAI API の ROS ラッパーの中で Completion API を利用している ROS1 の Python ラッパ https://github.com/davesarmoury/openai_ros を使ってみた様子を次回の OpenAI と ROS の記事でお伝えする予定です.
今回の記事はここまでです.
先日,長野市にある信州大学の山崎研究室を訪問して Ubuntu 20.04 および ROS Noetic に対応した HIRO ロボットソフトウェアを納品しました.
山崎研究室では HIRO で AI を用いたロボット制御などを行っているとのことで,今回は GPU ボードを搭載したワークステーションに Ubuntu 20.04 および ROS Noetic に対応した HIRO ロボットソフトウェアをインストールしました.
HIRO ロボットは新しいソフトウェアを得て今後も活躍してくれることと思います.
なお, 今回の HIRO とともに TORK では NEXTAGE OPEN も Ubuntu 20.04 および ROS Noetic に対応したロボットソフトウェアの動作確認をしました.
NEXTAGE OPEN や HIRO を Python3 で動かすことや ROS Noetic で使うことにご興味がありましたら,TORK( info@opensource-robotics.tokyo.jp )にお問い合わせいただけたらと思います.
関連記事: 信州大学 山崎研究室でHiroに会いました!
本シリーズ前回の記事 Gazebo/MoveIt のための 3D モデリング(13)MoveIt の静モデルの作成 では CAD などからエクスポートしたメッシュデータファイルを MoveIt の静モデルとしてモデルファイルに組み込んで表示する方法を紹介しました.
今回は洗濯機の URDF (Unified Robot Description Format) モデルにドアのヒンジなどの動く箇所を設定して,より機械らしい(ロボットに近い)モデルにする様子を紹介します.
前回の MoveIt の静モデル作成においては洗濯機全体として1つのメッシュデータファイル( DAE もしくは STL )をエクスポートして利用しました.
MoveIt のリンクモデル作成では各リンクに対応したメッシュをそれぞれエクスポートしてそれぞれのリンクのメッシュファイルとして利用します.
今回の洗濯機モデルでは次の3つのリンク構成にします.
今回は「洗濯機本体(main-body)」は元の洗濯機全体の座標系そのままとするので配置の変更はしません.
「洗濯槽の扉(door)」と「洗剤投入トレイ(tray)」の形状データを各リンクの座標系原点に配置します.
元々の洗濯機全体の座標系で配置されたオブジェクトを残しつつ,別途各リンクのエクスポート用にリンク座標系の原点にオブジェクトを配置してメッシュデータとしてエクスポートします.
Rhinoceros では右の図のようにオブジェクトを含む既存のレイヤを右クリックするとメニューに「レイヤとオブジェクトを複製」ができるのでこの機能で複製した先のレイヤで作業すると良いでしょう.
各リンク座標系基準の配置用レイヤでそれぞれの各リンクは次のように配置しました.
各リンク座標基準に配置したオブジェクトを選択して「選択オブジェクトをエクスポート」コマンドから DAE (Collada) か STL 形式でエクスポートします.
Rhinoceros から DAE (Collada) をエクスポートする場合はエクスポートオプションにて
「ジオメトリのみを保存」のみにチェック
を入れてファイルを書き出します.
この「ジオメトリのみを保存」でも色や単位情報も保存されます.
今回は表示(visual)用に色付きの DAE ファイルとしてエクスポートし,干渉チェック(collision)用にデータ量を少なくするため粗目の設定で STL ファイルをエクスポートしました.
DAE や STL のメッシュデータのエクスポートが終わったらリンク機構を含む URDF モデルファイルを作成します.
3dmodeling-examples/models/urdf/ ├── meshes │ └── washing-machine │ ├── base_link.dae │ ├── base_link.stl │ ├── door.dae │ ├── door.stl │ ├── main-body.dae │ ├── main-body.stl │ ├── tray.dae │ └── tray.stl ├── washing-machine_links.urdf └── washing-machine.urdf
前回作成してメッシュファイルを配置したフォルダ
3dmodeling-examples/models/urdf/meshes
内にエクスポートしたメッシュファイルを配置します.
そしてフォルダ 3dmodeling-examples/models/urdf/
にファイル washing-machine_links.urdf
をテキストファイルとして作成してそこにリンク機構を含む URDF モデルを作り込みます.前回作成したファイル washing-machine.urdf
を複製してファイルの名前を変更しても良いです.
URDF データで 「洗濯機本体(main-body)」 と 「洗濯槽の扉(door)」 および 「洗剤投入トレイ(tray)」 それぞれの相対的な姿勢の関係とそれぞれの可動域を 「関節(joint)」 として定義しますので, CAD ( Rhinoceros など ) 上で相対姿勢および可動域の測定を行います.
その際,各リンクオブジェクトについて DAE や STL ファイルへのエクスポート用に原点へ移動した配置ではなく元々の洗濯機全体内での配置で調べるということに注意してください.
まずは 「洗濯機本体(main-body)」 と並進的な相対位置関係にある 「洗剤投入トレイ(tray)」 の座標の確認と設定可能な可動域を調べます.
次に 「洗濯機本体(main-body)」 と 「洗濯槽の扉(door)」 の相対座標・角度やの確認と設定可能な可動域を調べます.
扉は傾いて洗濯機本体に取り付けられているのでその角度とヒンジ回りの可動域も調べます.Rhinoceros では角度表示がラジアンでもできるのでそれを利用します.
リンクモデルに必要なメッシュファイルと情報が揃いましたので URDF ファイルに書き込んだものが次のようになります.
<?xml version="1.0" ?> <robot name="washing-machine"> <link name="base_link"> <collision> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <mesh filename="package://3dmodeling-examples/models/urdf/meshes/washing-machine/main-body.stl" scale="0.001 0.001 0.001" /> </geometry> </collision> <visual> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <mesh filename="package://3dmodeling-examples/models/urdf/meshes/washing-machine/main-body.dae" /> </geometry> </visual> </link> <link name="door"> <collision> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <mesh filename="package://3dmodeling-examples/models/urdf/meshes/washing-machine/door.stl" scale="0.001 0.001 0.001" /> </geometry> </collision> <visual> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <mesh filename="package://3dmodeling-examples/models/urdf/meshes/washing-machine/door.dae" /> </geometry> </visual> </link> <link name="tray"> <collision> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <mesh filename="package://3dmodeling-examples/models/urdf/meshes/washing-machine/tray.stl" scale="0.001 0.001 0.001" /> </geometry> </collision> <visual> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <mesh filename="package://3dmodeling-examples/models/urdf/meshes/washing-machine/tray.dae" /> </geometry> </visual> </link> <joint name="joint1" type="revolute"> <parent link="base_link"/> <child link="door"/> <origin xyz="0.30658 -0.258 0.67582" rpy="0 -0.1396 0"/> <axis xyz="0 0 1" /> <limit effort="30" velocity="1.0" lower="-1.8326" upper="0.0" /> </joint> <joint name="joint2" type="prismatic"> <parent link="base_link"/> <child link="tray"/> <origin xyz="0.0 -0.190 0.956" rpy="0 0 0"/> <axis xyz="1 0 0" /> <limit effort="30" velocity="1.0" lower="0.0" upper="0.200" /> </joint> </robot>
washing-machine_links.urdf 内のそれぞれの要素について説明します.
<link>
要素: リンクの定義 3つ ( base_link, door, tray )<collision>
要素にメッシュに STL ファイルを使用し単位変換 [mm] → [m]<visual>
要素に DAE メッシュファイルを使用<origin>
はリンク内のメッシュの配置なので今回は全てゼロ<joint>
要素: joint1type
で関節形式 revolve
(=回転)を設定<parent>
要素で関節を介する親リンク base_link
を指定<child>
要素で関節を介する子リンク door
を指定<origin>
要素で親子リンク間の相対座標<axis>
要素で revolve
関節の回転軸のリンク座標系での方向を設定<limit>
要素effort
: 最大トルク – 今回はとりあえずの値velocity
: 最大角速度 – 今回はとりあえずの値lower
: 可動域下限 – 回転関節なので下限角度で単位はラジアン [rad]upper
: 可動域上限 – 回転関節なので上限角度で単位はラジアン [rad]<joint>
要素: joint2type
で関節形式 prismatic
(=並進)を設定<parent>
要素で関節を介する親リンク base_link
を指定<child>
要素で関節を介する子リンク tray
を指定<origin>
要素で親子リンク間の相対座標<axis>
要素で prismatic
関節のリンク座標系での移動方向を設定<limit>
要素effort
: 最大力 – 今回はとりあえずの値velocity
: 最大速度 – 今回はとりあえずの値lower
: 可動域下限 – 並進関節なので下限位置で単位はメートル [m]upper
: 可動域上限 – 並進関節なので上限位置で単位はメートル [m]下記リンク先の ROS Wiki に URDF ファイルの作成方法のチュートリアルがありますので参考にしてください.
urdf_tutorial
の display.launch
で URDF モデル washing-machine_links.urdf
の確認をします.(下記コマンド横スクロールで末尾まで表示)
$ roslaunch urdf_tutorial display.launch model:='$(find 3dmodeling-examples)/models/urdf/washing-machine_links.urdf'
URDF で <joint>
要素を定義して joint_state_publisher ウィンドウ内のスライドバーも有効になっているので関節を動かしてみます.
動画では表示メッシュの動きとともに TF も一緒に動いている様子が見られると思います.
今回の記事はここまでです.
本シリーズ前回の記事 Gazebo/MoveIt のための 3D モデリング(12)Gazebo の静モデルの作成 ではエクスポートしたメッシュデータファイルを Gazebo の静モデルとしてモデルファイルに組み込んで表示する方法を紹介しました.
今回はエクスポートしたメッシュデータファイルを MoveIt の静モデルとしてモデルファイルに組み込んで表示する方法を紹介します.
今回紹介するのは次の2通りの方法です.メッシュを MoveIt GUI で読み込んで障害物とする方法とロボットモデル作成につながる方法の URDF モデルの作成とそれを確認表示する方法です.
MoveIt には動作計画における障害物として STL ファイルや DAE ファイルをそのまま読み込んで MoveIt の動作計画空間内に配置する機能があります.
MoveIt の Motion Planning パネル内の Scene Objects タブを開いて, “Mesh from file” を選択します.
“Mesh from file” セレクタの右隣にあるプラスボタン [ + ] を押します.
(左図拡大は画像をクリック)
保存してある STL もしくは DAE ファイルを選択します.
ファイルを読み込むときに MoveIt の GUI インタフェースである RViz のメッセージウィンドウが開いて,ミリメートル単位で記述されているモデルをメートル単位に変換する旨の問いがなされるので [ Yes ] をクリックします.
読み込んだモデルをインタラクティブマーカや座標などを指定して意図した位置に設置し,左のチェックボックスをクリックすると設置リンクの選択を促されますので適宜選択して [ OK ] ボタンを押します.
次に [ Publish ] ボタンを押すと読み込んで設置したモデルが MoveIt 空間内で障害物として認識されます.
あとは [ Plan ] や [ Plan & Execute ] などで動作計画を実行するとその経路上に障害物があるとそれを避けたマニピュレーションの軌道が生成されます.
MoveIt モデルの URDF ファイルの作成は下記リンク先の ROS Wiki に書かれています.
本記事ではそれらから MoveIt 静モデル作成に絞って説明します.
MoveIt モデルの作成にあたっては ROS パッケージを作成してその中にモデルの URDF ファイルを置くのが本記事の内容に続く応用も含めると一番簡便なのではないかと思います.
今回 ROS パッケージをつくるのが面倒なようでしたら下記リンク先リポジトリをクローンして利用してください.
3dmodeling-examples/ ├── CMakeLists.txt ├── images │ ├── front_view_win.png │ ├── left_view_win.png │ ├── top_view_win.png │ ├── washing-machine_catalogue.pdf │ └── washing-machine_catalogue.png ├── launch │ ├── spawn-washingmachine.launch │ └── world-washingmachine.launch ├── LICENSE ├── models │ ├── gazebo_models │ │ ├── washing-machine │ │ │ ├── meshes │ │ │ │ ├── base_link_blue-gray.stl │ │ │ │ ├── base_link_dark-gray.stl │ │ │ │ ├── base_link_gray-white.stl │ │ │ │ ├── base_link_light-gray.stl │ │ │ │ └── base_link.stl │ │ │ ├── model.config │ │ │ └── model.sdf │ │ └── washing-machine-dae │ │ ├── meshes │ │ │ ├── base_link.dae │ │ │ └── base_link.stl │ │ ├── model.config │ │ └── model.sdf │ ├── urdf │ │ ├── meshes │ │ │ └── washing-machine │ │ │ ├── base_link.dae │ │ │ └── base_link.stl │ │ └── washing-machine.urdf │ └── washing-machine.3dm ├── package.xml ├── README.md └── worlds └── washing-machine.world
本記事執筆時のサンプルモデルパッケージは右に示すような構成になっていますので参考にしてみてください.
この中の MoveIt URDF モデルに関連するフォルダ・ファイルがハイライトされた部分です.
meshes フォルダに base_link.dae と base_link.stl の2つのファイルが含まれていますが,これはサンプルのためですのでどちらか1つのファイルだけでも URDF モデルは作成できます.
今回の MoveIt 静モデルのサンプル URDF ファイル washing-machine.urdf の中身は次のようになっています.
<?xml version="1.0" ?> <robot name="washing-machine"> <link name="base_link"> <collision> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <mesh filename="package://3dmodeling-examples/models/urdf/meshes/washing-machine/base_link.stl" scale="0.001 0.001 0.001" /> </geometry> </collision> <visual> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <mesh filename="package://3dmodeling-examples/models/urdf/meshes/washing-machine/base_link.dae" /> </geometry> </visual> </link> </robot>
URDF のデータ形式は XML で,モデル構成要素の link
や collision
, geometry
, mesh
が記述されています.今回は静モデルですので link
要素は1つですがロボットのように関節が多いとリンク数にともなって link
要素およびそこに含まれる子要素も増えます.
ROS パッケージ化していることで ROS のファイルシステムが名前空間から package://3dmodeling-examples/...
によって 3dmodeling-examples
パッケージのディレクトリを自動解決できるようになっています.
collision
メッシュの STL データは単位情報を持っていないので scale="0.001 0.001 0.001"
で 0.001倍(=1/1000) 変換をして [mm] のデータを [m] に換算しています.
visual
のメッシュは DAE ファイルを利用していて,DAE モデルは単位情報を持っていて読み込む側でスケール判断をするので scale
は必要ありません.
URDF モデルの確認には urdf_tutorial パッケージの display.launch を利用します.
urdf_tutorial は joint-state-publisher-gui パッケージをインストールすることで利用できるようになります.下記は ROS Melodic の場合のインストールコマンドですので他の ROS バージョンの場合は melodic
の部分を noetic
などに書き換えて実行してください.
$ sudo apt update $ sudo apt install ros-melodic-joint-state-publisher-gui
ターミナルで ROS 環境の設定と urdf_tutorial の display.launch の起動を行います.
$ source ~/$PathToYourWorkspace/devel/setup.bash $ roslaunch urdf_tutorial display.launch model:='$(find 3dmodeling-examples)/models/urdf/washing-machine.urdf'
$PathToYourWorkspace
は各自の ROS ワークスペースへのパスを記述
model:=
には URDF ファイルパスを指定正常に実行できると次の図のように洗濯機モデルが RViz 空間上に表示されます.
$ rosrun tf2_ros static_transform_publisher 0 0 0 0 0 0 /world /base_link
今回の記事はここまでです.
本シリーズ次回の記事は洗濯機の URDF モデルにドアのヒンジなどの動く箇所を設定してより機械らしい(ロボットに近い)モデルにする様子を紹介する予定です.
本ブログ記事「ROS 入門向けマニピュレータ導入検証」の公開後に OpenManipulator-X のソフトウェア構成の変更があり,記事で紹介した手順のアップデートが必要でしたので本記事にて紹介します.
基本的には ROBOTIS の e-Manual が充実していますのでその紹介ですが,加えて MoveIt での動作にフォーカスしたまとめと,「ROS 入門向けマニピュレータ導入検証」の MoveIt Commander Python サンプルスクリプトを実行する際の手順や入門者向けの注意点などをまとめています.
今回動作検証したシステム構成は次のようになっています.
インストールなどの手順は ROS Noetic については ROBOTIS の e-Manual の “Noetic” バージョンでの内容のとおりです.
ROS Melodic については ROBOTIS の e-Manual に記述は見つけられませんでしたがソフトウェアパッケージなどは準備されていましたので e-Manual の “kinetic” や “noetic” の部分を “melodic” に読み替えることで問題なくインストールなどの準備ができました.
MoveIt の実行についても ROBOTIS の e-Manual の内容のほぼそのままですが,実機動作のときはインタフェースに OpenCR を利用しましたので launch ファイルの起動オプションで USB ポートを指定する必要がありました.
$ roslaunch open_manipulator_controllers joint_trajectory_controller.launch
$ roslaunch open_manipulator_controllers joint_trajectory_controller.launch sim:=false usb_port:=/dev/ttyACM0
usb_port
が launch ファイルに書かれているデフォルト( /dev/ttyUSB0
)と異なる /dev/ttyACM0
であるため launch 時にオプション指定 usb_port:=/dev/ttyACM0
が必要ブログ記事「ROS 入門向けマニピュレータ導入検証」で検証したシステムの Ubuntu 16.04 + ROS Kinetic または Ubuntu 18.04 + ROS Melodic では Python 2 を使用していました.
今回 Ubuntu 18.04 + ROS Melodic のシステムでこのサンプルプログラムを実行させる場合は元のプログラムのまま実行できます.
Ubuntu 20.04 + ROS Noetic のシステムでは基本的に Python 3 を使用しますので Python 2 向けのサンプルプログラムを Python 3 に対応させるように変更する必要があります.
Python 2 から Python 3 への変更は下記リンク先 ROS Wiki – Source code changes to support Python 3 のドキュメントに推奨される方法が記述されています.
ただ推奨されている方法は少し手順が多いので,ここでは簡易的に記事内の「Open Manipulator X – MoveIt Commander テストプログラム」を Ubuntu 20.04 + ROS Noetic の Python 3 で実行するためにサンプルプログラムの 1行目 の python
を pyrhon3
に書き換えて対応します.
#!/usr/bin/env python
python
を pyrhon3
に変更
#!/usr/bin/env python3
サンプルプログラムは今回はインストール時にワークスペースにクローンした open_manipulator_controls
パッケージ内の /open_manipulator_controllers
フォルダ下に /script
フォルダを新規作成して,そこにファイル名 open_manipulator_moveit_tutorial_poses.py
で実行可能ファイルとして保存しました.
~/catkin_ws/src/open_manipulator_controls/open_manipulator_controllers/script/
open_manipulator_moveit_tutorial_poses.py
$ chmod 777 open_manipulator_moveit_tutorial_poses.py
Python スクリプトから MoveIt を動作させるコマンドインタフェースの MoveIt Commander の実行には MoveIt が起動している必要がありますので 1つ目のターミナル で MoveIt(対象は実機ロボットもしくは Gazebo シミュレータ)を実行した状態で,2つ目のターミナル で Python スクリプトを実行します.
$ roslaunch open_manipulator_controllers joint_trajectory_controller.launch
もしくは
sim:=false
/ OpenCR ポート設定usb_port:=/dev/ttyACM0
)$ roslaunch open_manipulator_controllers joint_trajectory_controller.launch sim:=false usb_port:=/dev/ttyACM0
ROS ではターミナルを新規に開くたびに ROS 環境の設定が必要です.
今回のケースでは ROS ワークスペース内のソフトウェアパッケージも利用しているので
$ source $PathToYourWorkspace/devel/setup.bash
で環境設定します.
$PathToYourWorkspace
は各自の ROS ワークスペースへのパスを記述
$ source ~/catkin_ws/devel/setup.bash
$ source $PathToYourWorkspace/devel/setup.bash
先程 open_manipulator_controls
パッケージ内にファイル保存と実行権限設定をしたサンプル Python スクリプト open_manipulator_moveit_tutorial_poses.py
を実行します.
$ rosrun open_manipulator_controllers open_manipulator_moveit_tutorial_poses.py
以上です.
本シリーズ前回の記事 Gazebo/MoveIt のための 3D モデリング(11)形状データのエクスポート で Gazebo や MoveIt で利用できるデータ形式にエクスポートする手順を紹介しました.
今回はエクスポートしたメッシュデータファイルを Gazebo の静モデルとしてモデルファイルに組み込んで表示する方法を紹介します.
今回紹介する Gazebo モデルを構成するファイル群は次のようなフォルダ構造にしています.
washing-machine ├── meshes │ ├── base_link_blue-gray.stl │ ├── base_link_dark-gray.stl │ ├── base_link_gray-white.stl │ ├── base_link_light-gray.stl │ └── base_link.stl ├── model.config └── model.sdf
Gazebo モデルは下記リンク先の GitHub リポジトリから入手可能です.
まずは Gazebo SDF モデルの本体のファイルとも言える model.sdf
の中身を見てみます.XML データになっていて干渉チェック用のモデルを記述した collision
や視覚表示用のモデルを記述した visual
などの要素があります.
<?xml version="1.0" ?> <sdf version="1.6"> <model name="washing-machine"> <!--static>true</static--> <pose>0 0 0 0 0 0</pose> <link name="base_link"> <inertial> <mass>10.0</mass> <inertia> <ixx>1.000000</ixx> <ixy>0.000000</ixy> <ixz>0.000000</ixz> <iyy>1.000000</iyy> <iyz>0.000000</iyz> <izz>1.000000</izz> </inertia> </inertial> <collision name="collision"> <geometry> <mesh> <uri>model://washing-machine/meshes/base_link.stl</uri> <scale>0.001 0.001 0.001</scale> </mesh> </geometry> </collision> <visual name="visual-gray-white"> <geometry> <mesh> <uri>model://washing-machine/meshes/base_link_gray-white.stl</uri> <scale>0.001 0.001 0.001</scale> </mesh> </geometry> <material> <ambient> 0.95 0.95 0.95 1.0</ambient> <diffuse> 0.95 0.95 0.95 1.0</diffuse> <specular> 0.95 0.95 0.95 1.0</specular> </material> </visual> <visual name="visual-light-gray"> <geometry> <mesh> <uri>model://washing-machine/meshes/base_link_light-gray.stl</uri> <scale>0.001 0.001 0.001</scale> </mesh> </geometry> <material> <ambient> 0.80 0.80 0.80 1.0</ambient> <diffuse> 0.80 0.80 0.80 1.0</diffuse> <specular> 0.80 0.80 0.80 1.0</specular> </material> </visual> <visual name="visual-dark-gray"> <geometry> <mesh> <uri>model://washing-machine/meshes/base_link_dark-gray.stl</uri> <scale>0.001 0.001 0.001</scale> </mesh> </geometry> <material> <ambient> 0.45 0.45 0.45 1.0</ambient> <diffuse> 0.45 0.45 0.45 1.0</diffuse> <specular> 0.45 0.45 0.45 1.0</specular> </material> </visual> <visual name="visual-blue-gray"> <geometry> <mesh> <uri>model://washing-machine/meshes/base_link_blue-gray.stl</uri> <scale>0.001 0.001 0.001</scale> </mesh> </geometry> <material> <ambient> 0.55 0.65 0.75 0.6</ambient> <diffuse> 0.55 0.65 0.75 0.6</diffuse> <specular> 0.55 0.65 0.75 0.6</specular> </material> </visual> </link> </model> </sdf>
STL ファイルは単位の情報を持っていません.本シリーズの記事では Rhinoceros 上で 単位 [mm] にてモデルを作成してメッシュを出力したので, [mm] での数値を Gazebo 上の単位 [m] に変換するために mesh
要素の scale
の (X,Y,Z) に全て 0.001 (=1/1000) を設定しています.適切なスケーリングを忘れたり,不要なスケーリングをしてしまったりするとモデルにメッシュは読み込めているのにありえない大きさのメッシュになってしまって目視できなくなるようなことがあるので注意が必要です.
visual
要素は色ごとに複数作成して各色のメッシュのファイルをそれぞれの uri
要素に記述して material
の ambient
(=環境反射率) diffuse
(=拡散反射率) specular
(=鏡面反射率) の数値を RGBA(=赤,緑,青,透明度) の順で設定します.(「透明度」は数値的には「不透明度」を意味するように思うのですが「透明度」と一般的には言われているようです.)
collision
要素はメッシュに洗濯機全体の閉じたメッシュ群である base_link.stl ファイルを使用しています.
inertial
の mass
(=質量) inertia
(=慣性モーメント) は今回はメッシュの確認が主な目的ですので適当な値を設定しました.精度良く物理シミュレーションを行いたい場合は適切な値を設定する必要があります.
model.config
ファイルの中身も XML データ形式で記述されていて当該 Gazebo モデルのメタ的な情報を記述しています.
<?xml version="1.0"?> <model> <name>washing-machine</name> <version>1.0</version> <sdf version="1.6">model.sdf</sdf> <author> <name>Tokyo Opensource Robotics Kyokai Association</name> <email>info@opensource-robotics.tokyo.jp</email> </author> <description> A Model Example of a Washing Machine. </description> </model>
Gazebo の 3D モデルをシミュレーション空間上に読込・表示する方法は主に次の3つの方法があります.
本記事における SDF モデルフォルダ washing-machine
をホームディレクトリ直下の隠しフォルダ .gazebo/models
内にコピーして Gazebo のウインドウ内の操作で読み込みます.
( USERNAME の部分は各自のユーザ名に読み替えてください.)
/home/USERNAME/.gazebo/models ├── ambulance │ ├── materials │ │ └── textures │ │ └── ambulance.png │ ├── meshes │ │ ├── ambulance.mtl │ │ └── ambulance.obj │ ├── model.config │ └── model.sdf : (中略) : └── washing-machine ├── meshes │ ├── base_link_blue-gray.stl │ ├── base_link_dark-gray.stl │ ├── base_link_gray-white.stl │ ├── base_link_light-gray.stl │ └── base_link.stl ├── model.config └── model.sdf
.gazebo/models
内にモデルをコピーすると Gazebo ウィンドウ内に挿入するモデルの選択肢の1つとして提示されるようになります.
$ gazebo
(図: クリックで拡大)
このような Gazebo 内に手作業でモデルを読み込む方法でもシミュレーションはできるのですが,自動的に読み込む手段として world ファイルを作成する方法や launch ファイル内やプログラムからモデルを読み込んで Gazebo に表示させる方法があります.自動的に読み込む方がモデルを用いた Gazebo シミュレーションでロボットを動作させるような段階では毎回手作業でモデルを Gazebo 空間内に読み込む必要がなく楽です.
前項目の「表示方法-1 .gazebo/models フォルダにコピー」は Gazebo を起動するたびにモデルを配置する必要があります.モデルの確認には十分ですが Gazebo のシミュレーションでロボットの動作を同じ環境で何度も試行するには向いていません.そこで Gazebo 環境の定義をする world ファイルを読み込むことで常に同じ環境を再現することができます.
world ファイルも XML 形式のデータです.
<?xml version="1.0" ?> <sdf version="1.4"> <world name="default"> <include> <uri>model://ground_plane</uri> </include> <include> <uri>model://sun</uri> </include> <include> <uri>model://washing-machine</uri> <name>washing-machine</name> <pose>0 0 0 0 0 0</pose> </include> <!-- <include> <uri>model://washing-machine-dae</uri> <name>washing-machine-dae</name> <pose>0 1.0 0 0 0 0</pose> </include> --> </world> </sdf>
上記 world ファイルでは ground_plane と sun,washing-machine モデルを Gazebo 空間に配置しています.16〜22行 はコメントアウト行で後述の dae ファイルを利用した場合の Gazebo モデルを配置する設定でそれを無効にしています.
world ファイルを読み込んで Gazebo を起動する launch ファイルを作成します.
<launch> <include file="$(find gazebo_ros)/launch/empty_world.launch"> <arg name="world_name" value="$(find 3dmodeling-examples)/worlds/washing-machine.world"/> <arg name="paused" value="false"/> <arg name="use_sim_time" value="true"/> <arg name="gui" value="true"/> <arg name="recording" value="false"/> <arg name="debug" value="true"/> </include> </launch>
今回作例を置いている ROS パッケージ内での world ファイルや launch ファイルのディレクトリ構造は次のようになっています.
3dmodeling-examples/ ├── CMakeLists.txt ├── images │ ├── front_view_win.png │ ├── left_view_win.png │ ├── top_view_win.png │ ├── washing-machine_catalogue.pdf │ └── washing-machine_catalogue.png ├── launch │ ├── spawn-washingmachine.launch │ └── world-washingmachine.launch ├── LICENSE ├── models │ ├── gazebo_models │ │ ├── washing-machine │ │ │ ├── meshes │ │ │ │ ├── base_link_blue-gray.stl │ │ │ │ ├── base_link_dark-gray.stl │ │ │ │ ├── base_link_gray-white.stl │ │ │ │ ├── base_link_light-gray.stl │ │ │ │ └── base_link.stl │ │ │ ├── model.config │ │ │ └── model.sdf │ │ └── washing-machine-dae │ │ ├── meshes │ │ │ ├── base_link.dae │ │ │ └── base_link.stl │ │ ├── model.config │ │ └── model.sdf │ ├── urdf │ │ ├── meshes │ │ │ └── washing-machine │ │ │ ├── base_link.dae │ │ │ └── base_link.stl │ │ └── washing-machine.urdf │ └── washing-machine.3dm ├── package.xml ├── README.md └── worlds └── washing-machine.world
また,この際に必要なことが Ubuntu の環境変数に world や Gazebo のモデルのあるディレクトリのパスを通しておくことです.ROS パッケージの package.xml に Gazebo モデルへのパスと実行依存関係を記述します.
<buildtool_depend>catkin</buildtool_depend> <build_depend>urdf</build_depend> <build_export_depend>urdf</build_export_depend> <exec_depend>urdf</exec_depend> <exec_depend>gazebo_ros</exec_depend> <!-- The export tag contains other, unspecified, tags --> <export> <gazebo_ros gazebo_model_path="${prefix}/models/gazebo_models"/> <gazebo_ros gazebo_media_path="${prefix}/worlds"/> </export> </package>
package.xml に記述した内容を有効にするためにビルドしてワークスペースの環境設定 source devel/setup.bash
をします.次のコマンドは Gazebo モデルを含んだワークスペース robotmodels_ws
にてビルドと環境設定を行った場合の例です.
world ファイルを読み込むように作成した launch ファイルを実行して Gazebo を起動します.
前項目の「表示方法-2 world ファイルを作成」では world ファイルでモデルの配置が決められた状態で Gazebo を起動していました. Spawn を行うことで既に実行されている Gazebo シミュレーション空間内に位置・姿勢を指定してモデルを配置することができます.
次に Spawn を用いた場合の launch ファイルの例を示します.
<launch> <include file="$(find gazebo_ros)/launch/empty_world.launch"> <arg name="paused" value="false"/> <arg name="use_sim_time" value="true"/> <arg name="gui" value="true"/> <arg name="recording" value="false"/> <arg name="debug" value="true"/> </include> <!-- Spawn a robot into Gazebo --> <node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model" args="-file $(find 3dmodeling-examples)/models/gazebo_models/washing-machine/model.sdf -sdf -x 0.0 -y 2.0 -z 0.0 -R 0.0 -P 0.0 -Y 0.0 -model washing-machine" /> </launch>
Gazebo が empty_world.launch
で実行開始された後 spawn_model
を用いて Gazebo シミュレーション空間上の ( 0.0, 2.0, 0.0 ) の位置に配置しています.
spawn-washingmachine.launch
を実行してみます.
world ファイルを読み込んで Gazebo を起動したときと異なる位置に配置しています.
Gazebo で dae ファイルを用いて色付きモデルを表示することも可能ですが,STL ファイルを用いて SDF ファイル内で色設定をした方が Gazebo 表示状態を確認してから SDF ファイル内で色や透明度の調整が可能ですので意図した表示になるように思います.
上の図の状態は先述の washing-machine.world
ファイル内のコメントアウトを行っている 16行目 と 22行目 を削除してファイルを保存し, world ファイルを読み込んで Gazebo を実行すると表示されます.
<?xml version="1.0" ?> <sdf version="1.4"> <world name="default"> <include> <uri>model://ground_plane</uri> </include> <include> <uri>model://sun</uri> </include> <include> <uri>model://washing-machine</uri> <name>washing-machine</name> <pose>0 0 0 0 0 0</pose> </include> <!-- <include> <uri>model://washing-machine-dae</uri> <name>washing-machine-dae</name> <pose>0 1.0 0 0 0 0</pose> </include> --> </world> </sdf>
Gazebo シミュレーションの様子をデモンストレーションなどで見せるような場合に,DAE ファイルを使った Gazebo モデルで見た目がいまいちに感じたら STL ファイルと SDF ファイル内での色指定を試してみてはいかがでしょうか.
今回の記事はここまでです.
本シリーズ次回の記事は
「Gazebo/MoveIt のための 3D モデリング(13)MoveIt の静モデルの作成」
として,前回エクスポートしたメッシュデータファイルを MoveIt のモデルファイルに組み込んで表示を行う様子を紹介する予定です.
本シリーズ前回の記事 Gazebo/MoveIt のための 3D モデリング(10)部品作成編 で洗濯機全体の形状が完成しました.
まずはエクスポートするメッシュの確認も兼ねて,可動部分のない一番単純な Gazebo と MoveIt それぞれにおける洗濯機モデルを作ることを目標として,今回は CAD( 本記事では Rhinoceros )の形状データに色を付けるとともに Gazebo や MoveIt で利用できるデータ形式にエクスポートする手順を紹介します.
次の図は今回エクスポートするデータを Gazebo と MoveIt のシミュレーションモデルに組み込んで表示させた様子で,次回の記事のゴールになる予定です.
Gazebo/MoveIt のシミュレーションモデルにはディスプレイ表示用の visual メッシュと干渉チェック用の collision メッシュの2種類のデータが必要です.今回は大きく分けて次の ① ② ③ の 3種類 のデータを用意します.
ひとまず可動部分のない Gazebo および MoveIt のシミュレーションモデルを作成しますので,これまで作成してきた洗濯機モデルの閉じたポリサーフェス(=ソリッド)をそのまま全て選択して「選択オブジェクトをエクスポート(Export)」で干渉チェック用の STL メッシュデータファイルとしてエクスポートします.
ファイルの種類で「STL (Stereolithography) (*.stl)」を選択します.ファイル名はメッシュモデルの乗るシミュレーションモデルのリンク名にすると分かりやすいので今回は「base_link.stl」とします.
「ポリゴンメッシュ詳細オプション」の子ウィンドウが出るので各設定項目は主に下のリストのように今回は設定しました.(図はクリックで拡大表示されます.)
STL メッシュデータの粗密やデータ量を調整したい場合は主にこれらの設定値を調整します.
「STLエクスポートオプション」ではデータ量を確認してデータが大きすぎるような場合には「メッシュを調整」ボタンから再調整して,問題なければ「バイナリ(B)」でエクスポートします.
エクスポートした STL ファイルの内容を確認するにはフリーソフトウェアの MeshLab にインポートするのが良いのではないかと思います.
MeshLab は Windows・Mac・Linux のどのプラットフォームにもインストールできますので便利です.
また Windows であれば「3Dビューアー」,Mac であれば「プレビュー」でも STL ファイルを表示することが可能です.
エクスポートした STL ファイルに洗濯機全体の形状データが含まれているように表示されるかと思います.
干渉チェック(collision)用の STL ファイルへのエクスポート手順は以上です.
ディスプレイ表示用の visual メッシュは色を付けない単色での利用も可能ですが,せっかくなのでカタログから推測して次のリストの色分けをしてみます.
Rhinoceros のデフォルトではポリサーフェスで1つにまとまっていると色や反射率,透過率などの設定が含まれるマテリアル設定が1つしか反映されないので,色ごとのポリサーフェスやサーフェス,それらのグループに分解します.ソリッド(=閉じたポリサーフェス)の状態は残しておきたいので色付け用のレイヤを作成してそのレイヤに洗濯機モデル全体をコピーしたものを分解,色付けします.
色はオブジェクトの「マテリアル」を設定して付けます.
色ごとに分けたオブジェクト(=ポリサーフェスやサーフェス,グループ)を選択してから右クリックして「オブジェクトのプロパティ(S)」を表示して「プロパティ: マテリアル」タブを開きます.
マテリアルの設定時に気を付ける点があり,「金属」系の色は後の項目でエクスポートする Collada(DAE)ファイルや Gazebo,MoveIt のディスプレイ上では反映されなく,意図しない,おそらくエクスポートしたオブジェクトのあるレイヤー色か黒などに表示されてしまうので「プラスチック」系のマテリアルを使用して各色を指定するのが良さそうです.
また,Rhinoceros 上での表示形式を「レンダリング」にすることでマテリアルが反映された表示になります.
上の図では 「gray-white」を選択した例を示していますが,他の「light-gray」「dark-gray」「blue-gray」についても同様にプラスチック系マテリアルの色を調整して設定します.
MoveIt シミュレーションモデルの URDF ファイルから表示用(visual)メッシュとして使うために,マテリアルを設定して色付けしたモデル Rhinoceros から Collada(DAE)ファイルとしてエクスポートします.
Collada(DAE)のメッシュデータには色や単位の情報も含まれるので全色分のオブジェクトを一緒くたに選択して「選択オブジェクトをエクスポート(Export)」でエクスポートします.
ファイルの種類に「COLLADA(*.dae)」を選択します.ファイル名はメッシュモデルの乗るシミュレーションモデルのリンク名にすると分かりやすいので今回は「base_link.dae」とします.
エクスポートした DAE ファイルの内容の確認は Mac だと「プレビュー」で右の図のように行えます.
FreeCAD は Windows や Mac,Linux で利用でき,DAE データも表示することができます.
FreeCAD の操作感はあまり良いとは言えないのですが様々な形式の 3D データが読み込めるのでデータ確認には非常に便利です.
今回,洗濯機操作部の丸いボタンに金属系マテリアルを設定して Collada(DAE)ファイルとしてエクスポートして利用しようとしましたが金属マテリアル部分が DAE メッシュとしては黒色になってしまって金属的な表現にはなりませんでした.
今回筆者の調べた範囲においては glTF(ジー”エル”ティーエフ) 形式とそのバイナリ形式の glb 形式が 3D モデルのファイル内に金属やガラスなどのマテリアル表現の情報も含まれる形式とのことでしたので Rhioceros にこれらの形式をエクスポートするプラグインを導入し,丸ボタンに金属マテリアルを適用したものを glb 形式でエクスポートして,Web にある glTF ビューア で表示してみたものが次の図です.
ボタンの部分が金属的な表現になっているように見えます.
ではこの glTF や glb 形式の 3D モデルファイルが Gazebo や MoveIt で使えるのか,といったところが ROS ユーザとしては気になるところです.Gazebo や MoveIt はレンダリングエンジンに OGRE(Object-Oriented Graphics Rendering Engine) を利用しています.
OGRE の現時点で最新リリースが 2022年2月9日 リリースの 13.3 です.OGRE v13.3 では glTF2.0 形式の情報を利用した金属や布などのマテリアル表現が可能になったとのことです.
Gazebo や MoveIt でも OGRE で新しくリリースされた豊かなマテリアル表現機能を使えるように実装が進んだら,今回上手くいかなかった金属表現もできるようになるのかな?と期待しています.
Gazebo シミュレーションモデルの SDF ファイルから表示用(visual)メッシュを色付きで使うためには色ごとにメッシュを分けた STL データファイルに対して SDF ファイル内で色情報を指定する必要があります.
そのために Rhinoceros からは色ごとにオブジェクトを選択して各色の STL ファイルとしてエクスポートします.
一般的な STL ファイルには色情報が含まれませんので Rhinoceros 上で色を付ける必要性はないのですが,前の項目で既に色ごとに分けて色付けしたオブジェクトがありますので,ここでは「色で選択(SelColor)」でそれぞれの色を選択して「選択オブジェクトをエクスポート(Export)」すると楽にできます.
STL エクスポート自体のの手順は先ほどの「干渉チェック(collision)用 STL メッシュデータのエクスポート」内で行った手順と基本的には同じですが,色分けした,ソリッド(=閉じたポリサーフェス)ではない,開いたポリサーフェスやサーフェスをエクスポートすることが出てきますので,その場合は「STLエクスポートオプション」にて「開いたオブジェクトをエクスポート(E)」のチェックを入れる必要があります.
ファイル名はメッシュモデルの乗るシミュレーションモデルのリンク名に色名を足しておくと分かりやすいので,今回は下のリストの各ファイル名で 4色分 4つのファイルとしてエクスポートしました.
複数に分けた STL ファイルを MeshLab にインポートすると MeshLab 内のレイヤとして表示されるのでレイヤの表示・非表示を切り替えるなどしてメッシュの確認を行うと良いのではないかと思います.
今回の記事はここまでです.
本シリーズ次回の記事は
「Gazebo/MoveIt のための 3D モデリング(12)Gazebo や MoveIt の静モデルの作成」
として,今回エクスポートしたメッシュデータファイルを Gazebo や MoveIt のモデルファイルに組み込んで表示する様子を紹介する予定です.
前回は「Gazebo/MoveIt のための 3D モデリング(9)滑らかなサーフェス – 作成編(その4)」として,制御点の大幅な位置調整も含めた NURBS サーフェスの調整や制御点移動による曲面サーフェス作成例を紹介しました.前回の記事も含め,複数回に分けてサーフェスの作成方法に主眼を置いたモデリングの紹介をしてきました.
今回の記事は洗濯機の扉などの各部品の作成例を紹介して最後に洗濯機のモデル形状を完成させます.
洗濯機前面が球面サーフェスなので,円形の扉の中心軸をその球の中心から作ると洗濯槽扉と洗濯機前面共に軸対称となり幾何学的に収まりが良くなります.
側面図から判断し,球の中心から水平よりも 8° 上方に角度を持つ直線が扉の中心軸であると推定しました.
(以後,各図ともクリックで拡大します.)
洗濯槽扉は中心軸周りの「回転(Revolve)」で作成できますので,そのプロファイル曲線作成にあたりそれに適した「作業平面」を設定すると描画しやすいと思います.
洗濯槽扉の軸上の 2点 とワールド座標系での XZ平面内 の点の「3点指定」で「作業平面の設定」を行ってから,ビューを「作業平面の平行ビュー」を設定すると見やすいです.
洗濯槽扉の奥行方向の大きさや形状は上面図に開いた状態の扉が描画されているので少し斜めから見た投影図になってしまいますがそこから推測します.
そのために既に 3D 空間上に配置されている上面図をコピーし,位置と方向を調整して,右の図の様に作業平面上で直接的に参考にできるように配置します.
洗濯槽扉の形状プロファイルを描画して「回転(Revolve)」などで作成します.
また洗濯機本体側の洗濯槽扉の収まる部分や洗濯槽については三面図などからは寸法は拾えないので推測で大体の形状で作成します.
洗濯槽扉が開く方向は三面図から洗濯槽扉の中心軸を通りワールド座標系の Y軸 に平行な平面内で回転して開いているようです.
この平面内で開いた状態の位置に洗濯槽扉をコピー移動・回転させることにより回転中心を幾何学的に算出することができます.
回転軸が算出できたら洗濯機本体に干渉しないヒンジのモデルを作成します.
洗濯槽扉を開くボタンは洗濯槽扉に正対する作業平面上で形状を描画してサーフェスにしてゆくと作業がしやすいです.
カタログのレンダリング図を見ると給水口が洗濯機本体への接続部は段落ち形状になっています.
段落ち部の平面形状は上面図から,また給水口の大体の形状は三面図から拾えます.
段落ちしている寸法は三面図からは拾えませんがシミュレーション上も問題になる部分ではないので推測で適当に 10mm としました.
洗濯機前面下部のフィルターが入っているところのフタは雰囲気を出すだけで溝を設ける形にしました.
洗濯機両側面の移設用の取っ手は側面図と正面図から大きさや出っ張り高さは分かりますが取っ手部分の形状はレンダリング画像から推測するしかないので大体の形状でモデリングします.
洗濯機を設置するロボットのような取っ手を持つことを前提としたシミュレーションの場合は形状をより気にしてモデリングした方が良いかもしれません.
「Gazebo/MoveIt のための 3D モデリング(6)滑らかなサーフェス – 作成編(その1)」で作成した洗濯機前面上部のボタン類も現在の作業レイヤーにコピーしてソリッドの「和(BooleanUnion)」をします.
また洗濯機前面上部のディスプレイ部境界線を YZ平面上 に描画して洗濯機前面サーフェスに「投影(Project)」してその曲線を用いて洗濯機前面サーフェスを「分割(Split)」します.
洗濯機本体側洗濯槽扉周辺の色違いで別部品となっている部分も正面図から大きさを拾ってサーフェスを「分割(Split)」します.
以上で洗濯機全体の形状が完成しました.
色分け前ですが表示形式をいろいろ変えて描画した様子が次のアニメーション画像です.
今回の記事はここまでです.
本シリーズ次回の記事は
「Gazebo/MoveIt のための 3D モデリング(11)形状データのエクスポート」
として,CAD( 本記事では Rhinoceros )の形状データを Gazebo や MoveIt で利用できるデータ形式にエクスポートする手順などを中心に紹介する予定です.
前回は「Gazebo/MoveIt のための 3D モデリング(8)滑らかなサーフェス – 作成編(その3)」として NURBS サーフェスの制御点や次数を編集する作成・調整方法について紹介をしました.
今回は制御点の大幅な位置調整も含めた NURBS サーフェスの調整をして残りの暫定オープンエッジ周辺のサーフェスを作成します.また洗濯機の洗剤投入部を開けるために指を入れる凹み形状も制御点の移動での作成例も紹介します.
左の図に赤色で示している洗濯機前面・側面・上面間コーナ部のサーフェスを作成します.
編集対象となる「サーフェスを抽出(ExtractSrf)」します.
新たに作成するサーフェスの1辺の形状を表す曲線を作成したいので,その基礎形状とするためにまず洗濯機前面・上面間のフィレットサーフェスの「アイソカーブを抽出(ExtractIsocurve)」します.
抽出したアイソカーブを洗濯機側面と平行な平面上に「投影(Project)」して基礎形状曲線として利用する配置にします.
投影する際に投影方向を「カスタム」にして始点をアイソカーブの上端点,終点をフィレットサーフェスの上端点に指定します.
投影した基礎形状とする曲線から「点を抽出(ExtractPt)」と「グループ化(Group)」を行い,新たに作成するサーフェスの辺形状曲線の基となる制御点の参考点とします.
トリムのための平面や洗濯機側面と新たに作成するサーフェス間の曲線形状端の配置のための直線を準備します.
以前の記事で洗濯機前面・上面間のフィレットサーフェスの高さは 30mm として作成しました.それと大体同じ大きさのフィレット曲線で洗濯機側面の平面サーフェスを再トリムして,その部分を新しく作成するサーフェスの1辺とします.そのために先程,洗濯機側面平面の上前頂点から水平に描画した直線を下方(Z軸のマイナス方向)に 30mm 移動させます.
先程抽出した制御点参考点グループを直線移動でできたた交点にコピーします.
サーフェスをトリムするためのサーフェスを作成するためにコピー前とコピー後の制御点参考点グループの対応する両端点間に「直線(Line)」を描画します.
トリムするためのサーフェスを「曲線を押し出し > 曲線に沿って(ExtrudeCrvAlongCrv)」で作成します.
トリムのための交差部が確実に算出されるように「サーフェス > 延長(ExtendSrf)」でトリムするためのサーフェスを拡大します.
洗濯機側面上の新しいトリム曲線を「曲線をブレンド(BlendCrv)」でコピーしていた制御点の参考点に合わせて作成します.
もう一方のレール曲線についても制御点の参考点をコピーして「曲線をブレンド(BlendCrv)」でそれに合わせて作成します.
またサーフェスをトリムしたトリムラインは 多点3次 の NURBS 曲線になってしまっているので,それに近しい形状の曲線としてサーフェスのアイソカーブをカスタム方向で平面のトリムサーフェスに「投影(Project)」してアイソカーブと同じ次数・制御点の NURBS カーブをサーフェス作成に利用します.
作成したいサーフェス周りの4辺の曲線が準備できましたので「2レールスイープ(Sweep2)」でサーフェスを作成します.4辺全て曲線から作成しますので接続条件は「位置」連続しか選択できませんが,サーフェスを作成後に「マッチング(MatchSrf)」などで曲率や曲率変化率を周辺サーフェスに合わせる手順で行います.
作成したサーフェスの「マッチング(MatchSrf)」を行います.まずは次の図に示す2辺を「アイソカーブ方向の調整」の設定を「ターゲットアイソカーブの方向をマッチング(M)」にして「マッチング(MatchSrf)」を実行します.結果を得てサーフェスを周辺サーフェスと「結合(Join)」して「エッジを表示(ShowEdges)」するとマッチングを行った辺が接続されています.
次に洗濯機側面の平面に接続する辺を「連続性」の設定を「位置」にして「マッチング(MatchSrf)」を実行します.位置連続性でのマッチングの場合はその辺から1つ目の制御点のみ調整されます.結果を得てサーフェスを周辺サーフェスと「結合(Join)」して「エッジを表示(ShowEdges)」するとマッチングを行った辺も接続されています.
ここは主に現状の制御点数で洗濯機側面平面のトリム部と接続が可能かの確認を目的としています.今回は現状接続先のある3辺で接続可能なことが確認できましたので後は辺から2つ目以降の制御点の調整をして接線方向,曲率や曲率変化率の連続性を調整すれば良いことがわかりました.
続いてサーフェス3辺の曲率連続条件での接続を調整します.「アイソカーブ方向の調整」の設定を「アイソカーブの方向を維持(P)」にして「マッチング(MatchSrf)」を実行します.Rhinoceros では「アイソカーブ方向の調整」が複数辺マッチング時に各辺別の設定ができないので各辺ごとの「アイソカーブ方向の調整」を設定したい場合は何度か設定を変えながら「マッチング(MatchSrf)」を繰り返してサーフェスの連続性を調整する必要があります.
「ゼブラ(Zebra)」でサーフェスの接続状況を確認すると少しずれている箇所が見受けられるので制御点を直接的に調整します.
洗濯機側面に接続する辺から数えて4番目の制御点までは他の2辺が接続するサーフェスも洗濯機側面の平面サーフェスに対して曲率変化率連続で接続しているので Y方向 の座標を洗濯機側面平面に合わせると大体合うはずです.
これらの制御点に対して変形の「XYZを設定(SetPt)」でワールド座標系の Y座標 をセットします.
曲率連続以上の滑らかさを求めている場合は制御点の第3点以内を編集したら再度「マッチング(MatchSrf)」を曲率連続条件にて実行して,「エッジを表示(ShowEdges)」や「曲率表示(CurvatureGraph)」などで確認しながら進めます.
制御点の第3点までの配置できたら(曲率連続),制御点の第4点を調整します.第4点各点を第1〜3点の延長上に配置すると「曲率変化率連続」に近いサーフェスになります.
第4点の配置の基本的な手順は接続先のサーフェスの曲率からくる第1〜3点までの状況によりいくつかあり,またそれらの組み合わせるなどして曲率変化率連続になるように配置します.
サーフェスの「マッチング(MatchSrf)」や制御点の「XYZを設定(SetPt)」,ガムボール移動などを繰り返して曲率変化率連続になるようにサーフェスを修正します.
おおよそ曲率変化率連続に近づいた状態でここで編集しているサーフェスとその周辺のサーフェスを「ゼブラマッピング(Zebra)」して縞の方向を縦と横にしたものが次の図です.だいぶゼブラが滑らかに通るようになったのではないかと思います.
残りのフレット部分のサーフェスを作成します.
先程と同様にアイソカーブをトリム平面にカスタム方向にて「投影(Project)」してフィレットサーフェス両端のプロファイル曲線とします.
色々と試しているときに洗濯機前面と側面間のフィレットサーフェスの長さが足りなかったので「サーフェスを抽出(ExtractSrf)」,「トリム解除(Untrim)」してから「サーフェス延長(ExtendSrf)」(タイプ: スムーズ)を行って,再度トリム平面で「トリム(Trim)」しました.
フィレットサーフェスを「2レールスイープ(Sweep2)」で作成します.レール曲線にサーフェス端部形状を使い,断面曲線に先程アイソカーブをトリム平面に「投影(Project)」した曲線を使います.後で「マッチング(MatchSrf)」で曲率連続での接続に修正するので,今回の作成時は接続条件は位置のみにします.
作成したフィレットサーフェスの制御点を「制御点表示オン(POn)」で表示してみると V方向 は 8点 ですが U方向 は多くの点で構成されていることが分かります.また次数は V方向 は投影したアイソカーブが反映されていて 7次 で U方向 はレール曲線の1つがサーフェス断面なので 3次 です.
U方向 の制御点数がサーフェス内での滑らかさの調整や周辺サーフェスとの曲率変化率連続のために第4点を全て手動で調整するには多いように思いますので「RebuildUV(メニューにはない)」で “U方向のみ” サーフェスを再構築します.
今回は再構築後の U方向の 制御点数を 11個 にしています.また「RebuildUV」オプションで「タイプ(T)=ユニフォーム」にしたので再構築後の次数は 3次 になります.
再構築したフィレットサーフェスの U方向 の次数は 3次 なので最終的には「次数を変更(ChangeDegree)」で 7次 にします.「次数を変更(ChangeDegree)」で 3次 から 7次 にする場合,次数を変更する方向の制御点に新たに4つ(セット)が元のサーフェスに対して増えます.
「次数を変更(ChangeDegree)」で 7次 に変更して制御点が増える前にまず 3次 の時点で制御点の配置を整えておきます.
洗濯機上面と側面間のフィレットおよび前面と側面間のフィレットはそのプロファイル曲線の制御点の Y座標 をほぼ一致するようにしていましたので両フィレットサーフェス間にある今編集しているサーフェスの制御点の Y座標 もそれらと大体一致するものと考えられます.そこで「制御点を選択 > U方向をすべて選択(SelU)」で8列の1つずつ U方向 の制御点を選択して「XYZを設定(SetPt)」でワールド座標系の Y座標 の設定にて各端点を選択して Y座標 位置を整えます.
U方向 だけ次数が 3次 のうちに一度曲率連続で接続先サーフェスに「マッチング(MatchSrf)」を「ターゲットアイソカーブの方向をマッチング(M)」で行い接続します.
フィレットサーフェスの U方向 の次数を 「次数を変更(ChangeDegree)」で 3次 から 7次 に変更します.
次数が 7次 に変更された U方向 だけ曲率連続で接続先サーフェスに「マッチング(MatchSrf)」を「ターゲットアイソカーブの方向をマッチング(M)」で行い接続します.
今度は4辺全てにおいて曲率連続で接続先サーフェスに「マッチング(MatchSrf)」を「アイソカーブの方向を維持(P)」で行い接続します.
フィレットサーフェスの4辺が曲率連続で接続されているはずですので周辺のサーフェスと全て「結合(Join)」してから「エッジを表示(ShowEdges)」で隙間が無いことを確認し.また「曲率分析(CurvatureAnalysis)」でおおよその曲率連続性を見てみます.
大体曲率連続接続になっているので後は「曲率変化率連続」になるように全ての第4制御点について第1〜3制御点に対する位置の調整を行います.
第4制御点の位置調整をする際にガムボールの白い丸をクリックするとガムボール設定が表示されるので適宜ガムボールの移動方向を「ワールドに合わせる」や「ビューに合わせる」に変更したり,「ドラッグ強度」を小さく設定して微妙な位置修正をできるようにするとより良く編集できると思います.
全ての第4制御点の位置を大体調整して「曲率表示オン(CurvatureGraph)」を行ったのが右の図です.おおよそ曲率変化率連続(G3)に近い状態になっているかと思います.
「ゼブラ(Zebra)」表示をして「縞の方向」と「縞のサイズ」を変更したものが次の図です.ゼブラも比較的良く通っているように見えます.
また,作成したポリサーフェスを「環境マッピング(Emap)」表示を行ってもサーフェスやその接続の滑らかさの様子を見ることができます.
これで洗濯機本体の隙間があった部分のサーフェスもできましたので今回作成・編集したサーフェスで置き換えた洗濯機本体のポリサーフェスを再構成して「結合(Join)」したものが右の図です.
今回の記事の最後に平面に接続する場合において曲率変化率連続接続されるサーフェスのパワープレー気味ですが簡単な制御点移動による曲面の作成方法を1つ紹介します.
本項で作成するのは左の図の赤い楕円で囲ったところにある洗濯機の洗剤投入トレイに指を掛けるためのトレイ後ろ側本体窪み形状のサーフェスです.
洗剤トレイとそれが入る洗濯機本体部分のモデリング手順はここでは省略して既にあるものとします.
上面図に少しサーフェス範囲の線が入っているので洗濯機上面平面前端曲線の同心円やトレイの中心線からのオフセットラインを描画してサーフェスの作成範囲の参照線とします.
新たに作成するサーフェスの1辺として同心円間に円の中心からサーフェス端の方向に「直線(Line)」を描画します.
描画した直線を同心円中心周りに「回転(Revolve)」でサーフェスを作成します.
この「回転(Revolve)」で作成されたサーフェスは円弧方向は 3点2次,直径方向は 2点1次 で構成されたサーフェスになります.
このサーフェスを変形して曲面にしても洗濯機上面の平面に曲率変化率連続で接続するには洗濯機上面につながるサーフェスの辺から第4の制御点までこの平面上に位置していれば良いので「リビルド(Rebuild)」して制御点と次数を変更して再構築します.
「リビルド(Rebuild)」で U方向 を 16点7次 に V方向 を 8点7次 にします.
洗濯機上面の平面に接続する3辺から第4までの制御点以外の制御点を選択してガムボールで Z軸方向 に -15mm 移動させます.
「曲率表示オン(CurvatureGraph)」をすると平面に接続する3辺が曲率ゼロ,曲率変化率ゼロになっていることが見て取れます.
このように NURBS サーフェスの接続連続性と制御点と次数の関係が分かっていると単純な操作で滑らかに接続するサーフェスを作成できるケースもありますので便利です.
今回作成したサーフェスを含めた洗濯機モデルの全体像は右の図のようになります.
今回の記事はここまでです.
「滑らかなサーフェス – 作成編」などサーフェスの作成方法に主眼を置いたモデリングの記事は今回で終了となります.
本シリーズ次回の記事は
「Gazebo/MoveIt のための 3D モデリング(10)部品作成編」
として,洗濯機の扉などの部品の作成例を紹介する予定です.
前回は「Gazebo/MoveIt のための 3D モデリング(7)滑らかなサーフェス – 作成編(その2)」としてサーフェスのプロファイル曲線の制御点や次数を少し意識した滑らかなサーフェスの作成例を紹介しました.
今回は NURBS サーフェスの制御点や次数を編集する作成・調整方法について紹介しつつ,前回の記事中では暫定的にオープンエッジのままとしていた箇所,左の図で赤く示した辺りのサーフェスを作成します.
編集対象となる「サーフェスを抽出(ExtractSrf)」してから洗濯機のソリッドモデルを非表示にしておきます.
前面の上下を接続する大きめのフィレットサーフェスに合わせて新しいサーフェスを作成したいので,既存のフィレットサーフェスを「分割(Split)」して不要部分を削除します.
この際,コマンド内設定で「切断に用いるオブジェクトを選択」に「アイソカーブ(I)」を指定し,洗濯機前面の上下を接続する大きめのフィレットサーフェスの端点にアイソカーブを合わせて分割します.
アイソカーブ(Isocurve)
「アイソカーブ」はサーフェスの UV 各方向に沿った曲線で,サーフェス上の1点における各方向の制御点配置と次数がそのまま反映されます.アイソカーブではないサーフェス上の曲線や分割線は Rhinoceros では 多点3次 の曲線として扱われるため,3次 よりも大きな次数の NURBS サーフェスの場合はそのアイソカーブに比べてアイソカーブではないサーフェス上の曲線は滑らかではない可能性が高いです.よって,サーフェスを分割する場合は可能であればアイソカーブで分割すると,その分割部に接続するサーフェスを作成する際に滑らかなサーフェスを作成しやすくなります.
フィレットサーフェスに隣接する角部の大きい方のサーフェスも同様にアイソカーブで「分割(Split)」します.
新規に作成するサーフェスを既存の洗濯機前面上下間サーフェスに合うものにしたいのでその既存のプロファイル曲線の制御点をサーフェスの1辺の曲線を作成するための参考点とします.
洗濯機前面上下間サーフェスの中心の「アイソカーブを抽出(ExtractIsocurve)」し,抽出したアイソカーブに対して「点を抽出(ExtractPt)」を行い,扱いやすいように「グループ化(Group)」します.
抽出した制御点のグループをブレンド曲線の参考点とするために「配置 > 2点指定(Orient)」で「コピー」を「はい」,「スケール」を「3D」に設定することで作成するサーフェスのレール曲線を作成する部分の各両端にスケールコピーします.
「曲線ブレンド(調整)(BlendCrv)」で各制御点をコピーした点群にスナップすることで曲線を作成します.曲線を作成できたら点群は非表示にするか削除しておきます.
洗濯機側面の平面も暫定的なトリムラインになっているので「境界曲線を複製(DupBorder)」してから「すべてトリム解除(UntrimAll)」を一度して,境界曲線の一部を作成したレール曲線に置き換えて再度「トリム(Trim)」します.
ここの新しいサーフェスは周辺の面構成から判断するに「レールに沿って回転(RailRevolve)」で作成するのが良さそうです.
「レールに沿って回転(RailRevolve)」でのサーフェス作成に必要なデータは「プロファイル曲線」「レール曲線」「回転軸」で,前者2つは既にあり,「回転軸」の方向は Y軸と平行 にするので回転軸の「中心点」1つを準備します.
準備として下の図のように,解析ツールの「半径(Radius)」のコマンド内オプションで「半径カーブを作成(M)=はい」にすると曲率半径に対応した円を作成してくれるのでそれを利用します.そして作成した円の中心点と作成するサーフェスの端点を結んだ線を2つ描画してその交点を「レールに沿って回転(RailRevolve)」の回転軸の1つの「中心点」として軸方向はその中心点から Y方向の1点 を [ Shift ] キーで指定することにします.
準備が整いましたので「レールに沿って回転(RailRevolve)」でサーフェスを作成します.
「輪郭曲線」(プロファイル曲線)と「レール曲線」回転軸の「始点」(交点)と「終点」(交点からY軸と並行方向の1点)を指定します.
「レールに沿って回転」で作成したサーフェスは周辺のサーフェスとの接続および接続条件が確約されたものではないので,作成したサーフェスのエッジで接続先サーフェスがある3辺について接続条件のマッチングを行います.
サーフェスの「マッチング(MatchSrf)」を実行し,コマンド内オプション「複数マッチング(M)」として「m」を設定してから3辺それぞれにおいて「接続させたいエッジ」とその「接続先のサーフェスエッジ」の選択を行います.
( 都合 6回 選択クリック = 3辺 ✕( 接続させるエッジ + 接続先のサーフェスエッジ ) )
サーフェスのマッチングを行ったら他のサーフェスと「結合(Join)」して,まずは「エッジを表示(ShowEdges)」で隙間が無い(=位置連続)ことを確認します.
「マッチング(MatchSrf)」では「曲率連続」までしか合わせないので「曲率変化率連続」については各種「解析」ツールを利用して目視でチェックします.
「ゼブラマッピング(Zebra)」は作成したサーフェスと上下のサーフェスや洗濯機側面の平面ともに縞模様が滑らかにつながっていますので曲率連続から曲率変化率連続ぐらいの連続性であろうと思われます.
ポリサーフェスを「分解(Explode)」して作成したサーフェスだけ「曲率表示オン(CurvatureGraph)」させたのが右の図です.
洗濯機側面の平面(曲率ゼロ)に対して V方向 の曲率が変化率も含めて連続しているように見えます.
右の図は作成したサーフェスに対して「制御点表示オン(PointsOn)」をして洗濯機前方(Rhinoceros での Right ビュー)から見た図です.
洗濯機側面の平面からつながる制御点各4点が洗濯機側面平面と同一平面内にあるので,制御点の配置からも曲率ゼロの平面に曲率変化率連続で接続しているであろうことが見て取れます.
ゼブラマッピングを見ていて今回作成したサーフェスとは別のサーフェスの接続連続性があまり良くない箇所を見つけました.
ゼブラのずれは単に「解析メッシュが粗いことで生じてしまう見かけ上のずれ」の場合もあります. その確認は「ゼブラオプション」内の [ メッシュを調整… ] ボタンから「最大エッジ長さ」を短くしてメッシュを細かくしてゆくことで解消されるような場合は「見かけ上のずれ」と考えられます.
ただ,今回はメッシュを細かくしてもゼブラのずれは解消されませんでした.
筆者の経験では「円弧(Arc)」を分割すると,サーフェスの作成経緯からはゼブラはずれないであろう箇所でゼブラのずれが生じることが多く起きるように感じています.
このフィレットサーフェスはこの後作成するフィレットサーフェスにも影響するのでこの時点で修正しておきます.フィレットサーフェスの U方向 である 3点2次 の円弧を必要な部分だけを 8点7次 の NURBS データに変換してからサーフェスの「マッチング(MatchSrf)」することで曲率変化率接続のサーフェスに修正します.
「マッチング(MatchSrf)」で接続する先のサーフェスの端点からのアイソカーブで「分割(Split)」して必要な部分を残します.
「分割(Split)」を行っただけでは基となるサーフェスの一部となっているだけですので,基となるサーフェスをトリム境界線近くまで縮小するために「トリムサーフェスをシュリンク(ShrinkTrimmedSrf)」を実行します.
そして「次数を変更(ChangeDegree)」で縮小したサーフェスの U方向 の次数を 7 に変更し, V方向 についても指示を問われますがこちらも基と同じ 7 として実行します.これにより U方向 の制御点が次数に合わせて 8 (=次数+1)に変わります.
次数の変更を行ったサーフェスに対して「マッチング(MatchSrf)」を実行して2辺を接続先のサーフェスと曲率連続にします.
「制御点表示オン(PointsOn)」と「曲率表示オン(CurvatureGraph)」により曲率連続にしたサーフェスの曲率接続状況を確認します.
曲率変化率連続は「マッチング(MatchSrf)」では調整されないので,目視確認して修正が必要であれば接続端から4番目の制御点を手動で調整します.
今回は元々のサーフェスが曲率変化率連続接続で作成して変更も主に次数のみの小さなものだったので第4の制御点の調整は必要ありませんでした.
このサーフェスの U方向 の制御点は 8点 なので曲率変化率連続の場合は 4番目の制御点 も 1辺あたり8個 で 両辺で16個 ありますのでざっと各16点について確認します.
このように制御点が多くなると調整作業も多くなってしまうのでサーフェスを作成・修正変更する場合に必要十分な少ない制御点のサーフェスとなるようにすると良いです.
修正前と後のゼブラマッピングをアニメーションで比較してみると改善されているようです.
修正したフィレットサーフェスが良さそうなので Z=350mm でミラーリングして下部のフィレットサーフェスも置き換えておきます.
分析メッシュの消去
Rhinoceros 7 の Mac 版ではあまり気にしたことなかったのですが Windows 版の場合に解析で作成されたメッシュが全て保存されるようになっており 3MB ほどのデータが 6GB ほどのファイルとして保存されて上書き保存も難しい状況に陥ってしまいました.この対策として時々「分析メッシュを消去(ClearAnalysisMeshes)」を行うと再度分析するときには時間がかかりますがファイルサイズを小さくすることができます.
洗濯機前面と側面間に穴として残っているフィレットサーフェスも「レールに沿って回転(RailRevolve)」で作成して「マッチング(MatchSrf)」で修正を行います.
今回の記事はここまでです.
本シリーズ次回の記事は
「Gazebo/MoveIt のための 3D モデリング(9)滑らかなサーフェス – 作成編(その4)」
として,暫定的に隙間を開けてしまっている部分の残り,洗濯機前面・上面・側面が合わさるコーナー部を塞ぐサーフェスの作成例を紹介する予定です.
前回は「Gazebo/MoveIt のための 3D モデリング(6)滑らかなサーフェス – 作成編(その1)」として Rhinoceros のコマンドを利用した滑らかなサーフェスの作成例を紹介しました.
今回は NURBS の次数と制御点を少し意識したサーフェスの作成方法について説明します.
側面視(Rhinoceros の Back ビュー)に線があるのでこれをサーフェスの1辺とします.このサーフェスの1辺に相当する線を「直線(Line)」で描画します.
また洗濯機側面後部の辺を「エッジを複製(DupEdge)」で複製します.
そして「洗濯機側面後部の辺を複製した曲線」の「サーフェスの1辺に相当する線」よりも高い部分を「トリム(Trim)」します.
ブレンド曲線を「曲線ブレンド(調整) (BlendCrv)」で描画します.
ブレンド曲線の描画中にビューを洗濯機正面(Rhinoceros の Right ビュー)に移動して図面上の洗濯機上部角部形状に沿うように制御点の調整をしてからブレンド曲線の描画の確定をします.
結果, 5点4次 の NURBS 曲線になります.
「曲線を押し出し(ExtrudeCrv)」でサーフェスを作成します.
洗濯機上面と側面間のサーフェス作成で使ったプロファイル曲線をコピー移動して洗濯機前面と側面間のサーフェスも作成します.
洗濯機前面は球面サーフェスですので平断面でトリムすると円になりますのでその円の中心を通る Y軸 と平行な軸回りにプロファイル曲線を「回転(Revolve)」します.
洗濯機前面サーフェスをこれまで作成してきた洗濯機ソリッドモデルから「サーフェスを抽出(ExtractSrf)」して新規サーフェスの作成作業を失敗しても元ソリッドに影響がないようにしておき,また洗濯機ソリッドモデルは「非表示」か「ロック」状態にしておきます.
洗濯機前面サーフェスのトリムをします.洗濯機上面と側面間のサーフェスの上端のエッジを「複製(DupEdge)」した曲線で上面視(Top ビュー)でトリムします.
前述のようにここでトリムされた前面サーフェスのエッジは円弧ですので,洗濯機側面視(Rhinoceros の Back ビュー)で Osnap の「中心点」をチェックして「円(Circle)」を描画します.この円弧エッジをクリックすることで中心点を選択してこの円弧の端点をクリックして半径を決定します.
円を描画したら「回転(Revolve)」でサーフェスを作成するプロファイル曲線の配置が容易なのと洗濯機前面付近のみサーフェスを作成したいので,円の中心から水平に直線を描画して円の下半分をトリムします.
円の前端部にサーフェスのプロファイル曲線を配置します.「コピー(Copy)」して「回転(Rotate)」しても良いですし,前回の記事で利用した「3点指定配置(Orient3Pt)」でコピー配置しても良いです.
「回転(Revolve)」を使ってプロファイル曲線を円の中心を通る Y軸 に並行な軸回りに 0° から洗濯機上面より高い位置までサーフェスが作成するよう角度を指定してサーフェスを作成します.
洗濯機前面下部のサーフェスが上部サーフェスを Z=350mm の面で「ミラー(Mirror)」したものであるのと同様に洗濯機前面と側面間のサーフェスもミラー反転するとともに Z=350mm でトリムして「結合(Join)」します.
前回の記事までで作成した洗濯機ソリッドモデルのサーフェスをトリムしたものに置き換えるなどして今回新しく作成したサーフェスと「結合(Join)」したポリサーフェスが右の図です.
結合したポリサーフェスでは「エッジを表示(ShowEdges)」で洗濯機前面・側面・上面の交わる頂点付近に隙間が確認できますが,この箇所は後でフィレットサーフェスを作成して閉じるので,ここでは暫定的に各辺の交点を結んだ直線で洗濯機側面視で両サーフェスをトリムしています.
互いが同じサーフェスに接続する曲率変化率連続のサーフェス同士の場合,サーフェスの交差角度が浅すぎて交わる曲線を Rhinoceros が計算できないことがあります.サーフェスを細分しながら交線を計算させたり,計算できた範囲の交線と大体それらしい曲線を手動で描画したりして閉じたポリサーフェスにすることも可能ですが,今回は最終的には使わないトリムラインですので暫定的にオープンエッジにしています.
前回の記事の四角いボタンのモデリングでは「曲率連続フィレットサーフェス」を作成し,また丸いボタンの角部は「曲率変化率連続曲線」を「回転(Revolve)」して「曲率変化率連続のフィレットサーフェス」を作成しました.
ここでは前回の丸いボタンの方法の応用として「曲率変化率連続曲線」を「曲線を押し出し(ExtrudeCrv)」し,また「制御点を編集した曲率変化率連続曲線」を「回転(Revolve)」して「曲率変化率連続フィレットサーフェス」を作成します.
まずは洗濯機上面と側面コーナー部の間に「曲率変化率連続のフィレットサーフェス」を作成します.先述のコーナー部の大きめのサーフェスと同じように曲率変化率連続のプロファイル曲線を作成して「曲線を押し出し(ExtrudeCrv)」でサーフェスにします.
プロファイル曲線は洗濯機の上面図にフィレットの長辺の線が見られるのでそれを目安にして両端の接続条件「G3(曲率変化率連続)」にて 8点7次 の曲線を描画します.
プロファイル曲線を「曲線を押し出し(ExtrudeCrv)」してフィレットサーフェスを作成します.
次に洗濯機前面と側面コーナー部の間に「曲率変化率連続のフィレットサーフェス」を作成します.これもコーナー部の大きめのサーフェスと同じように曲率変化率連続のプロファイル曲線を作成して「回転(Revolve)」でサーフェスにします.
先程の “洗濯機上面と側面コーナー部の間に「曲率変化率連続のフィレットサーフェス」” のプロファイル曲線をコピー配置します.
洗濯機前面の球面サーフェスに曲率変化率連続で接続するので曲線の修正が必要で,次の図にあるような側面コーナー部形状と洗濯機前面の形状の両方に曲線変化率連続接続するプロファイル曲線にします.
また,修正したプロファイル曲線が元のプロファイル曲線と同じような制御点配置をしていると後の記事で取り上げる両フィレットサーフェス間をつなぐフィレットサーフェスを作成するときに便利なので制御点の Y方向位置 を揃えるようにします.
制御点の Y方向位置 を揃えるための補助線を描画しておきます.
プロファイル曲線の修正の方法は主に2つの方法「再構築的方法」と「修正+調整的方法」があるのではないかと考えています.
8点7次 の曲線のようなブレンド曲線(BlendCrv)の機能に備わっているのと同じ曲線の場合は「再構築的方法」を用いて,曲線の次数+1個よりも多い制御点を持つようなブレンド曲線(BlendCrv)の機能に備わっていない曲線の場合は「修正+調整的方法」を用いると比較的整った曲線ができるのではないかと思います.
「修正+調整的方法」はサーフェスのマッチング修正でも同様のことを3次元的に行います.これは次回の記事で紹介する予定ですので,予習的に今回の2次元上での調整方法を体験しておくのも良いかもしれません.
プロファイル曲線ができてしまえば後は洗濯機の上面と側面のコーナー部サーフェスと同じ軸回りの「回転(Revolve)」と「ミラー(Mirror)」を実行して適切にトリム・結合するとフィレットサーフェス作成は終了です.
ここでも暫定的にオープンエッジを残しています.
一部のサーフェスを曲率分析(CurvatureAnalysis)したときのキャプチャ画像が次の図です.
洗濯機の前面と上面の間の少し大きめのフィレットサーフェスと洗濯機前面の上下のミラー反転されているサーフェス間の大きめのフィレットサーフェスもこれまで紹介してきた方法と同様に曲率変化率連続のサーフェスとして作成しますので,大まかに紹介します.
フィレットを架けるサーフェスを洗濯機のポリサーフェスから抽出して編集します.
右の図は洗濯機両サイドのフィレットエッジの Y座標 で新規作成した2つのフィレットサーフェスをトリムして結合したものです.
洗濯機全体のポリサーフェスのうち洗濯機前面と上面のサーフェスをフィレットを追加したポリサーフェスで置き換えて結合して「エッジを表示(ShowEdges)」したのが右の図です.
まだ暫定的に隙間を開けたままにしています.
さらにレンダリング表示をしてキャプチャした画像が右の図です.
だいぶ洗濯機本体の細かいサーフェスも作成できてきたように思います.
今回の記事はここまでです.
本シリーズ次回の記事は
「Gazebo/MoveIt のための 3D モデリング(8)滑らかなサーフェス – 作成編(その3)」
として,今回は暫定的に隙間を開けてしまっている部分を塞ぐサーフェスの作成をする過程で
について説明する予定です.
前回 「Gazebo/MoveIt のための 3D モデリング(5)滑らかなサーフェス – 知識編」 では 3D モデリングにおける滑らかなサーフェスとは何かについて曲率などの連続性や CAD やサーフェスモデラ内での形状表現のされ方について説明しました.
今回は前回の記事の知識を踏まえて滑らかなサーフェスの作成例について説明します.
滑らかなサーフェスは Gazebo や MoveIt のモデルを作成する場合においてはあまり重要性は高くない… と前回の記事を書いた時点では考えていましたが,今後,Gazebo や MoveIt を走らせる PC の CPU / GPU 性能が向上して細密メッシュモデルを使った精密なシミュレーションへの要求も段々と高くなるかもしれない,とも思いました.
サーフェスはモデル内で大きいものから順に作成していった方が全体のバランスを確認しながら作業を進められて修正作業が必要になる量も少なくなるので良いと思います.
ただ,本記事ではまず,Rhinoceros に備わっているコマンド1つほどであまり制御点とか次数とか細かく意識しなくても作成できる曲率連続の滑らかなサーフェスの例として小さいサーフェスの洗濯機前面上部の操作ボタンのモデリングについて説明します.
洗濯機の前面視( Rhinoceros の Right ビュー )で四角いボタンの大きさを見ると大体 20mm 角でした.
ボタンを1つモデリングして,それを洗濯機前面のサーフェス上に8つコピーして配置します.
左の図は四角いボタンのソリッドモデルの作成過程をアニメーション化した画像です.
各手順を以下に順を追って説明します.
20mm の正方形の線を選択して「テーパで平面曲線を押し出し(ExtrudeCrvTapered)」 を実行し,ドラフト角度 15° の設定で 3mm 押し出します.
四隅を「曲率連続」で丸めるために「エッジをブレンド(BlendEdge)」を実行して四隅のエッジを選択します.
デフォルトでは半径が 1mm となっていてモデリングしたい四隅の半径はもう少し大きいので洗濯機前面図と比較しながら寸法を調整します.
「エッジをブレンド」コマンド内の設定を次のようにして
次にコマンド内設定で「全てを設定(T)」で半径(上記設定の場合はレール間の距離)を 8mm にしてコマンドを確定します.
「エッジをブレンド」コマンド内の「レールタイプ」の設定は「レール間の距離」にした場合が比較的綺麗なフィレットがかかるように思っているので設定しました.フィレットをかけるサーフェスの組み合わせによって他の設定の方が良い場合もあるので各モデリング対象にて適宜選択してください.
今度は指で押す面の周囲にブレンドエッジを作成します.「エッジをブレンド(BlendEdge)」コマンドを実行してコマンド内設定 「次の半径(R)」 を 2mm に設定してから該当するエッジをすべて選択して確定・実行します.
下の図は「エッジのブレンド」でフィレットを作成した四角いボタンの平均曲率解析とゼブラ解析の表示結果です.
これらのブレンドエッジは数ミリと小さいので問題にはあまりなりませんが,大きなサーフェスとしてブレンドエッジを作成する場合は応用的に次のリストの項目を調整編集すると良いでしょう.
四角いボタンのモデルができましたので洗濯機前面のサーフェス上にコピーして配置します.
ボタンの押される方向の軸と洗濯機前面のサーフェスの法線軸を合わせ,かつ上下辺を水平に配置したいので「配置(3点指定)・(Orient3Pt)」を利用してコピーします.「 配置(3点指定)」は下記リストの 3点 を移動元と移動先で指定して配置変換するものです.
四角いボタンの移動先とするために配置するサーフェス上の法線方向と接線方向の直線を各配置点で描画します.まず,YZ 平面上に四角いボタンを配置する中心線を描画して,洗濯機前面視(Rinoceros の Right ビュー)にてそれらをサーフェスに「投影(Project)」します.
「直線(Line)」を実行してコマンド内で「法線(N)」を指定,もしくはメニューから「サーフェス法線(U)」を実行して,サーフェスを選択後,サーフェス上にある投影した中心曲線の交点を選択して法線を描画します.
今回の「配置(3点指定)・(Orient3Pt)」ではスケーリングコピーはしないので長さは適当で大丈夫です.順次各点における法線を描画して合計8軸を準備します.
洗濯機前面の球面サーフェスに食い込む形で四角いボタンを配置したいのでコピー元となる点を 1mm ボタンの高さ方向へ移動しておいてから「配置(3点指定)・(Orient3Pt)」でコピー元,コピー先の各3点を指定してボタンをサーフェス上に配置します.
8つの四角いボタンを洗濯機前面のサーフェス上に配置してゴースト表示とレンダリング表示をしてそれぞれキャプチャしたものが次の2つの画像です.
丸いボタンのように軸回転形状のものは回転形状のプロファイル曲線を作成してそれを軸回りに回転してソリッドモデル(閉じたポリサーフェス)とするのが一番簡単だと思います.
丸いボタンモデルの作成自体は上記四角いボタンのように作成しやすい場所で作成して,軸回りの形状は軸対称で同じなのでそれを今度は「配置(2点指定)・(Orient)」でコピー移動して洗濯機上のサーフェスに配置します.
丸いボタンのモデリングと配置の作業手順をまとめると次のようになります.
回転方向は曲率一定になるので回転プロファイルの曲線さえ滑らかな曲線を作成すれば回転で作成するポリサーフェスも滑らかになります.そこで丸ボタンの回転プロファイルを次の図のように作成するのですが,ボタンの側面と指で押される面に相当する曲線間に滑らかなフィレット曲線を作成します.
ボタンの側面と指で押される面に相当する両曲線に接する円を描画して円の接する点でトリムするとその間の曲線の接続も比較的バランス良く繋がります.円との接点でトリムされた両曲線間に「接続(BlendCrv)」で曲線を作成します.
「接続(BlendCrv)」内の設定で各接続点における接続条件を設定します.連続性を「曲率」もしくは「G3(曲率変化率)」を設定すると各設定に応じた滑らかな曲線が描画されます.各制御点は [ Shift ] キーを押しながらマウスでドラッグすると対象な点も同時に移動してくれるので便利です.曲線形状や曲率変化を見ながら制御点を調整して意図した形状で確定をします.
回転形状のプロファイル曲線が作成できたら「回転(Revolve)」 で曲線を回転したサーフェスを作成します.
1回転分のサーフェスを作成するにはコマンド内で「360度(F)」を指定します.
右の図(ワイヤーフレーム表示)のようなボタン形状のサーフェスが作成されます.
1回転分作成したサーフェスをすべて選択して「結合(Join・Ctrl-J)」してソリッドモデル(閉じたポリサーフェス)にします.
<参考>
Rhinoceros 上では回転形状プロファイル曲線群を先に「結合(Join)」してから「回転(Revolve)」しても同じ形状になるのですが,サーフェスのフィレットのような回り込みの大きい形状と一体化したサーフェスをメッシュ化するときにフィレット形状付近を飛ばして粗いメッシュが作成されてしまうことがあります.フィレット形状部分のサーフェスは一体化したものとせずに別体のものを作成した後「結合(Join)」した方がフィレットサーフェスのエッジがメッシュ境界に反映されるので適切な形状のメッシュ作成のためには良いでしょう.
丸いボタンのソリッドモデルが作成できたら「配置(2点指定)・(Orient)」で洗濯機前面サーフェス上の法線方向に合わせてコピー移動します.先述したように軸回りの形状は軸対称で同じなので位置と方向1つのみの指定の移動変換をします.
四角いボタンと同様に前面サーフェスに少し食い込ませたいので丸いボタンの背面から 1mm 入ったところをコピー原点としてからボタンを押す方向軸上の1点を選択して,コピー先の洗濯機前面サーフェス上の点と法線方向を指定してスケーリングしない設定でコピー移動します.
丸いボタンを洗濯機前面サーフェス上に配置したものを四角いボタンと併せて Perspective ビューにゴースト表示させたものが次の図です.
レンダリング表示にしてキャプチャした画像が次の図です.
洗濯機本体とボタン類のソリッドモデルをブーリアン演算して一体化するのは全ての作業の最後で良いので,他のモデリング作業の邪魔にならないようにとりあえず新しいレイヤー buttons(例)を追加してそこに移動しておきます.
今回の記事はここまでです.
本シリーズ次回の記事は引き続き滑らかなサーフェスの作例紹介で
「Gazebo/MoveIt のための 3D モデリング(7)滑らかなサーフェス – 作成編(その2)」
を予定しています.
前回 「Gazebo/MoveIt のための 3D モデリング(3)基本形状編 – その2」 では洗濯機の基本的な形状で構成されるサーフェスのモデリングを行いました.
今回は発展的な内容として滑らかなサーフェスのモデリングに向けた予備知識的な内容の説明をします.
ロボットモデルはシミュレータ上で使うために結局メッシュ(ポリゴン)にしてしまうのでシミュレーションなどに利用する 3D モデル作成においては 「滑らかなサーフェス」 である必要性は高くありません.
しかし,モデリング対象の中には滑らかなサーフェスになるように設計されている製品もあります.そのような製品のモデリングの際に対象物の形状が円弧のように見えるけど何か違うので合わなくて悩むようなことがあります.そういったときに円弧などの基本的な形状以外のサーフェスもあることを知っていると,それは厳密には合わないものとして割り切って近似的に円弧などのシンプルな形状としてモデリングするということも適切に判断できると思います.
このようなことから,今回の記事はそういった 「滑らかなサーフェス」 について 「知る」 ことを目的としています.
「滑らか」 とはは何であるかというと,曲線やサーフェスの位置や接線方向,曲率,曲率の変化率に連続性があるということです.
上の図は 90° の角度をもつ直線間を曲線で接続させたときの連続性の違いによる曲率(黄色カーブ)のグラフ(CurvatureGraph)を表した画像をアニメーション化したものです.
(クリックで拡大)
各接続条件は次のリストのように連続性の条件が加わってゆくように考えてください.
「R形状」は「接線連続」のうち円弧で接続できる特殊なケースと捉えることができます.
上の図の接続連続性の異なる曲線を 「押し出し」 してサーフェスを作成してレンダリング表示にしたものが次の図です.
影の付き方が曲率や曲率変化率などの連続条件を加えてゆくと段々と滑らかになるのが見て取れるでしょうか?
サーフェスの曲率を解析して色で表した(CurvatureAnalysis)ものが次の図で,青が曲率が小さく,赤が曲率が大きいコンタ図になっています.
連続性の条件が加わるにつれて接続部周辺の曲率の変化が緩やかになっています.
また,サーフェスの滑らかさを評価するために 「ゼブラ(縞模様・Zebra)」 解析もわかりやすいのでよく利用します.
ゼブラ表示によりサーフェスの連続性がより強調されます.縞模様の通り方の滑らかさがサーフェスの接続性の滑らかさを表しています.サーフェスが滑らかに接続しているかどうかを評価したり,接続を滑らかに修正する際に役立ちます.
本シリーズの記事のモデリング対象として作成した洗濯機モデルの曲率とゼブラを表示したものが次の2つの図です.モデル全体で解析すると解析用のメッシュを細かく出来なくなるので,実際には接続性を評価する面に限って解析用メッシュをなるべく細かくして解析をするようにしています.
実際に滑らかなサーフェスをモデリングする場合は,サーフェスが CAD やサーフェスモデラ内部でどのように表現されているかを理解しているとより意図したものに近いサーフェスを作成できるように思います.
Rhinoceros や一般的な CAD などでは曲線やサーフェスは NURBS (Non-Uniform Rational B-Spline/非一様有理Bスプライン) という数学的モデルで表現されています.
NURBS 以外にもサーフェスの 3D 表現モデルとして SubD (Subdivision/細分割曲面) もあります. SubD はコンピュータグラフィックス系の 3D モデリングソフトウェアで利用されていますが,機構設計分野ではあまり使われていませんので本シリーズの記事の対象としません.
NURBS で表現される曲線やサーフェスが何で構成されているかは大まかに述べますと 「制御点」 と 「次数」 です.
上の図は前項目で 90° の角度をもつ直線間を連続性の異なる接続をした曲線がそれぞれどのような 「制御点」 と 「次数」 で表現されているかを示した図をアニメーション化したものです.
NURBS カーブにおいてはその接続における連続性は次のリストにある各数の「制御点」により構成されています.
「次数(degree)」 は大きな数字になるほど曲線が滑らかになります.
上の図は 90° の角度をもつ直線間を接続した 「制御点:8 次数7 の曲線(曲率変化率連続)」 をあえて 「リビルド(Rebuild)」 して 「制御点:8 次数: 3 の曲線」 にして両端点の曲率を接続先の直線に 「マッチング(Match)」 した曲線の曲率の比較です.同じ制御点数でも次数が低いと曲線内で曲率の変化率の連続性が保てなくなってしまいます.
曲線に設定できる 「次数の最大値」 は 「制御点数 – 1」 です.
両端を曲率連続にするための 「制御点が6個」 の曲線の場合は 「次数の最大値は5次」,両端を曲率変化率連続にするための 「制御点が8個」 の場合は設定できる 「次数の最大値は7次」 になります.
制御点が多いとより細かく曲線やサーフェスの形状の制御が出来ますが,編集が大変だったり,データサイズが大きくなってしまうので,最小の制御点と適切な次数で表現したい形状や滑らかさを規定できるのがベストです.
接続条件は曲線の両端で同じである必要はないので,例えば片方の端は 「位置連続」 にして,もう片方の端は 「曲率変化率連続」 にするということも可能です.この場合の必要最小限の制御点は 「位置連続側: 1点」 と 「曲率変化率連続側: 4点」 と合わせて 「5点」 は必要になります.制御点を 「5点」 とした場合の次数の最大値を採って 「4次」 とするのが良いでしょう.
制御点が少なくて意図する形状が得られないようでしたら適宜制御点を多くして,次数もそれに合わせて大きくすると良いですが,次数の方は最大でも 「7次」 で十分なように筆者は考えています.
これまで曲線を例に 「制御点」 と 「次数」 について説明してきましたが,サーフェスは曲線の「制御点」と「次数」を2方向に拡張したものです.
サーフェスは 「U方向」 と 「V方向」 の2方向がある 「四角い布」 をベースに,それを伸縮・曲げを行ったり,トリムしてその一部を使ったりするイメージとして捉えることができます.
円錐体のような三角形のサーフェスもありますが 「四角い布」 の特殊例と捉えることができ,同様にUV方向それぞれの要素があります.
次の図は本シリーズでモデリング対象とするために作成した洗濯機モデルのボディの角部のサーフェスの制御点と曲率のグラフを表示したものです.四方にある接続先のサーフェスとそれぞれ(なるべく)曲率変化率まで連続するように作成しました.そのため次数を 7次 とし,制御点を U方向に 15点,V方向に 8点 を持つサーフェスとしました.
曲線の連続性と同じように,サーフェスの連続性も各辺毎に作成時設定できるサーフェスもありますし,マッチングの際に異なる設定で各辺で行えば可能ですが,四辺の接続先と矛盾がないようにしないと隙間のないサーフェスにならない可能性もある点が曲線に比べて難しいところです.
さて,ロボットシミュレータのための 3D モデリングにおいてはどれほど滑らかなサーフェスを作成したら良いのでしょうか?
本記事冒頭で述べたように,ロボットモデルはシミュレータ上で使うために結局メッシュ(ポリゴン)にしてしまうのでシミュレーションなどに利用する 3D モデル作成においては 「滑らかなサーフェス」 である必要性は高くありません.
曲率連続や曲率変化率連続のサーフェスでモデリングしてメッシュ化してもそのような連続性に近い状態を維持しようとするとメッシュが細かくなりデータが重くなります.ただ,そのロボットシミュレーションをデモンストレーションやプレゼンテーションで綺麗に見せたく,少しメッシュデータが重くても良いような場合はなるべく滑らかなサーフェスをモデリングすることもあるように思います.
また,メッシュのデータ量の他にモデル作成の手間も考えておくべきでしょう.
下のリストにサーフェスの連続性の違いをまとめました.技術的なロボットシミュレーションが目的であれば 接線連続 までとしてモデリング時間を省くのも1つの方法です.大きな面はメッシュで形状が潰れてしまわないので 曲率連続 や 曲率変化率連続 まで考慮したモデルとして,小さな面はメッシュ形状に埋もれてしまうので R形状 や 接線連続 としてメリハリをつけるのも良いでしょう.
Rhinoceros では「曲率連続」までは標準の機能として普通に利用できるのでロボットシミュレータのための 3D モデリングでも用いるのはそんなに手間のかかることではないように思います.
今回の記事はここまでです.
大体どのような滑らかさのサーフェスの種類があって,CAD やサーフェスモデラでそれを作成するために必要な条件や作成の手間のイメージが伝わっていると良いのですが.
本シリーズ次回の記事は
「Gazebo/MoveIt のための 3D モデリング(6)滑らかなサーフェス – 作成編」
を予定しています.
前回 「Gazebo/MoveIt のための 3D モデリング(3)基本形状編 – その1」 で Box 形状や球面で洗濯機の大きな面のモデリングを行いました.
今回はその続きで,洗濯機の背面や底部のモデリングを行います.
ボディ背面の突出形状部の最後部から 40mm の幅がありますので,洗濯機の主要形状部をその分トリムします.(前回 Box 形状の Scale1D を前後方向に行わずにガムボール移動などで World 座標系で X の正方向に 40mm 移動した場合はこの手順は不要)
洗濯機の側面視で最背部から垂直な直線を描画して,前方向に 40mm 移動させ,この直線を使ってボディをトリム(Trim)します.
Perspective ビューでトリムされたボディのエッジ分析(ShowEdges)をすると次の左の図のようになります.
このような開口部エッジが同一平面内にあって閉曲線になっている場合は平面で塞ぐ 「キャップ(Cap)」 を実行できます.
次は背部に突出している形状を作成します.
背部の台形状の輪郭を描画します.上面視(Top ビュー)で座標 (-320,0) から水平の直線(Line)を後部に向かって描画して,その直線からオフセット(Offset)で オプション Both(B) で両サイドへのオフセット線をオフセット量 260[mm] = 520mm/2 で描画します.メインボディ最後部のエッジと 260mm オフセットした両直線の交点を中心に回転(Rotate)で 45°,-45° を指定して回転させて上面図画像の輪郭に合うことを確認します.
また直線(Line)を座標 (-360,0) から「両方向(B)」を指定して洗濯機の幅方向に描画します.
描画した3つの直線の台形での不要部分を互いにトリムします.
Perspective ビューに移って台形の開いている部分を直線で接続して結合(Join)して曲線を閉じます.閉じた曲線を洗濯機の高さ方向(Z方向)に +90mm ガムボールで移動させます.
背面部の基礎となる 3D 形状をソリッドの「垂直に押し出し」で作成します.とりあえず上面高さまで押し出しします.
洗濯機の側面視(Back ビュー)にて洗濯機背部形状の上端に相当する斜めの直線を描画して先程「押し出し」したソリッドを トリム(Trim) して キャップ(Cap) で閉じます.
三面図から読み取れる形状としてはここまでなのですが,洗濯機背部は角部や隅部に 「R形状」 や 「フィレット」 と言われる形状がつけられていることが多いです.
今回は三面図から 「R形状」 の寸法は読み取れないので,それを想像して寸法を決めて 「ロフトサーフェス(Loft)」 で作成します.
ロフトサーフェスは曲線と曲線の間にサーフェスを作ります.ロフトサーフェスの基となる曲線を 「フィレット(Fillet)」 で描画します.
フィレットの半径は最後部の平面上の方に 40mm メインボディとつながる平面上の方に 80mm のフィレットをかけるとバランスの良さそうなロフトサーフェスになるかと思います.
洗濯機背部上方のコーナー部にロフトでフィレットサーフェスが作成できたら ミラー(Mirror) でX軸対称に反転コピーします.そしてミラーリングして左右2つになったフィレットで洗濯機背部のソリッドモデルを トリム(Trim) します.
2つのフィレットとそれらでトリムされた背部ポリサーフェスを 結合(Join) すると1つのソリッド(閉じたポリサーフェス)になります.
洗濯機のメインのボディと背部の2つのソリッドモデルは互いに接し合っているので2つのソリッドの 「和の演算(BooleanUnion)」 を行って1つのソリッドモデルにします.
1つのソリッドになるので,くどいようですが ShowEdges で 「閉じたポリサーフェス(=ソリッド)」 であることを都度確認すると良いでしょう.
Gazebo や MoveIt のモデルとしては洗濯機底部はロボットとインタラクションすることはあまりないと思いますので大体の雰囲気をモデリングできれば十分です.
洗濯機の足部は三面図だけではなくカタログ画像からも少し形状が分かるので三面図と併せて参考にしてモデリングします.
カタログ画像や3面図から,足部はテーパのかかった円錐台形状であろうと思われます.
側面視や前面視からそれぞれの足の中心座標を推定し,下面と上面の直径はそれぞれ 50[mm] と 54[mm] ぐらいと当たりをつけて円を描画してロフトとキャップを組み合わせてソリッドモデルを作成します.
洗濯機底部の足以外のサーフェスのモデリングの大まかな様子は次の GIF アニメーションのような感じです.モデリングの履歴(ヒストリー)を使わないモデリングなので作成手順はやり易い順番で大丈夫です.またサーフェスの作成方法も1通りしかないのではなく,例えば 「ロフト (Loft)」 でフィレット形状を作成する代わりに 「サーフェス > フィレット(FilletSrf)」 や 「エッジをフィレット(FilletEdge)」 ,「回転(Revolve)」 を使ったりすることもできます.
これまで取り上げていない機能で利用したのは 「曲線を押し出し(ExtrudeCrv)」 と 「円柱(Cylinder)」 の機能です.
今回は洗濯機ボディの背部や底部のモデリング方法を紹介して,次のモデルとなり本記事のゴールに到着しました.
基本形状編はひとまず今回の記事までです.
本シリーズ次回の記事は 「Gazebo/MoveIt のための 3D モデリング(5) 滑らかなサーフェス – 知識編」 を予定しています.
前回の Gazebo/MoveIt のための 3D モデリング(2)準備編 で右の図のように三面図を空間上に配置してモデリングの準備を行いました.
今回から実際のモデリング方法の紹介を行います.今回のゴールは基本的な形状で構成された次の図の状態です.
直方体と球面でモデリングします.
レイヤ03 を model という名前にしてこのレイヤ内でモデルを作成します.
レイヤ model をダブルクリックするとチェックマークが model レイヤに付いて編集対象のレイヤになります.
三面図を見るとボディの上面や側面,1段上がった底面,背面から1つ前方の面は平面で構成されているようです.(筆者が基のモデルを作成しているので自作自演なのですが…)
直方体を描画してそれらのサーフェスとします.
まず,準備で描画した outline のボックスを利用して直方体を描画するために Osnap の「端点」のチェックを入れておきます.
直方体は Box コマンドかメニューから ソリッド(O) > 直方体(B) > 2コーナー,高さ指定(C) を選択して描画します.
outline の底面の対角点の2点と高さとして上面のいずれかの角の点を順次クリックすると右の図のように直方体が描画できます.
次に,1方向のみのスケーリング Scale1D( 変形(T) > スケール(S) > 1Dスケール(1) )を使ってボディの底面の位置と奥行方向の2つの寸法調整をします.
底面の位置は Scale1D で上面位置を基準として変形を行います.
奥行方向の寸法調整は後で前面のサーフェスを作成してそれでトリムをしたいので少し前に出しておきます.もしくは背面の突出している部分の基となる面がが 40mm 分前に来るのでガムボール移動で X方向 に 40mm 移動するようにしても大丈夫です.
洗濯機前面の主なサーフェスは球面ぽい感じがします.(自作自演ですが…)
まずは球面の半径を推定します.
洗濯機の側面視,Rhinoceros での Back ビューにて外形カーブに沿って3点指定の円を描画しておおよその半径を見てみます.
3点指定の円はメニューからは 曲線(C) > 円(C) > 3点指定(3) で実行し,コマンドでは Circle を実行してから 3点(O) を指定します.アイコンからは円形状から3点付いた円を選択します.
洗濯機前面の側面視への投影輪郭線上の3点を指定して円を描画します.
次に描画した円の半径を調べます.メニューからは 解析(A) > 半径(R) を選択し,コマンドの場合は Radius を入力して描画した円を選択します.その結果,先程描画した円の半径は「5182.7590331 ミリメートル」と解析されました.
切りの良い数字で半径は 5000mm ぐらいかな?と当たりをつけて球を描画してみます.
描画した円を削除します.
先程と同じメニュー・コマンドの「3点指定の円」を利用しますが今度は投影輪郭線上の2点と半径 5000mm を指定して描画します.
描画した半径 5000mm の円の中心から半径 5000mm の球を作成します.Osnap の「中心点」にチェックを入れます.球を作成するにはコマンドでは Sphere,メニューからは ソリッド(S) > 球(S)です.球の中心に円の中心を選択して半径 5000mm を指定して球を作成します.
このように側面視では半径 5000mm の球であるとみなしましたが,他の投影図で見ても洗濯機前面のサーフェスとしてこの半径 5000mm の球面が妥当であるか? を見てみます.
上面視(Rhinoceros の Top ビュー)から見ても半径 5000mm から作られる形状が三面図と整合するかを確認します.
作成した球を上面の高さでトリムします.上面高さで水平な直線を描画してそれを用いてトリムします.
側面視で Line コマンドかメニュー 曲線(C) > 直線(L) > 線 もしくはアイコン選択で直線描画を開始し,Osnap の「端点」にチェックが入っている状態で上面の1つの頂点を選択して Shift キーを押しながら水平に直線を描画します.
トリムに用いる直線を選択した状態でキーボードショートカット Ctrl+T を選択するとトリムコマンドが開始されますのでトリム対象として球のサーフェスを選択します.この時トリム設定として ( 切断線を延長(E)=はい 仮想交差(A)=はい ) として実行します.
次の図は洗濯機の上面高さでトリムした球面サーフェスの上端エッジの円とその上端エッジを曲線として複製( DupEdge )してその曲線を洗濯機の上面図上の曲線とほぼ重なる場所にオフセット( Offset )させた比較です.
(画像クリックで拡大) オフセットさせた曲線は洗濯機上面図の曲線と比べて少し半径の大きい円のようですので,実際の洗濯機の前面の球面の半径は 5000mm よりも小さい可能性が高いです.
洗濯機前面を球面とした場合は 5000mm では少し半径が大きいようですので,半径 4000mm の球面として半径 5000mm で行ったのと同じように描画して評価する手順を再び行います.
洗濯機前面サーフェスを半径 4000mm の球面とした場合の洗濯機上面図とトリムされた球面エッジを比較したのが次の図です.
画像では「上端エッジからオフセットした曲線(円)」が黄色になっているので少し見づらいかもしれませんが洗濯機の上面図内の曲線と一致しているように見えます.(画像クリックで拡大) このことより洗濯機前面のサーフェスを半径 4000mm の球面としたのはおおよそ妥当だと判断しました.
Perspective ビューで少し広めにモデリング空間を表示させたのが次の図です.ボックスと上面高さでトリムされた球面が見えています.
側面視で描画した円は オブジェクトを非表示( メニュー: 編集(E) > 表示(V) > 非表示(H) / コマンド: Hide ) にしてしまっても良いかもしれません.
球面とボックスを互いにトリムして洗濯機のボディ形状に近づけます.
互いに完全に交差した球面サーフェスと Box サーフェスを互いにトリムしたので両者間に隙間はないはずです.ただ,これらは結合(Join)して一体化していないので,状態としては隙間なく互いにただ並べられている状態,英語では Watertight(水密)などと言われる状態です.
それを確認するために解析ツールで「エッジを表示」してみます.
エッジ分析の小ウィンドウが表示されたらその中の 表示 – オープンエッジ(N) を選択します.
トリムされた球面サーフェスと Box サーフェスの境界部分が明るい紫からピンクのような色で表示されると思います.
トリムした球面サーフェスと Box サーフェスを結合(Join)してオブジェクトとして1体化ます.両方のサーフェスを選択してから結合を実行します.
結合したら再び「エッジを表示」を実行してオープンエッジがないかを確認します.
オープンエッジがなかったら次のようなエッジ分析の結果が出るかと思います.
「合計??個のエッジ.オープンエッジ,非多様体エッジはありません.」
これは 「閉じたポリサーフェス」 や 「ソリッド」 と呼ばれるモデルの状態を意味します.
今後「ソリッドモデル」や「閉じたポリサーフェス」であるはずのモデルを作った場合は都度確認するようにしましょう.都度確認しないで何かのはずみで僅かな隙間が残っているまま作業を進めてしまうと後々にサーフェスが閉じなくなり多くの作業をやり直さないとならなくなってしまうことがあります.
次に前面下部のサーフェスも似たような面であろうと目論んで,側面視(Rhinoceros の Back ビュー)で半径 4000mm の円を描画してみると,大体 Z=350mm ぐらいの平面で上下反転しているように見えます.
球面サーフェスを反転コピーするために先程結合したソリッド(閉じたポリサーフェス)モデルから 「サーフェスを抽出」 して球面サーフェスを分離します.
球面サーフェスを反転コピーするために側面視(Rhinoceros の Back ビュー)で直線(Line)を座標 (0,350) から水平に引きます.
前面の球面サーフェスを選択してミラー変形で反転コピーします.
座標 (0,350) から水平に引いた線の両端を順に選択して反転させます.
座標 (0,350) から水平に引いた線で不要になる球面サーフェスをトリムし,またミラーコピーした球面サーフェスの Box サーフェスからはみ出る部分や Box サーフェスのはみ出る部分を球面サーフェスでトリムします.
これらのトリムされた上下の球面サーフェスと Box サーフェスを結合(Join)すると次のようなソリッド(閉じたポリサーフェス)モデルになり,記事の冒頭で述べたゴールに辿り着きました.
次回は, 「3D モデリング(4)基本形状編 – その2」 として洗濯機の背面や底部の形状のモデリングを説明する予定です.
今回の記事のゴールは右の図のようにモデリングに必要な情報を Rhinoceros 上に表示することです.
筆者はこの作業を「召喚の儀式」と勝手に呼んでいます.召喚の儀式を行っても勝手にモデルが湧き出てくるわけではないのですが,このようにすることで効率的にモデリングができると考えています.
作業の流れは次のようになっています.
まず,カタログの PDF ファイルから寸法図の各投影を画像として切り取ります.カタログが紙面の場合はスキャナで画像として取り込むと良いでしょう.
本例では右の図をクリックするとサンプルカタログ画像が表示されるのでそれを使ってください.また同じサンプルカタログの PDF ファイルは下記リンク先にあります.
正面図 | 左側面図 | 上面図 |
Windows の場合は一例として次のように PDF ファイルから投影図を画像として保存します.
Mac の場合は同様のことを次のように行います.
各投影図の画像を Rhinoceros の空間上に配置する前に画像のサイズ調整やモデリングしながら大きさの確認をするなどの目的のためモデリング対象の外形寸法を反映した線画(ワイヤーフレーム)の直方体を描画します.
Rhinoceros を起動します.起動時に表示されるテンプレートの Small Millimeters か Large Millimeters を開きます.
Rhinoceros の設定変更は必須ではないですが,洗濯機のような大きさの対象物の場合は次のようにしておくのをお奨めします.設定変更はメニューバーの ファイル(F) → プロパティ(R)… を選択して小ウィンドウ「ドキュメントのプロパティ」内で行います.
それでは Rhinoceros 空間内にモデルの外形寸法に対応したワイヤーフレームボックスを描画します.
分かりやすいように「レイヤ 01」の名前を本記事では「outline」に変更します.レイヤ名は何でも良いです.
そして outline レイヤ名の少し右をクリックしてチェックマークを入れて編集対象にします.
カタログの3面図を見ると洗濯機のボディの高さが 1050 [mm],主な幅が 640 [mm],奥行きが 720 [mm] とあります.
またロボットの座標構成は一般的には次のようになっています.
なお,Rhinoceros はどのような分野の座標系を採用しているのか分かりませんがビューの名前とロボットの一般的な座標構成による前後・左右が異なっているので,それはそれとしてビューの名前は気にしないこととします.
このように製品の外形寸法やロボットの一般的な座標構成をふまえて,最初に XY 平面上に原点を重心とする X方向 740 [mm] Y方向 640 [mm] の長方形を描きます.
次に XY 平面上に描いた長方形を洗濯機の上面に相当する上方に 1050 [mm] コピー移動させます.このような単純な移動は Rhinoceros の「ガムボール」を利用すると良いでしょう.Rhinoceros ウィンドウ内の下の少し右の方に「ガムボール」ボタンがあるのでクリックして有効にします.
ガムボールを用いた移動は Ctrl や Alt キーを組み合わせることで次のように働きます.
また,ガムボール以外のコピー移動の方法としてメニューバーの 変形(T) → コピー(C) もしくはコピーのコマンド入力「Copy」もあります.この場合は移動する始点と終点の座標を順次入力してコピー移動させます.
あとは2つの長方形の各頂点間に直線を描画して線で構成された直方体にします.
次の図のようにオブジェクトスナップ Osnap をオンにして端点にスナップするようにチェックを入れると描画時に端点にスナップして正確に描画することができます.
直線コマンドはメニューバーからは 曲線(C) → 直線(L) → 線 で,コマンド入力では Line で実行できます.
(画像をクリックすると大きな画像として表示されます.)
線で構成された直方体が描画できたらそれをグループ化しておきます.全体を選択してメニューバーからは 編集(E) → グループ(G) → グループ化(G) で,コマンド入力では Group で,キーボードショートカットでは CtrL + G でグループ化できます.
後で各投影図画像を配置する時に補助線を描き加えますが,とりあえず outline レイヤーは編集終了ということでロックします.
現在編集中のレイヤはロックできないので「レイヤ 02」を次の各投影図画像を貼り付けるためのレイヤーとして名前を「drawings」などに変更して,drawings レイヤのチェックマーク列をクリックして編集レイヤを変更します.その後で outline レイヤの鍵マークをクリックして南京錠が掛かったアイコンに変更するとレイヤーがロックされます.
本記事冒頭の「召喚の儀式」の図で示したように Rhinoceros では空間上に画像ファイルを平面として配置することができます.
まず,正面の投影図の画像を配置してみます.
Rhinoceros のビュー名の設定は一般的なロボット座標系の投影面名と異なるので,ロボット座標系から考えると「正面図」は YZ平面(とその平行面)なので,Rhinoceros では Right ビューに相当します. ビューの下にある Right タブを選択したり,Perspective などのビュー左上のビュー名をダブルクリックするなどして4ビュー画面にしてからビュー名 Right をダブルクリックして Right ビュー1つの表示にします.
ビュー左上のビュー名 Right をダブルクリックして全体に表示します.
画像はメニューバーから サーフェス(S) → 平面(P) → ピクチャー(E) を選択すると「ビッマップを開く」子ウィンドウが開くので正面図の画像ファイルを選択して開きます.
すると「ピクチャーの1つ目のコーナー」を指定するよう言われるので,位置やスケールは後から outline レイヤの直方体に合わせるので,ここでは適当にクリックして指定します.次に「もう一方のコーナーまたは長さ」を指定するように言われるので,Ctrl キーを押しながらマウスを動かすと画像の縦横比を保持したままもう一方の頂点の座標が変化しますのでここでも先ずは適当にクリックしてピクチャーを配置します.
画像の位置とスケールを合わせてゆきます.
まずはコーナー位置を合わせます.正面図のピクチャオブジェクトを選択してオブジェクトを直接ドラッグしたりガムボールを使って移動させ,右の図の例では洗濯機の正面図の右下コーナーを外形の直方体の角に合わせています.画像ファイルなので線はある程度ドット幅を持っていると思いますが,outline レイヤの外形の直方体の線と画像上の線の大体の中心が合うようにします.
次は画像のスケールを outline レイヤの外形の直方体の大きさに合わせます.スケールはまず縦横2方向同時スケールの操作をします.縦横どちらで合わせても良いですが寸法が長い方が相対的に精度がでやすいので縦方向で合わせます.メニューバーからは 変形(T) → スケール(S) → 2Dスケール(2) ,コマンドでは Scale2D で実行します.
画像ファイルはドット絵(ラスターデータ)であることや,カタログの印刷とスキャンや PDF 化の過程で図形としての縦横比が必ずしも保たれているわけではありません.そのため先ほど 2D スケールを行って縦方向のスケールは合ったものの横方向を確認してみると少しずれているようなことが結構あります.その場合は1方向のみの Scale1D コマンド(メニューバーなどからも選択可能)で横方向のみスケール調整します.
このように位置とスケールを合わせるのですが1回でバシッと綺麗に決まらないことがままあるので何回か「位置」「スケール」を繰り返して調整します.
配置した正面図ピクチャーをビューを Perspective に変更して見てみると,おそらく YZ 平面上にあると思います.この場所だとこれから 3D モデルを作るスペースのド真ん中にあり邪魔になるので X 軸方向に -1500[mm] ぐらい移動させておきます.
あとは同様にして「左側面図」と「上面図」の画像を Rhinoceros 上のピクチャとして配置します.
「左側面図」は一般的なロボット座標系では XZ平面 を Y軸 のプラス方向からマイナス方向へ見ることになります.この視点は Rhinoceros の設定では Back ビューに相当します.Rhinoceros のデフォルトでは Front ビューが最初のセット内に設定されていると思いますのでこれを Back ビューにします.ビュー内左上のビュー名右隣にある ▼(逆三角形)マーク → ビューの設定(V) → Back(A) で変更します.
今回の作例用に用意した「左側面図」には最も外側の寸法だけではなく洗濯機の設置検討に参考にする寸法を入れてあります.外寸のスケール調整をした後に寸法の数値から拾った線を outline レイヤーに加えて寸法補助線と重なるかを見て,スケールが合っているか?,位置が合っているか?など確認できます.今回は洗濯機の設置脚が付いている下部ボディの前端の寸法の数値を拾うと最後部から前方に 605[mm] ( = 550 + 55 )の位置だということが分かりますのでそこに線を引き該当する寸法補助線と重なるかを確認しました.
最初の各投影図をレイアウトする時点で間違ったまま進めてしまうとているとそのあとモデリングしたものが使えないものになってしまう可能性があるので注意してください.
他のヒストリータイプの CAD では遡って修正することも可能ですが,時として修正可能なパラメータから外れてモデルが成立しなくなる可能性も無きにしもあらずなのでまず最初の段階で寸法等確認しながら先に進むことをお薦めします.
Rhinoceros ではオブジェクトの位置や距離を確認するにはメニューバーの 解析(A) → 点(P) や 距離(D) で確認しながら進めると良いでしょう.
「上面図」は Rhinoceros でも Top ビューですので X方向,Y方向 を間違わずに配置すれば問題ないと思います.
さてこれで本記事の最初に述べました「召喚の儀式」が整いました.
おそらく本記事の読者に召喚術を使える「魔術師」や「陰陽師」の方はそう多くはないと思いますので,次回の記事からは今回準備した「召喚の儀式」の情報を基に地道に Rhinoceros 上で 3D モデリングを行う方法をご紹介したいと思います.
<追記:つづきの記事>
ROS で Gazebo や MoveIt を利用してシミュレーションや動作計画を行うときに既存のモデルも多くあり重宝しますが,それだけでなくて実際の製品の形状でシミュレートしたいと思う場面もあるかと思います.
モデリング対象物の実物があれば 3D スキャンすることもあるでしょうがメッシュを整える手間があったり,実物がない場合もあります.
そこで本シリーズでは複数回の記事に分けてカタログにある図面から 3D モデリングを行って Gazebo / MoveIt で利用できるようにするにはどのようにするのかの例をご紹介します.
モデリング作業のゴールとなる Gazebo と MoveIt のモデルに必要なデータを次の表にまとめます.
Gazebo モデル | MoveIt モデル | |
---|---|---|
モデルファイル | URDF or SDF ファイル | URDF ファイル |
チュートリアル |
最終的に必要になる URDF ファイルや SDF ファイルは XML データのファイルですのでテキストエディタなどで編集します.
URDF と SDF に内包するのに利用可能な 3D モデルデータを次の表に示します.
SDF ファイル | URDF ファイル | |
---|---|---|
モデルファイル | STL ファイル | Collada or STL ファイル |
表示用メッシュ |
|
|
干渉用メッシュ |
|
|
それぞれ画面表示用とロボットリンク干渉チェック用のデータは別々に設定されるので必要に応じてメッシュの粗密を調整します.SDF ファイルの表示用メッシュは Collada (*.dae) フォーマットも使えるのですが色情報が表示に反映されないのでここでは色ごとに分けた STL フォーマットファイルを作ります.
全体の作業と記事の流れは次のようになります.
今回のモデリング例の対象物は多くの製品でカタログに寸法図が掲載されている洗濯機としました.
意匠権や著作権などの侵害がないように本記事の作例用に予めドラム式洗濯機モデルを作成してそれから寸法図を含む模擬的なカタログの PDF ファイルを作成しました.
このカタログの図面を元にレンダリング図も参考にしながらモデリングします.本記事筆者が対象モデルを作りカタログ化して再びモデリングするということで自作自演になってしまいますが,モデリングの流れや方法をお伝えするためと思ってご容赦ください.
本シリーズの記事では 3D モデル作成ソフトウェアは Rhinoceros 7 を用いています.Rhinoceros は CAD ソフトウェアの1つと言えますが,どちらかと言うとサーフェスモデラに近いと思います.各機能自体は読者が使っている CAD と共通点があると思いますのでコマンド等それぞれ置き換えて読んでいただけるとありがたいです.
参考のため比較的安いもしくは無料で入門的にも利用可能な CAD を次の表に示します.
Rhinoceros 7 | Fusion 360 | FreeCAD | |
---|---|---|---|
URL | https://www.rhino3d.co.jp/ | https://www.autodesk.co.jp/products/fusion-360/ | https://www.freecadweb.org/ |
商業利用 | 158,400円 | 61,600円/年 | 無料 |
教育利用 | 39,600円 | 1年間無償 | 無料 |
モデリング | 非パラメトリック*注 | パラメトリック | パラメトリック |
モデリングでは下記リストのような色々なサーフェス要素の作成方法を説明する予定です.
このうち曲率連続や曲率変化率連続のサーフェスは Gazebo や MoveIt で利用する場合は結局メッシュデータ( STLメッシュ / Collada も内部ではメッシュ )になってしまうので必須ではないですが参考までに紹介します.
本シリーズ,次回はモデリングの準備編です.
トランジスタ技術 2020年9月号( https://toragi.cqpub.co.jp/tabid/918/Default.aspx )の ROS 入門の記事を執筆しましたのでご紹介します.
東京オープンソースロボティクス協会は次の章を執筆しました.
ROS(ロス/Robot Operating System)の学習は実際にロボットがなくてもロボットのシミュレータが入手できるのでネットワークにつながるパソコンが1台あればできますので結構自習に向いています.この記事では ROS の学習を始める,進めるにあたり必要な情報がある Web へのリンクを中心に紹介します.
大まかに言うと次のインストールを行えば ROS の学習をスタートすることができます.
ROS と Ubuntu Linux のバージョンは後述する ROS 学習のチュートリアルが現時点では ROS Kinetic というバージョンを基本としているので下記の組み合わせをお勧めします.
ROS Melodic は ROS Kinetic と基本的な操作のほとんどは変わらないので ROS Kinetic で学習してから ROS Melodic に移行しても難なく可能です.
パソコンはどのようなものを使えば良いのか?については下記記事を参考にしてください.
最新高性能パソコンよりも数年型落ちや廉価の機種のほうが Ubuntu Linux をインストールしやすい傾向にあるように思います.
下記リンク先に各 ROS のバージョンにおけるインストール手順が書かれています.
また,Ubuntu のバージョンと ROS のバージョンには1対1の対応関係があるので組み合わせを気をつける必要があります.
各チュートリアルを進めるとそれらの中で ROS シミュレータなどのインストールも行います.
ROS の入門には TORK MoveIt チュートリアルをお薦めします.MoveIt は ROS のマニピュレーションロボット動作計画ソフトウェアです.このチュートリアルでは数種のロボットの ROS シミュレータのインストールや基本的な操作,プログラムでのロボット操作を学習することができます.TORK MoveIt チュートリアルではプログラミング言語に Python を用いていますが,プログラミングの経験がほとんどない人にもプログラムによるロボット操作の体験と学習ができるように構成しています.
ROS を初めて使う方に TORK MoveIt チュートリアルを学習したときのレポートも下記の記事に書いてもらっています.学習過程でいろいろと疑問をもった点などの体験を書いてもらいましたので参考にしてみてください.
より発展的な ROS プログラミングを学習したい場合は ROS-Industrial トレーニングを行ってみるのも良いでしょう.この教材で取り上げられているプログラミング言語は主に C++ と Python です.C++ によるロボット制御や画像処理,3D ポイントクラウド処理などとそれらの組み合わせのプログラムの学習ができます.
ROS Discourse やチュートリアル,パッケージの GitHub Issues に質問を投稿してみてください.
1台のパソコンだけ,シミュレータだけでなく入門的な実機マニピュレータを利用してみたいと思った方は入門的なマニピュレーションロボット2例の導入検証を行った記事を参考にしてみてください.
ROS やその MoveIt の学習を始めたい,もしくは Gazebo などのシミュレータでの実行はできたので,実際のロボットも動かしてみたい!と思っている方もいらっしゃるのではないでしょうか.
また,Ubuntu ROS をインストールする PC はどのようなものにしたら良いのか?というご質問と同じように,マニピュレータを ROS で動かす学習をしたいが実際にどのようなロボットを導入したら良いのか?といったご質問を TORK にいただくことがあります.
そこで,価格なども含めて比較的入手性の良さそうな次の2種のマニピュレーションロボットを購入して ROS や MoveIt で利用した場合について調査・検証しました.
uArm Swift Pro | Open Manipulator X | |
販売価格 | ¥99,000.- | ¥272,800.- |
納期 | 数日 | 2〜7週間 |
腕部自由度 | 3 DOF | 4 DOF |
PC 接続 | micro USB-B | micro USB-B |
外観 |
GitHub ページ SwiftAndProForROS https://github.com/uArm-Developer/RosForSwiftAndSwiftPro のトップページにある README.md に従ってダウンロードとインストールを行いました.
まず前提としてロボットに接続する側の PC に Ubuntu と ROS がインストールされている必要があります.ROS のインストールは下記サイトを参考に行うことができます.
README.md にはおおまかにしか書いていないように思えたので,補足的に書き加えると次のようになります.
$ sudo apt-get install git ros-kinetic-serial $ mkdir -p ~/catkin_ws/src #既にワークスペースがあるならそちらを使ってもOK $ cd ~/catkin_ws/src $ catkin_init_workspace $ git clone https://github.com/uArm-Developer/RosForSwiftAndSwiftPro.git $ cd ~/catkin_ws $ rosdep install --from-paths src --ignore-src -r -y $ catkin_make $ source ~/catkin_ws/devel/setup.bash
ここでは Ubuntu 16.04 + ROS kinetic のケースを書いていますが Ubuntu 18.04 + ROS melodic でも下記の kinetic のところを melodic にしてインストール・実行できました.
「 2. Set up enviroment 」は手順通りに ROS 環境がターミナルに反映されるための設定を行いました.ROS melodic の場合もインストールに関するコマンドの kinetic
を melodic
に変更することでインストールでき,今回の記事の範囲の動作を確認しました.
eマニュアルが充実しているので下記 URL の手順に沿ってインストール作業を進めました.
こちらも ROS melodic の場合もインストールに関するコマンドの kinetic を melodic に変更することでインストールでき,今回の記事の範囲の動作を確認しています.
eマニュアルの手順に従い,Arduino IDE でポートの設定なども行いました.
uArm Swift Pro と Open Manipulator X を ROS の MoveIt の GUI(グラフィカル・ユーザ・インタフェース)から動かした手順を中心に報告します.
まずは uArm Swift Pro の電源投入と PC との接続を行います.
次にターミナルを2つ開いて,1つ目のターミナルでは uArm Swift Pro への接続と制御を実行します.
$ sudo chmod 666 /dev/ttyACM0 $ roslaunch swiftpro pro_control.launch
2つ目のターミナルでは MoveIt を実行します.
$ roslaunch pro_moveit_config demo.launch
腕自由度が 3 自由度しかないため MoveIt 上の空間の 6 自由度(XYZ, RPY)でインタラクティブマーカを動かそうとすると上手く動かせません.”Allow Approx IK Solutions” のチェックを入れるとロボットの自由度・可動範囲内でインタラクティブマーカの厳密ではないものの最適解が計算されるので比較的楽にインタラクティブマーカを動かすことができます.
インタラクティブマーカを動かして目標姿勢を定めてから [ Plan and Execute ] ボタンを押します.
必須ではないですが MoveIt の表示上調整すると良かった項目を挙げます.
問題もありました.MoveIt に表示される uArm Swift Pro のロボットモデルがパラレルリンク分の運動学計算がされていないような状態と正常に計算されたような状態を交互に繰り返していました.この件は GitHub Issue – Missing robot joints としても報告されているようですが改善はされていないようです.
MoveIt やコントローラを終了するには各ターミナルで Ctrl+C を入力することで終了します.
uArm Swift Pro は動作時の剛性感が高いように思いました.ステッピングモータでガッチリと固定されているような印象を受けました.ただ MoveIt から制御した動作はカタカタカタとしていました.これはロボット側のファームウェアを更新したらカタカタの度合いが少し細かくなりましたがまだ残っています.uArm Swift Pro を uArm Studio から動かすと動きがスムーズだったので ROS や MoveIt と uArm Swift Pro のインタフェース部分に詰めきれていない部分があるように感じました.
まずは Gazebo シミュレータが用意されているので Gazebo 上の Open Manipulator X を MoveIt から動かしてみました.
ターミナルを2つ開いて,1つ目のターミナルでは Open Manipulator X の Gazebo シミュレータを起動します.
$ roslaunch open_manipulator_gazebo open_manipulator_gazebo.launch
正常に実行されると次の画像のような Gazebo のウィンドウが表示されます.ここで一番下段の部分にある ▶ ボタンをクリックしてシミュレータを走らせます.
次にコントローラと MoveIt を起動します.
$ roslaunch open_manipulator_controller open_manipulator_controller.launch use_moveit:=true use_platform:=false
空間6自由度に対して腕部自由度が4自由度と少ないので Allow Approx IK Solutions のチェックを入れると楽にインタラクティブマーカを動かすことができます.
インタラクティブマーカを動かして目標姿勢を定めてから [ Plan and Execute ] ボタンを押します.
次に Open Manipulator X の実機ロボットを MoveIt GUI から動かしてみました.
今回は Ubuntu PC と Open Manipulator X を OpenCR 回路を経由して接続しました.接続方法は下記ページに説明があります.
http://emanual.robotis.com/docs/en/platform/openmanipulator_x/ros_setup/#opencr
ターミナルを1つ開いてコントローラと MoveIt を起動します.
$ roslaunch open_manipulator_controller open_manipulator_controller.launch dynamixel_usb_port:=/dev/ttyACM0 use_moveit:=true
Gazebo シミュレーションのときと同様に “Allow Approx IK Solutions” のチェックを入れます.
インタラクティブマーカを動かして目標姿勢を定めてから [ Plan and Execute ] ボタンを押すと,Gazebo シミュレータで行ったときと同じように実機ロボットを操作できました.
MoveIt の GUI 経由で uArm Swift Pro と Open Manipulator X を操作することができました.次の段階としてプログラムから MoveIt を操作してロボットを動かしてみました.
GUI からではなくプログラムからロボットを操作できることで,例えば画像処理から得られた座標をもとににマニピュレータを動かすといった応用につながります.
プログラムから MoveIt を動かすには MoveIt Commander を利用します.MoveIt Commander には C++ や Python のインタフェースが用意されていますので,今回は Python にてプログラムを作成して各ロボットを動作させました.
MoveIt の GUI にあった “Allow Approx IK Solutions” にチェックを入れた場合と同様の動作指令を出せる MoveIt Commander の機能が set_joint_value_target()
メソッドです.一般的には set_joint_value_target()
メソッドには各関節の目標角度を引数として渡すことがまず説明されるかと思いますが,第1引数に Pose 型か PoseStamped 型のデータを第2引数に True
(=近似解=Approximate / デフォルトは False
=厳密解)を渡すことでマニピュレータの自由度が少ないことにより厳密解が得られない状態を近似解を用いることで回避します.
なお,6自由度以上を有するマニピュレータでは一般的に set_pose_target()
に Pose 型か PoseStamped 型のデータを渡して厳密解をもって動作させますので,そのようなマニピュレータのプログラムを応用する場合には注意が必要です.
今回作成したテストプログラムを以下に記します.
#!/usr/bin/env python import sys, math, copy import rospy, tf, geometry_msgs.msg from moveit_commander import MoveGroupCommander, RobotCommander from geometry_msgs.msg import Pose, PoseStamped if __name__ == '__main__': node_name = "commander_example" rospy.init_node( node_name, anonymous=True ) group = MoveGroupCommander("arm") group.set_planning_time( 600.0 ) # Getting Initial Pose & RPY pose_init = group.get_current_pose() rospy.loginfo( "Get Initial Pose\n{}".format( pose_init ) ) rpy_init = group.get_current_rpy() rospy.loginfo( "Get Initial RPY:{}".format( rpy_init ) ) # Pose 1 rospy.loginfo( "Starting Pose 1") group.set_start_state_to_current_state() pose_target_1 = Pose() pose_target_1.position.x = 0.20 pose_target_1.position.y = 0.00 pose_target_1.position.z = 0.15 pose_target_1.orientation.x = 0.0 pose_target_1.orientation.y = 0.0 pose_target_1.orientation.z = 0.0 pose_target_1.orientation.w = 1.0 group.set_joint_value_target( pose_target_1, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Pose 2 rospy.loginfo( "Starting Pose 2" ) pose_target_2 = Pose() pose_target_2.position.x = 0.15 pose_target_2.position.y = 0.15 pose_target_2.position.z = 0.10 pose_target_2.orientation.x = 0.0 pose_target_2.orientation.y = 0.0 pose_target_2.orientation.z = 0.3826834 pose_target_2.orientation.w = 0.9238795 group.set_joint_value_target( pose_target_2, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Pose 2 Z:+0.05[m] rospy.loginfo( "Starting Pose 2 Z:+0.05[m]") pose_target_2.position.z += 0.05 group.set_joint_value_target( pose_target_2, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Back to Initial Pose rospy.loginfo( "Back to Initial Pose") group.set_joint_value_target( pose_init, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) )
基本的な流れとしては Pose 型のインスタンス pose_target_1
などに位置・姿勢のデータを代入して group.set_joint_value_target( pose_target_1, True )
で目標をセットし,group.go()
で実行しています.
プログラムの実行方法は前述の MoveIt GUI でロボットが動作する状態にしてからもう1つターミナルを開いてテストプログラムを実行します.今回はテストプログラムのファイルを ~/catkin_ws/src/pro_moveit_config/script/uarm-sp_moveit_tutorial_poses.py としましたので,次のようにターミナルで実行しました.
$ rosrun pro_moveit_config uarm-sp_moveit_tutorial_poses
MoveIt Commander プログラムで uArm Swift Pro を動作せたときの動画です.
Open Manipulator X のテストプログラムも基本は uArm Swift Pro と同様に set_joint_value_target( Pose, True )
を利用して作成しました.
追加的に Open Manipulator X の運動学上の「厳密解」の位置・姿勢データを予め計算しておいて set_pose_target()
に与えたときの動作の様子もテストしました.
今回作成したテストプログラムを以下に記します.
#!/usr/bin/env python import sys, math, copy import rospy, tf, geometry_msgs.msg from moveit_commander import MoveGroupCommander, RobotCommander from geometry_msgs.msg import Pose, PoseStamped if __name__ == '__main__': node_name = "commander_example" rospy.init_node( node_name, anonymous=True ) group = MoveGroupCommander("arm") group.set_planning_time( 600.0 ) # Getting Initial Pose & RPY pose_init = group.get_current_pose() rospy.loginfo( "Get Initial Pose\n{}".format( pose_init ) ) rpy_init = group.get_current_rpy() rospy.loginfo( "Get Initial RPY:{}".format( rpy_init ) ) # Pose 1 rospy.loginfo( "Starting Pose 1") pose_target_1 = [ 0.12, 0.0, 0.1, 0.0, math.pi/2.0, 0.0 ] # [ x, y, z, r, p, y ] group.set_pose_target( pose_target_1 ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Pose 2 rospy.loginfo( "Starting Pose 2") group.set_pose_target( [ 0.2, 0.0, 0.2, 0.0, 0.0, 0.0 ] ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Pose 3 rospy.loginfo( "Starting Pose 3") pose_target_3 = Pose() pose_target_3.position.x = 0.10 pose_target_3.position.y = 0.10 pose_target_3.position.z = 0.10 pose_target_3.orientation.x = -0.2706 pose_target_3.orientation.y = 0.6533 pose_target_3.orientation.z = 0.2706 pose_target_3.orientation.w = 0.6533 group.set_joint_value_target( pose_target_3, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Pose 3 Z:-0.05[m] rospy.loginfo( "Starting Pose 3 Z:-0.05[m]") pose_target_3.position.z -= 0.05 group.set_joint_value_target( pose_target_3, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Pose 4 rospy.loginfo( "Starting Pose 4") pose_target_4 = Pose() pose_target_4.position.x = 0.10 pose_target_4.position.y = -0.10 pose_target_4.position.z = 0.05 pose_target_4.orientation.x = 0.2706 pose_target_4.orientation.y = 0.6533 pose_target_4.orientation.z = -0.2706 pose_target_4.orientation.w = 0.6533 group.set_joint_value_target( pose_target_4, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Pose 4 Z:+0.05[m] rospy.loginfo( "Starting Pose 4 Z:+0.05[m]") pose_target_4.position.z += 0.05 group.set_joint_value_target( pose_target_4, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) ) # Back to Initial Pose rospy.loginfo( "Back to Initial Pose") group.set_joint_value_target( pose_init, True ) group.go() rospy.sleep(5.0) pose_current = group.get_current_pose() rospy.loginfo( "Get Current Pose:\n{}\n".format( pose_current ) )
このテストプログラムのうち # Pose 1
と # Pose 2
の部分は set_pose_target()
で目標姿勢を設定しています.このようにXZ平面上に位置する点の厳密解を指定した場合は set_pose_target()
でも動作しましたが,# Pose 3
や # Pose 4
のようにXZ平面から外れたところは set_joint_value_target( Pose, True )
を利用しないと動作しませんでした.
プログラムの実行方法は前述の MoveIt GUI でロボットが動作する状態にしてからもう1つターミナルを開いてテストプログラムを実行します.今回はテストプログラムのファイルを ~/catkin_ws/src/pro_moveit_config/script/openmanipulatorx_moveit_tutorial_poses.py としましたので,次のようにターミナルで実行しました.
$ rosrun open_manipulator_moveit openmanipulatorx_moveit_tutorial_poses.py
Open Manipulator X を MoveIt Commander から動作させたときの動画です.
今回 ROS の入門向けを念頭に2つのマニピュレータを導入し調査・検証しました.その結果を以下にまとめます.
set_joint_value_target()
を使う必要あり今回の2台のマニピュレータであれば Open Manipulator X の方が提供されている情報も多く,予算的に許されるのであれば入門に適していると思いました.
TORK の ROS ワークショップを受講された方などから ROS を使用するにあたりどのような PC を利用したら良いかを問い合わせいただくことがあります.
基本的には利用したい ROS の各バージョンに対応した Ubuntu のバージョンが動作可能な PC であれば良いのですが,スペックが多岐にわたるパソコンの数々からどのようなパソコンを選んだら良いのか迷ってしまいます.
そこで ROS を導入するパソコンの選定の参考なるよう,4つの異なる特徴のノートパソコンに実際に Ubuntu と ROS を導入して,その導入のポイントや動作結果を報告したいと思います.
各ノートパソコンの主要なスペックは以下のとおりです.
ROS / Ubuntu の導入機種を選ぶにあたって Ubuntu Certified hardware という Web ページが参考になります.
Ubuntu Certified hardware で今回の各ノートパソコンの対応状況を調べた結果が次の通りです.
これらのノートパソコンに限れば,2018 年の日付があるものは Ubuntu 16.04 に対応していて,2019 年の日付があるものは Ubuntu 18.04 に対応していると記載されています.
次項目で記述しますが対応が非明記のバージョンの Ubuntu をインストールしても問題なく動作する組み合わせもあります. Ubuntu Cetrified hardware を参考にしつつ,各ノートパソコンで使用されている各種チップの Linux デバイスドライバの対応状況等ふまえて導入を検討するのが良さそうです.
Ubuntu はバージョン 16.04 と 18.04 をそれぞれのノートパソコンにインストールを試みました.各ノートパソコンに購入時にインストールされている Windows 10 を残したまま Ubuntu も起動できるように SSD にパーティションを切ってインストールすることとしました.
Ubuntu のインストール手順は Dell と Lenovo のノートパソコンで BIOS の設定方法が少し違うので分けて説明したいと思います.
なお,本記事では必要な手順の項目を中心にお伝えします.実際に PC に Ubuntu をインストールする際には具体的な方法を十分調査の上作業を行ってください.
後述する Lenovo ThinkPad への Ubuntu のインストールと比べて BIOS の設定変更に関する手順が多くなっています.
bcdedit /set {current} safeboot minimal
を実行bcdedit /deletevalue {current} safeboot
を実行インストールにあたっては次のサイトを参考にしました.
sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt-get update
各 PC で UnixBench を実行して,シングルコア・マルチコアのスコアを調査しました.
Dell Inspiron 13 5390 | Dell XPS 13 7390 | ThinkPad X1 Extreme Gen2 | ThinkPad T480s | |
スペック | ||||
CPU ナンバー | Core i5-8265U | Core i7-10710U | Core i9-9880H | Core i7-8550U |
スレッド / コア | 8 / 4 | 12 / 6 | 16 / 8 | 8 / 4 |
ベース周波数 | 1.6 GHz | 1.1 GHz | 2.3 GHz | 1.8 GHz |
最大周波数 | 3.9 GHz | 4.7 GHz | 4.8 GHz | 4.0 GHz |
UnixBench | ||||
シングルコア | 1640.1 | 2106.8 | 1829.1 | 1234.6 |
マルチコア | 3550.8 | 6012.3 | 7960.4 | 3399.5 |
Multi Cores はコア数に応じたスコアを示しているように思います.
また Dell Inspiron 13 5390 が値段の割に良い結果が得られました.
GPU は ROS では Gazebo シミュレーションの 3D 表示能力などと関係がある項目です.
各 PC で Unigine Benchmark – Heaven (1920 x 1080) と glmark2 をそれぞれ実行して,スコアを調査しました.
Dell Inspiron 13 5390 | Dell XPS 13 7390 | ThinkPad X1 Extreme Gen2 | ThinkPad T480s | |||
GPU | Intel UHD 620 | Intel UHD 630 | Intel UHD 630 | GeForce GTX 1650 | Intel UHD 620 | GeForce MX150 |
Unigine Benchmark – Heaven 1920 x 1080 | ||||||
Score | 281 | 310 | 290 | 1565 | 267 | 548 |
FPS | 11.2 | 12.3 | 11.5 | 62.1 | 10.6 | 21.8 |
Min FPS | 5.0 | 5.9 | 8.1 | 21.4 | 5.3 | 6.3 |
Max FPS | 23.7 | 25.9 | 23.2 | 124.7 | 22.1 | 46.2 |
glmark2 | ||||||
Score | 2244 | 2892 | 2978 | 2633 | 2500 | 3343 |
Unigine Benchmark – Heaven では NVIDIA グラフィックの優位性が顕著に出ました.
一方 glmark2 の方は NVIDIA GeForce MX150 の優位性はあるものの NVIDIA GeForce GTX 1650 はむしろ Intel UHD 630 よりも低いスコアとなりました.これらの PC では glmark2 実行時に 2000 〜 4000 fps ほど出てしまうので,現在の GPU に対しては負荷が軽すぎるような印象を持ちました.
実際の ROS プロセスの動作状況を比較するためにポイントクラウドのフィルタリング処理能力を比較しました.
予め記録したポイントクラウドメッセージの rosbag
データを各 PC で Voxel Grid フィルタと Statistical Outlier Removal フィルタをかけて ROS トピック /camera/statistical_outlier_removal/output として出力して周波数を調査しました.
$ rostopic hz /camera/statistical_outlier_removal/output
Dell Inspiron 13 5390 | Dell XPS 13 7390 | ThinkPad X1 Extreme Gen2 | ThinkPad T480s | |
MAX | 2.855 | 5.052 | 4.333 | 2.000 |
Average | 2.353 | 3.759 | 3.830 | 1.873 |
min | 2.126 | 2.975 | 3.623 | 1.787 |
3D グラフィクの表示は行わなかったので基本的には CPU によるデータ処理と考えられます.
CPU Multi Cores のスコアが一番近い傾向にあるように思いますが,Dell XPS 13 と ThinkPad X1 Extreme Gen2 の差は CPU Multi Cores ほどは出ませんでした.より多い数のスレッドを必要とするプロセスでは差が出るかもしれません.また Dell XPS 13 7390 は処理周波数の最大,最小の差が大きかったです.
Dell Inspiron 13 5390 は値段の割に良い結果を出している印象を持ちました.
Dell Inspiron 13 5390 | Dell XPS 13 7390 | ThinkPad X1 Extreme Gen2 | ThinkPad T480s | |
Ubuntu 16.04 + ROS Kinetic | ◎ | △ | △ | ◎ |
Ubuntu 18.04 + ROS Melodic | ◎ | ◎ | ◎ | ◎ |
BIOS 設定の容易さ | △ | △ | ○ | ○ |
ROS ポイントクラウド処理性能 | ○ | ◎ | ◎ | ○ |
価格 | ◎ | ○ | △ | – |
2019年に ROS パッケージをリリースしました CIS ToF カメラセンサ DCC-RGBD1 がネットから購入できるようになりました.
Amazon.co.jp で購入の場合は日本国内への出荷のみですが,日本国外へも 株式会社シーアイエス の販売窓口メールアドレス ec-sales@ciscorp.co.jp にお問い合わせいただくと販売可能とのことです.
皆さん,こんにちは
今回,TORKのROSチュートリアルを使って,初めてロボットのプログラムの勉強をしたので,そのときに苦労した点を中心に感想を書いていきたいと思っています.
私のプログラミングレベルはDOSやBASICを少し知っている程度,WindowsはOSとして利用するだけで,Windowsのプログラムを書いたこともありません.もちろんLINUXも最近のプログラム言語であるPythonは全く知りません.個人的にはかなりハードルが高いのですが挑戦してみたいと思います.
ここではROSチュートリアルとして,TORKのMoveIt! Tutorial Documentation Release0.0.7を使っていきます.ちなみに日本語ですので大変助かります.
1章(CHAPTER ONE)
とりあえずサラッと読んで次へ
2章(CHAPTER TWO)
あれ,シミュレータ上のロボット? シミュレータはロボットのシミュレータじゃないのNEXTAGE OPEN,Baxter・・・・なんだなんだ? その下,2.1にはROSのシミュレータ,Hrpsys(RTM)シミュレータ??? 全然わからない???
これはすぐには理解できなかったので,実際はこのチュートリアル通りに淡々と進め,ぼんやりと分かってきた時点で整理してみると下記のようなことでした.
最初に出てきたNEXTAGE OPEN,Baxter・・・・というのはシミュレータ上で動作するロボットの名前でした.具体的なイメージは以下の画面キャプチャを見てください.このチュートリアルで使うシミュレータ上のロボットはこの4種です.
NEXTAGE OPEN | Baxter Research Robot | MINAS TRA1 | KHI duaro |
|
|||
2.3.2項 | 2.3.3項 | 2.3.4項 | 2.3.5項 |
初めから整理した形で進めると2章の理解が早いと思いました.
更にこれらのロボットが動作するベースとなるシミュレータはGUIでロボットの動作を計画(指示)するMoveIt!というものと,その計画に沿って動作するロボットの土台となる物理シミュレータであるGazeboというものがあるということです.
これらの関係を理解しておくとチュートリアルで何をしようとしてその手順を踏んでいるのか理解しやすくなります.
私はこの関係が理解できないまま進めてしまったので,進めている割には何をしているのか理解できずまごついてしまいました.
2.2 ソフトウェアのインストール
まずUbuntuのインストールから始めました.最初はWindows10にOracleのVirtual Boxをインストールし,VMの中にUbuntuをインストールしました.インストールは無事できたのですが,その後トラブル続出で,途中であきらめてしまいました.やはり慣れていない人は素直にネイティブでインストールすることが必須と思いました.
ちなみに,Ubuntuは16.04LTEの英語版を使用しました.日本語版だとディレクトリの名称に日本語が入り,うまく動かないことがあるので注意です.英語版をインストール後,日本語が使えるようにMozcをインストールしました.また,ROSのバージョンはKineticです.本チュートリアルのROS Kinetic版を行う上では Ubuntu16.04LTEとの組合わせが必須です.前のバージョンであるIndigoはUbuntu 14.04LTEとの組み合わせで検証されているため,問題が発生しても初心者では解決ができません.私自身,このチュートリアルのテキストを読む前はこの組み合わせを把握していなかったので,16.04にIndigoを入れてしまい,訳が分からなくなってしまいました.要注意です.
私は10年程前からUbuntuを試用してきましたが,基本GUIベースでしか使っていませんでした.今回はターミナル上のコマンドベースです.昔MS-DOSのコマンドを使ってみたことはありましたが,Ubuntuでは初めてです.これも勉強しながら進めていこうと思います.
さていよいよROS関連ソフトウェアのインストールです.
ソフトウェアは3ページ下部に書いてあるROS,チュートリアルパッケージ,ロボットソフトウェア3種です.
まず,ROSのインストールです.
現時点ではチュートリアルも修正されているかもしれませんが,掲載されている内容はキー情報が古いため,下記URLに記載されている手順でインストールを行いました.これはスムーズにインストールできました.
http://wiki.ros.org/ja/kinetic/Installation/Ubuntu
次にチュートリアルのインストールです.これも現時点で apt-getで取ってこれないとのことでGithubからdebianパッケージをダウンロードしてインストールすることが必要でした.具体的には下記場所から ros-kinetic-tork-moveit-tutorial_0.0.7-oxenial_amd64.deb をダウンロードし,これを下記のようなコマンドでインストールしました.
ダウンロード先:https://github.com/tork-a/tork_moveit_tutorial/releases/tag/0.0.7
インストール: $sudo apt-get install -f ./ os-kinetic-tork-moveit-tutorial_0.0.7-0xenial_amd64.deb
NEXTAGE OPEN,MINAS TRA1,KHI duaroのロボットソフトウェアはチュートリアル通り行っていくと問題なくインストールできました.
Ubuntuをコマンドベースで使っている方には初歩の初歩ですが,私はこの過程で,↑,↓キーを押すことで,前後に実行したコマンド履歴から選んで,再実行できることや,コマンド入力途中でTabキーを使うことにより,オートフィルのような機能があることを知りました.MS-DOSの時代のコマンドに比べるとすごい進化ですね.
さて全てインストールできたので,チュートリアルに沿って,実行してみました.実際にMoveIt! GUIで動作目標の位置を設定(InteractiveMakerを動かして設定)し,Plan and Execute ボタンを押すと,Gazeboシミュレータ上のロボットがその通りに動きました.ちょっと感動です.
MoveItもGazeboも表示画面のメニューを見ると機能が豊富そうなので,もう少し慣れてきたら,どんなことができるのか確認をしてみたいと思っています.
3章(CHAPTER THREE) プログラムでロボットを動かす.
ようやく,ロボットを動かす環境が整い,実際にシミュレータ上で,NEXTAGE OPENロボットをコマンドで動かしてみるところまでたどり着きました.
ワクワクしますが,ここでプログラム言語のPythonを使う必要が出てきました.この言語は全く初めてなのでこれも勉強しながらやっていこうと思います.PythonはCのようにコンパイルしたりすることがなく,1行ずつ実行する環境があるとわかり少し安心しました.また,Pythonの開発環境はROSをインストールしたときに同時にインストールされているとのことなので,そのまま進められそうです.
Pythonに関しては7章(CHAPTER SEVEN)にチュートリアルが書いてありますので,時々参照しながら行っています.
3章では基本的に1行づつの実行で確認を進めていけます.Python を1行ずつ実行する環境は tork_moveit_tutorial demo.py を実行することで可能になります.最初の行の冒頭 In[1]:は何を意味するのか分からなくて,最初はこのチュートリアル通り1から始まるのですが,1行実行すると2になってしまいます.チュートリアルでは2行目実行後でも1になっている場合があるので,何とか戻そうとしましたが戻りません.これも聞いたところ,1行実行する度に増えていく仕組みになっているので戻すことはできないし,実行上の意味は無いので気にする必要はないとのことでした.聞けば「そうですか」なのですが,本当に初めはこんなつまらないこともわかりません.トホホです.
それ以上に難しいのが,位置や姿勢を示す用語の意味です.ロール,ピッチ,ヨーについては下記のページを参照させていただきました.
https://watako-lab.com/2019/01/23/roll_pitch_yaw/
クォータニオンについては下記のページを参照させていただきました.
https://qiita.com/drken/items/0639cf34cce14e8d58a5
一通り読みましたが,ベースとなる知識がないので,十分には理解できませんでした.ここで立ち止まってもしょうがないので,とりあえずそういう定義の方法があるということだけ記憶し,次へ進むことにしました.
4章(CHAPTER FOUR) 発展的なロボットプログラミング
いよいよプログラミングのスタートです.チュートリアルではいきなりプログラムの実行のコマンドが書いてありますが,3章終了時にすべてのターミナルを閉じていた私には「あれ?いきなりコマンドを実行するの??」と,具体的にどうしたらよいかわかりませんでした.聞いたところ,この章で使用するロボットはNEXTAGE OPENとのことなので,まずコマンドを実行する前に3.2.1項に書いてあるようにまず一つ目のターミナルでNEXTAGE OPENを起動し,二つ目のターミナルでMoveIt!を起動した後,もう一つターミナル(ターミナル3)を開いて,そこでプログラムファイルを実行していく必要があるとのことでした.
ここまで準備ができれば,チュートリアルのプログラムファイルを“rosrun ファイル名” で実行していけば動作を確認できますが,問題はそのプログラムファイルの中身ですね.
4.1.1項の nextage_moveit_tutorial_poses_ifqyn.py の下にいきなり最初のプログラムファイルの中身が書いてあります.これがPythonで書かれたプログラムです.
Pythonは細かな文法はBASIC等と異なるものの,大きな考え方は共通するものがあり,それほど違和感はありませんでした.ただ,クラスという考え方は新しいことでした.それも7.3.3項を読んでみると,なんとなくわかったような気になって,そのまま進めることにしました.
4.3.2項 まではスムーズにプログラムを理解し,実行できたのですが,4.3.3項のtfでつまずいてしまいました.最初からtf=Transform Frameと理解しておけばよかったのですが,単なる記号として読み進めたため,なかなか理解できなかったのです.これまでは,単純に動作の目標位置を設定し,実行するとそこへ動くという内容だったのですが,ここで時間の概念が入ってきたことになかなか気が付かなかったのです.
考えてみれば,ロボットは逐一動いていて,時間ごとにどんどん位置や姿勢が変わっていくので,時間の概念を入れないと,自動的に判断して動いていくようなロボットのプログラムは作れないのは当然でした.そう思って,この4.3.3項以降を読むとすんなりと理解できました.
つぎに思ったことは4.3.5項の障害物の設定です.障害物は box_poseで設定すれば,MoveIt!が自動的に動作計画を作りますということなのですが,実際にはどういうステップで障害物を避けながら動いていくのか知りたいと思いました.この辺りは,これから実際にプログラムを書いて試してみて,慣れてきたら,勉強してみようかと思います.
以上,理解がまだまだ不十分ですが,チュートリアルを終えた感想をまとめます.
1.本チュートリアルでROSを使ったロボットの基本的な動作は解説されているので,これらの動作の組み合わせやセンサーからのフィードバックで目標姿勢を変えながら,繰り返し動作をさせていけば,物を掴んで移動させたり,両腕を使って,何かを組み立てさせたりすることが比較的簡単にできそうだという感触は掴むことができました.
2.しかし,チュートリアルを終えても,ROS=通信機構+ツール+ライブラリ群+コミュニティという定義に対し,ROSはこれというような概念がつかめていないことが反省です.というのは,①具体的に通信機能,ツールにはこのチュートリアルのどの部分が該当しているのか,ライブラリ群は多分膨大にあるのだとは思いますが,例としてどんなものがあるのか,ここまではROSでカバー,ここは自分でプログラムを作らないとダメとか,ROSの全貌と境界が良く見えないことです.それと②私個人の問題ですが,ROSは分散システムであり,従来自分が接してきたシリアルなプログラムとは取り扱う概念が異なるため,分散システムの同期,非同期等の考え方等,もう少し勉強しないといけないと感じました.
3.ここまでのチュートリアルでMoveIt!等の便利に使えるツールが存在すること等からロボットの動きを比較的簡単にシミュレーションしたりすることができるということは面白いと思いました.実際のプログラムを書いて実行してみたいと感じています.これから,プログラムを書く上での細かなルールや手順,作成上のツール等をもっと勉強してみたいと思います.これは,TORKのROSセミナー初級編が参考になるのではと思っています.また,最新版のMoveIt! Tutorial Documentation Release0.0.10では新しく「独自プログラムの実行」という章が加筆され,この辺を重点的に解説されているので,今後読み進めて,簡単なプログラムを書けるようになりたいと思っています.
4.CommandベースのUbuntuの操作やPythonを初体験したのですが,昔のMS-DOSのCommand操作やBasicの延長で,当初想定していたよりは取り組みやすかったと思っています.
以上,本当の初心者がチュートリアルをやってみて単純に思ったことを書いてみました.あまりにも初心者でお叱りを受けそうなところも多々ありますが,これからROSを使ってみたい人の参考にしていただければ幸いです.
新しい ROS パッケージ cis_camera( https://github.com/tork-a/cis_camera )をリリースしました.
この ROS パッケージは 株式会社シーアイエス( https://www.ciscorp.co.jp/ ) ToF (Time of Flight) カメラセンサ DCC-RGBD1 のためのドライバパッケージです.
DCC-RGBD1 は小型ながら広いレンジの深度画像が取得可能な ToF カメラセンサ(ディベロップメントキット)です.
本パッケージでは CIS ToF カメラセンサの ROS ドライバに加え,ノイズ除去,平面検出・除去,対象物点群抽出とフレーム座標算出のポイントクラウド処理ならびに,それらの処理結果を RViz で 3D 表示するためのサンプルプログラムおよび launch ファイルを同梱しています.
使い方は GitHub のドキュメントをご参照ください.
もし問題にぶつかった場合は GitHub Issues で報告をお願いします.
CIS ToF カメラセンサのハードウェアの入手などに関するお問い合わせは下記連絡先までお願いします.
ハードウェアに関するお問合せ先:株式会社シーアイエス 営業担当
メールアドレス:newbiz@ciscorp.co.jp
電話番号:042-664-5568
11月20日に,World MoveIt Day 2019 in Tokyoが開催されました! 当日の様子を写真をたくさん載せながらレポートしたいと思います.参加できなかった方もWorld MoveIt Dayの雰囲気を感じていただけると幸いです.当日の実施したスケジュールをたどりながら記事にしたいと思います.
会場は株式会社オムロンサイニックエックス様のオフィスでした.オフィス玄関,エレベータ,会場などにTORK作成のWorld MoveIt Dayのポスターを貼って雰囲気を盛り上げました.
会場したときの写真です.オムロンサイニックエックス様のご提供の会場はおしゃれなオフィスでした.参加者みなさん,それぞれ開発の準備をしています.
TORKよる開会の挨拶がありました.1日の日程の説明を行いました.
早急に開会の挨拶を終了し,ハッカソン開始!みなさんそれぞれの課題を見つけ開発を行います.わからないことがあれば,スタッフに積極的に質問してくださったり,参加者同士で助け合ったりと良い雰囲気でした.
昼食はTORKの提供でした.ごはんをしっかり食べて午後からも頑張れそうです!!
お昼ごはんを食べながら,主催者によるスポンサープレゼンがありました.
オムロンサイニックエックスのフェリクスさんからのスポンサープレゼンが実施されました.オムロンサイニックエックスとしての活動,MoveItの開発スケジュールなどの説明がありました.
TORKから,TORKの会社説明,活動(セミナー,トレーニング教材の作成,MoveItへのコミット)などを説明しました.
午後もハッカソンが続きます.午後には事前に用意していたロボットを参加者さんが動かせるようになりました.そのときのトラブル事例などをシェアしたりと,開発者同士の積極的な交流がありました.またホワイトボードに今実施している内容(Issue番号なども)を書き出したりしました.
夕方17時から,今日一日の成果発表です.参加者皆さん,今日一日やったことを発表するスタイルでした.「私のやったことなんて…」みたいなことがなく,互いの成果を称え合うすばらしい時間だったと思います.たくさんの発表があったので,一部だけご紹介します.
MoveItプラグインのScene Objectsの設定画面にて,各Sceneに紐付けられたインタラクティブマーカのサイズがおかしいという問題をTORK から発表しました.当日は間に合いませんでしたが,その後問題を解決し,Pull Request を本家リポジトリへ出し,現在 merge を待っています.
RViz broken Interactive Marker in “Scene Objects” Tab #1115
https://github.com/ros-planning/moveit/issues/1115
Add interactive marker resizing #1795
MoveItプラグインで,ロボットの開始終了姿勢を指定するときにCurrentという設定があると思います.それに追加で,Previousを実装したという発表でした.これによって,プランニング実行後,更にプランニングを行う場合,以前の姿勢を目標姿勢に設定することができます.なんとこの成果はMoveItのマスターブランチにマージされました!!すばらしいです.
add “<previous>” robot state to RViz motion display #14
MoveItチュートリアルの日本語化を現在取り組んでいます.その一部を2名の方に手伝ってもらいました!ありがとうございます.
Japanese Translation #415
MoveItのプラグインは横幅のサイズが固定で.ディスプレイサイズが小さいとRvizを専有してしまいます.このIssueに取り組んでくださいました.
make MoveIt’s RViz display properly resizable #13
ロボットを持ち込んで参加してくださった方々もいらっしゃいました.xArmの動作デモを実施していただきました.xArmの実物を見たことがなかったので,新鮮でした!
本日はWorld MoveIt Day2019に参加してます.xArmというロボットを持参してます!#WMD2019 #ROS pic.twitter.com/xbyhz5d8Wu
— Connected Robotics Inc (@CROctoChef) 2019年11月20日
TORKからMoveItの新しいプランナであるTrajOptの説明を行いました.WMD当日時点では,TrajOptの機能はプルリクエストがあがっていますが,動作しなかったので,そのプルリクエストの内容のレビューを実施しました.WMDの時間内でなんとかプランニングを実行することまではできるようになりました.
Trajopt with no dependency to tesseract #1626
発表時間には多くの発表があり,この記事のボリュームの関係で紹介しきれなかったものもたくさんあります.発表してくださった方にはMoveItステッカーやTORK作成のMoveIt DayのTシャツをプレゼントさせていただきました.
集合写真もとりました.途中からの参加や,途中でお帰りになった方もいらっしゃいますが,定員で設定していた30名をお迎えすることができ非常によかったです.
閉会後スタッフとPanda,URのコラボ写真を撮影しました.
今年のWorld MoveIt Dayの日本開催では,Masterブランチへマージされるようなすばらしい成果を出してくださった参加者さんもいらっしゃいました.だんだんと日本でもMoveItを使う側から開発側に入り込めるように推進活動をしたいと思っています.参加者の皆さん,ありがとうございました! 今年参加してくださった方も,参加できなかった方も,来年お会いしましょう!
本記事では,World MoveIt Day 2019 in Tokyo(WMD 2019 in Tokyo) の会場にて動かすことのできるロボットアーム Panda を,実際にPCと接続して動かす方法を紹介します.
後編では,Panda のパッケージ群である franka_ros の中身について紹介します.
当日実際に機体を動かしてみたい方は,必見です!
Panda を動かすPCの環境構築と,PCと実機の接続方法を説明した前編はこちらになります.
MoveItでPandaを動かそう:前編(WMD 2019 in Tokyo 準備編)
本記事はWorld MoveIt Day 2019 in Tokyo(WMD 2019 in Tokyo)へ参加するにあたり,MoveItで使用できるプランニングアルゴルリズムに関して解説します.
MoveItでは非常に多くのプランニングアルゴリズムが利用できます.プランニングアルゴリズムは理論や実装方法によって軌道の計算時間や軌道そのもののが大きく変わるため,ユーザにあまり意識させないような実装にMoveItは設計されているものの,実は非常に重要な要素です.しかしその豊富さが災いして,結局どのアルゴリズムがよいのかわからなくなっているのが現状です.そこでこの記事では現段階で実装されているアルゴリズムについて整理しようと思います.
アルゴリズム内部を理解していると,適用先のロボット,環境によってどのアルゴリズムが適しているかを判断しやすくなりますので,この記事を読んでアルゴリズムの理解を進めていきましょう.
本記事では,World MoveIt Day 2019 in Tokyo(WMD 2019 in Tokyo) の会場にて動かすことのできるロボットアーム Panda を,実際にPCと接続して動かす方法を紹介します.
前編では,Panda を動かすPCの環境構築と,PCと実機の接続方法について紹介します.当日実際に機体を動かしてみたい方は,必見です!
本記事は World MoveIt Day 2019 in Tokyo(WMD 2019 in Tokyo)へ参加するにあたり,MoveItのソースコードを変更し,コミットするためのやり方を紹介します.
MoveItにはPull Requestを送るためのルールがあるので,これに沿ったやり方が出来るよう解説します.WMD 2019 in Tokyoへ参加しない方でも,MoveItを使う方なら参考になると思うので,是非ご覧ください!
なお,今回想定しているROSのバージョンは,ROS1 melodic
です. 続きを読む
MoveIt の利用者,開発者のための世界的なイベント World MoveIt Day 2019 (以下WMD 2019)のローカルイベントを,東京で開催します.
MoveItとは ROS コミュニティ が開発している,ロボットマニュピレータを対象としたROSの主要パッケージの一つで,障害物にぶつからないようなロボットアームの軌道を計画するモーションプランニングのソフトウェアパッケージです.WMD 2019 は,このMoveItの開発を世界中の人々で一気に推し進めようという開発者のためのイベントです.
和気あいあいと開発を行っていきたいと考えています.
実機 Panda Arm の用意をはじめ,開発中に詰まったポイントは随時ホワイトボードに書き出し,みんなで共有->わかる人がいれば一緒に解決する.というスタイルで開発していきます.
さらに昼食も無料ですし,閉会後も可能な時間まで開発を続けることもできます…!是非産業ロボット大国日本から一丸となってMoveItに貢献し,MoveItとロボットを楽しみましょう!!
初めてMoveItに触れる方におすすめの日本語教材が2つあります.
自分にあっている方を選んでまずはご覧ください.
はじめてMoveItに触れる方のために, ROS Industrial トレーニング教材(英語) が提供されています.しかし,これらは英語で書かれているため,日本語も欲しいところですよね!!
実はTORKでは以前にこのページを日本語化し,公開しています.MoveItの基本的な使い方,他のチュートリアルやマニュアルへのリンクなどがまとめられているので,まずはこちらをご覧ください.
また,2019年11月16〜17日には,日本ロボット学会(RSJ)の主催でMoveItとROSを用いたマニピュレータ制御に関するセミナーが開かれます.申し込み期限は2019年9月27日なので,是非参加されてみてください.
TORKからMoveItの日本語チュートリアルを無料で公開しています.是非ご覧ください.
どんなロボットを用いて開発をされても構いませんが,WMD 2019 では,Panda Arm の実機を用意しています.これは,Moveit!のチュートリアルで使用されているロボットです.
WMD 2019では,このチュートリアルの不備があれば公式リポジトリへIssueを出していただくことも推奨しています!!ただし英語のため,TORKにて部分的に日本語訳を行っていく予定です.
ここまでに登場したリンク以外にも,参考になるリンクをまとめて紹介しておきます.
MoveItが使えるようになったら,是非MoveItに貢献しましょう!WMD 2019もROS Industrial に貢献することが開催目的です!
といっても,何から始めたら良いかわからないですよね…
実は公式ページからそのガイドラインが出ています.このページの”Finding Where You Can Help” と書かれてる箇所に具体的に載っています.内容は下記のとおりです.
上記の中からとくに,WMD Tokyo 2019では実機のPanda Arm もあるため,documentation の項目を更新できるかもしれません…他のラベルもどんどん解決していきましょう!!!
筆者も昨年のWMD 2018 では simple_improvements の解決にチャレンジしていました.もちろん,WMD 2019 開催前にどんどんと解決していってもらっても構いません(むしろ歓迎).そして,その内容をWMD 2019で発表してください.
なお,WMD 2019で成果発表を行ってくださった方には素敵なプレゼントがあります!!!
「MoveItの本家リポジトリへコミットする方法」 を公開しました!(2019/10/24)
「MoveItでPandaを動かそう:前編」を公開しました!(2019/10/28)
「MoveItの各プランナーについての解説」を公開しました!(2019/10/30)
「MoveItでPandaを動かそう:後編」を公開しました!(2019/11/18)
「MoveIt2のビルドとマニピュレータ「MARA」による動作確認」を公開しました!(2019/11/19)
記事の更新情報は随時公開していきます.是非RSS等登録頂き,チェックしてください!
以下日程でROSワークショップを行います.
4月19日(金)13:30~ ROSワークショップ初級編
4月25日(木)13:30~ ROSワークショップ初級編
場所は都内・有楽町の会議室で実施します.
お申込みは以下より詳細をご確認の上,ページ内のお申込みリンクよりエントリをお願い致します.
ROSワークショップ初級編
上記以外での日程の調整,その他ご相談,開発委託も承っております.
お気軽にご相談ください.
info[at]opensource-robotics.tokyo.jp
春ですね!春は新しく勉強をはじめる方も多いと思います.
ROSワークショップはLinuxで実施しますが,Linux環境を簡単に準備できない方やLinuxが初めての方もいらっしゃいます.
環境をすぐに準備できない方はWeb上のターミナル環境を使ってまずはLinuxコマンドに慣れておくのをおすすめします.
Web上のターミナル環境
・ターミナル:Unix Terminal Online
http://www.tutorialspoint.com/unix_terminal_online.php
おすすめのLinuxコマンドのサイト
・ Linuxコマンド
http://robotics.naist.jp/edu/text/?Robotics%2Flinux-command
・参考:ROSを初めて勉強するときに
https://opensource-robotics.tokyo.jp/?p=1361
以下日程でROSワークショップを行います.
2月26日(火)13:30~ ROSワークショップ初級編
場所は都内・有楽町の会議室で実施します.
プライベートでのお申込みが大変増えております.
人数が揃うようでしたら,プライベートでのワークショップ,出張のワークショップも開催可能です.
ご希望の日程をお問い合わせください.
お申込みは以下より詳細をご確認の上,ページ内のお申込みリンクよりエントリをお願い致します.
ROSワークショップ初級編
上記以外での日程の調整,その他ご相談,開発委託,出張ワークショップ,カスタマイズワークショップも承っております.
お気軽にご相談ください.
info[at]opensource-robotics.tokyo.jp
産業用などのロボットアームとROSの組み合わせについて調べると,”ROS-Industrial(以下ROS-I)”というのが見つかって,気になりますよね.自分のロボットに対応しているのだろうか,ロボットにやらせたいことが出来るパッケージが揃っているんだろうか,そもそもROS-Iって何なんだろうか,ROSとは違うの? そのような問い合わせをTORKでも多く受けています.
ROS-Iは,国際的なコンソーシアムの名前です.このコンソーシアムでは,ROSを産業用途に用いる際の技術的な問題を参加メンバー企業間で共有し,メンバー内の企業が(契約に基づき)パッケージやソリューションを提供する,という活動です.ROS-Iという規格やパッケージ群が,ROSと独立してあるわけではありません.あくまで,ROSのエコシステムの中での話です.
ROS-Iで開発,管理されたパッケージは,しばらくはメンバー企業の中でのみ共有されますが,最終的にはオープンソースとすることが契約で決められています.ROS-Iのレポジトリで公開されているのは,これらの成果です.
ROS-Iでは,この成果を使うためのトレーニングコースを北米,EU,そしてアジアではシンガポールで定期的に開催されています.3日間ぐらいのコースとなっています.このトレーニングコースは,ROS-Iのメンバーでなくても受講することができます.
さらにそのトレーニング用の教材も公開されていて,これを参考にすれば興味がある人はだれでも,ROS-Iの主要パッケージについて勉強することができます.
これには,ROSの基本的な解説やセットアップの他に,C++でのノードの書き方,MoveIt!,ROS-Iで最近開発された直交座標系でのプランニングパッケージ”Descartes”や,センサを使った点群処理,画像処理といった内容が含まれています.演習が主になっていて,自分のPCもしくはVMで試しながら習得するというスタイルです.
正直言って,難易度はけっこう高いと思いますが,ROSをすでに習得していて産業用ロボットでこれからガンガン使うぞ!という方にとっては,大いに参考になる内容ではないかと思われます.
「でも英語じゃーなあ...」と思ったそこのあなた,朗報です! このトレーニングコースの教材をTORKで日本語訳し,このたび完成しました!
日本語の目次は以下のようになっています.興味が湧いた方は,ぜひ日本語でチャレンジしてみてください.
PC のセットアップ
準備
C++
Linux の基礎演習 0.1 – Ubuntu GUI 入門
演習 0.2 – Linux のファイルシステム
演習 0.3 – ターミナルを使う
基礎編
セッション 1 – ROS の概念と基礎演習 1.0 – ROS のセットアップ
演習 1.1 – ワークスペースの作成
演習 1.2 – パッケージのインストール
演習 1.3 – パッケージとノード
演習 1.4 – トピックとメッセージ
セッション 2 – 基本的な ROS の使用法演習 2.0 – サービス
演習 2.1 – アクション
演習 2.2 – launch ファイル
演習 2.3 – パラメータ
セッション 3 – マニュピレータの制御演習 3.0 – URDF 入門
演習 3.1 – 作業セルの XACRO
演習 3.2 – TF を用いた座標変換
演習 3.3 – MoveIt! パッケージのビルド
演習 3.4 – RViz 上での動作計画
セッション 4 – Descartes パッケージと認識演習 4.0 – C++ 上での動作計画
演習 4.1 – 直交座標系動作軌道計画入門
演習 4.2 – 知覚・認識系入門
応用デモ 1 – センサ認識を用いたマニュピレーション
デモ 1 – センサ認識を用いたマニュピレーション
応用デモ 2 – Descartes パッケージによる動作計画と実行
デモ 2 – Descartes パッケージによる動作計画と実行
応用編
セッション 5 – 軌道生成と知覚パイプラインの作成演習 5.0 – 高度な直交座標系動作軌道計画
演習 5.1 – 知覚パイプラインの構築
演習 5.2 – STOMP 入門
演習 5.3 – Python のためのシンプルな PCL インタフェースの構築
演習 5.4 – OpenCV 画像処理( Pyhton )
セッション 6 – ドキュメント生成 / ユニットテスト / ROS ユーティリティ / デバッグ演習 6.0 – ドキュメント生成
演習 6.1 – ユニットテスト
演習 6.2 – rqt 分析ツール
演習 6.3 – ROS スタイルガイドと ros_lint
演習 6.4 – ROS と Docker / Amazon Web Service
冬休みの課題として,チャレンジしてみてはいかがでしょうか.
注意点ですが,日本語版の内容に問題や間違い,改善点があった場合には,本家ではなくTORKの方へご連絡およびPull Requestをお願いします.
それではみなさま,良いお年を.
ROS2はこれからどのように開発が進んでいくのでしょうか.
2018年の9月末頃から,こちらのスレッドで,ROS1からROS2への移行計画についての議論が行われました.簡単に議論内容をまとめてみようと思います.
最初の議論の出発点は,ROS1のリリースをある年度までで辞めることにして,その間の4.5年間にコミュニティ全体でROS2への移行を進め,その後はROS2の開発に集中するというのはどうか,という提案でした.ROS1のリリースをやめる背景には,Python2からPython3への移行の問題もありました.
(… So, I’d like to know other users thoughts. Is 2023 enough time to move fully to ROS2? Do we need a LTS release in 2020? My proposal is to forgo a ROS release in 2020 and put the effort in to ROS2 instead. … by mkhansen)
これに対し,複数の賛成意見が寄せられました.
(… While no one is saying it will happen tomorrow, I’m looking forward to ramping down ROS1 development and future releases. Instead we need to focus our limited community resources on a better robotics middleware that wasn’t built in a graduate student lab in 2007. … by davetcoleman)
(… Since leaving Willow Garage in 2012, we’ve received approximately $0 directed at maintenance or improvement of ROS 1. And even if we had such funding, we’d still be limited by the number of people on our team. … by gerkey)
その一方で,ROS1からROS2への移行はもっと徐々に進めてほしいという意見もありました.
(… To me, that says that after April 2020 (only about 18 months away), it gets a lot harder to run the current ROS2 release with any ROS1 packages bridged in. Is that logic right? By releasing ROS1 on Ubuntu 20.04, you can an extra 2 years of bridge availability. by mikeferguson)
また,ROS1とROS2を共存させていくべきではないかという声もあがりました.
(… Instead of porting any package to ROS2, efforts could be spend on reducing the differences between ROS1 and ROS2 from both ends, to reduce the impact of the community split, and all costs of eventual full migration. … by tkruse)
(… As a company building solutions based on ROS 1, porting all of our code base to a new middleware would be a major effort. Our robots perform mobile picking in warehouses, where performance and reliability demands require a well-understood system. Exchanging the foundation of this very complex system and getting to a similar performance level again will not be an easy step. … I hope that we can find either a good migration path or ways for maintaining both versions for a longer time. by moritz)
やはりROS1のサポートは必要ではないか,という意見もあり,ROS1をサポートする新たな組織が必要ではないかという提案もありました.
(… I understand that OSRF cannot commit resources to ROS1 forever. But when that day comes, please let’s try to find a successor organization that takes over stewardship of ROS1…. by Martin_Guenther)
ROSのコミュニティには多様なニーズや必要性を持っている人が所属しているので,これらを可視化して,皆にとってより良い方向性を決めていくべきではないか,という意見もありました.
(… Different segments have different types of needs, requirements, costs, and constraints. Not only that, but different segments use, contribute, and maintain different types code. I think seeing a breakdown and a graph of these relationships of that would be really valuable. … by jbohren)
最後に,スレッドを立てられた方は,これまでの議論を踏まえて,ROS1からROS2移行のために必要な作業をまとめられました.
(…
Open Roboticsの方は,ROS2のこれからをこのように予想しています.
(… Given the current status and level of community contributions I expect that ROS 2 will be well-featured and very usable for a wide variety of applications long before Melodic goes EOL in 4.5 years. …
Of course, irrespective of the state of ROS 2 I expect that many many people will still be using ROS 1 in 4.5 years and even after, primarily because of a combination of familiarity and reliance on existing ROS 1 code. by gerkey)
いかがでしたでしょうか.
ROS1と比べることで,ROS2での変更点が少し探れたのではないかと考えています.また,執筆者自身は,ROS2との違いを意識することで,逆に,普段何気なくROS1を使っていることに気付かされました.ROS1の理解も少し深まった気がしています.ROS1とROS2の違いは,今回書いた点以外にもあると思いますので,皆様も是非チュートリアルを体験してみてください!
また,ROS2への移行に関する議論は,ROS1を研究で使う者として,しっかりこれからも追っていきたいです.皆様も是非ROS2を試してみてください!
それでは,早速チュートリアルを進めていきます.今回は,gbiggsさんが作成された,
ROS Japan ユーザグループ 講習会 ~ ROS 2 の紹介 ~ (https://gbiggs.github.io/rosjp_ros2_intro/index.html)
のチュートリアル資料を使わせていただきます.ROS2ならではのノードの書き方を理解し,ROS1との違いを探ることを目的とします.
Ubnutu 18.04にROS2 Bouncy をインストールします.ROS2 Bouncyのインストールはこちら (Desktop Install) を参照しました.ROS2のインストールがうまく行っているかはこちらで確認できました.
ROS 2の基本 に従ってチュートリアルを進めていきます.ROS1のチュートリアルでお馴染みの talker/ listener プログラム をROS2のノードの書き方で書いていくものです.
ROS2ならではのノードの書き方として,以下のポイントが挙げられると思います.
チュートリアルの詳細については,リンク先を参照していただきたいのですが,ここからは,チュートリアルを通して印象に残った点を挙げていきます.
1. ROS2を利用するためにインクルードするヘッダの変更(ROS2のノードの書き方を理解->コンポーネントノードのソースを読み解く->ヘッダーファイル 42行目):
#include <rclcpp/rclcpp.hpp>
ROS1におけるrospyはrclpyに,roscppはrclcppに変更になっています.
2. 初期化の方法の変更(ROS2のノードの書き方を理解->コンポーネントノードのソースを読み解く->スタンドアローンノードラッパーのソースファイル 7, 8行目):
rclcpp::init(argc, argv); auto greeter = std::make_shared();
ROS1では,
ros::init(argc, argv, "talker");
のようにROSの初期化に合わせてノードを初期化します.一方,ROS2では,ROSの初期化とノードの初期化が別々に分けられています.そのため,ノードを共有ライブラリとして実装すると,複数ノードを同一プロセスの中に入れられるようになります.
(詳しくはこちらのチュートリアルのmain関数4, 5行目
rclcpp::init(argc, argv); auto node = rclcpp::Node::make_shared("greeter");
にも説明があります.)
すべてのノードはexecutorというオブジェクトの中で実行します.
こちらのチュートリアルの greet_and_displayer.cpp 10-18行目を抜粋します.
// タイマーコールバック,トピックコールバック等を行うexecutor rclcpp::executors::SingleThreadedExecutor exec; // Greeterコンポーネントノードのインスタンスを作成しexecutorに登録する auto greeter = std::make_shared<greeter::Greeter>(); exec.add_node(greeter); // Displayerコンポーネントノードのインスタンスを作成しexecutorに登録する auto displayer = std::make_shared<displayer::Displayer>(); exec.add_node(displayer);
3. ノードなどのインスタンス作成時のスマートポインタの使用(ROS2のAPIの基本を理解->ノードの実装 main関数5行目):
auto node = rclcpp::Node::make_shared("greeter");
ROS2はC++11/14を使っているため,autoを用い,変数のメッセージ型をコンパイラに判断してもらうようにします.コンパイラに型判断をお任せできるので,ソースコードが簡単になります.
4. ノードの制御の仕方の変更(ROS2のノードの書き方を理解->コンポーネントノードのソースを読み解く->ソースファイル 19行目):
timer_ = create_wall_timer(1s, std::bind(&Greeter::broadcast_greeting, this));
ROS1の talker/ listener プログラム のチュートリアルでは,whileループを回し,一定時間ごとにsleepすることよってノードの周期を決めていました.ROS2では,リアルタイム制御や実行時間の管理のため,タイマーイベントで制御を行うことが推奨されています.
1. ビルドシステムの変更(ROS2のノードの書き方を理解->ビルド&実行):
ROS1ではcatkinを用いたビルドを行っていました.catkinは直接cmakeのみを扱います.一方,ROS2では,colconと呼ばれるメタビルドシステムを用います.colconは依存関係を考慮してパッケージのビルド順を決め,ビルドを実行します.ビルドの方法は各パッケージに任せるので,cmakeによらず複数のビルドタイプを選択可能です.
2. ソースコード実行のために実行ファイルのインストールが必須に(ROS2のAPIの基本を理解->パッケージのコンパイル方法 CMakeLists.txt 25-29行目):
# ノードの実行ファイルをインストールする(必須) install(TARGETS greeter DESTINATION lib/${PROJECT_NAME} )
ROS1ではビルド時に,すべてのビルドされたファイルがソフトリンクされた,development space (devel space) が作られました.この開発環境を用いれば,インストールせずビルドのみで開発したソフトウェアを利用することができました.一方,ROS2のcolconビルドではdevel spaceが作られないため,開発パッケージのCMakeLists.txtに,実行ファイルのインストール先を指定する必要があります.(執筆者は,ROS1でdevel spaceを用いて自身が開発したソフトウェアを実行しており,正直に書くと,これまでインストールのことを意識していませんでした.)
colconについてはこちらのチュートリアルに詳しく紹介されています.
1. source install/local_setup.bash を使用する端末で必ず一回実行(ROS2のAPIの基本を理解->ビルド&実行):
source install/local_setup.bash
ROS1でいうところの source ~/catkin_ws/devel/setup.bash の代わりです.
2. 実行コマンドの変更 ( ros2 run greeter_ros2_style greeter )(ROS2のAPIの基本を理解->ビルド&実行):
ros2 run greeter_ros2_style greeter
ros2 run displayer displayer
ROS1でいうところの rosrun greeter_ros1_style greeter の代わりです.その他のコマンドについてはこちらのチュートリアルに紹介されています.
3. roscoreが必要なくなる(メッセージ受信ノードの作成->ビルド&実行):
データ通信方式が変更になりました.ROS1では,出版購読モデルの先駆けだったため,独自の出版購読モデルを構築していました.ROS2を開発する頃には,既存のライブラリが複数登場するようになりました.そのような経緯で,Data Distribution Service (DDS) を採用しました.これにより,マスタによるノード間接続が必要なくなり,DDSミドルウェアを介して直接ノード間で接続できるようになりました.ROSにおけるDDSは,こちらのサイトに詳しい説明があります.
執筆者が一番難しさを感じているのは,CMakeLists.txtの書き方です.これまでインストールのことを深く考えたことが無かったため,単にツケが回ってきただけだと思いますが,必要な情報についての理解がまだまだ足りていません.ヘッダーファイルのマクロの理解も追いついていません.ドキュメントを読んで,勉強していこうと思います.
さらに,これはROS1のチュートリアルを最初に勉強した時と同じ感想なのですが,talker/ listenerのプログラムの書き方が分かっても,自分が今使っているロボットをどのようにROS2で動かせば良いのかについてはまだよく分かりません.センサデータが取り扱えるパッケージなどの情報があると嬉しく思います.または,既存のROS1の認識系プログラム等をROS2用に置き換える方法が分かるとありがたいなと思いました.
また,ROS2のlaunchファイルは,xml形式からpython形式になったということです.まだ開発中ということで,これから情報が増えてくることを楽しみに待っています.
皆さんはROS2を知っていますか?
ROS2は,ROSの次世代版です.ROSは元々,ロボティクス研究用ソフトウェアプラットフォームとして開発されてきました.ROSの普及に伴い,研究開発のみの用途だけでなく,製品に活用する動きが活発になってきました.その過程の中で,ROSに対する新たなニーズが生まれ,ROSのフレームワークのみで対応するのが難しくなってきました.
そこで,ROS2が新たに生まれました.2017年12月にArdent Apaloneが,そして今年2018年7月にBouncy Bolsonがリリースされ,現在も開発が続けられています.
本ブログでは,ROS2が生まれた背景について簡単に触れながら,ROS2の日本語版チュートリアル体験を通して,ROSとROS2の違いとして印象に残った点について述べていき,ROS2のこれからに関する議論を追いかけていきます.(ROSのことは,ROS2と区別して,ROS1と記述します.)
ROS1はPR2というロボットを用いたロボティクス研究開発環境として,その開発がスタートしました.当初は以下のような用途が想定されていました:
一方で,ROS1が普及することで,PR2だけでなく様々なロボットで用いられるようになったり,学術用途から製品化に用いられるようになったりしていき,以下のような新しい用途が生まれていくようになりました:
ROS1がこれまで満たしてきたニーズを維持しつつ,このような新たなニーズも満たしていくために,ROS1と切り分ける形でROS2が生まれました.
詳しい内容は,こちらのサイトに記述されています.
TORKでは,活動をお手伝いしてくれる人を大募集しています.
もちろん,報酬も出ます.学生さんやお勤めの方も副業OKなら,ぜひご相談ください.アルバイト,パートタイム,フルタイムなど,いろいろな形態で関わることができます.
以下のようなことをお手伝い出来る方なら,どなたでも大歓迎です.
興味ある方は,以下のメールアドレスまでお気軽にお問い合わせください.
jobs@opensource-robotics.tokyo.jp
11月6,7日にフランスのボルドーで開かれるオープンソースソフトウェアのカンファレンス “B-Boost” に,TORKも招待されました.ロボットやROSについて講演してまいります.
また様子を報告します.Je suis parti.
先週の金曜日にWorld MoveIt! Day 2018 in 柏の葉が開催されました! 当日の様子を写真で紹介します.参加できなかった方にも雰囲気を伝えられればと思います.
ついにWorld MoveIt! Day 2018 in 柏の葉が始まりました! ハッカソンでの課題の例についての説明などがありました.
次に,会場にロボットを展示していただいた企業の方からロボットのご紹介がありました.
皆さんもくもくと作業されています.実機でプログラムを試す方もいらっしゃいました.
午前中はお疲れ様でした!お昼ご飯の時間です.
お昼ご飯を食べながらの,参加者による発表が始まりました.
WRS2018製品組立チャレンジ参加報告とオムロンサイニックエックス株式会社のご紹介をしてくださいました.
MoveIt!の新機能,Task Constructorについてご紹介してくださいました.これにより,今までできなかった,物を掴みながら移動するといった,並列タスクが可能になるそうです.
SEED-noidの実用例を,コンビニを舞台にした競技会やレストランでの実証実験のお話などを通してご紹介くださいました.
MoveIt!でロボットを動かす際,各関節の角度を知りたい時に便利なツールのご紹介です.
発表が終わったら,ハッカソンの再開です.
お疲れ様でした!ハッカソン終了です.今日一日何に取り組んだか,発表し合います.
次回参加時の参考になる取り組みがたくさんありますね!
参加者の皆さま,ありがとうございました! 来年もお会いしましょう!
日本ロボット工業会様より,「RTミドルウェア普及貢献賞」をいただきました.カワダロボティクス様との共同受賞です.NEXTAGE Openのソフトウェアサポートが評価されました.今後ともロボット分野のオープンソース・ソフトウェアに貢献していきます.
皆さんはMoveIt!を知っていますか? MoveIt!とは,マニピュレータ用のプランニングフレームワークです. MoveIt!を使うことで,サーボの1つ1つを別々に制御するのではなく,一つのマニピュレータとして扱い,動かすことができます.
World MoveIt! DayはMoveIt!のコード,ドキュメント,コミュニティをますます発展させていくことを目的とした国際的なハッカソンです.今年の日本でのイベントは千葉県の柏の葉で,来週末に開催されます!
詳しい内容と参加登録はこちらのConnpassのページをご覧ください.
ハッカソンなんて敷居が高い?いえいえ,そんなことはありません.コードやドキュメントの修正案として,以下のようなものが事前に与えられています.参加する前に,ぜひ一度目を通してみて,出来そうな課題があれば,取り組んでみてください.
(公式のイベントサイトに記載されているものを簡単に和訳しました.)
例えば,このIssueでは,テストコード(ユニットテスト,インテグレーションテスト両方)がたくさん必要だと提案されています.このIssueでは,RVizのバージョンが上がった時に使用できないフォントを,MoveIt!で使わないようにしようとしています.このIssueでは,moveit_python (MoveIt!のPythonインターフェース)の中身を充実させていこうと提案がされています.このIssueでは,もっと初心者に分かりやすくなるように,RVizを使ったMoveIt!のチュートリアルの内容を整えていこうとしています.このIssueでは,SRDFの文法エラーがあったら,MoveIt!がエラーを出すようにしようと提案されています.
初学者がドキュメントを更新していくことも推奨されています.たとえばこのIssueは,既存のチュートリアルがちゃんと動くか,順を追って確認する,という内容になっています.MoveIt!初心者でも,当日チュートリアルをやりながら修正案を出していくのはできそうですね!
ぜひ一度目を通して,自分で取り組めそうなIssueがあれば,チャレンジしてみてはいかがでしょうか?その際には他の人と作業がかぶらなくてすむように,予めIssueにコメントしておきましょう.assignedタグは,その課題に取り組んでいる人が既にいるかどうかを判断するのに便利です.
参加の際はROSのKinetic LTS branch/releaseをインストールされたパソコンをお忘れなく.Kineticの入ったUbuntu16.04のVirtualBox イメージは公式イベントサイトからダウンロードできます.他のROS バージョンについては公式イベントサイトをご確認ください.
それでは,当日会場でお会いしましょう!
今回も有楽町にてROSワークショップ初級編を開催しました.
ご参加いただいた皆様,お疲れ様でした!
初級編では環境の構築からセンシングデバイス,サーボの実機をROSで動かすところまで半日で習得できます.
時間中にはROSに関するお困りごとだけでなく,社内でOSSを運用していく際の疑問点等にも随時お答えしています.
出張ワークショップ,プライベートワークショップ,その他OSSに関するご相談も承っております.
お気軽にお問合せください!
info[at]opensource-robotics.tokyo.jp
先日,ブログでアナログ・デバイセズ株式会社のIMU用パッケージadi_driverについてご紹介しています.
TORKがROS化をお手伝いさせていただきました ”IMU ADIS16470モジュール” について,
アナログ・デバイセズ株式会社からプレスリリースが出ました.
http://www.analog.com/jp/about-adi/news-room/press-releases/2018/9-10-2018-ROS%20Driver-ADIS16470.html
お問い合わせも多くGithubへのアクセスも活発で,好評をいただいております!
まだお試しいただいていない方は,是非IMU ADIS16470をゲットしてご利用ください!
6月27日,28日にシンガポールで開催された,ROS Industrial Asia Pacific Workshopに参加してきました.(公式ブログの更新を待っていたら,TORKのブログを更新しそびれてしまいました...)
TORKからは初めての参加です.どちらかというと,技術的な内容というより各国のプロジェクトや,企業での取り組みの紹介が多く,ROSのパッケージや技術に特化したROSConとはまた違った印象でした.その代わり,ほぼ日本では知る機会のない海外の大手企業やベンチャー企業の活動内容を知ることが出来ました.また,それらの人々と歓談する機会も多く設けられていて知り合いになれるのも非常に楽しいです.
TORKからも,活動内容と開発中のjog_controlパッケージについて紹介し,開発中の ROSネイティブティーチングペンダントについても展示し,多くの人に関心をもっていただきました.
ARTCには”Future Factroy”と銘打ったものすごく広くてカッコいい施設があり,たくさんの産業用ロボットが所狭しと並べられていました.そこで,ARTCのロボットチームのデモも見せてもらいました.ROSと最新の産業用ロボットを組み合わせで,Scan-N-Planや物体認識といったテーマをターゲットに研究を行っていました.残念ながらWS内での参加者の撮影は許されていないので様子をお見せすることができませんが,公式のブログ等で追って様子が公開されるのではないかと思います.
ワークショップ全般的に言えるのは,「全員がROSの産業応用について疑いなく一致している」ということです(ROS-Iのイベントなので当たり前ですが).ROS-Iの参加者は実際にROSを応用的な研究開発に利用しつつ,自社の製品力の強化に具体的につなげていこうとしています.また中国や台湾の会社では,ROSやROS2の製品を積極的にリリースしています.ROSの産業応用にはいくつか課題があるのは確かですが,ROSINによるパッケージ作成の支援やコード品質の管理のしくみ,Scan-N-Plan基盤技術の開発など,コンソーシアムとして大きな課題に取り組もうとしています.なにより,手を動かして作って成果を公開する,というループが回っているのがすばらしいなと感じ,TORKも負けないように頑張ろうと思いました.
そして,主催者の運営がすばらしかった! いろいろと気配りをしていただいて,大変楽しく,快適なワークショップに感謝したいと思います.
ROSはオープンソース・ソフトウェア(OSS)です.OSSは1990年代後半から2000年台前半にかけて,LinuxやApache, Java, Androidといったソフトウェアプロジェクトの隆盛とともに一般化してきました.現在では,OSS無しのソフトウェア開発など考えられない,というのが情報産業では常識です.
しかし,ロボットの分野はハードウェアが主体を占めるためか,それほどオープンソースと縁のない開発をしてきていることがあります.そのため,OSSについて必ずしも正しく理解されていないようです.よくある誤解として,
といったものがあります.どれも私たちが実際に聞いたことがある意見で,そのたびに「そんなことはないんですよー」と説明はしますが,なかなか理解してもらえないことがしばしばで,大きな悩みの種でもあります.
最近発売されたこの「OSSライセンスの教科書」は,それらの誤解を完全に解いてくれます.非常にわかりやすく,平易な文章で綴られていて,ソフトウェアを書いたことのない方,ライセンスの条文に馴染みがない方も理解しやすいようになっています.
第一部「基本編:OSSとOSSライセンス」では,代表的なOSSライセンス(GPLv2, GPLv3, MIT, BSD, Apacheライセンスなど)を解説しています.ただ単に個別のライセンスの解説に留まるのではなく,ライセンサーの「思い」や歴史的経緯の説明があり,「なぜこんなライセンスが必要なのだろう」という疑問に答えてくれます.
第二部「実務編:ソフトウェア開発とOSS」では,実際の業務でOSSをどのように取り扱うべきかという点に焦点をおいています.知的財産(特許)とOSSの関係という,実務上で非常に大事な点についても解説されています.
第三部「戦略編:OSSイノベーション戦略」は特に注目です.OSSライセンスにとどまらず,OSSをどういう場面で使うべきか,OSSやコミュニティに関わるということはどういうことなのか,その対局にある「フリーライダー」とは何なのか,といった話題を扱っています.当然ですがどれもROSとまったく共通の話題で,私たちTORKが日々理解してもらおうと努力している部分でもあります.
この本のおかげで,これから私たちはただ,「あなた,それは誤解ですからとりあえずこの本を読んでください」と言えば良くなりました.まさに教科書,バイブルと言えましょう.よくぞ書いてくれました!
技術に携わる全ての人が(それにマネージャや経営者も!)読むべき本であると断言できます.まずは読んでみてください.
以下日程でROSワークショップを行います.
9月12日(水)13:30~ ROSワークショップ初級編
10月2日(火)13:30~ (名古屋) ROSワークショップ初級編
10月3日(水)13:30~ ROSワークショップ初級編
場所は都内・有楽町の会議室または名古屋市内での実施を予定しています.
プライベートでのお申込みが大変増えております.
人数が揃うようでしたら,プライベートでのワークショップ,出張のワークショップも開催可能です.
中級編については公開されている日程以外はご要望があり次第,日程を調整にて開催いたします.
メイルにてお問い合わせください.
(初級者以上,初級編を受講した方を対象としております.中級マニピュレーション編のページまたは中級・自律移動編のページをご参照ください)
お申込みは以下より詳細をご確認の上,ページ内のお申込みリンクよりエントリをお願い致します.
上記以外での日程の調整,その他ご相談,開発委託,出張ワークショップ,カスタマイズワークショップも承っております.
お気軽にご相談ください.
info[at]opensource-robotics.tokyo.jp
今回も有楽町にてROSワークショップ初級編を開催しました.
ご参加いただいた皆様,お疲れ様でした!
初級編では環境の構築からセンシングデバイス,サーボの実機をROSで動かすところまで半日で習得できます.
時間中にはROSに関するお困りごとだけでなく,社内でOSSを運用していく際の疑問点等にも随時お答えしています.
出張ワークショップ,プライベートワークショップ,その他OSSに関するご相談も承っております.
お気軽にお問合せください!
info[at]opensource-robotics.tokyo.jp
本日2018年8月8日,おかげさまで TORK は設立5周年を迎えました.
これまで支えていただきましたすべての皆様に,心から感謝と御礼を申し上げます.
これからもお客様のご要望に応え,産業・学術界でのオープンソースロボティクスの進展に寄与できるよう,より一層努力して参ります!
今後とも東京オープンソースロボティクス協会(TORK)をご支援ご愛顧くださいますようお願い申し上げます.
日本ロボット学会の研究専門委員会の1つ「ネットワークを利用したロボットサービス研究専門委員会」の2018年度第二回研究会にて「ROSの10年間と動向」と題して講演させていただきました.
お伝えしたいことが多すぎて質疑応答の時間を押してしまいましたが,まとまったお話をできる機会をいただき感謝しております.
ROSを導入する際の社内での周知や疑問点の解消のための出張プレゼンテーションも承っております.
出張ワークショップ,ROSコンサルティングサポート,その他OSSに関するご相談も承っております.
お気軽にお問合せください!
info[at]opensource-robotics.tokyo.jp
日頃より弊社サービスをご愛顧賜り,誠にありがとうございます.
弊社では,下記の期間を全社一斉の夏季休業とさせていただきます.
夏季休業期間:2018年8月11日(土)~2018年8月19日(日)
休業期間中にいただきましたE-mail等のお問い合わせにつきましては,8月20日(月)より順次対応とさせていただきます.
お客様には大変ご不便をおかけいたしますが,何卒ご理解のほど,宜しくお願い申し上げます.
今回も有楽町にてROSワークショップ初級編を開催しました.
ご参加いただいた皆様,お疲れ様でした!
初級編では環境の構築からセンシングデバイス,サーボの実機をROSで動かすところまで半日で習得できます.
時間中にはROSに関するお困りごとだけでなく,社内でOSSを運用していく際の疑問点等にも随時お答えしています.
出張ワークショップ,プライベートワークショップ,その他OSSに関するご相談も承っております.
お気軽にお問合せください!
info[at]opensource-robotics.tokyo.jp
以下日程でROSワークショップを行います.
名古屋でも開催いたします!
8月7日(火)13:30~ (名古屋) ROSワークショップ初級編
8月8日(水)13:30~ ROSワークショップ初級編
場所は都内・有楽町の会議室または名古屋市内での実施を予定しています.
プライベートでのお申込みが大変増えております.
人数が揃うようでしたら,プライベートでのワークショップ,出張のワークショップも開催可能です.
中級編については公開されている日程以外はご要望があり次第,日程を調整にて開催いたします.
メイルにてお問い合わせください.
(初級者以上,初級編を受講した方を対象としております.中級マニピュレーション編のページまたは中級・自律移動編のページをご参照ください)
お申込みは以下より詳細をご確認の上,ページ内のお申込みリンクよりエントリをお願い致します.
上記以外での日程の調整,その他ご相談,開発委託,出張ワークショップ,カスタマイズワークショップも承っております.
お気軽にご相談ください.
info[at]opensource-robotics.tokyo.jp
以下日程でROSワークショップを行います.
名古屋でも開催いたします!
7月24日(火)13:30~ (名古屋) ROSワークショップ初級編
7月25日(水)13:30~ ROSワークショップ初級編
場所は都内・有楽町の会議室または名古屋市内での実施を予定しています.
プライベートでのお申込みが大変増えております.
人数が揃うようでしたら,プライベートでのワークショップ,出張のワークショップも開催可能です.
中級編については公開されている日程以外はご要望があり次第,日程を調整にて開催いたします.
メイルにてお問い合わせください.
(初級編を受講した方を対象としております.中級マニピュレーション編のページまたは中級・自律移動編のページをご参照ください)
お申込みは以下より詳細をご確認の上,ページ内のお申込みリンクよりエントリをお願い致します.
上記以外での日程の調整,その他ご相談,開発委託,出張ワークショップ,カスタマイズワークショップも承っております.
お気軽にご相談ください.
info[at]opensource-robotics.tokyo.jp
6月27日,28日にシンガポールで開催される,ROS Industrial Asia Pacific WorkshopにTORKも参加します.
SwRI, FaunhoferIPAといった北米,EUのROS-Iデベロッパーからの講演や, OpenRobotics, ADLINK,ボーイング,といった企業メンバからの発表があります.どのような話が聴けるのでしょうか.
TORKも現在開発中のパッケージなど,幅広い活動をアピールしていきたいと思います.内容についてはまたブログにて報告します.
ROSとMoveIt!は,ロボットアームのための非常に強力なツールです.ROSの基本機能とros_controlの枠組みにより,どのようなロボットアームも統一的なインターフェースで動かすことができます.その上で動くMoveIt!は,障害物の回避や拘束条件を考慮したロボットアームの動作計画を,色々なアルゴリズムを使って簡単に行うことができます.ROS-Industrialレポジトリを見ると,色々な産業用ロボットアームをROSとMoveIt!を使って動作させるためのパッケージが,すでに公開されています.これらの機能は,産業用ロボットアームをROSで使おうという大きな動機となっています.
しかし実際に使ってみると,産業用ロボットアームがあたりまえに備えている機能が,逆にROSには無いことに気づくのではないでしょうか? それは,ジョグ動作とティーチングです.
ジョグ動作というのは,ロボットの関節や手先を実際にちょっとずつ動かして,目標のロボット姿勢に到達させる機能です.ジョグ動作により,ロボットを目視しながらロボットの関節角度の微小な変位量を連続して与えて動かすことができ,ワークとの位置合わせなどでは必須の機能です.MoveIt!のrvizプラグインはGUI(Interactive Marker)でロボットの手先の目標位置姿勢をマウスで指定することができます.しかし,ロボットが仕事をする姿勢は実際にロボットを環境に置いて動かして指定するのですが,やってみるとrvizプラグインでは思い通りに動かすのは少し,いえ,かなり難しいです.
ティーチングというのは,目的のロボットの姿勢を覚えさせた上で,目的のタスクに対してその到達の順番や