2011/09/21

Eclipseでgoogletestを使う方法（Mac OS X SnowLeopard編）


Emacs + gccで開発もいいですが、IDEも使ってみたいのでEclipseでgoogletestのテストを実行する方法を調べてみました。

なお、前回のエントリでgoogletestのライブラリを作成したり、テストを行うサンプルコードを作成する手順を紹介しています。そちらの手順を実施していない場合は、前回のエントリを参照してください。

環境

  • Mac OS X: 10.6.8（Snow Leopard）
  • gcc: 4.5.4
  • Eclipse: 3.7.0
  • Eclipse C/C++ Development Tools: 8.0.0
手順

  • C++のプロジェクトを作成し、ソースファイルを追加する
  • プロジェクトにライブラリを追加する
  • プロジェクトにインクルードパスを設定する
  • ビルドし、テストを実行する


(1)C++のプロジェクトを作成し、ソースファイルを追加する

メニューの File -> Project -> C/C++ Project でプロジェクトで作成します。プロジェクトの種類は「Executable -> 空のプロジェクト」で良いと思います。これは、実行ファイルを作るプロジェクトで、プロジェクト内にはファイルを追加しないという意味です。

ここにmain関数があるソースファイルおよびテストコードを追加します。昨日のエントリにサンプルを紹介しているので、そちらを参照ください。

(2)プロジェクトにライブラリを追加する

プロジェクトを右クリックして、Propertiesを開きます。

開いた画面の中から「C/C++ Build -> Settings -> Mac OS X C++ Linker -> Libraries」を選んでライブラリの設定画面を開き、以下を設定します。
  •  Libraries(-l)
    • gtest
    • gtest_main
  • Library search path(-L)
    • gtestのライブラリがあるディレクトリパス

ライブラリの名前は "libgtest.a" と "libgtest_main.a" ですが、頭の "lib" とお尻の ".a" はつけません。これはgccの慣習です。

(3)プロジェクトにインクルードパスを設定する

Propertiesの画面の「C/C++ Build -> Settings -> GCC C++ Compiler -> Includes」を選んでインクルードパス設定画面を開き、googletestのヘッダファイルのあるパスを設定します。

 場所は <googletest>/include です。<googletest> はgoogletestの配置場所です。自分の環境のものと置き換えてください。

(4)ビルドし、テストを実行する

 これで設定は完了です。

メニューの「Project -> Build All or Build Project」をクリックし、ビルドします。エラーが出なければ成功です。

さらにメニューの「Run -> Run As -> Local C/C++ Application」をクリックすると、実行ファイルが実行され、テスト結果が表示されます。テストが通っていれば成功です。


投稿者 時刻: 0 コメント
ラベル: , , , ,

2011/09/20

gccとCMakeでgoogletestをビルドする方法（Mac OS X編）

Webを調べていると、googletestをビルドする際にVC++かXCodeを使う例が多かったので、IDEを使わないでできる方法を調べてみました。なお、googletest自体の説明は割愛します。


環境
私の環境は以下の通りです。

  • Max OS X 10.6.8（Snow Leopard）
  • gcc 4.5.4
  • cmake 2.8.5
公式のREADMEには cmake 2.6.4 以上が必要とありますが、gccのバージョンは明記されていませんでした。

手順

  1. svnリポジトリからgoogletestを取得する
  2. cmakeでgoogletestをビルドする
  3. main関数を持つソースファイルを作成する
  4. テストコードを作成する
  5. g++でテストコードでビルドする
  6. テストを実行する

(1) svnリポジトリからgoogletestを取得する

適当な場所に配置します。

svn checkout http://googletest.googlecode.com/svn/trunk/ gtest-svn

(2) cmakeでgoogle testをビルドする

cmakeを実行するディレクトリも適当な場所で良いです。 {GTEST_DIR}はgoogletestのあるパスに置き換えてください。 libgtest.a と libgtest_main.a ができれば成功です。

mkdir mybuild
cd mybuild
cmake ${GTEST_DIR}
make
なお、ビルド関係はREADMEが参考になります。

(3) main関数を持つソースファイルを作成する

以下のソースファイルを参考に、main関数のあるソースファイルを作成します。

ファイル名はtestmain.ccとしました。ちなみに必ず以下の順に呼ばないといけないようです。
  • testing::InitGoogleTest(&argc, argv);
  • RUN_ALL_TESTS();
#include <iostream>

#include "gtest/gtest.h"

GTEST_API_ int main(int argc, char **argv) {
  std::cout << "Running main() from testmain.cc\n";

  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

(4) テストコードを作成する

テストコードを作成します。ファイル名はmytest.ccとしました。
#include "gtest/gtest.h"

TEST(firstTest, abs)
{
  EXPECT_EQ(1, abs( -1 ));
  EXPECT_EQ(1, abs( 1 ));
}

(5) g++でテストコードをコンパイルする

コンパイルする時はgoogle testのヘッダファイルがあるディレクトリをインクルードパスに入れる必要があります。また、cmakeでビルドした時にできたライブラリも含めてビルドします。

なお、以下のコマンド中の testmain.cc はmain関数が入っているファイル、mytest.cc がテストコードが入っているファイルです。また、{GTEST_DIR}はgoogletestが入っているディレクトリのパスに置き換えてください。

g++ -I{GTEST_DIR}/include testmain.cc mytest.cc libgtest.a libgtest_main.a -o mytest
(6) テストを実行する
できあがったバイナリを実行すると、テスト結果が表示されます。テスト結果がOKなら成功です。

投稿者 時刻: 0 コメント
ラベル: , , , ,

2011/08/05

#SP_kayac 面白法人カヤックさん主催の「スマートフォンアプリエンジニア ライトニングトーク交流会」に参加してきた

夏休み中に面白そうなイベントがあったので、面白法人カヤックさん主催の「スマートフォンアプリエンジニア ライトニングトーク交流会」行ってきました。ちょろりと参加報告を書いておきます。

■面白法人カヤックとは？
http://www.kayac.com/

Webサービス/スマートフォンアプリetcの受託開発やら独自サービス展開をやっているそうです。サイトが大学生ノリで、良い意味で変な会社ですね。業績も順調に伸びているようです。

LT見てて知ったんですが、

  • 知り合いの元組み込みソフト開発者で国産JavaScriptライブラリuupaa.jsの作者であるスーパーハッカー @uupaa さんやら、
  • メーカーの研究部門出身の人がいたり、
  • 元組み込みの人いたり

純粋なWeb系の人だけじゃないようです。

■スマートフォンアプリエンジニア ライトニングトーク交流会とは？
スマートフォンのアプリを開発しているエンジニアが集まって、LTやったり、飯食ったりしながら情報交換するゆるい会でした。

アジェンダは以下の通り。
  • ” ナカマップの実装について ”, 大塚 雅和さん（@maaash）, カヤック
  • ”Reengoの技術ってどんななの？”, 村瀬大輔さん, カヤック
  • ”EncountMeのできるまで”, 堤修一さん, カヤック
  • ”スマートフォンアプリ開発のクロスプラットフォーム戦略”, 塩屋啓さん（@kwappa）, dwango

詳しくはサイトを参照してください。

■ナカマップの実装について
http://maaash.jp/lab/bowls-smartphone-lightning-talk/#landing-slide

ナカマップというのは、複数人のお友達で位置情報を共有したり、リアルタイムにグループチャットをできるiOS/Androidアプリとのことだそうです。

今回の発表は、リアルタイムなクライアント／サーバ間通信の工夫についてでした。

過去のナカマップでは、クライアントから定期的にサーバに定期的にポーリングする方式をとっていたそうですが、これではポーリング周期分遅れるという問題があったそう。

何度かの改善を経て今は、サーバとのコネクションは接続しっぱなしにして、イベントがある度にサーバからレスポンスをプッシュしてもらう形式にしたそうです。子のメリットは、リアルタイム性が高くて、サーバの負荷が低いとのこと。

発表中に、「multipart/mixed方式」とか「diggが提案した」というようなことを話していたと記憶していますが、ググってみると以下のブログを発見しました。
http://about.digg.com/blog/duistream-and-mxhr

diggの人はこの技術をMXHR (short for Multipart XMLHttpRequests)と読んでいるそうです。

今考えているアプリで複数のクライアント間でリアルタイム通信をやる必要があって、実現方法を検討していたので、ちょっと良い話聞けたなと思いました。あまりよく分かっていないので、ちらっと調べてみます。

ちなみに、懇親会の時に聞きましたが、いわゆるpush型の通信としてはC2DMというのもあるそうです。


■Reengoの技術ってどんななの？
Reengoは電話番号なしにfacebookの友達に電話がかけられるアプリだそうです。

この発表ではVoIPの待ち受けの実装について話していました。

待ち受けはアプリでは実装しておらず、OS自体にVoIPの通信を待ち受ける機能が存在するらしく、単にイベントハンドラを登録して待てば良いとのこと。

実装は以下の通り。クロスプラットフォーム開発のために可能な限り、C言語で書いているというのが興味深かったです。

  • クライアントのロジックはC言語
  • UI周りはネイティブ（iOSの場合はObjective-C、Androidの場合はJava）
  • サーバサイドはPerl/Node.js
■EncountMeのできるまで
EncountMeはスマートフォンで、いわゆる「すれ違い通信」ができるアプリだそう。

位置情報をサーバに蓄積して、マッチングして、「○○さんとすれ違いました！」とユーザに通知する機能があるとのこと。ただし、このアプリ電気をくいすぎる実装になっているそうで、アプリ提供は8月で終了するそう。でも、いろいろ反省点を活かして、次のゲーム開発に活かすそうです。

アプリとは関係ないですが、アプリ出すまでの過程が面白かったです^^; 発表者の方はたしか組み込み系の開発から転職組だそうで、転職したすぐはWeb系のプログラミングがまったくできず、戦力外通告を一度受けたとか。自分より若い人がバリバリ開発している中、PHPの本を読む毎日だったそうですが、ふんばってiPhoneアプリの勉強をして、アプリ開発者として今の立場を築いたとか。思わず拍手してしまいました。

■スマートフォンアプリ開発のクロスプラットフォーム戦略
スマートフォンアプリ開発のクロスプラットフォーム戦略
View more presentations from kwappa

TitaniumとかPhoneGapとか、iPhone/Androidなどクロスプラットフォームなアプリが簡単に開発できると言われている開発環境の現状についての発表でした。

まず「同じアプリを作りたい」という場合の「同じ」の定義から入っていました。同じという場合に、機能（ユーザに提供する価値）、UI（見た目）、ソースコードの3つに分けられるとのこと。

機能とUIを分けた理由は、UIは違ってても同じ機能（ユーザに提供する価値）が同じであれば、同じアプリだろ？ってことだそうです。実際に僕も使っているジョルダンの乗り換え案内はAndroid版とiOS版で少しUIが違うそうです。

詳しくは資料を見ていただきたいですが、PhoneGapについてはパフォーマンスがいまいちだけどソースは共通にできるとのこと。スマートフォンの性能が上がれば問題なく使えるレベルになりそうという印象でした。

実際に使っていないので何とも言えませんが、こういうツールってバグが多いとよく噂を聞くので、眉唾な感じがしました。しかし、私は個人でアプリ作ろうとしているだけなので、切迫感はありませんが業務でやっている場合、予算握っている人はこの辺は切実なんでしょうね。。。

■おわりに

自分の中で企画を考えている段階で、まだアプリできていない状況なんですけど、実際にやっている人達の話を聞けてモチベーションが上がりました。そのうち作ったアプリについてLTしたい！

機会あればまたイベント参加しますね。
投稿者 時刻: 1 コメント
ラベル: , , , , , ,

2011/07/18

ETロボコン2011 東京連合第2回集会を開催しました

先日、オブジェクトの広場にて東京連合第1回集会の模様を紹介した記事が掲載されました。ETロボコン参加者の皆様は、もうお読みいただけましたか？

そして、7/17（日）に株式会社オージス総研東京オフィスにて第2回集会が開催されました。

■参加チーム
今回の参加チームは以下の通り。総勢27名が参加しました。
  • 飛べ!　ぼくらの夢ヒコーキ
  • リンク二郎同好会
  • 電大ロボメカ
  • StrayCab06
  • チームSUPRAパンダ
  • AEKRUNNER11
  • 特命平社員2
  • H23
  • 勝ちロボ
  • 芝浦雑伎団
  • 田町レーシング
■開催内容

第2回は”難所攻略祭り”と題して、チームの代表者に各難所の攻略方法について解説していただいた後、全チームが入り交じって難所攻略についてグループディスカッションを行っていただきました。


13:00〜 案内（手嶋さん＠東京連合）
13:10〜 第1回集会アンケート結果の紹介（大西＠東京連合）
13:20〜 難所の攻略 個人発表（担当チーム）
14:35〜 休憩
14:45〜 グループワークのやり方（大西＠東京連合） 
14:55〜 難所の攻略 グループ検討
16:25〜 休憩
16:35〜 難所の攻略 グループ発表（難所グループ）
18:05〜 案内
18:15〜 終了

■難所攻略の検討および発表について


皆さん、まだ難所攻略の検討を始めたばかりで、まだ手探り状態のようでした。
しかし、皆さん、今の段階で分かっていることや、昨年の経験をふまえて活発に議論していました。
各難所の検討グループは必ず他チームメンバとの混成になるようにグループ分けを行い、意図的に他チームの人と交流を行えるようにしました。主催側としては、ギクシャクしてしまうかと思いましたが、そこは同じETロボコン参加者同士、すぐに打ち解けて議論ができたようです。

■どんな奇抜なアイディアが出た？

どんな議論をしたかは、そのうちオブジェクトの広場でも公開されます。
今は秘密です^^

実は、タイムマネジメントに忙しく、あまりメモできなかったからですが＞＜

■次回の予定

第3回は8月に開催予定です。
今のところ、本番コースを敷いての試走会、モデルレビュー、ワークショップなどを行おうかと話し合っています。
ワークショップは、参加者が疑問に思っていることなどを持ち寄って、みんなでわいわい議論したりする企画です。

そのうち、関係者にはアナウンスする予定です。お楽しみに。

■（補足）当日使った資料

投稿者 時刻: 0 コメント
ラベル:

2011/07/03

Mac OS XでJavaのkeytoolコマンドを使用する時の文字化け対応

英語のブログの方に書きましたが、Androidアプリを作ってたらkeytoolというJava関係のコマンドを使う機会がありました。

これMac上で使ってみると、以下の理由で文字化けします。
  • MacにインストールされているJavaの文字コードがShift-JIS
  • ターミナルの文字コードはUTF-8
ターミナルの「文字エンコーディング」を一時的にShift-JISにして対処しましたが、今時Javaの文字コードがShift-JISとかちょっとばかばかしいです。

どうやらcocotというツールを使うとターミナルとプロセスの間に入り込んで、エンコーディングの変換を行うツールとかあるようですが、Javaの方をUTF-8にしてほしいところですね。

投稿者 時刻: 0 コメント
ラベル: ,

2011/06/21

実践でまいまい式を使うための改善策

先日の東京連合では、外乱光対策として有力候補の「まいまい式」を実際に使うための改善策について話しました。

結論から言うと、まいまい式の弱点である輝度計算の周期が遅い問題を多少改善できることは分かりましたが、速さを競う競技ではまだまだのレベルでした。ここに調査結果を記しますので、ETロボコン有志が改善策を練ってくれることを期待しています（私は参加者じゃないので^^;）。

調査して何か分かったら、 #maimai #etrobo でつぶやいていただけるとうれしいです^^

■まいまい式について

slideshareにアップしたプレゼン資料にも書いていますが、特に東京地区大会の会場のように太陽光がコースに直接入射する場合、光センサーの仕組み上、地面の反射率が高い（明るい色）なのか、太陽光が強いのか区別できなくなります。そして、レーンが識別できなくまります。


それを回避する手法として、ETロボコン界隈では「まいまい式」がよく知られています。
原理については、すねいるさんのブログを参照してください。

http://www.chihayafuru.jp/etrobo/?p=1349
http://www.chihayafuru.jp/etrobo/?p=1371
http://www.chihayafuru.jp/etrobo/?p=1326

■まいまい式の問題点 - 輝度計算周期が長い

このまいまい式は「効果が絶大」との報告がありますが、1つ難点があります。コースの輝度を早く計算できないことです。サンプルだと20ミリ秒周期になっていますが、倒立制御の周期が4ミリ秒なのに対して、これはあまりにも長過ぎる。

では、何が問題なのか？を考えました。

(1) LED光の点滅周期が遅い

まず疑ったのが、LED光を早く点滅できないんじゃないかということ。普通に考えると、こんなシンプルな回路でミリ秒もかかるわけないのですが、裏を取ってみました。

http://mindstorms.lego.com/en-us/support/files/default.aspx

上記のURLから取得できるNXTの回路図を見ると、LED光の点滅はメインプロセッサのARM側でやっています。LED光を点滅するための回路がARMに直接つながっているシンプルな構成です。回路的には問題ないと思います。

また、デバドラのソースコードはnxtOSEKの下にありますので、探してみてください。レジスタを操作してるだけなの普通のコードです。これも問題ないと思います。

（回路図とデバドラに問題ないので、問題ないと自分の中では結論付けていますが、電気的な特性で何かあると分かる人いましたら、ご連絡ください）

(2) 光センサ測定値の測定周期が遅い


もしかすると光センサの測定値を早い周期で取得できないのではないかと考え、こちらも調べてみました。ハードウェアの仕様書によると、とある事情でAVRのサブプロセッサが3ミリ周期で光センサのA/D変換結果を取得し、2ミリ秒周期でARMのメインプロセッサに送っているようです。

つまりは3ミリ以上は速くなりません。また、ARM側が値を取得するタイミングとARM-AVR間の通信周期が合わない場合もあるので、ARM側の取得が約2ミリ遅れることもありえます。

つまり、以下の3つの周期が噛み合ないと最新のデータが期待するタイミングで取得できません。

  • AVRのA/D変換が3ミリ周期
  • AVR - ARM間の通信が2ミリ周期
  • ユーザプログラム側で光センサ測定値を取得する周期・・・実装次第

ボトルネックはここにも存在することが分かりましたが、20ミリとかのオーダーの問題を調べているので、他にも問題は潜んでいそうです。

(2)' 光センサの測定速度が遅い

ちなみに、光センサのデバドラはAVRのサブプロセッサ側にありますが、こちらも回路図とデバドラともにシンプルで問題ないはずです。ドキュメントによると0.1ミリ秒くらいで処理は終わっているよう。

デバドラのソースコードはこちらで入手できますので、興味ある方は調べてみてください。

(3) 光センサがLED光の点滅の影響を受ける

これは調べきれていませんが、点滅と光センサの測定がほぼ同時期に実施されると、何らかの影響を受けてもおかしくはありません。きっちり点灯（もしくは消灯）してから光センサ測定をするように、タスク設計すると良いと思います（まだ調べてないのでなんとも言えません）。

(4) まいまい式の差分計算の計算量が多い

これは、まいまいさんが現実の光センサ値を線形補正するやり方をご紹介しています。
http://www.chihayafuru.jp/etrobo/?p=1371

計算量をおさえるように工夫されていて、問題ないようでした。
ちなみに、ここの補正係数は各自で調整が必要です。

(5) その他のオーバヘッドが大きい

オリジナルの実装ではタスクの生成／破棄を頻繁にやってるので、ここは少し冗長だなと思いました。周期タスクで処理をやりつつ、一切破棄をしない実装だとどうなるのか調べてみました。


ライントレースしての実験ではないので不完全ですが、8ミリ周期でLED光を点滅しながら、光センサも測定し、輝度計算もできていました。

■まとめ

ちょっと工夫したら、少し遅めに走る分には問題ないレベルに改善することが分かりました。ただ、AVRのデバドラを規約上書き換えることができないので、根本的に直すのは無理のようです。

会場からは「マップ走行（光センサを使わず、モータエンコーダ値で位置を計算する方法）をメインに使って、補助としてまいまい式の輝度計算結果を使ってみてはどうか？そうするとまいまい式の計算速度は気にならない」という意見もありました。これはなかなか現実的な提案なので、どなたか試してみてください！
投稿者 時刻: 0 コメント
ラベル:

2011/06/19

ETロボコン東京連合の第1回を開催しました

6/18（土）に株式会社オージス総研東京オフィスにて、ETロボコン東京連合の第1回集会を開催しました。そのうちオブジェクトの広場でも、報告記事が載ると思いますが、ここでも報告します。

■東京連合とは？

ETロボコン東京地区参加者の有志による独自勉強会です。2010年から始めて、今年で2年目です。だいたいモデルのレビュー、合同試走会を行っています。

昨年の様子はこちらを参照してください。
http://www.ogis-ri.co.jp/otc/hiroba/technical/ETRoboconTokyoRengo/index.html

■第1回の参加チーム


  • 勝（かち）ロボさん
  • 笑's3人娘さん
  • 飛べ！僕らの夢ヒコーキさん
  • すねいるさん
  • 田町レーシング
  • 芝浦雑技団

■スケジュール

今回は初回なので全員で顔合わせ。そして、常連の人が講演するという内容でした。次回以降はもっと参加者全員で対話的に議論する形になると思います。


  • 13:45 全員で自己紹介
  • 14:05 東京連合とは？（手嶋さん＠東京連合）
  • 14:15 大胆予想〜今年のモデル／競技はこう変わる〜（手嶋さん＠東京連合）※全員でのブレストあり
  • 15:15 休憩
  • 15:30 要求分析入門（片山さん＠田町レーシング）
  • 16:00 縦横無尽走行解説（瀬尾さん＠勝ロボ）
  • 16:30 休憩
  • 16:45 まいまい式解説（大西＠東京連合）
  • 17:45 第2回集会のお知らせ（手嶋さん＠東京連合）
  • 18:00 終了
  • 18:30 懇親会（南関東地区の方も4名参加されました）

■講演の感想

○ 大胆予想〜今年のモデル／競技はこう変わる〜（手嶋さん＠東京連合）

2011年で規約が変わった箇所について、モデル審査や競技面の両方について議論しました。詳細は、後日公開予定のオブジェクトの広場の記事を参照してください。

気になったのはBluetoothでPCとロボットが通信できるようになったこと。ある人は無限の可能性が広がったと期待感を示していました。一方で、通信の信頼性の問題があるので、頼りすぎるのは良くないとの意見も。可能生はありますが、どこまで使えるかは各自検討が必要です。

○15:30 要求分析入門（片山さん＠田町レーシング）

要求分析の入門として、要求分析の目的やユースケース図および要求図の書き方について紹介していただきました。

会場からは要求を整理することは大事だとは重々承知だけど、最初に要求図をちゃんと書けるの？との意見も。田町レーシングのメンバが昨年使った感想として、「最初から一発でできない。反復型の開発を取り入れて、開発を通じて分かったことを要求図に盛り込むやり方が良い」とのコメントしました。

○16:00 縦横無尽走行解説（瀬尾さん＠勝ロボ）

これは、いわゆるマップ走行という光センサを使わない走り方の紹介です。光センサは一切使わず、エンコーダ値からロボットの位置を計算し、あらかじめ決めたルート通りに走ります。

ここでは書ききれませんが、高校数学レベルの知識があれば、すべて計算できます（三角関数、ベクトル演算など）。おそらくは、数学の知識に関しては2Dのゲームなどを作った経験ある人はみんな知ってる内容です。

ロボコンでやる場合は、エンコーダ値のズレなどを補正する必要があります。やり方としては、光センサで直線部分などコースの特徴的な場所を検知して各種パラメタをリセットすると良いようです。

○16:45 まいまい式解説（大西＠東京連合）

これは後日ブログに掲載します。

■懇親会の感想

南関東の方も来られて、地区を超えた熱い議論をしました。ロボコンも地区内外の交流が増えてきましたね。

■第1回を終えてみて

2011年の参加者がひとまず一カ所に集って、勉強会できたことは大きな成果です。
皆さん、今後も参加を希望しているとのことで、東京地区全体のレベルアップ、そしてチャンピオンシップ大会で東京地区参加者の上位総なめを目標に支援していきたいと思います。

あと、もしかすると南関東の人達とコラボするかもしれません。
投稿者 時刻: 0 コメント
ラベル:
登録: 投稿 (Atom)