choreonoid_ros パッケージについて

現状,choreonoid_rosという名称のパッケージが,中岡先生のものと金広先生のものとで重複して存在してしまっています.
ROSのパッケージの名前空間上あまり嬉しくない状態です.

@nakaoka
ROS上でのChoreonoidの起動については,中岡先生のものを今後は主に使う,という方向性でよろしいでしょうか?

そのつもりだったのですが、現状では元のchoreonoid_rosに機能的に追いついていないですし、今もそちらを使っていらっしゃる方が居られるということで、この状況で同じパッケージ名にするのは傲慢な気もしてきました。

そこで考えたのですが、現在はros2もあるので、公式版をchoreonoid_ros1というパッケージ名にするというのもありかなと思いました。今後ros2対応版を出す時はchoreonoid_ros2にするとして。

この名前でおかしくないか、違和感はないか、ご意見いただければ幸いです。(以前はros1しかなかったのであえてros1という名前をつけているパッケージはあまり無さそうなので、その点違和感はないかなぁと。まああまり気にしなくてもよいですよね?)

あと気になったのは、ROS2用のパッケージで_ros2みたいな名前が付いたパッケージが既にあるようだと、この名前でやりやすいですね。そのあたり何かご存じでしたら教えてください。

あるいは同じソースでROS1とROS2の両方に対応するようなパッケージとかあったりしますでしょうか。ROS2についてはよく分かっていないのですが、ビルドシステムでROS1かROS2かを認識できて、それによってビルド内容を変えられるとか。そうだとすると_ros2みたいな名前は一般的ではないかもしれませんし。

なるべく名前の付け方は既存のパッケージの慣習に合わせたいので、その点で「ROS1、ROS2用にソースを分けて、それぞれ_ros1、_ros2といった名前を付与する」というやり方に違和感がないかが少し気になっています。

そこで考えたのですが、現在はros2もあるので、公式版をchoreonoid_ros1というパッケージ名にするというのもありかなと思いました。今後ros2対応版を出す時はchoreonoid_ros2にするとして。

個人的には悪くないと思います,しかし,このようなrosの名を含めた命名規則のパッケージはかなり少ないというのが実情です.

私もROS2について十分に追えているわけではないのですが,

  • 同一パッケージでブランチを分けているもの
  • rviz2moveit2 のように単純に2が付加されているだけのもの

が圧倒的に多いように感じております.

ここで例示するのは野暮かもしれませんが,おそらく金広先生のchoreonoid_ros_pkgの元であろうgazebo_ros_pkgsはブランチ管理の方法でROS1とROS2両方に対応しているようです.

Choreonoid自体は別にROS専用のパッケージではない,というのが大前提ですので,既存のROSパッケージの命名規則に従う必要があるわけでもなく,その分命名の自由度はあると思います.

一点懸念としては,choreonoid_roschoreonoid_ros{1,2}が共存するのはやはり紛らわしい,というところです.
どのように新規命名するにしても現在の金広先生のところのchoreonoid_ros_pkg/choreonoid_rosについては,機能を完全に継承した上で削除する方針にするべきかと思います……

1 Like

追記ですが,パッケージ名が重複したとしても,aptなどで公開するようになってしまえば,あまり影響がないように思えました.

ご見解をお知らせいただきありがとうございます。大変参考になります。

なるほど、そこが一番の問題ということですね。
追加でいただいたコメントと合わせて、パッケージ名自体はそれほど本質的な問題ではないようですね。

「機能を完全に継承した上で」というところは少し精査したいところではあるのですが、いずれにしても従来のchoreonoid_rosと同等の機能を公式版で提供することが重要な部分かと思います。その点は Onishiさんと同じ認識かと思います。

この件私の方で対応したい思いもあり、その旨もお伝えしてきていたのですが、ご存知のようにまだ手が付いていない状況で、大変申し訳なく思っています。

最近の認識としましては、このROSの件もそうですが、他にもChoreonoidに関して様々な要望が寄せられており、Choreonoid自体の規模や要望の幅の広さを考えると、正直なところ私一人でそれら全てに対応するのは難しい状況になってきました。これはChoreonoidの使用が広がっていることでもあるので、大変有り難いことではありまして、それらに応えるために会社を設立したという経緯もあります。実際に会社の方は順調に仕事をいただいておりまして、その中で行ったChoreonoid本体に対する改良はそのままオープンソースに還元するという良い流れにあり、この取り組みを発展させたく思っています。その一方で、オープンソースソフトウェアとして誰でも無償で使える状態にあり、必ずしも対価をいただけない要望もある以上、オープンソースソフトウェアとしての開発コミュニティも充実させていかないと、うまく回っていかないというところがあるかと思います。

そのような観点で振り返りますと、これまでChoreonoidに対して貢献しようにも、どう貢献してよいか分からなかったり、貢献してもあまり報われ無さそうな雰囲気があったかもしれません。この点を改善することで、コミュニテイを充実させ、今後もChoreonoidをオープンソースソフトウェアとして発展させられないものかと考えております。

ただし私一人ではこれは難しいので、皆様の知恵や力をお借りしたく思っています。そこで考えたのですが、この件に関心をもっていただける方でまず一度「Choreonoidコミュニティ会議」のようなかたちで集まって、議論できればと思っております。この件あらためてフォーラムの別トピックで相談しようと思います。

全然本トピックの回答でない上に長くなってしまいすみません。ROSプラグインについても、まず必要な機能に関して意見交換を行って、その上でもし協力いただける方がいればどう協力していくかの体制づくりをできればと思います。もちろんこの件は私が一番責任がありますので、協力が難しい場合でも私の方で少しずつ構築していこうとは思っておりますが、その場合でもまず意見交換はできるとうれしいです。

3 Likes

ご回答ありがとうございます.

「機能を完全に継承した上で」というところは少し精査したいところではあるのですが、いずれにしても従来のchoreonoid_rosと同等の機能を公式版で提供することが重要な部分かと思います。その点は Onishiさんと同じ認識かと思います。

そうですね,それから,どれが公式のパッケージなのか,という点についても再度明示する方が良いかもしれません.
ただ公式として提供する場合,ただコードを書くだけでなく,ドキュメント整備等の必要もありますので,かなり時間が必要になると思います.

会社が順調なのは何よりです.
コミュニティについて,ミートアップなど行っていければ良いのかなと感じております.
(中岡先生のスケジュールの許す範囲で,早めに一度行えると良いかもしれません)
プラグインの設計ができてしまえば,私たちユーザとしても,コントリビュートがかなり楽になるかと思います.

企画などでも,もしお手伝いできることがあれば,ご相談いただければと思います.
取り急ぎ……

1 Like

既にご存知かとは思うのですが、最近マニュアルにROSプラグインに関するページを追加していて、
https://choreonoid.org/ja/manuals/latest/ros/index.html
以下のページでどれが公式かもいちおう注釈を入れています。
https://choreonoid.org/ja/manuals/latest/ros/build-choreonoid.html#id2

ちなみに昨年末に某所でROS連携に関する講習会を開催しまして、その際に自前でROS連携を行う方法を紹介するサンプルとチュートリアルを作成しました。
サンプルは以下のリポジトリになります。

内容は従来のTankチュートリアルと同様のことをROSで行うというものです。
このチュートリアルのドキュメントを作成してマニュアルに載せようと思っていたのですが、その際に使える時間が尽きてしまい、保留となっています。3月には時間がとれそうなので、チュートリアルは早めに完成させたく思っています。

私としては「choreonoid_rosと同等のすぐに使える各種通信機能を公式版で提供することが重要」であるという認識はあるものの、「トピックとかのやりとりを自前で書けばやりたいことはできるはず」という考えも同時にありまして、まずは後者に関する情報の提供を優先できればと思っています。

ご意見ありがとうございます。
少し遅くなりますが3月上旬くらいの予定で企画してみようと思います。

ありがとうございます!
Onishiさんにはぜひご参加いただきたいです。
まずはフォーラムに開催案をのせようと思いますので、よろしくおねがいします。

1 Like

注釈を見落としていました,失礼しました.
ありがとうございます.

よろしくお願いします!

すみません、この件3月上旬くらいでと申したのですが、コロナウィルスの件もあり、しばらく様子をみたいと思います。期待をもたせておいて大変申し訳ないです。(やるとしても小規模なものになると思いますので、そこまで気にすることもないかもしれませんが、念の為ということで。実は私が講演する予定だった3月開催の某イベントも中止になってしまいまして、今はそういう時期なのかなと・・・。)

choreonoid_rosの件ですが、実は会社の方でここのところChoreonoidのROS連携に関わる仕事もしておりまして、サンプルなども作りながら、今後どのようなものを構築していったらよいか考えておりました。

その中で旧choreonoid_rosパッケージについても内容を再確認しまして、どのようなものが必要かひととおり把握できてきました。それを参考にしながら、とりあえず仕事で必要になった/clockトピックのpublish機能などを実装しておりました。(旧choreonoid_rosと同様に、WorldROSItemというものを定義して、そこに実装しています。)

今後旧choreonoid_rosの機能で必要なものを順次実装していきたいと思っています。ただそちらのマニュアルをみたところ、概ねgazeboのAPIを踏襲しようとしているようですが、以下の「機能比較」にあるように、未実装のものも多いようですね。

https://fkanehiro.github.io/choreonoid_ros_pkg_doc/html-ja/manual.html#features-comparison

また、調べたところGazeboで使用しているトピックやサービスについて、設計に少し疑問を感じる点もありました。例えばset_model_stateやset_link_stateはリンクの位置姿勢を設定するものですが、シミュレータでそのようなインタフェースだと、制御には使えないでしょうし、初期位置を通信で設定したいことがあるのか、あるいはGazeboをビュアー的に使用したいのか、イマイチ意図が分からないところがあります。またこれらはリンクごとに独立して通信するようになっているので、モデルやワールド全体の状態を通信しようとしたときに、時間が進行していると、モデルの姿勢にズレが出てしまうことになりそうです。(ズレを防ぐためには、独立して送信されたメッセージが同じまとまりであることを示すためのID値やタイムスタンプといったものが含まれる必要があるかと思うのですが、なぜかそのようなメンバも定義されていませんし、あまり使えない感じがしました。)

それで、実際のところ、これまで使われていたのは、以下の「ROSトピックス」の項目

https://fkanehiro.github.io/choreonoid_ros_pkg_doc/html-ja/manual.html#ros-topics

にある、

  • /[robotname]/joint_states
  • /[robotname]/[controlmode]/set_joint_trajectory
  • /[robotname]/[sensorname]

といった部分なのではないかと思いました。とりあえずこれらを使って制御ができればよいのかなと。

そのあたりも含めて、GazeboのAPIということになるといろいろあるにはありますが、実際に必要なもの(優先度の高いもの)はどれなのか、実際に機能を必要としているユーザーさんからご意見いただけると助かります。

3月には少し時間がとれそうですので、優先度が分かれば、優先度の高いものから実装を進めていければと思っています。

3 Likes

以前ここで以下の書き込みをしました。

これについて、チュートリアルのマニュアル化を少し進めることができたので、アップしました。
https://choreonoid.org/ja/manuals/latest/ros/tank-tutorial/index.html

まだステップ1までしか書けていないのですが、多少の参考になるのではないかと思います。ステップ2以降についても今後時間のあるときにマニュアル化を進めたいと思いますが、ソースコード(launchファイル含む)はステップ5までありますので、ある程度分かっている方であればステップ1までの説明で残りも進められるのではないかと思います。(そこまで出来る人はチュートリアルもいらないかもしれませんが…。)

1 Like

チュートリアルの概要を記したPDFもここにアップしておきます。概要のみですが、ステップ5まで含まれています。

ROS版Tankチュートリアル.pdf (207.6 キロバイト)

1 Like