-
Notifications
You must be signed in to change notification settings - Fork 18
problem_and_coping
各開発環境における課題と対処法について解説します。
ETロボコンの技術教育ではβ7-2の利用を前提としており、本部技術委員会ではこれを推奨します。 今までβ5を利用していた方は、以下に示すβ6からの変更点に注意してください。
- 作業ディレクトリが「hrp2/sdk/workspace」へ移動しました。 β5までのアプリケーションをビルドする際には、Makefile系のファイルをβ6以降のものに置き換えてください。
- makeコマンドのオプションが変更になりました。 アプリケーションローダーから起動する動的ローディング形式のビルドは「make app=フォルダ名」、 プラットフォームも含めたスタンドアロン形式のビルドは「make img=フォルダ名」で呼び出してください。
Bluetoothドングルやドライバに相性問題があります。 現状で検証した結果についてはEV3RTのページのWindows でのBluetoothの接続方法を参照してください。
EV3RTのデフォルトでのBluetoothデバイス名は "Mindstorms EV3"、PINコードは "0000" になっています。 参加しているチームが同じ会場でBluetoothにて走行体とペアリングしようとしたなら、以下のような状況になることが容易に想像できます。
- デバイス名は皆 "Mindstorms EV3" なので、間違って他チームの走行体をペアリングしてしまう可能性が極めて高い
- PINコードが皆同じなので、悪意のあるチームが勝手にペアリングして妨害工作をすることが可能
対処方法としてはデバイス名をチームごとに変更し、PINコードをチーム内で秘密のものに変更することです。 EV3RT β4以降でデバイス名とPINコードを変更する方法は、EV3RTのページのFAQの「Bluetooth 接続に関する質問」を参照してください。
EV3RT では現状、グローバルや static に定義された C++ オブジェクトのデストラクタ実行に対応しておりません。
デストラクタを持つクラスのオブジェクトをグローバルや static に定義すると、プログラム終了時の実行の仕組みとして __dso_handle への参照が発生しますが、EV3RT はこの __dso_handle の扱いに対応していないためリンクエラーが発生します。
この問題を回避するためにコンパイル時のオプションとして -fno-use-cxa-atexit を指定することにより、__dso_handle への参照が発生しないようにもできます。 ただし、他でコンパイル済の C++ ライブラリを利用する場合 -fno-use-cxa-atexit では回避できないので、以下のコードを app.cpp に入れてリンクを解決することで回避は可能です。
void *__dso_handle=0;
いずれにしても、グローバルや static に定義された C++ オブジェクトのデストラクタは動作しないので、プログラム終了時のリソース解放がOSまかせになるという問題は残ります。
初回起動時は、メニュー画面（StartupApp.exe）とファームウェアに入っているMonoBrickFirmware.dllに対してAOT(Ahead-Of-Time)コンパイラが動くので、かなり「猿ダイアログ」の出ている時間が長くなります。気長にお待ちください。
Bluetooth PANはWifiアダプタを使わなくてもBluetoothでIP接続できる便利なものですが、デフォルトではデバイス名がEV3で、PINコードなしでペアリングできてしまいます。参加しているチームが同じ会場でBluetooth PANで走行体とペアリングしようとしたなら、以下のような状況になることが容易に想像できます。
- デバイス名は皆EV3なので、間違って他チームの走行体をペアリングしてしまう可能性が極めて高い
- PINコード認証が無いので、悪意のあるチームが勝手にペアリングして妨害工作をすることが可能
対処法としてはデバイス名をチームごとに変更することとPINコードでの認証を強制することです、MonoBrickは標準ではどちらの機能も提供していません。
EV3way用のサンプルプログラムでは以下の拡張を導入していて、プログラムの先頭部分で呼び出しています。この実行により認証が強制されるようになります。
ETRobocon.EV3.Brick.InstallETRoboExt();
ホスト名を変更するには以下を呼び出す必要があります。
ETRobocon.EV3.Brick.SetName(デバイス名);
PINコードを変更するには InstallETRoboExt() を最初に呼び出す前にソースコード Brick.cs の以下の部分を修正するか、EV3にログインして /etc/bluetooth/btpin ファイルの中身を書き換える必要があります。
if (!File.Exists (LEJOS_BTPIN)) {
fs = File.Create (LEJOS_BTPIN);
sw = new StreamWriter (fs);
sw.WriteLine ("1234"); // ここを書き換える
sw.Close ();
fs.Close ();
}
ペアリング前に上記変更を行ってからプログラムを起動し、一度実行を中断してMonoBrickを再起動してからペアリングを行ってください。
Yosemite 以降のOS XではBluetoothに関する設定が簡略化されすぎており、ペアリング後にEV3のデバイス名やPINコードを変更して再ペアリングできないという問題があります。これは以前のペアリングを削除しても情報がキャッシュ情報として残っていて、再ペアリングの際に利用されるためです。
回避方法としては、一度Bluetoothを無効にし(Bluetooth接続のキーボードやマウスも使えなくなるので注意)、 /Library/Preferences/com.apple.Bluetooth.plistを削除し、OSを再起動することで再ペリングが可能になることを確認しています。この回避方法を行うとペリングしている他のデバイスの情報も消えてしまうので、再度ペアリングし直す必要があります。
注意 システムファイルの削除を行う操作となるため、細心の注意の上で操作を行なってください。本対処の結果について、ETロボコン実行委員会は責任を負いません。
この他、Appleが開発者向けに提供している Hardware IO Tools for Xcode に含まれる Bluetooth Explorer を使えば、上記のようにシステムファイルの削除を行わなくても再ペアリングを行えます。ただし、開発者向けであるので、Bluetoothの中身を知らずに使うのには難があります。ダウンロードサイトは以下となります。
https://developer.apple.com/downloads/?name=for%20Xcode
Xamarin StudioからプログラムをEV3に転送して実行すると、プログラムを終了した時に、メニュー画面（firmware画面）に戻りません。これは、環境構築ガイドにも記載している通りです。プログラムを終了する時に、メニュー画面（実体は、StartupApp.exeというアプリケーションです）を起動し直すことで、この問題を解決できます。
EV3wayのサンプルコードでは、この対処を行っています。このサンプルでは、MainClassクラスのMain()メソッドの末尾で、System.Diagnostics.DebuggerクラスのIsAttachedプロパティがtrueの場合は、ETRobocon.EV3.BrickクラスのExitToMenu()メソッドを呼び出します。ExitToMenu()では、メニュー画面（StartupApp.exe）を起動することにより、アプリケーションが終了した時にメニュー画面に戻るようにしています。
注意：アプリケーションをEV3のSDカードに転送して、メニュー画面から起動した場合（つまり、リモートデバッグ実行ではなく、通常実行した場合）は、ExitToMenu()を呼び出すと、メニュー画面が 二重に動作 してしまいます（StartupApp.exeが二つ同時に動いている状態になってしまい、動作がおかしくなります）。そのため、System.Diagnostics.DebuggerクラスのIsAttachedプロパティを使って、デバッグ実行中かどうかを判定し、 デバッグ実行中の場合にだけ ExitToMenu()を呼び出すようにして下さい。
※leJOS EV3の検証は0.9.1で実施しています。
leJOS EV3もMonoBrickと同様の問題があります。MonoBrickの場合と同様に対処してください。
leJOS EV3では、Javaの実行にNXTまでのTiny VMではなく、Oracle純製のVMを利用しています。Javaの機能をフルに利用できるようになった反面、NXTまでのものより実行が重くなっています。実際に計測したところモータやセンサにアクセスするのにそれぞれ数ミリ秒かかっていました。このため、EV3wayのような４ミリ秒の間にセンサから情報を読みだして倒立振子制御を行なってモータを駆動しなければならない場合には走行体を立たせることもできなくなります。
OracleのJavaにはHotSpotという機能があり、プログラム中の頻繁に利用する部分からCPUネイティブなコードに変換していきます。デフォルトでは1500回実行したメソッドからネイテイブコードに変換します。この機能を利用して倒立振子制御を行う前にモータやセンサに1500回アクセスしておくと、以後のアクセスが高速化され、倒立振子制御に十分な性能が得られるようになります。EV3way用のサンプルプログラムでは、このHotSpotの機能を利用して倒立振子制御を実現しています。