ROS とは？ROS は何が嬉しいのか？

ROS(Robot Operationg System)は、ロボット・アプリケーションを容易に記述するために開発された、オープンソース・ソフトウェア(BSD ライセンス + Apache 2.0ライセンス)です。また、ROS は Operating System とは言っても、Linux や Windows、組込み向けの RTOS と同列に位置する存在でなく、これらの OS 上で動作するミドルウェアの位置付けにあります。(上図は、github.com/xuefengchang/micros_swarm_framework、github.com/ros-planning/panda_moveit_config、github.com/ros-planning/moveit_tutorials、https://github.com/husky/husky を動作させた結果の画面コピー)
そのような ROS ですが、どの様な点が便利なのでしょうか？
ご存知の方も多いと思いますが、

– Rviz、Gazebo といった、視覚化パッケージや、シミュレーション環境が用意されていること
– moveit のような、多関節ロボットで頻繁に用いられる複雑な計算パッケージが用意されていること
– 種々 SLAM デモ・パッケージに代表される障害物回避等の、はやりの研究成果などが公開されていて、試すことができること
* 東京2020五輪のドローンによる演出のような、複数ロボットによる集団動作(Swarm)のフレームワークも ROS での用意があります。

等が挙げられると思います。

組込み製品で ROS を使う場合の難点とは？

ROS コミュニティである、ROS.org の記載内容を見ると分かるのですが、ROS が動作する標準プラットフォームとして、Ubuntu Linux が取り上げられています。ネットで紹介されている記事もUbuntu で作業したものが多く見受けられます。

一方で、ROS にも、Linux や、Windows と同様、バージョンがあり(もちろん、弊社の扱う RTOS の VxWorks にもありますが。。。)、Ubuntu のバージョンとの関連は右の表のようになっています。

この関係を無視すると、Ubuntu と言えど、簡単には ROS を使わせてはくれません。実際、ROS Kinetic を使おうとして、何も考えずに Ubuntu 18.04 LTS で作業して、結構な時間を費やした後、16.04 LTS に変更。。。なんてこともありました。

ところで、非 Ubuntu の Linux で、ROS を使いたい場合、何か参照できるものがあるか調べてみると、http://wiki.ros.org/hydro/Installation/OpenEmbedded がありました(2021年8月12日現在も存在)。URL 中の、OpenEmbedded は、yocto Linux のことなのですが、ここに記載の、”おそらくこうであろう” 諸々のことを行って、いざ build、

$ bitbake core-image-ros-roscore

とやっても、早い段階で ERROR 終了してしまい、なかなかゴールできそうにありませんでした。

yocto Linux や、RTOS で ROS を使用するために

RTOS の「VxWorks」や、yocto ベース Linux の「Wind River Linux」で、ROS 環境を構築する手順が、Wind River によって公開されていますので、参考までに以下を案内しておきます。

– Wind River Linux ： https://github.com/Wind-River/wr-ros
– VxWorks ： https://github.com/Wind-River/vxworks7-ros2-build

Wind River Linux の方は、intel-x86-64 あるいは、Raspberry Pi 4 のいずれかの手順についての記載です。

ROS のバージョンに関しては、ROS 2 foxy です。Raspberry Pi 4 では試していませんが、intel-x86-64 では、Rviz2 まで含めて build する手順があり、下図のような、Rviz2 の動作などを確認しています。

一方、VxWorks の ROS については、ROS 2 のデモなどで紹介される、timer_lambda — 周期的に Hello ・・・ をコンソールに出力するだけのコードですが、https://github.com/ros2/examples/tree/master/rclcpp/topics/minimal_publisher 以下のものが動作していますので、一般的な ROS のコードが動作することへの裏付けになります。

動作させるまでに、POSIX thread、semaphore、pipe 等が使えること、および、CMake の Build が行えることが OS や、Build 環境の前提になっていることが分かったので、その点では、VxWorks は、ROS に十分対応できる開発環境であると言えます。

バージョン依存を何とかしたい — Linux での一案

yocto Linux や、RTOS でも ROS を使用する手順が存在することを紹介しました。

ところで、ROS には、2つの流れが存在します。ROS 1 と ROS 2 です。ROS 2 も OS のバージョン依存があって、ROS.org の記載を抜粋すると、右の表のようになっています。ROS 2 では、Windows はもとより、OE(yocto) に関する記載も増えてます。

ROS 2 は、ROS の機能拡張バージョンになるのですが、我々の付き合いのある範囲で話を聞いても、製品搭載を考える場合、ソフトウェア資産の豊富さから、ROS 2 ではない、ROS 1 という選択の方が多いようです。

そのような状況を踏まえると、先に紹介した Wind River Linux での、ROS 環境構築手順は、ROS 2 のものだったのですが、この Linux 環境に加えて、 ROS 1 の環境も追加できる方がよさそうです。ただ、Wind River Linux (すなわち yocto) の package manager で、ROS 1 環境を構築するのは、かなり手間がかかりそうです。そこで、Docker コンテナの利用を考えてみました。

ROS 1 のコンテナが、docker hub にいくつか存在しますので、それを利用します。以下 root@intel-x86-64:~# のコンソールは、ROS 2 の環境のみ構築された Wind River Linux のものです。(docker を使用するための package は予め組み込んでおく必要があります)

root@intel-x86-64:~# docker pull ros:kinetic — ROS kinetic(ROS 1) イメージを取得
root@intel-x86-64:~# docker network create ros — 仮想ネットワーク “ros” を作成

動作イメージの構成は下図のようになります。talker と listener が master(roscore) によって、メッセージの授受を行います。

〇 コンソール -1 で、ROS 1 コンテナを起動(master と listener 用)

root@intel-x86-64:~# docker run –rm –name master –net=ros -it –env ROS_MASTER_URI=http://master:11311 ros:kinetic
root@5e812e2ac6c3:/# apt update
root@5e812e2ac6c3:/# apt install -y ros-kinetic-ros-tutorials ros-kinetic-common-tutorials — ROS 1 チュートリアルのインストール

〇 コンテナで master、listener を起動

root@5e812e2ac6c3:/# /opt/ros/kinetic/bin/roscore & — コンテナで ROS master(roscore) を起動
root@5e812e2ac6c3:/# /opt/ros/kinetic/bin/rosrun roscpp_tutorials listener — listener を起動
br-3f79703f70f2: port 2(veth344a8e6) entered blocking state
br-3f79703f70f2: port 2(veth344a8e6) entered disabled state
device veth344a8e6 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): veth344a8e6: link is not ready
eth0: renamed from veth1ba4c1f
IPv6: ADDRCONF(NETDEV_CHANGE): veth344a8e6: link becomes ready
br-3f79703f70f2: port 2(veth344a8e6) entered blocking state
br-3f79703f70f2: port 2(veth344a8e6) entered forwarding state
★ listener 受信待ち

〇 コンソール -2 で、もう一つ、ROS 1 コンテナを起動(talker 用)

root@intel-x86-64:~#docker run –rm –name talker –net=ros -it –env ROS_MASTER_URI=http://master:11311 ros:kinetic
root@f78c0cc078a1:/# apt update
root@f78c0cc078a1:/# apt install -y ros-kinetic-ros-tutorials ros-kinetic-common-tutorials —  ROS 1 チュートリアルのインストール

RTOS の ROS と、Linux ROS を組み合わせる

ROS の設計思想として、それぞれの処理を小さい単位に分けて、それらを組み合わせて、全体のシステムを構築してゆくというものがあると思います。その処理単位を node と呼び、それぞれが通信し合って動作します。そのため、通信を制御する master と呼ばれる処理が存在しています。さらに、同期通信のための message、非同期通信のための topic が存在します。

そのため、ROS の実装に際しては、ROS のフルセットを一つの OS に構築するのではなく、グラフィック資産の貧弱な RTOS では、例えば、Rviz 等のパッケージは実装せず、グラフィック部分は Linux や Windows で分担し、node 間の通信によって全体のシステムを構成する考え方もあると思います。

今回の確認では、IP アドレスの異なる 2つの Linux の ROS node(ROS 1 のチュートリアル/ talker <—> listener)での動作を確認してみました。(片方は VxWorks で確認したかったのですが、準備が間に合いませんでした。次回別の形で紹介したいと思います。また、python のコードを使ったため、先ほどとログが若干異なります)

〇 listener 側

$ export ROS_MASTER_URI=http://192.168.13.233:11311 — master(roscore) が動作している IP アドレス
$ rosrun rospy_tutorials listener.py
★ 受信待ち

〇 talker 側

root@f1b9c68212fc:/# export ROS_MASTER_URI=http://192.168.13.233:11311 — master(roscore) が動作している IP アドレス
root@f1b9c68212fc:/# rosrun rospy_tutorials talker.py
[INFO] [1629367891.448477]: hello world 1629367891.45
[INFO] [1629367891.549460]: hello world 1629367891.55
[INFO] [1629367891.650578]: hello world 1629367891.65
・・・

〇 再び listener 側

★ 受信出力開始
[INFO] [1629367471.064544]: /listener_5605_1629367247193I heard hello world 1629367471.06
[INFO] [1629367471.164554]: /listener_5605_1629367247193I heard hello world 1629367471.16
[INFO] [1629367471.264580]: /listener_5605_1629367247193I heard hello world 1629367471.26
[INFO] [1629367471.363884]: /listener_5605_1629367247193I heard hello world 1629367471.36

rqt_graph(github.com/ros-visualization/rqt_graph) という、動作状況を図にしてくれるツールがありますので、上記例の場合の出力結果を以下に紹介しておきます。

まとめ

組込み OS で ROS を使う手順を紹介し、ROS の環境構築の負荷を軽減するための一例について記述してみました。ROS に限らず、環境構築や、そのメインテナンスに関しては少なからず負担になっている作業だと思われますので、工夫することも必要だと思います。

次回以降の予定

今回は、実例に乏しかったので、次回以降は、

– ROS 1、ROS 2 混在での、アプリケーション構築 — ros1_bridge を使う
– VxWorks で実際に ROS を動作させるまで – コンテナのレイテンシに関する考察

等に焦点を当ててみたいと思います。

※ Wind RiverおよびVxWorksは、Wind River Systemsの登録商標です。

※ 本文中、”表1. ROS 1 バージョン履歴” は、wiki.ros.org/Distributions の内容を抜粋して作成しました。
上記抜粋部分に関しては、the ROS wiki により右記ライセンスに従 いライセンスされます。Creative Commons Attribution 3.0

※ 本文中、”表2. ROS 2 バージョン履歴” は、github.com/ros2/ros2_documentation/blob/galactic/source/Releases.rst の内容を抜粋して作成しました。
上記抜粋部分に関して は、ros2/ros2_documentation により右記ライセンスに従いライセンスされます。Creative Commons Attribution 4.0