この件であやしいのはやはり CameraImage.idl と CameraCommonIntefrace.idl が混ざって使われているのではないかというところですね。
ChoreonoidのCMakeオプションとして、 USE_BUILTIN_CAMERA_IMAGE_IDL というのがありまして、これはデフォルトではOFFになっています。その場合、非公式のIDL(CameraImage.idl）が取り込まれることはないはずです。
これについて、オプションはどうなっていますでしょうか？＞升谷先生
症状としては、これをONの状態で使うと、この例外が出てもおかしくないです。
ただOFFの状態だとすると、このIDLは使われないはずなので、少し不可解です。ですが、何かの間違いで取り込まれてしまっているのかもしれません。
まずはこのオプションの設定についてお知らせください。
あと、ご自分で作成したRTCで非公式のIDLを使っているということはないですよね。
念の為確認ということで。
昨年11月の問題はそれが原因でしたが，今回は違うのではないでしょうか．
USE_BUILTIN_CAMERA_IMAGE_IDLはOFFにしています．
前にお知らせしたように，chodenoidの付属のプロジェクトを使って，
bin/choreonoid sample/OpenRTM/OpenRTM-AizuSpiderSS-Remote.cnoid
だけで問題は発生しますので，自作のRTCは無関係かと．
RTCのプロパティの項目は違っていても大丈夫でしょうか？
bin/choreonoid sample/OpenRTM/OpenRTM-AizuSpiderSS-Remote.cnoid
を実行すると2個のRTCが起動します．既報ですが，これらに対してｒｔshellを使うと，
$ rtls /localhost/AizuSpider-JoystickInput.rtc
AizuSpider-JoystickInput.rtc
$ rtls /localhost/AizuSpider-VisionSensorIoRTC.rtc
rtls: CORBA.MARSHAL(omniORB.MARSHAL_InvalidEnumValue, CORBA.COMPLETED_YES)
となります．これらのRTCを「RTCプロパティ」ビューで見ると，項目が微妙に異なっています．
AizuSpider-JoystickInput.rtc
AizuSpider-VisionSensorIoRTC.rtc
https://github.com/s-nakaoka/choreonoid/blob/master/sample/OpenRTM/VisionSensorIoRTC.cpp#L140
を
"activity_type", "PERIODIC",
"kind", "DataFlowComponent",
と置き換えたところ，RTCのプロパティは他と一緒になりましたが，RTShellの問題は解決しませんでした．
一応ご報告まで．
こちらでは、Windowsでは問題が再現されますが、ubuntu16.04では問題が起きません。
先生の実行環境はどちらでしょうか。
Ubuntu 16.04です。またもうちだけの問題ですか！お手数をおかけして恐縮です。
うちでは、このためだけにUbuntu 16.04をゼロからインストールした環境でも起きています。Ubuntu 16.04の標準パッケージ以外にインストールしたのは、OpenRTM-aistの
http://openrtm.org/#linux_packages
debファイルと、pipコマンドインストールした、
sudo pip install rtshell
それから、関係ないと思いますが、Visual Studio Codeだけです。
なにかマズいことがありますか？
こちらのUbuntu 16.04で問題が発生するできるだけ簡単なプロジェクトファイルを提供します．
OpenRTM-Tank-Test.cnoid (7.8 KB)
OpenRTM-AizuSpiderSS-Test.cnoid (8.1 KB)
OpenRTM-Tank-Test.cnoidでは，１０回に５回ぐらい，OpenRTM-AizuSpiderSS-Test.cnoidでは１０回に９回ぐらい
$ rtls /localhost
rtls: CORBA.MARSHAL(omniORB.MARSHAL_InvalidEnumValue, CORBA.COMPLETED_YES)
が発生します．
すみません。Ubuntuでエラーが出なかったのは、私の環境の問題で、同じエラーを再現できるようになりました。
エラーの原因もほぼ特定できましたので、修正まで今しばらくお時間を下さい。
結論としましては、OpenRTM-aistのOutPort.hの不備によるものでした。
先日升谷先生よりご指摘がありまして、別の不具合でOutPort.hの修正版を使っていただくよう周知しておりましたが、それの更なる修正版があったようです。
これについて案内を更新しておきましたので、こちらをご参照の上、OutPort.hの更新を行ってください。
http://choreonoid.org/ja/manuals/latest/openrtm/install.html#openrtmplugin-patch-for-version112
（ブラウザのキャッシュで古い案内が表示されてしまうかもしれません。今回の不具合に関する説明が見当たらない場合は、ブラウザのリロードを行ってください。）
今OpenRTMのメーリングリストが使えないようなのでこちらで書かせていただきますが、OpenRTM開発チームにおかれましては、この不具合への対応（この修正を適用したバージョンのリリースや、OpenRTM配布ページでの案内など）を行って頂ますよう、よろしくお願い致します。
ありがとうございます！
OutPort,hを入れ替えてビルドをし直して，
bin/choreonoid sample/OpenRTM/OpenRTM-AizuSpiderSS-Remote.cnoid
で繰り返しテストしましたが，異常はありませんでした．
本質的なことではありませんが，訂正版のOutPort,hの文字コードはオリジナルに揃えてEUC-JPにしませんか．変更点を確認しようとして差分が大量に現れたので驚きました．
そちらでも不具合が解消されたようでよかったです。
ご確認、ご報告ありがとうございました。
本質的なことではありませんが，訂正版のOutPort,hの文字コードはオリジナルに揃えてEUC-JPにしませんか．変更点を確認しようとして差分が大量に現れたので驚きました．
確かに元のコードはEUC-JPだったのですが、UTF-8に変換しました。最近のLinuxではUTF-8が標準で、コンパイラがUTF-8ではないローカルの文字コードでも問題なく処理できるのか確証がありませんでしたので。
やはり現在の標準を考えると、UTF-8にしておくべきかと思います。（更に言えば、C++のソースコードには日本語のテキストは無い方がよいと思います。）
私はそのような見解なのですが、このあたり詳しい方いらっしゃいましたら、コメントいただけるとうれしいです。
でも考えてみると今回差し替えるのはOpenRTMのソースコードで、そちらは元々EUC-JPなので、OutPort.hだけ文字コードを変えるというのも変ですね。
というわけで元に戻しておこうと思います。
http://choreonoid.org/ja/manuals/latest/openrtm/install.html#openrtmplugin-patch-for-version112
で配布しているOutPort.hの文字コードをオリジナルのEUC-JPに戻しておきました。