sensorの名前がkeywordではないのでアクセスできなくなっている

[YoheiKakiuchi]

@snozawa このセンサの名前を文字列にするのはなぜ必要だったのでしたか？
9d9cf0a

副作用として、以下のようにアクセスできていたのができなくなっています。

(send *robot* :force-sensor (car (send-all (send *robot* :force-sensors) :name)))

--> irteusgl 0 error: cannot find method lfsensor in (forward-message-to (car (send self :force-sensors)) args)

https://github.com/start-jsk/rtmros_common/blob/master/hrpsys_ros_bridge/euslisp/rtm-ros-robot-interface.l で

(send *ri* :state :force-vector)

がエラーになります。

[k-okada]

こういうことが起るのでテストコードを作りましょう．

[orikuma]

コミットログを見る限りではsymbolで無視される大文字小文字の差異を別物として扱えるように
symbolからstringに変えたようですが,
テストコードは書くとして結局これはどう直すのが正解なのでしょうか.

候補としては

1. :nameにstringを入れてsymbolを入れるplistを新しく作る(:symbol-nameとか)
2. :nameにsymbolを入れてstringを入れるplistを新しく作る(:string-nameとか)
3. string -> symbolの変換関数を作ってsymbolが欲しいときはその変換を噛ませる(jmanualを見る限りでは出来るのかどうか不明)
   等がありますが, 1, 3の場合rtm-ros-robot-interface.lをはじめとした関連する
   コードの変更が必要になります.
   ただlinkでの使い方ををはじめとして:nameはもともと表示のためのstringを入れるものとしての扱いを
   想定しているようなので(参照: euslispのjmanual), :nameにはstringを入れるのが正しい気もします.

[YoheiKakiuchi]

判断のポイントはロボットに

 send *robot* :<sensor_name>

のようなアクセスをする必要があるかどうかですかね。
ここのsensor_nameは普通にしていては大文字小文字の区別をつけないので。

 send *robot* :sensor "sensor_name"

でアクセスするのはどうでしょうか？

[k-okada]

なんか同じ議論がirtmodelかpr2の時にあった気がします．さがしてもパッとメールがでてこないんだけど．その時はどういうことになったんだっけ？

テストプログラムは
send robot :sensor "sensor_name"でもsend Robot :sensor
'sensor_nameでも何でもいいので，それを使うコードを一つサンプルに
いえておけば，そこでコケるから分かるよね，程度でいいとおもいます．

2014-04-15 21:29 GMT+09:00 Yohei Kakiuchi [email protected]:

判断のポイントはロボットに

send robot :<sensor_name>

のようなアクセスをする必要があるかどうかですかね。
ここのsensor_nameは普通にしていては大文字小文字の区別をつけないので。

send robot :sensor "sensor_name"

でアクセスするのはどうでしょうか？

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-40475438
.

[snozawa]

すいません、こちら忘れていました。
PReqをだしました。

もともと議論があって、もろもろ合意にいたったルールとしては、

• できるだけモデル変換の後のフォーマットで、変換前のフォーマットの情報を残す

があります。
ちょっと前まではeuslspモデルのリンクやジョイントの名前がシンボルでしたが、
変換前後の整合性がとれない（とくに大文字小文字なくなってしまう）というのがあって、
名前などでstringをサポートするようになりました。
今回のバグは、シンボルにしたところを直したのに関連して、直す必要のあるところが治ってないのが原因でした。

モデルに関連するテストは、Euslispモデルがないとできないので、結構テストが難しいですね。
今回はsamplerobot.lでも起きるバグですが、そもそもsamplerobot.lはhrpsys_ros_bridge_tutorialsがないと生成されないです。

一つありえる方法は、生成物をどこかにコミットする(今回のケースだとeus/models)、でしょうか。

[k-okada]

ちょっと前まではeuslspモデルのリンクやジョイントの名前がシンボルでしたが、
変換前後の整合性がとれない（とくに大文字小文字なくなってしまう）というのがあって、
名前などでstringをサポートするようになりました。

は以下だっけ？　Issueへのリンクが無いので，どうしてこうなったかわからないですね．メールは無かったっけ？

euslisp/jskeus@b6f4d94

send robot :sensor "sensor_name"
が許されている書き方？　ただ，そもそもこれってjskeusにはなくてeuscollada-robot.l にしかないメソッド？
であれば，やっぱりそもそも何かおかしいので，jskeusのモデルにサポートして，sample-robot-model.l
をつかったサンプルで

(dolist (l (send *robot* :links))
  (print (send *robot* :link (send l :name))))
(dolist (s (send *robot* :sensors))
  (print (send *robot* :sensor (send s :name))))

みたいな事が書いてあれば，テストになるし，これが正しい使い方，というふうにできて，

一つありえる方法は、生成物をどこかにコミットする(今回のケースだとeus/models)、でしょうか。

みたいなことをしなくていいはずです．

[snozawa]

は以下だっけ？　Issueへのリンクが無いので，どうしてこうなったかわからないですね．メールは無かったっけ？

時期的には、だいたいこのくらいだったんだと思います。
結局は整合性をとることが重要で、stringを採用したという経緯でした。

send robot :sensor "sensor_name"
が許されている書き方？　ただ，そもそもこれってjskeusにはなくてeuscollada-robot.l にしかないメソッド？

そうです。
ただ、おっしゃるとおりeuscollada-robot.lでなくて、euslispにはいっててほしいコードですね。
これはirtrobot.lに追加しておきます。
多分、pr2eus/pr2.lにかいてある:cameraメソッドが元ネタで、pr2.lがirteusにはいってないから、euscollada-robot.lにいれたんだったと思います。
今となっては、force-sensorもimu-sensorもcameraも、irtrobot.lに追加するので良いきがしてます。

一つありえる方法は、生成物をどこかにコミットする(今回のケースだとeus/models)、でしょうか。
みたいなことをしなくていいはずです．

これは必要だと思います。
もっというと、hrpsys_ros_bridgeのサンプルなどもそうですが、
ロボットが関係しそうな部分はできれば全ロボットでテストしたいです。

今回のバグも、あるロボットでは:rasensorみたいにシンボルでアクセスして、
別ロボットでは"rasensor"でアクセスすることになるので、
一個のサンプルだとなりなくて、ロボットごとの差異も含めてチェックすべきと思います。
本当はこの辺は内部のjenkinsでもテストしてたのですが、jenkins側がgithub移行できてないのと、
testコードはコードの近くに置いたりすべきとも思って、今はとまってました

[k-okada]

話を理解していないかもしれないけど，生成物をコミットすると，生成ツールを変更した時に手作業が必要になって，それが面倒になると直接書き込んで，二度と自動生成できないのでよくわからなくりますね．nervousのAutobalancerが良い例です．なので止めたほうが良いです．

また「内部のJenins」もある意味branchだったわけですが，今回のように変更があると置いていかれますよね．２ヶ月ぐらい放置になっているかと思います．大体そういうものでしょう．githubはprivateなリポジトリがつくれるから，それも一案かもしれません．

[snozawa]

話を理解していないかもしれないけど，生成物をコミットすると，生成ツールを変更した時に手作業が必要になって，それが面倒になると直接書き込んで，二度と自動生成できないのでよくわからなくりますね．nervousのAutobalancerが良い例です．なので止めたほうが良いです．

なるほど、確かに生成物コミットは危ないですね。

また「内部のJenins」もある意味branchだったわけですが，今回のように変更があると置いていかれますよね．２ヶ月ぐらい放置になっているかと思います．大体そういうものでしょう．githubはprivateなリポジトリがつくれるから，それも一案かもしれません．

これもそうですね。

ただ問題は今は2つあって、

• privateなものをテストする方法をどうにかする
• 下流工程での生成物を使うようなテスト、全ロボットに渡るテストをどうにかする

だと思います。
内部のjenkinsでテストしていたのは主に前者の理由ですが、
今回のバグを確認したりするテストで主に問題なのは後者だと思います。

例えば、samplerobotはprivateでなくopenhrp3標準で、hrpsys_ros_briddgeレベルではテストされてますが、
euslisp/testでこのロボットをテストしたいときに、工夫が必要そうです。

本当はバグにそったテスト用ロボットを作るか、
今あるirteus/demo/sample-robot-model.lなどにテストケースな部分をいれてくかがいいのかもしれません。
ただ今回はリンク名やセンサ名のアクセッサが何通りかあります、というところのバグなので、
一個のロボットでその何通りかをいれるのも気が引けますし、
個人的な好みとしては使ってる全ロボットでテストしたい、というのもあります。

[YoheiKakiuchi]

ただ今回はリンク名やセンサ名のアクセッサが何通りかあります、というところのバグなので、
一個のロボットでその何通りかをいれるのも気が引けますし、

なん通りもあるかな？ ２通りぐらいで、かつ、書く時はこちらで書いて下さいという標準があればいいように思います。
標準の方法はこれでいいんじゃないかな。

(dolist (l (send *robot* :links))
  (print (send *robot* :link (send l :name))))
(dolist (s (send *robot* :sensors))
  (print (send *robot* :sensor (send s :name))))

[snozawa]

今は歴史的に４とおりあり、

• stringの名前でアクセス
• symbolの名前でアクセス
• indexでアクセス
• limbでアクセス

になってますが、
euslisp/jskeus#72
にかいてあるとおり確かにsymbolかstringの名前に絞るのでいいきがしてきています。

ただ、２通りだとしても、２種類のロボットモデルがあるほうがいいきがします
（sample-robotにstringとsymbolをちゃんぽんするのでもいいかもしれませんが）

[k-okada]

4個！

link/jointは何個だろうか．

[k-okada]

• privateなものをテストする方法をどうにかする
• 下流工程での生成物を使うようなテスト、全ロボットに渡るテストをどうにかする

はそうで，privateはprivate repo　でいいんじゃないかというのと，下流工程の物はhttp://jenkins.ros.org/job/prerelease-hydro-openrtm_aist_core/ARCH_PARAM=amd64,UBUNTU_PARAM=precise,label=prerelease/5/consoleFull みたいなjenkins jobを作ればいいので，http://jenkins.jsk.imi.i.u-tokyo.ac.jp:8080/job/rtm-ros-robotics/ みたいな物を整理して，ちゃんとセキュリティをかんがえて作ればいいともいますが，

このIssueそのものポイントは

jsk-ros-pkg/jsk_model_tools/euscollada/src/collada2eus.cpp
の変更により，
start-jsk/hrpsys_ros_bridge/euslisp/rtm-ros-robot-interface.l
が動かなくなる．

というかなりわかりづらい依存関係が生じていることです．なので，
collada2eusの生成物はこうなっているはず，という期待すべき振る舞いが
かかれた簡単なプログラムAを作っておいて，collada2eusに変更があった
ときは，そのプログラムAで動くことを確認する．

一方で，collada2eusの生成物を使っているrtm-ros-robot-interface.lを
作るときはプログラムAに書いてあるメソッドを使って作るようにする．という
風にしておけば，もし，重要な変更があればプログラムAをかえる必要があり，
それが起こるということは重要なので皆に周知して移行期期間を設ける，などの
対策をとることができます．

プログラムAは

collada2eusの生成物はこうなっているはず，という期待すべき振る舞いが

と書きましたが，これは結局はirtrobotのAPIリストになるわけで，

(dolist (l (send *robot* :links))
  (assert (send *robot* :link (send l :name))))
(dolist (s (send *robot* :sensors))
  (assert (send *robot* :sensor (send s :name))))

みたいに関数があるかないかぐらいのものでもいいともいますし，あるいは
irteusのサンプルプログラムをロードしてモデルをいれかえて実行する，
というだけでもよくて，サンプルプログラムの側で使いそうなメンバ関数が
呼ばれるようにしておく．というのでもいいかもしれません．

以下で言いたかったのもそういうことになります．

> > テストプログラムを作っておくべき
> 
> はい。
> ただ、やりかたが分からないです。
> どれか真似て使えるプログラムとかあります？

https://github.com/jsk-ros-pkg/jsk_roseus/tree/master/euslisp/test
に.lファイルをいれて，https://github.com/jsk-ros-pkg/jsk_roseus/blob/master/euslisp/test/test-euslisp.test から
呼び出すようにします．

が既にある所に一行いれておけばよいので，たとえば，
https://github.com/jsk-ros-pkg/jsk_roseus/blob/master/euslisp/test/test-irtrobot.test
に注目すると，
https://github.com/euslisp/jskeus/blob/master/irteus/demo/crank-motion.l
あたりにコードが入っていて，
c2e876fd13e1087c68fc41002d3ce06022571d43
をコミットした時にtestも替えなきゃとおらない，となると，APIが変わったという事で，
皆に注意喚起するという流れを狙っています．

が，今回の場合は
(:difference-cog-position
(:cog-convergence-check
が変更だったけど，これはik-serverではつかっていなくて，ik-serverではfullbody-inverse-kinmaticsをつかっているとすると
これは既に上のdemoコードで利用されているのかな．であれば，いまのままでOKではあります．

eusはプライベートとパブリックの区別が無いので，ここは何となくのコンセンサスになりますが，
パブリック扱いにしたいコードはdemoかtestにいれておいて，jskeus/eusを変更した時に気づくようにする，
というのが良いですね．

[snozawa]

はそうで，privateはprivate repo　でいいんじゃないかというのと，下流工程の物はhttp://jenkins.ros.org/job/prerelease-hydro-openrtm_aist_core/ARCH_PARAM=amd64,UBUNTU_PARAM=precise,label=prerelease/5/consoleFull みたいなjenkins > jobを作ればいいので，http://jenkins.jsk.imi.i.u-tokyo.ac.jp:8080/job/rtm-ros-robotics/ みたいな物を整理して，ちゃんとセキュリティをかんがえて作ればいいともいますが，

そうですね、jenkinsならちゃんとテストできますね。

サンプル兼テストを作る、というのも賛成です。
センサはこれから追加ですが、以下にPReqだしました。
jsk-ros-pkg/jsk_roseus#70

というかなりわかりづらい依存関係が生じていることです．なので，
collada2eusの生成物はこうなっているはず，という期待すべき振る舞いが
かかれた簡単なプログラムAを作っておいて，collada2eusに変更があった
ときは，そのプログラムAで動くことを確認する．

これに関しては、いくつかことなるものをサポートする場合には、
それぞれを確認するテストケースをつくる必要がありますが、
今回のような場合ロボットモデルそのものがテストケースになってて、
そう考えるとテスト用のものを作るというよりは、
すでにあるロボットが使えたらうれしいかも、ということでした。

今回のバグはアクセッサに関してですが、「いくつかことなるもの」のもっと最たる例は、
足があるロボットかどうか、はちゃんとテストしたいな、と思ってます。
sample-robot-modelの台車版をつくるか、eus/modelsの代表的なものを使うのがいいかもしれません。

[snozawa]

4個！
link/jointは何個だろうか．

link/jointは、string+symbolでのアクセスで、2コですね。
センサも、

• indexでアクセス
• limbでアクセス

をけずるかんじでしょうか。
前者は昔からあるけど私は使ったことがなくて、後者は便利なのでよくつかってましたが削れるかと思います。

[snozawa]

euslisp/jskeus#72

で、センサのaccessorをかえてPReqを直しました。
string, keywordだけでアクセスして、

(send robot :camera)

など引数なしで実行するとなぜか一個目のセンサがかえってくるのも、
引数がないとエラーになるようにしました。

[k-okada]

(send robot :camera)
など引数なしで実行するとなぜか一個目のセンサがかえってくるのも、

いいか悪いか分からなけど，rbrainの仕様がそうなっているので，意図的にそうしてあると思います．確認してみて下さい．

歴史的経緯としては昔はカメラは１つしかついていなかったので，send robot :camera としたらカメラが一つ帰ってくる，
というので疑問がなかった，ということだとおもいます．

2014-04-18 12:53 GMT+09:00 snozawa [email protected]:

euslisp/jskeus#72 euslisp/jskeus#72

で、センサのaccessorをかえてPReqを直しました。
string, keywordだけでアクセスして、

(send robot :camera)

など引数なしで実行するとなぜか一個目のセンサがかえってくるのも、
引数がないとエラーになるようにしました。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-40784994
.

[snozawa]

はい、rbrain由来のものです。
その上で、ここでの議論の流れが
　絶対に必要なアクセッサが２種類(リンク名前がstring, symbol)
　必須でないけど歴史的経緯であるものが２種類(引数なしで一個帰ってくる、limbをいれるとかえる)
の総計４種類になってて、テストを足しておくにしてもそれだと多いから
減らす話の流れになっていたと解釈してましたが、違うでしょうか。

個人的には、limbで変えるものもやはりかなり必要だと思っていて，
歴史的経緯のものを残すのであれば残しておき、テストはしっかりかいておくのでも
いいきがしています。

[k-okada]

ごめん，議論を降り出しにしちゃうけど，一回
:camera
:sensor
:link
:joint
等でどういう引数があるか整理しない？

2014-05-01 12:42 GMT+09:00 snozawa [email protected]:

はい、rbrain由来のものです。
その上で、ここでの議論の流れが
絶対に必要なアクセッサが２種類(リンク名前がstring, symbol)
必須でないけど歴史的経緯であるものが２種類(引数なしで一個帰ってくる、limbをいれるとかえる)
の総計４種類になってて、テストを足しておくにしてもそれだと多いから
減らす話の流れになっていたと解釈してましたが、違うでしょうか。

個人的には、limbで変えるものもやはりかなり必要だと思っていて，
歴史的経緯のものを残すのであれば残しておき、テストはしっかりかいておくのでも
いいきがしています。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-41877303
.

[snozawa]

そうですね。

これまでのissueとちょっと方法のカウントの仕方をかえて、下記にまとめてみます。

pr2eusやrbrainのコードであったのは、

• :link, :joint, :camera, :sensorあわせて
  • 名前でアクセスする
  • インデックスでアクセスする
  • 引数がなければインデックス0のカメラをとってくる
  • limbでアクセスする

の４つくらいがあって、それぞれ実際どれがあるかは下記のようになってます。

• link, jointに関して

  :link, :jointはアクセス方法は

  • 名前でアクセスする (send robot :link "RARM_JOINT0")

  の一つくらいだと思います。
  これはrbrainにもありますし、irtmodel.lにも取り込まれています。
  名前は、link, joint名はシンボル・stringの両方があります。
  引数は名前以外に対応してなくて、引数なしで最初の一個が返ることもないです。

• cameraに関して

  :cameraに関しては、

  • 名前でアクセスする (send pr2 :camera :openni-depth)
  • インデックスでアクセスする (send pr2 :camera 0)
  • 引数がなければインデックス0のカメラをとってくる (send pr2 :camera)

  一番機能が多いのはpr2eus/pr2.lに加追されてます。

• :sensorに関して

  :sensorというメソッドはrbrainにもなかったようですが、
  :force-sensorなどセンサに対してメソッドがあり、
  :cameraとほぼ同じにしていて

  • 名前でアクセスする
  • インデックスでアクセスする
  • 引数がなければインデックス0のカメラをとってくる
  • limbでアクセスする (send robot :force-sensor :rarm)

です。

リンクやセンサ単体にアクセスする他にlimbからアクセスすることも別途できて、
(send robot :rarm :links)
(send robot :rarm :joint-list)
とするとlimbに対応したものが帰ってきます。
これはrbrainもirtreusも同じです。

なので、上記のforce-sensorの

• limbでアクセスする

も、
(send robot :force-sensor :rarm)
でなくて
(send robot :rarm :force-sensors)
としてlimbのメソッドの中にいれてしまうのがすっきりするかもしれません。
そうすると、:link, :joint, :camera, :sensorのメソッドの
引数が４とおりが３とおりにできます。

[k-okada]

2014-05-03 16:38 GMT+09:00 snozawa [email protected]:

(send robot :force-sensor :rarm)
でなくて
(send robot :rarm :force-sensors)
としてlimbのメソッドの中にいれてしまうのがすっきりするかもしれません。
そうすると、:link, :joint, :camera, :sensorのメソッドの

これが良さそうですね．

また，

名前は、link, joint名はシンボル・stringの両方があります。

は，結局シンボルだと大文字小文字で名前の衝突は避けられないから，stringが推奨されている，というので正しい？

[snozawa]

は，結局シンボルだと大文字小文字で名前の衝突は避けられないから，stringが推奨されている，というので正しい？

そうなります。

これが良さそうですね．

limbメソッドからセンサにアクセスするようにして、再度PRを修正しました。
また、このPRでsample-robot-modelにセンサをつけて、
テストプログラムでチェックするようにしました。

あとは残りの項目ですが（最後の一個はさっき思いつきました）、

• 「引数がなければインデックス0のカメラをとってくる」のアクセス方法が必要かどうか

• forward-message-toをいれるかどうか

• rbrainにはcameraなど個別のセンサでなくて、:sensorsというのもありますが

  必要かどうか。irteusになってから使われてないので、いらない気もしています。

[k-okada]

rbrainにはcameraなど個別のセンサでなくて、:sensorsというのもありますが
必要かどうか。irteusになってから使われてないので、いらない気もしています。

モデルコンバージョンなどで必要にならないでしょうか？そもそもirteusにした時にセンサをちゃんと使っているロボットがなかったので，sensor系が貧弱というだけの理由だと思います．

また，今回の変更でrbrain側からコードが幾つか消せる気がする(pr2eusも）とおもいますが，そのへんはどうなっているでしょうか？

[snozawa]

モデルコンバージョンなどで必要にならないでしょうか？そもそもirteusにした時にセンサをちゃんと使っているロボットがなかったので，sensor系が貧弱というだけの理由だと思います．

なるほど、やはり必要でしょうか。

また，今回の変更でrbrain側からコードが幾つか消せる気がする(pr2eusも）とおもいますが，そのへんはどうなっているでしょうか？

jsk-ros-pkg側からはいくつかコードがきえます。
euscollada/src/euscollada-robot.lやpr2eus/pr2.lの中でセンサのアクセッサを
定義していた部分が不要になり、コードが削除できます。

rbrainは難しいですが、どうしましょうか。
理由は、rbrainのrobot-frameとirteusのrobot-modelクラスが別だからです。
今おこなっているPRはすべてrobot-modelクラスのもので、
このPR自体にはrobot-frameに何も影響を及ぼさないです。
robot-frameにrobot-modelクラスで整理されたルールを逆輸入してくるのは
できなくはないと思います。

[k-okada]

モデルコンバージョンなどで必要にならないでしょうか？そもそもirteusにした時にセンサをちゃんと使ってい
るロボットがなかったので，sensor系が貧弱というだけの理由だと思います．
なるほど、やはり必要でしょうか。

どうでしょうか？ @YoheiKakiuchi

理由は、rbrainのrobot-frameとirteusのrobot-modelクラスが別だからです。
今おこなっているPRはすべてrobot-modelクラスのもので、

なるほど．では難しいですね．pr2.l euscollada-robot.lだけですね．euscollada-robot.ｌの前の方の定義は全て消せるかな．本来は必要ないはず，だと思うので．

[snozawa]

pr2.l euscollada-robot.lだけですね．euscollada-robot.ｌの前の方の定義は全て消せるかな．本来は必要ないはず，だと思うので．

そうですね。pr2.lの該当部分だけでなく、
euscollada-robot.lの定義部分もけせると思います。

euslisp/jskeus#72
を更新して、センサをrobot-modelのslotsにいれつつcamerasなどもirtrobot.lに追加しました。
これで、subclassのロボットでcamerasなどを定義する必要がなくなります。

また、
euslisp/jskeus#72
のPRがだいぶ修正のコミットが重なってしまいrebaseもかなりむずかしくなっているので、
新しくPRをつくってmergeしようと思いますが、いかがでしょうか。

[k-okada]

はい

それでいいと思います

[YoheiKakiuchi]

最終的にどういう仕様になったのでしょうか？
以下がサポートされている（今後サポートする）アクセス方式という認識であっていますか？
あと、それぞれ、 send robot limb .. とするバージョンがある。

send robot :link link-name としたときに、シンボルかストリングと書いていたけれど、
send link :name の返り値とマッチングするという話で、２つと書いていたけれども実質１つだよね。

(mapcar #'(lambda (c) (send *robot* :link (send c :name))) (send *robot* :links))
(mapcar #'(lambda (c) (send *robot* :joint (send c :name))) (send *robot* :joint-list))
(mapcar #'(lambda (c) (send *robot* :camera (send c :name))) (send *robot* :cameras))
(mapcar #'(lambda (c) (send *robot* :force-sensor (send c :name))) (send *robot* :force-sensors))
(mapcar #'(lambda (c) (send *robot* :imu-sensor (send c :name))) (send *robot* :imu-sensors))

[snozawa]

遅くなりましたが、アクセッサは、ご指摘のものであっています。
https://github.com/euslisp/jskeus/blob/master/irteus/test/robot-model-usage.l

send link :name の返り値とマッチングするという話で、２つと書いていたけれども実質１つだよね。

そうですね。

せっかくdocumentationもできたので、書いておくとよさそうですが、
こちら話題は解決しましたのでcloseにします。
問題あれば、再度openしてください。