[openrtm-users 00793] Fw: サービスポートを使ったデータの受信について

2 posts / 0 new
Last post
root
Offline
Last seen: 1 day 22 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00793] Fw: サービスポートを使ったデータの受信について

お世話になっております。
富士通研究所の深貝です。

下記の件について補足と質問を追加させていただきます。
下記IDLファイルを用い、Template Editorが生成したサービス
プロバイダー側のコードをコンパイルする際、コードを以下の
ように修正しました。(修正しないとコンパイルが通らなかった
ため)

(TestServiceSVC_impl.h)
修正前:
Data *getData();
修正後:
Data getData();
(TestServiceSVC_impl.cpp)
修正前:
Data *TestServiceSVC_impl::getData()
修正後:
Data TestServiceSVC_impl::getData()

そこで質問なのですが、サービスポートで構造体を返すことは
そもそもしてはいけないことなのでしょうか?

以上、よろしくお願いいたします。

Forwarded by Takuya Fukagai
----------------------- Original Message -----------------------
From: Takuya Fukagai
To: openrtm-users@m.aist.go.jp
Date: Fri, 22 May 2009 17:05:52 +0900
Subject: [openrtm-users 00792] サービスポートを使ったデータの受信について
----

はじめて投稿させていただきます。
富士通研究所の深貝と申します。

大容量(12MB)の構造体をサービスポートの関数の返り値として返
すようにしたところ、コンポーネントのactivate時にエラーが
発生してしまいました。
サイズが小さな構造体を返すようにしたときは問題がなかったので、
返す構造体の大きさに制限があるのではと考えています。

データポートでは2MBの制限があり、それはrtc.confにて最大サイズを
指定することで回避できるとのことでしたが、サービスポートの場合は
rtc.confに、
corba.args: -ORBgiopMaxMsgSize 31457280
のように30MBの最大値を指定しても問題を回避できませんでした。

サービスポートで扱うことのできるデータのサイズはデータポートとは
異なるのでしょうか?

以下にバグ再現用のテストで用いたIDLファイル記します。

---ここから--
const unsigned long DATA_SIZE = 3145728;
struct Data {
unsigned long info[DATA_SIZE];
unsigned long size;
};
interface TestService{
Data getData();
};
---ここまで--

環境はOpenRTM-aist-0.4.2, OSはWindows XP, コンパイラはVisual C++ 2008です。
以上、よろしくお願いいたします。

Undefined
root
Offline
Last seen: 1 day 22 hours ago
Joined: 2009-06-23 14:31
[openrtm-users 00795] Fw: サービスポートを使ったデータの受信について

富士通研究所 深貝様

お世話になっております。
産総研 栗原です。

サービスポートではユーザー定義のオペレーション呼び出しを行って
いるだけですので、構造体を使用しても特に問題ありません。

こちらでも、深貝様が提示されましたIDLファイルにてコンポーネント
を作成し、確認してみましたところActivate時にエラーとなりました。
環境は、Windows XPとUbuntu-8.10にて確認致しましたが、どちらでも
エラーとなりました。

下記のURLに「structを使用するより、sequenceを使用した方がよい」
という内容の記述がありましたので、参考にして頂ければ幸いです。
# 既にインターフェースが決定している場合でのIDLの変更は厳しいか
# とは思いますが。。。

http://www.nabble.com/omniorb-4.1.3-and-large-messages-td21603930.html

ちなみに、こちらの環境にて、下記のようにIDLファイルを書き換えて
動作確認しましたところ、Activate時のエラーは発生しませんでした。

-----------------------ここから---------------
const unsigned long DATA_SIZE = 3145728

interface TestService{
typedef sequence MyData;
MyData getMyData();
};
-----------------------ここまで-------------------

以上、宜しくお願い致します。

On Tue, 26 May 2009 17:14:08 +0900
Takuya Fukagai wrote:

> お世話になっております。
> 富士通研究所の深貝です。
>
> 下記の件について補足と質問を追加させていただきます。
> 下記IDLファイルを用い、Template Editorが生成したサービス
> プロバイダー側のコードをコンパイルする際、コードを以下の
> ように修正しました。(修正しないとコンパイルが通らなかった
> ため)
>
> (TestServiceSVC_impl.h)
> 修正前:
> Data *getData();
> 修正後:
> Data getData();
> (TestServiceSVC_impl.cpp)
> 修正前:
> Data *TestServiceSVC_impl::getData()
> 修正後:
> Data TestServiceSVC_impl::getData()
>
> そこで質問なのですが、サービスポートで構造体を返すことは
> そもそもしてはいけないことなのでしょうか?
>
> 以上、よろしくお願いいたします。
>
>
> Forwarded by Takuya Fukagai
> ----------------------- Original Message -----------------------
> From: Takuya Fukagai
> To: openrtm-users@m.aist.go.jp
> Date: Fri, 22 May 2009 17:05:52 +0900
> Subject: [openrtm-users 00792] サービスポートを使ったデータの受信について
> ----
>
> はじめて投稿させていただきます。
> 富士通研究所の深貝と申します。
>
> 大容量(12MB)の構造体をサービスポートの関数の返り値として返
> すようにしたところ、コンポーネントのactivate時にエラーが
> 発生してしまいました。
> サイズが小さな構造体を返すようにしたときは問題がなかったので、
> 返す構造体の大きさに制限があるのではと考えています。
>
> データポートでは2MBの制限があり、それはrtc.confにて最大サイズを
> 指定することで回避できるとのことでしたが、サービスポートの場合は
> rtc.confに、
> corba.args: -ORBgiopMaxMsgSize 31457280
> のように30MBの最大値を指定しても問題を回避できませんでした。
>
> サービスポートで扱うことのできるデータのサイズはデータポートとは
> 異なるのでしょうか?
>
> 以下にバグ再現用のテストで用いたIDLファイル記します。
>
> ---ここから--
> const unsigned long DATA_SIZE = 3145728;
> struct Data {
> unsigned long info[DATA_SIZE];
> unsigned long size;
> };
> interface TestService{
> Data getData();
> };
> ---ここまで--
>
> 環境はOpenRTM-aist-0.4.2, OSはWindows XP, コンパイラはVisual C++ 2008です。
> 以上、よろしくお願いいたします。
>

Log in or register to post comments

Download

latest Releases : 2.0.0-RELESE

2.0.0-RELESE Download page

Number of Projects

Choreonoid

Motion editor/Dynamics simulator

OpenHRP3

Dynamics simulator

OpenRTP

Integrated Development Platform

AIST RTC collection

RT-Components collection by AIST

TORK

Tokyo Opensource Robotics Association

DAQ-Middleware

Middleware for DAQ (Data Aquisition) by KEK