忍者ブログ
ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
[11]  [12]  [13]  [14]  [15]  [16]  [17]  [18]  [19]  [20]  [21
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

この作品に3週間ぐらい前に投稿したコメントの返信があったみたいです。
ソースコードを読んでみた感じ、moveCircularCartesianAbsとmoveCircularCartesianRelとgoHome関数に似たコードがあるように見えます。
まあ何か理由があるのかもしれないのですけど、これ以上追及するのはやめておきます。
相対位置での円弧補間動作が定義されていないのですか。
という事は、マニュアルに載っていたM1~M35は誰が定義したものなのでしょうか?
直線補間の相対指令のmoveLinearCartesianRel関数では絶対位置に変換しているようですが、sprintf(char_buffer,M11_Command,~としているので最終的に相対指令で入力しているように見えます。
正直よくわからないのでORiN2の仕様書を読んでみたところ重大な勘違いをしている事に気付きました。Moveというメソッドの引数は、補間指定、ポーズ列、オプションとなっているようです。つまり補間指定でPTP、直線、円弧のいずれかを指定して、ポーズ列で目標位置を指定することになると言う事だと思うので、絶対位置か相対位置か指定する項目はないという事になります。
それじゃあ、わざわざchar_bufferの先頭にM11とか付けていたのは動作にはなんの影響もなかったということなのでしょうか?ポーズ列の指定方法が各メーカーに依存するとORiN2の仕様書に書いてあるのですが、その指定方法を自力調べる方法がないので知っている人がいれば教えてください。
いやでも関係ないのだとすれば、直線補間ではsprintf(char_buffer,M11_Command,~と相対指令のコマンドを入力しているにもかかわらず、円弧補間ではsprintf(char_buffer,M31_Command,~と絶対指令のコマンドを入力しているのは何故なのかわかりません。


あと、クラスにまとめたほうがバグが発生しにくくはなると思いますけどね。
おそらくですが、以下の点が問題になるのではないでしょうか?
  • どこの関数で変更されるのかわかりにくいので処理の流れが分かりづらくなる
  • 名前の衝突が起きやすくなる
まあ何かできない理由があるのでしょうから、そのままでも構わないとは思います。


これで今までに投稿した全てのコメントに返信が来たという事にはなります。
正直なところ人の作品にコメントしたら自分の作品にもコメントしてくれるかなとか思っていたのですが、なかなかそう上手くはいかないようです。
他の作品にコメントをすればするほど他の作品がベストサポート賞等を取る可能性が高くなるわけで、相対的に自分が不利になっている感はあります。むしろ作品の出来を考えたら他の参加者が僕が有利になるようにコメント等を投稿してくれるぐらいのハンデがあっても良いと思うのですが、まあ僕なんかに構っている余裕はないですよね。



補足ですが、Ogre3Dで作成した2D、3Dゲーム作成ツールを更新しました。
Qtのバージョンが古かったのでQt-5.3.2でビルドしました。






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

人気ブログランキングへ
PR
やはりデモプログラムが手薄なのでなんとかしたいと思うのですが、僕の悪い頭ではなかなかインパクトのあるものが思いつきません。
何かアイデアがあればぜひとも教えてほしいです。
他の参加者には弱いものを助けると思って僕のプロジェクトページにコメントしてほしいと思っています。



他の作品を見ていると、やはりデモプログラム、サンプルプログラムの存在は重要だと感じました。
指差し指示のRTCはRTMコンテスト2011のこの作品と被っているのですが、デモプログラムが面白そうなので評価は高くなりそうな感じです。
デモプログラムに加えて、動画等があれば印象に残りやすいのではないでしょうか?


今回のRTMコンテストにはいくつかデータポートが動的に増減するRTCがあるようですが、そのタイミングは共通してアクティブ化した時のようです。
RTMコンテスト2010に自己拡張するRTコンポーネントという作品があるのですが、このRTCのデータポートが増減するタイミングはコネクタを接続した、切断した時になっているようです。

以下のタイミングが考えられそうです。
  1. onInitialize
  2. onActivate
  3. コネクタコールバック、コンフィギュレーションコールバック等
  4. サービスポートの関数が呼び出されたタイミング
  5. GUI等による操作時
1は起動後に変更はできないのですが、それでも十分な場合も多いとは思います。
2の方法をとるRTCは多いのですが、問題点が多い感じはします。
  • RTシステムエディタの復元機能との相性が悪い
  • 設定する度に活性化、不活性化をする必要があるため面倒
何と言うか、1よりも自由度は高いのですが、3~5に比べれば手間が多いので非常に中途半端な印象で利点がよくわかりません。

何が正解なのかはよくわからないので詳しい人は教えてください。








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

人気ブログランキングへ
MS Officeを操作するRTC群のPython版のマニュアルを作成しました。

ここから読めます。

メインスレッド以外で2つ以上のスレッドでExcelを操作しようとすると動作が止まります。
何か良い方法を知っている方は下のコメント等で教えて頂けると大変助かります。



とりあえずプロジェクトページに載せてあるRTCのソースコードの行数をコロ助というソフトウェアでカウントしてみたところ28174行という結果でした。
ちょっと長いかな?ぐらいな感じでしょうかね。
ソースコードは短ければ短いほど良いとは思うので、どこか削減できるならしたいと思います。




もっと他の作品にコメントしたいのですが、動作できる環境がない事もあってなかなか書くことがないです。
「マニュアルはどこですか?」とか「スクリーンショットを貼ってください」とか書くこともできますが、僕がそういうコメントをするのは違うと思うのでやめておきます。
それにしても全作品を見てもコメントをしたのが2人というのも盛り上がりに欠けるというか、淋しい印象です。
もっと参加者が相互にフィードバックできたら良いとは思うのですが、なかなか難しいみたいですね。
僕は1人で参加している事と能力的に劣る事を考えると、他の参加者は僕の作品にアドバイスするために数日を費やすぐらいのハンデをくれても良いと思うのですが。言ってもらえればGitHubのリポジトリを編集できるユーザーに追加します。科研費とか使っている研究もあるわけで、一体どうすれば勝てるのかを教えてほしいです。











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

人気ブログランキングへ
ExcelRTCのPython移植ですが、7割ぐらい出来ました。
マルチスレッドを使用したときのWin32Comのプログラミングはかなり難しくかなり苦戦しています。マーシャリングが正直よくわかりません。僕みたいな素人にはなかなか厳しいです。
マニュアルを書く必要もあるのでそれなりに時間がかかりそうです。



まだまだマルチスレッドでのWin32Comの使い方がわかっていないのですが、今の所以下の方法を取っています。

まずはメインスレッドでCOM オブジェクトを作成します。


Application = win32com.client.Dispatch("Word.Application")
Documents = Application.Documents
Document =Documents.Open(filename)



次に以下のようにしてインターフェースのマーシャリングします。

mApplication = pythoncom.CoMarshalInterThreadInterfaceInStream (pythoncom.IID_IDispatch, Application)
mDocuments = pythoncom.CoMarshalInterThreadInterfaceInStream (pythoncom.IID_IDispatch, Documents)
mDocument = pythoncom.CoMarshalInterThreadInterfaceInStream (pythoncom.IID_IDispatch,Document)

そして別のスレッドでアンマーシャリングを行えば、そのスレッドでCOMオブジェクトが利用できるようになります。

pythoncom.CoInitialize()
umApplication = win32com.client.Dispatch ( pythoncom.CoGetInterfaceAndReleaseStream (mApplication, pythoncom.IID_IDispatch))
umDocuments = win32com.client.Dispatch ( pythoncom.CoGetInterfaceAndReleaseStream (mDocuments, pythoncom.IID_IDispatch))
umDocument = win32com.client.Dispatch ( pythoncom.CoGetInterfaceAndReleaseStream (mDocument, pythoncom.IID_IDispatch))

これで一応Wordの操作ができてはいます。
メインスレッド+実行コンテキストのスレッドの2つなら特に問題はないのですが、コネクタコールバック等さらに別のスレッドから操作しようとすると動作できないみたいです。

詳しい人がいれば教えてください。









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

人気ブログランキングへ
間違えてInPort同士を接続してしまいました。
まあ皆さんよくやるミスと言うか、RTMあるあるですね。


何の意味があるのかと言われれば何の意味もないですけど。


MS OfficeのRTCのPythonへの移植をしていますが、配布は来週になりそうです。



去年の作品を見ていると、この作品はかなり頑張っているように見えるのですが賞を何も貰えなかったみたいです。何故でしょうね?
まあでも、要は賞を提供している方が気に入るかどうかなのでたとえ作品の出来がよくても運が悪ければ誰も選ばない可能性もありますし、運が良ければ作品の出来が今一つでも賞を貰えることもあると思います。最優秀賞はともかく、他の賞は平等に審査する必要なんてない訳ですからね。



何度が言っていますが、RTCをあまり分割しすぎるのは好きではありません。
このサイトでは以下の点が問題になると言っているようです。

  1. システム全体の見通しを著しく害する
  2. コンポーネント間通信やスレッド生成によりオーバーヘッドが増える

システムの見通しの悪さはrtshell等で複合コンポーネントを自動的に作成するようにして中身を隠蔽すれば解決はできると思います。
オーバーヘッドはrtcd等で同一プロセスでRTCを起動すればある程度改善はできます。
しかし僕の勘違いでなければ違う言語で作成したRTCは同じrtcdでは起動できなかったと思うので、オーバーヘッドはどうにもなりません。
boost.python等を使えば同一プロセスでC++で作成したRTCとPythonで作成したRTCを起動できるかもしれないですけど、その場合も単なる関数呼び出しでデータの受け渡しができるのでしょうかね?
まあ何にせよ無駄に分割しすぎるのはデメリットの方が大きいのでよく考えて設計した方が良いと思います。











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

人気ブログランキングへ
カレンダー
10 2024/11 12
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
フリーエリア
最新CM
[08/31 ysuga]
[08/31 Nobu]
[08/31 ysuga]
[12/11 Nobu]
[12/11 Kanamura]
最新TB
プロフィール
HN:
Nobu
年齢:
36
性別:
男性
誕生日:
1988/09/22
職業:
あれ
趣味:
妄想、自堕落
バーコード
ブログ内検索
P R
カウンター
忍者ブログ [PR]