マニュアル執筆中(その58)

とりあえずOOoBaseRTC、OOoImpressRTCのデモ動画をアップロードしておきました。





これでとりあえず基本機能は揃った形にはなったと思います。
インストーラーも更新しました。
テスト用RTCを除くとメインのRTCが9つ、サブのRTCが8つの計17個のRTCを配布することになりました。
とりあえず最優秀賞はもう無理ですが、まだ何らかの奨励賞を貰える可能性も0ではないと思うのでバグの改善などには手を抜くことなく取り組みたいと思っています。





昨日投稿された作品の産業用ロボット汎用RTC 操作マニュアル_ver_1_0.pdfを読んでいて気になったのですが、CMakeでプロジェクトを作成した後にuseORiN.cpp、defcommand.cppを追加してくださいと書いてあります。srcのCMake.txtのset(comp_srcs ～の部分にファイル名を書けばCMakeの段階で追加できると思ったのですが、既にコメントしてしまったのでもう一度連投するのは少し気が引けます。
まあそもそも実行ファイルが付属していてビルドなんてする必要はないので別にいいか。

本当なら使ってみてのコメントを書きたいのですが、ORiN2 SDKも実機もないのでどうでもいいような事ばかり書いてしまいます。
使える環境のない僕が完全に悪いのですけど、なかなか実のあるコメントができません。
RTM_ORiN_Converter_CRDは実行できる環境がないし、IntegratedControlRTCは実質的に専用のRTCだと思うので他で配布されているRTCと組み合わせるのは難しそうだし、となるとCameraPositionCorrectionRTCぐらいしか試用できそうにないですが、特に言うこともないしなあ。
シミュレーションでも出来たら良かったのですけど、実装の都合でそれも難しいのですかね？
ORiN2 SDKの詳細なマニュアルがあれば分かるかもしれませんが、正直どういうことができるのか理解できていないのでよくわかりません。

それにしても多関節ロボットを制御する前にはシミュレーションを綿密にすることが普通だと思っていたのですが違うのですかね？
以前に四足歩行ロボットの制御をやっていたことがあるのですが、シミュレーションをやっても2回ほど壊しかけたことがありました。なんとか無事でしたけど。
そりゃ小さなロボットなら大丈夫でしょうけど、あのRTCで対象にしているロボットはそれなりに大きいと思うのでシミュレーション無しはかなり危険だとは思うのですが。













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

マニュアル執筆中(その57)

また作品が投稿されてる。
凄い力の入れようなのが見ただけで伝わってきます。
これは参りましたね。降参せざる得ないようです。
とりあえず最優秀賞を貰える事が無い事は確定しました。予想通りとは言え残念です。
いやというより、NEDOプロジェクトとかいうのは税金から予算が出てるんですよね？
僕なんかに負けたら返金しなければならないと言っても過言ではないのでこの結果は当然です。
別に結果が出た訳ではないけど、力の差は歴然としています。

Orin2 SDKが有料らしく、調べてみればお試し版があるとか書いてあったのですがリンク先が消えているらしいので利用できません。
Orin2 SDKのドキュメントもおそらく購入しないと読めないので、詳細不明です。
実行ファイルが付属しているので別にライブラリをダウンロードしなくても使えるのかな？
まあ最大の問題はハードウェアがないことなんですが。

無知なのでCRDプロバイダが何かわからず調べてしまいました。
CRDとはXMLファイルで産業用デバイスの情報を記述するための規格らしいです。
要は投稿作品はCRDの規格で書いたXMLファイルからロボットの情報を読み込んでサービスポートからの指令→ロボットコントローラにEthernetで通信→実機が動作するみたいです。
規格だから仕方ないですけどM1とかM2とか分かりづらい名称は一体何なんでしょうね？


なんでOpenCV 2.2をインストールするのかと思いましたが、他からダウンロードする画像認識コンポーネントが古いのか。よく考えてみれば去年の作品でもそうだったかもしれません。


ソースコードを読んで気になったのはManipulatorCommonInterface_MiddleLevelSVC_impl.cpp等で同じような記述が何故か多かったので関数にまとめた方がコードが短くなるのではとは思いました。
あと何故かは知りませんがグローバル変数多用しています。
useOrin.hの関数と変数をクラスにまとめてm_ManipulatorCommonInterface_Common、m_ManipulatorCommonInterface_Middle初期化時に引数として代入した方がいいのじゃないかなあと思いましたけど、何か理由があるのだとは思います。

とりあえず明日にでもコメントを書いておきます。
褒めるところならいくらでもあると思うのですぐ書けそうです。









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

マニュアル執筆中(その56)

他の作品のプロジェクトページが作成されたようです。
Kobukiの値段を調べたところ67000円ぐらいするのでさすがに試用するのは無理そうです。
MapperRTCとかなら試せるかもしれません。
まだソースコード等のアップロードはしていないようですが非常に楽しみですね。
コメントしたいのですけど、全部英語で書いてあるようなので日本語のコメントでも大丈夫なのかが不安です。僕が糞みたいな英語で書いてあちらの人に何とか内容を理解してもらうか、僕が日本語で書いてあちらの人に訳してもらうかと言われれば前者をやるべきなのでしょうけど、実際は後者の方が内容を理解してもらえる確率は高いと思っています。こちらが質問等をする側なので前者をせざる得ないのですけど。
まあ、内容がわからないうちから別にそんなこと考えなくてもいいか。

とは言ってもここまで僕一人だったので「暫定1位だぜ！！」とか勝手に思っていたのですが、暫定1位(笑)の座が音を立てて崩れてきてます。これでソースコードをアップロードされたら完全に逆転されます。というより今の時点で逆転されてるかも。

僕は人に煽てられたというか騙されたような形で参加するわけですが、他の人は自分の作ったものに確固たる自信をもっています。やはりその辺から意識の違いというのが生じているとは思います。



ここからは自分の作品の話です。
現在作成中のRTCは基本機能は実装できたのですが、目玉になる機能がない状態です。
何にせよこのままでは勝負にならないので何か特徴を出すしかありません。











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

マニュアル執筆中(その55)

10月中にもう一つRTCを配布するつもりですが、かなり苦戦しそうです。
何かと言うとキャプチャーしたスライドショーの画像を表示するGUIのRTCなのですが、いろいろ機能を持たせたいのでひょっとしたら10月中は無理かもしれません。
まあ既に作品投稿自体はしているので減点とかはないかもしれませんが、さすがにページだけ作って内容が薄かったら印象が悪いのでなんとか間に合わせて少しでも点数を稼ごうとは思います。
まあ加えたところで他の人との差が少し縮まる程度だとは思いますが。


締め切りまであと1週間です。
やはり締め切りが早かったのでしょうかね？
とは言っても11月下旬とかだとなにかフィードバックがあっても発表までには対応できないので、それはそれで問題はあります。僕がフィードバックの心配をするのもおかしな話ですが。



そういえば前の記事でちょっと書いた画像データの圧縮の件ですが、TwitterでGitHubのソースコードを教えてもらいました。やはりInterfaceDataTypes.idlのCameraImage型ではなく、Img.idlで独自に定義したデータ型を使用しているようです。将来的にはそちらに移行するのかもしれないのですが、現状InterfaceDataTypes.idlのCameraImage型を使用しているRTCが多いというかほとんどなのでどちらを使えば良いかはわかりません。ただ昨日の記事で紹介した画像データ変換RTCみたいにInterfaceDataTypes.idlのCameraImage型でも画像データを圧縮して通信ということはできると思うので、今はとりあえずInterfaceDataTypes.idlのCameraImage型を使用したいとは思っているのですが他に対応しているRTCが見当たらないので独自のRTC以外では無圧縮での通信をせざる得ないという状態ではあります。それならリンク先のRTCに対応させた方が便利なような気もします。ただどうにも使いづらいような印象です。何故かと言うと使い回せるような処理を全部onExecuteに書いてしまっているからで、同じコードを書いたRTCがいくつもあるように思います。その部分を関数にまとめてくれたら対応するRTCも作りやすいのですが。まあ今後おそらく改善されると思うので、それに期待します。











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

マニュアル執筆中(その54)

以前の記事で書いたことをメーリングリストで聞いてくれた人がいたのですが、ようやく回答があったようです。どうやら遅かったのはただメールを送る際にミスがあっただけみたいです。OpenRTP 1.1.0-RC5で対応するとからしいのですが、ファイルが存在しない原因はなんだったのかはメール読んだ限りではよくわかりませんでした。

前回の記事でOpenCVを複数バージョンインストールした場合にトラブルが起こりやすいと書きましたが、このページのように環境変数を変更すれば解決はできると思います。それから複数のOpenRTM-aistをインストールした場合はRTM_ROOTとOMNI_ROOTが違うバージョンになっていたのかなあとは思いますが、今はインストールしていないので確認できません。
その辺の解決方法をマニュアルに書いておけば良いとは思いますが、初心者にはなかなか厳しいですね。


今回はデータポート、サービスポートについて自分勝手な見解を書いていきたいと思います。
まず、独自のデータ型、独自のインターフェースはあまり使用するべきではないと思っています。
まあ単純に既存のRTCと接続できないと言う単純な理由ですが。
BasicDataType.idl、ExtendedDataTypes.idl、InterfaceDataTypes.idlで定義されたデータ型をできるだけ使うべきかなあとは思います。
ただ、独自のデータ型を使った方が便利なことがあると言われれば確かにそう思います。
音声データをTimedOctetSeq型で入出力しますがサンプリング周波数、ビット数、チャネル数も含んでいたほうがCameraImage型みたいに使いやすくはなります。と言うか画像データの扱いもちょっと前まで同じような扱いだったような。
DoubleSeq型の0番目をX座標、1番目をY座標で使うか、そのままPoint2D型を使うのとどっちが良いかと言われれば後者だとは思います。
ただTimedDoubleSeq型のデータポートを使用しているRTCが多いので実は前者の方が他のRTCと接続しやすかったりしているような気はしてます。





画像とかはこのページのように圧縮して送信する方が通信が速くなるので別のPCに送信する場合は便利です。リンク先のRTCはOpenCVのimencode関数で圧縮したデータをOctetの配列に書き込んで送信しているみたいなので、動作環境はUbuntuと書いてありますがWindowsでも動作できそうですね。
CameraImage型にはformatで圧縮形式を指定できるのですが、サンプルのソースコードを読んでみても使ってる気配はありませんね。
とりあえず画像データを圧縮して出力、圧縮された画像データを元に戻して出力するRTCを作成しておいたので使ってあげてください。
マニュアルは今週中に書きます。









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