個人的な雑記やら感想やらなんやかんや

ロボット用ミドルウェアの歴史

ロボット用ミドルウェアとは一般的にはロボットのソフトウェアをモジュールに分割し、ソフトウェアモジュールを組み合わせてシステムを開発するためのフレームワーク、通信ライブラリのことを指します。
あるいはロボットのソフトウェア開発に有用なライブラリ群を指すこともあります。

ロボット用ミドルウェアのようなものが出てきたのは90年代前半にSPACEが出てきたあたりだろうけど、そんな昔のことは詳しく知りません。ちなみにSPACEはONC RPCによるリモート呼び出しによりモジュール間の連携を行っていたのでほとんど現在のロボット用ミドルウェアと仕組みは同じです。

ロボット用ミドルウェアと名乗るものが出始めたのが2000年前後にMCA、SmartSoft、OROCOS、Orca、ORiN、Player、RTミドルウェア、MIRO等がどこからともなく湧いてきたごろだろうと思いますが、そんな昔のことは知りません。

ちなみにOpen Robot Controller Architectureの略のORCAとシャチの学名から付けられているOrcaは別物です。一般的に知られているのは後者の方です。

2000年代半ばになるとMRDS、ROS、ASEBA、YARP、RSNP、ERSP、MARIE等の怪しい実装がわらわら出てきました。

MRDSはVPLによるビジュアルプログラミングができ、解説書も出ていたのでそれなりに知名度があったと思います。
ROSはPR2ベータプログラム等で普及活動に重点を置いていたような印象です。
RTMはOMG標準規格を取ることに力を入れていた感じです。

それでどうなったかというとROS以外消えました。
MRDSはMicrosoftがやる気をなくしたのかどうか知りませんが、まあ.NETの言語やVPLでロボットを開発する人なんてほとんどいないだろうし、プログラミング教材として残るという道はあったかもしれないけどそれもありませんでした。
RTMについては標準規格を持っていて勝てるならCORBAは大人気のはずだし、PythonよりもRubyの方が人気があるはずです。RTMは次世代ロボット知能化技術開発プロジェクトでいろいろ作っていたのに全部捨てたのがちょっともったいなかった感じです。
ロボット用ミドルウェアを使いたくて使う人はほぼいません。Moveit!等のツールを使うために仕方なくROSを使うというのが普通です。

2010年以降もCCA、MIRA、ISCSP等の胡散臭い実装が登場してはROSに蹴散らされてるか、もしくはだれにも認識されずに消えています。ISCSPなんて数人しか知らないと思う。
ROS2もROSに蹴散らされる予定です。まあ小さい業界の話だし、普及しているといってもそれなりですが。

上記のロボット用ミドルウェア対応のモジュールは大抵オープンソースで公開されていますが、今後はクローズドソース、シェアウェアも利用する方向になるのか。でもROSの方針とは違うのでそうならないかもしれません。
これからもオープンソースだけでやっていくとなるとどうやって収益化するのかということですが、それは散々問題視されているから簡単ではないのでしょう。JR北海道を黒字化させる方が簡単な気がする。つまりほぼ不可能という事。

考えられる方法としては、顧客の要求しているシステムをオープンソースから構築するシステムインテグレートで儲けるという手はあるかもしれません。
そのオープンソースの品質をだれが保証するんだという問題もあるかもしれないので、「ROSに何かあったら俺が責任を取る」とか言ってサポート料金を取るという手はあるかもしれません。
もしくはROS等で制御するハードウェアを売って儲けるという手段はあり、実際そういう商売をしている人はいますが、オープンソースがどの程度収益に影響しているかは不明です。

というわけで、現在はロボット用ミドルウェア(主にROS)を使ってどう収益化するかという方向に向かっており、概ね失敗しています。
個人的にはオープンソースから脱却したほうがいいと思う。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

プラットフォーム、フレームワーク、ミドルウェア、ライブラリの違い

プラットフォーム、フレームワーク、ミドルウェア、ライブラリについて用語の意味の違いが分かりづらいのでメモしておきます。間違っていたらコメントで指摘してください。

プラットフォーム

プラットフォームは日本語では「基盤」という意味ですが、基盤となる装置やソフトウェアのことを指すようです。具体的にはWindows、Linux、Java VM、Lua VMなどが該当します。
ロボット界隈では「プラットフォームロボット」という用語を使いますが、これは新規機能の開発、追加が可能な基盤となるロボットのことを指します。

フレームワーク

フレームワークは日本語では「枠組み」であり、ソフトウェアフレームワークはソフトウェアをある枠組みで開発、実行するための機能や実装などを指します。
具体的にはRuby on Rails、OpenRestyなどが該当します。
ただ、ソフトウェアフレームワークはユーザーの作成したアプリケーションの機能をフレームワーク側のメインループから呼び出す「制御の反転」の構造になっている必要があります。
論文などでROSはフレームワークであると書いてあるものがありますが、これは厳密には間違いという事になります。
OpenRTM-aistやChoreonoidはフレームワークに該当します。

Lua VMがプラットフォーム、OpenRestyがフレームワークという事です。多分。
.NET Frameworkはフレームワークで、その実行環境のCLRがプラットフォームという事になります。

ミドルウェア

OSとアプリケーションの中間に位置するソフトウェアです。
というか、ほとんどの場合はアプリケーション、OS以外のソフトウェアのことを指します。
具体的にはOpenCV、OpenGLなどが該当します。
Java VMやLua VM等のプログラミング言語の実行環境も該当します。

ただし、ミドルウェアはその名の通りOSとアプリケーションの中間に位置するソフトウェアのため、OSが無い環境のライブラリはミドルウェアには該当しません。例えばArduino用のライブラリはミドルウェアではありません。

ライブラリ

ソフトウェアの機能を再利用可能な形でまとめたものです。
フレームワークの場合はフレームワークが主となりますが、ライブラリはアプリケーションに機能を提供するだけのため、アプリケーションが主になります。

適当にソフトウェアを分類すると以下のような感じだろう。

ソフトウェアの分類	プラットフォーム	フレームワーク	ミドルウェア	ライブラリ
OpenRTM-aist		〇	〇	△
omniORB			〇	〇
Qt		△	〇	〇
ROS			〇	〇
Choreonoid		〇
ODE			〇	〇
OpenCV			〇	〇
Lua VM	〇		〇	△
VMWare	〇

所々どこに分類すればいいのか分からないものもあります。
まずOpenRTM-aistはスタンドアロンRTCとして起動すればライブラリ、RTCDで起動すればフレームワークに該当しそうなので仕分けが難しいです。
これがLove2Dのようにアプリケーションのみの提供であればライブラリには該当しません。

QtはQt Creatorを使えばフォームに追加したウィジェットから直接スロット関数をいじることでフレームワーク的な使い方ができるので、フレームワークでもあると言えます。

Luaは単体で実行したらただのプラットフォーム、組み込んで実行すればミドルウェアでもあるということになります。組み込む側からすればライブラリのようにも見えます。

というわけでライブラリ、フレームワーク、プラットフォームを図で表すと以下のような感じになりますが、プラットフォームの定義がよく分からないので間違っているかもしれません。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

RTミドルウェアコンテスト2019感想

とりあえずRTMコンテストの感想を書きます。

今年はロボットでプレゼンをするという前代未聞の発表があったわけですが、まさか本当にやるとは・・・。予想はしていたけど、マジでやるのかよと思いました。

今年の作品の中で出来のわりに評価が低ったのはこの作品ですかね。
審査員のほとんどはROSも分かるのでROSだからは関係ないと思いますが、スマホからロボットを操作する事例がよくなかったかもしれません。
rosbridgeを使ってWEBブラウザからROSノードを操作する事自体はそんなに難しくないだろうし、複数のマシン上のROSノードを管理できるというのが今一つピンとこない感じがします。
RSNPでは複数のロボットを管理するような事例がありますが、あんな感じのものを出したら多少変わっていたかもしれません。
後、表彰式のスライドでタイトルを間違えてすみませんでした。焦って作ったので間違えました。

この作品は発表でしくじったのがまずかったかもしれません。Macは発表で使うべきではありません。Appleは倒産したほうがいいです。
内容だけ見れば別にこれが最優秀賞でもよかったとは思いますが、なんだかこの作品は最優秀賞が合わない雰囲気なんだよなあ。新しいことが一つもないので面白みがない感じです。

ほかはこんなもんじゃないですかね。
今年は内容がひどい作品が受賞するという事は無かったと思います。

それにしてもMacがプレゼンでトラブルを頻発するのはちょっと考えたほうがいいよなあ、と思いました。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

RTMコンテスト2019 投稿作品の感想(その3)

最近の投稿に毒が足りないというありがたいお言葉をいただいたので、残りの3作品はやや辛辣に行きます。

まずはこの作品の感想を書きます。
最初に一言いうと、rowmaの発音が分からないので教えてください。

この作品のコンセプトは「簡単に誰でも使えるシステム」ということですが、まずコマンドラインの操作ができない人がROSを使ってはいけません。これは一般常識です。
遠隔操作や監視ができるという事を挙げていますが、セキュリティに穴をあけているだけです。

WEBブラウザでの操作中にエラーになるとエラー発生個所を表示するのはやめてほしいなあとは思いました。というか、画面上に表示される円を動かしただけでにエラーが発生するのは問題だなあ。

このソフトウェアはマニュアル通りにrosrun rowma_ros rowmaを実行すると外部のサーバーに繋ぎに行くようなのですが、その辺の仕組みがマニュアルからは分かりづらいです。

ソースコードについては・・・、謎のprint文とか細かい点で気になるところはあるけど、今のところ別に言うことないなあ。どうてもいいけど、この作品ではrosbridgeが重要な要素になっている気がするけど、何故か使用技術でsocket.ioについてだけ触れているのが気になります。
まあデバッグを頑張ってください。

一言言っておくと、別のこの作品の評価は低くないです。まあでもマニュアルがなあ、という評価です。

次にこの作品の感想を書きます。
マニュアルはいったいどこなんでしょうね・・・。
仕様書らしきものがありますが、OdomViewerの概要説明が間違っているように見えます。
独自データ型の意味が不明です。そもそもPose3D型にロール・ピッチ・ヨーの回転角が入っているので、そこにクォータニオンの情報も入れる意味が分かりません。Point2D型でよかったのでは？

ソースコードを読んだ感じでは、コンフィギュレーションパラメータSensorNumberはどこでも使われていないため、仕様書に書いてあることは嘘ではないかと思います。
そしてやっぱりPose3D型の回転角には何も入れていません。
わざわざVisualOdometryクラスのInit関数で初期化失敗したときの処理も考えているのに、onActivate関数でエラーに遷移しないのは何故なのか。
よほど時間がぎりぎりだったのか、やっつけで作った部分が目立ちます。
まずはマニュアルを作ったほうがいいです。

最期にこの作品の感想を書きます。
評価不能です。終わり。
・・・まあ一応コメントをしておくと、MIND STORMとは何でしょうか？
LEGOのことだとすると、MINDSTORMSなのでタイトルがおかしいです。
いやでもLEGOだとすると意味が通らないような気がするので別物かもしれません。
これ以上語ることがないので終わります。

これで一応全作品の感想を書き終わりました。
実は一つ書いてないけど、まああれはいいか。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

RTMコンテスト2019 投稿作品の感想(その2)

今年はSI2019でRTM講習会があるのですが、参加登録数はかなり不調です。
四国開催なのに四国からの参加者0は笑えないのですが。

なんでも同じ日にROS勉強会を開催するという動きがあるらしいですが、そっちの方が人が集まったらやだなあ、と思っているところです。僕も参加申し込みをしようと思ったのですが、その後何の情報もないです。

それはさておき、まずはこの作品の感想を書きます。
教材は今までのコンテストに腐るほどあったのであまり気が進まないのですが、これは最初から教材を作成するつもりでやっているように感じるのでいいのかもしれません。
あまり突っ込む点はないなあ。I2Cはフィリップじゃなくてフィリップスだろとか、3日目と4日目のタイトルが微妙に違うけど何か意味あるのかとか、細かい話くらいですかね。
ソースコードについてはコンフィグレーションパラメータを使ってほしいとかありますけど、作成例なのでこれでもいいかもしれません。
ただPython3に対応していないのは残念です。

何か新しい発想があるわけではないので、他の人がどういう評価にするかは気になります。

次にこの作品の感想を書きます。
さて上の作品は最初から教材を作成しているのでいいと言いましたが、この作品は教材を取って付けた感があるので印象がよくないです。
教材といっていますが学習する手順が示されていないので、頑張った割には評価は厳しくなるかもしれません。必要なハードウェアについても具体的に必要な製品のページのリンクを貼るなりした方がいいです。

後は動画があったほうが分かりやすいと思いました。
その辺を改善出来たら最優秀賞もありそうなのになあ。

最後にこの作品の感想を書きます。
まずプロジェクトページの画像を見て思ったのが、SysMLで設計したとか強調する必要ある？という点です。まあそれはいいか。

ソースコードを見て思ったのは、マジックナンバーが気になります。今年の作品はマジックナンバーが問題になるケースが多い気がする。
PresentationManageSystem.pyで変数を1や2と比較しているのですが、意味が不明です。
あとサービスインターフェースをいくつか定義していますが、説明不足であり動作が分かりません。
ちょっとonExecute関数に書きすぎだと思う。onExecute関数内でSleepしている箇所がありますが、意味がよく分かりません。
見たところSpeechManageSystem.pyのStartFlag==1の時の処理は1回しか実行しないようですが、なぜonActivated関数で処理しないのか。全体的に処理の流れが分かりづらいです。

まあでも上の作品が改善しないようであればこの作品のほうが評価が高いように思います。

今日はこのぐらいにしておきます。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

RTMコンテスト2019 投稿作品の感想(その1)

ずいぶん久しぶりですが、毎年恒例なのでRTMコンテストの作品の悪口感想を書きます。
死んだと思った人もいるかもしれませんが、僕は元気です。健全とは言ってない。

まずはこの作品の感想をかきます。
なんと高校生が参加するのか。受験勉強は大丈夫なのか心配です。

全体的な出来としては学部4年にも引けを取っていないと思います。

マニュアルに関してはハードの構成が分かりづらいです。どこに何を配置したのかを分かりやすい図で表現したほうがいいです。熟読してわかったのですが、ごみを入れる位置でタピオカの落ちてくる位置は変わらないみたいです。
ソースコードを読んだ感じですが、ちゃんとonActivateで問題が起きた時にエラー状態に遷移させています。またonExecute関数などに全て記述せずに、機能ごとに関数を実装しています。この時点でその辺の大学生を超えていそうです。
ただマジックナンバーがちらほらあるのが気になります。コンフィグレーションパラメータをもっと有効に使えるようになった方がいいかもしれません。

次にこの作品の感想を書きます。また高校生か・・・。
マニュアルに関しては概要が分かりづらいので概念図のようなものがあったほうがいいです。
あと途中に数式が出てきますが、意味が不明です。まあ仕方ないか・・・。
ソースコードを読んだ限りでは圧力の値が大きく変動したときに音が大きくなる処理のようです。
マニュアルでは「上昇度の大小によって変動する」と書いてありますが、上昇なのか下降なのか区別していないので、厳密には違います。まあ閾値を超えた場合にしか判定しないのでほとんど動作に影響はなさそうですが。

他の作品にも言えることだけど、ポートの接続やRTCのアクティベートは自動化したほうが簡単です。

高校生はこの2人だけみたいです。

次はこの作品の感想を書きます。
なんだかやけにコメントの返信が早いので驚いています。
マニュアルに関しては、軌跡を予測をすることで何が改善されたのか分かりづらいです。おそらく「障害物の回避後に人を見失った場合に動作する」という点が改善された点なのだろうけど、最初と最後によく見たら書いてあるのは強調するなりしたほうがいいです。

ソースコードについては、グローバル変数使い過ぎかなあと思います。
social-lstmというライブラリのソースコードを一緒に入れてしまっていますが、この人の作ったファイルと区別できません。あとpycファイルなどはいらないので消した方がいいです。

複雑なシステムを作っているのはいいけど、今回作ったもの自体は少ないし厳しいかなあという印象です。

最後にこの作品の感想を書きます。
まず気になったのは、これって効果あるの？という点です。身も蓋もないですが。

コンポーネントの設計という点では大いに問題あるなあ。
ソースコード中でマジックナンバーを多用しているのですが、このマジックナンバーが他のRTCのためのものなのでRTCを交換しようと思ったらソースコードの編集が必要になりそうです。
数値でいいところにTimedString型を多用しているところもよく分かりません。
どうもロボットをNAO以外に変更できなさそうなのも問題かなあ。

今回はこのぐらいにします。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

RTMコンテスト2018 投稿作品の感想(その3)

今回で最後です。

まずはこの作品の感想を書きます。
　
　

流石にRSNPコンテストで最優秀賞を取っただけのことはあるのですが、「こんなシステムを作ってみました」になっているのが惜しいです。例えば「RTMとRSNPを連携させて遠隔のロボットを操作するシステムを構築するにはどうすればいいのか？」という手順のマニュアル化、あるいは手順を簡略化するツールを作るとか、もっと広い範囲で考えてほしかった。

あるいは何か既存のシステムよりも性能が向上したとか検証結果があれば違ったのですが、そういうわけでもなさそうです。

試みは面白いとは思いますし、ソースコードもよく書けています。少し詰めが甘いかなあという印象です。ちょっと使用方法に記述が雑だとは思いますが、マニュアルの出来も悪くないです。
ただ誰かが使うとか参考にするという段階に至っていないので、人によって評価が分かれそうな感じはします。

　
　
　
　
　
　
次にこの作品の感想を書きます。　

　
　
双腕ロボット制御機能共通インタフェースを使うのは挑戦的で面白いのですが、この作品のポイントはどこにあるのだろうかと疑問です。概要の説明をもっと書いたほうがいいです。ただ「双腕ロボット制御機能共通インタフェースを適用してみた」だけだとちょっと微妙かなあ。ソースコードはよく書けていると思いますし、起動スクリプトを用意しているのは親切だと思います。マニュアルをもっと加筆すれば評価は違うかもしれません。

　
　
　

他の気になった点は以下の通り。

・ちょっとonExecute関数が長い

・moveLinearCartesianAbs関数などで右腕と左腕で同じような処理を2回書いているのがなんだか気持ち悪い。無駄にコードが長くなっている。関数を使いまわすべき。

・動画がないのは痛い。何ができるのかよくわからない。

・使い方がよくわからない。右腕、左腕の共通インターフェースはどうやって使うのか？双腕共通インターフェースと同時に使えるのか？

・NeckInterfaceにgetFeedbackPosNeckというオペレーションを用意して、WaistInterfaceにgetFeedbackPosWaistというオペレーションを用意するのは非常に違和感。インターフェース名からどの部位を対象にしているかは明らかでは？

　
　
　
最後にこの作品の感想を書きます。
　

この作品は地味の一言に尽きる。

「深層学習」とか「教材」という単語は過去のコンテストの作品にもあった言葉ですし、物体を画像で認識して把持するだけなので見た目があまり面白くありません。特に「教材」がタイトルに入る作品は過去に腐るほどあったので、何か工夫がないと厳しいです。

悪い点もそんなにないのが地味さを際立たせているような気がする。

マニュアルはよく書けていると思うのですが、学習教材なので具体的にどの作業で何を学ぶことができるのかの説明が欲しいです。

学習時の動作はフローチャートがあったほうがよかったかもしれません。

あとはシミュレータが欲しいです。

onExecute関数にこんなに長々と書くのはやめてほしいなあ。初期姿勢に戻る処理が何回かあるので関数で定義してほしいです。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

RTMコンテスト2018 投稿作品の感想(その2)

今日もRTMコンテストの作品の感想を書きます。
3作品ずつ書くので次で終わりです。

まずはこの作品の感想を書きます。
　

市販のデバイスをRTC化するというよくある話なので、何らかの工夫がないと評価は低くなります。

この作品に関しては独自データ型の定義がポイントになるのだろうけど、なんだか定義しただけになっている感が否めません。色んなシステムで検証してもらわないと微妙な評価になりそうです。

マニュアルを見た感じ、RTCのビルド、起動する手順が一切書いていません。おそらく既存のRTCと同じ手順だからという理由で省略しているのだろうけど、だったら手順を書いたページに誘導するとかしてほしいです。

その他に気になった点は以下の通り。

・もうちょっと概要の説明が欲しい

・OpenVRはリリースされたものを使ったほうがいいのでは？

・ちょっとonExecute関数に書きすぎな感じはある

・openVive関数は初期化に失敗したら戻り値をfalseにするなどすべき

・どうでもいいことだが、CMakeのバージョンを書くぐらいならVC++のバージョンを書いたほうがいい

・OpenVRのパスは環境変数ではなくコマンドライン引数で渡してはどうか？

ソースコードに関してはよく書けていると思うのですが、今後の展望に書いてあることを今すぐやったほうがいいと思う。

　
　
　
　
　
　
　

次にこの作品の感想を書きます。
　

見た感じ特定の画像の矢印しか認識できないようですが、それが何の役に立つのかという感じはします。他の作品で機械学習を使っているものがありますが、この作品も色んな画像を認識できるようにしてみたらどうでしょうか。ちょうど深層学習の教材があるようなので、やってみてはどうですか？(適当)

この作品もCMakeLists.txtでOpenCVの設定をしていないため、無駄に手間を増やしています。

他の作品でも言っていることですが、このソフトウェアを使うことで何の問題が解決できるのか、だれが得をするのかを書いてほしいです。

なんでソースコード中に画像ファイルのパスを記述しているのか。マニュアルのソースコードが移っている画像にモザイクをかけていますが、そのソースコードが公開されている時点で意味がないのでは？まあどうでもいい話ですが。

ほかに気になった点は以下の通り。

・コンフィギュレーションパラメータを使ってほしい

・システムの例が載っていた方がいい

・グローバル変数はやめてほしい

・マジックナンバーはやめてほしい

・169～301行目に似たような処理が並んでいるので関数にして使いまわすべき

　

　
　
　
　
　
　
　
最後にこの作品の感想を書きます。
　

ちょっと概要の説明が手抜きすぎるような気がします。

「サービスロボットのため」とか書いている割には、どうサービスロボットに活用するのか書いていません。

システムの例を用意している作品がほとんどありませんが、それで大分見栄えが違うのでなんとかしたほうがいいです。

どの作品もグローバル変数を多用しているのは非常に気になります。大半はメンバ変数で問題ないので、何とかしてほしいです。

他に気になった点は以下の通り。

・カテゴリ名は設定してほしい

・TimedLongSeq型に位置のデータを入れるのはかなり疑問

・m_positions.data.length(3 * 6);<-この6って何？

　
　
　
残りは明日書きます。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

RTMコンテスト2018 投稿作品の感想(その1)

今年もRTMコンテストの作品の感想を書きます。
ちょっと野暮用で書くのが遅れました。楽しみにしている人には申し訳ないです。

まずはこの作品の感想を書きます。

何に使うのかよく分かりません。右に行くか左に行くか予測出来たら何が嬉しいの？という感じです。

実践的なシステムの例が無いのが痛すぎるような気がする。発表で突っ込まれると評価が下がるかもしれません。

ただコメントへの対応は速いし、動画を用意しているのは親切だし、全体的にやる気は感じられます。

他に気になった点は以下の通り。

・VelCalc関数で0.1で割る意味が分からない

・SeriesData関数で1000倍する意味が分からない

・numpy.arctan2を使ったほうが簡単では？

・CMakeが生成したファイルは消してほしい

・ファイル名はコンフィグレーションパラメータで設定すべきでは？

・RTCの使用方法をもう少し詳細に書いてほしい。というかビルドが必要なRTCは自動でビルドするスクリプトを作ってほしい。

コンフィギュレーションパラメータを使いこなしている人ってそんなにいない気がする。

　

　
　
　
次はこの作品の感想を書きます。
　

「やっていること自体は面白そう」と言うのが大抵の人の感想だと思います。それ以上のものがあるかといわれると、今のところないです。
ビルド時に生成したファイルを消していないためファイルのサイズが驚異の452MBもあります。アップロードする前にちょっとは考えてほしいです。

まあ確かにあの装置を持っている人はいないだろうから、公開しているソフトウェアを使う人もいないのだろうけど、人に使ってもらおうという感じが一切ないのは問題だなあ。
　

なんでこっちの環境でデバッグしなきゃならないのかというのも疑問です。ただRTC単体ではなくシステムになっているので、その点は評価が高いと思います。
　
　

その他に気になった点は以下の通り。

・グローバル変数はやめてほしい

・CSVファイルの名前はコンフィギュレーションパラメータにすべき

・マジックナンバーはやめてほしい

・Voice_output0のVoiceInがTimedLong型のため、使い方が分からない

こちらの環境で動作確認ができそうな作品がほぼ無いような気がする。

　
　
　
　
　
　
最後にこの作品の感想を書きます。
　
概要説明が雑すぎる。開発したソフトウェアが何の役に立つのか、誰が得するのかをまず書いてください。

利用方法は詳しく書いてありますけど、CMakeLists.txtで予め設定しておけばVisual Studioでの作業はほぼ無くなるので、無駄に手間を増やしているように思います。コードを読んだ限り設定しようとはしているのですが、何故か途中でやめているように見えます。
　

上の作品は概要や背景は良く書けているけど利用手順の説明が雑で、この作品は利用手順はよく書いているけど概要や背景を全く書いていません。お互いのいいところを真似したらいい感じのマニュアルが作れそうです。
　
　

ほかに気になった点は以下の通りです。

・Kinectが複数接続されている場合はどうなるのか？

・グローバル変数はやめてほしい

・ERROR_CHECKでなんでエラーなのにRTC_OKを返すのか？

・283～285行目で角度をint型のdegree単位に直した後、289～291行目でintをdoubleに直しているのは意味不明。値が丸められている

・複数のBodyが取得できた時でも同じデータに格納して出力しているのは疑問

・応用例が欲しい
　

　
　
他の作品の感想は明日書きます。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

計測と制御ミドルウェア特集号の感想

今回は計測と制御のミドルウェア特集号の感想を書きます。

「ROSの近況と今後の展望」と言う記事があるのですが、僕が読んだ限りでは今後の展望については一切書いていません。ROS2が普及するか、需要が本当にあるかどうかは一番知りたいところではあるので残念です。まあ、ROS2は普及しないと思いますけど。

なんだかこういう解説や論文になると途端にROSに対してネガティブな意見が出てくる。
今回多かったのは、「誰でも簡単にロボットが作れてしまうので、学生の教育に適していないかもしれない」と言う意見で、それはそうかもしれません。

まあでも、学生だったら自分が使っているライブラリの概要ぐらいは知っておいた方がいいとは思います。
学会発表とかで「それは外部のライブラリ(例えばgmapping)がやっているので分かりません」とか言ったら馬鹿にされるかもしれません。

ROSが使われているのは主に研究用途のため、学術分野から離れてしまうとROSの知識は全く役に立たなくなるかもしれないです。ROSが衰退した場合も同じです。10年後には消えている可能性も0ではありません。

あと宇宙機でROSを使おうとか言う解説もあったのですが、なんでもROSのコードを変換する必要があるらしいです。
そもそも、ROS等のミドルウェア依存の部分とコアの処理は別ファイルで切り離して実装するのが基本であり、移植したいのであればミドルウェア依存の部分だけを新規に作成するのが基本だと思います。コードを変換するツールを作っている時点で迷走しているような気がします。
例えば「ROSのコードをOpenRTM-aistに変換するツールを作りました」とか言い始めたら途端に話はおかしくなるわけで、方向性を見失っています。これがROSのコードがそのまま使えるという話なら分かったのですが。

にほんブログ村のロボットのカテゴリから
全然人が来ない・・・