No.100 finished presentation

研究成果を発表するプレゼンを今日終えた。
ああ、疲れた。
俺ってやっぱりダメだな、そう痛感しっぱなし。

プレゼンも前日に作成して、まったく練習できずに当日にまだ入れてなかった数式入力してたりしてたし。
それでいざ練習してみたら、まったく言葉がでてこないのに愕然とする。

本当にダメだな、なんか、細かいことにこだわって、大局的に物事を進めるということがどうも苦手なんだよな。

それでもプレゼン良かったと言ってくれるBenに感謝。
最近は自分でプレッシャーを感じて押しつぶれそうになってたけど、それでもプレッシャーを与える側であるBenが気にしないで励ましてくれる存在であったことをありがたく思う。

プレゼン後はBenがビールをおごってくれて研究室の人と飲みにいった。
満足のいくプレゼンはできなかったけど、あまりに準備ができてなかったわりには
割とうまくいったかとか思ったり、とにかくもプレゼンを終えたという安堵感に浸る。
そしてBenに会うのもこれで最後かと思うと、なんとも複雑な心境。
反省やら、とにかくできるだけ頑張ったよなと思ったり。

でも実はまだやらなきゃいけないことがある。
これまた今日がDeadlineであったレポートの期限を明日に伸ばしてもらった。
てか、レポートというよりThesisなんですけど、、、なんで半年留学してThesis書いてるんだろ。
この段階でまだできてないことからして、クオリティは悪いということは言ってあるけど、
とにかくもうこれ以上伸ばしてもいいことない。
とにかくクオリティ悪かろうが、明日までに提出する。
できるだけシンプルにかく。
成績は気にしない。

そして日本に帰ってから、満足のいかないとこはできれば直したいと思う。
明日は友達が日本から来る。
一緒に思いっきり遊べるために、なんとしても今日頑張ろう。
もう一日だけ、頑張ろう。

blue at 18:28 Trackback() Comment(0)

No.98 想定読者は自分です

レポートが全く書けていない。
これは、やばい、ほんとこんなペースじゃ間に合わないよ。
倒立振子で忙しいからといって書いたイントロダクションをＢｅｎに見せるのを延ばし延ばしにして、今日には見せると約束してたのに、今日も間に合わなかった。あぁ、昨日徹夜しようと思ったけど気力が出なかったんだよな、、、。
約束を破ることに慣れてしまいたくないな。自分がダメ人間と責めてしまうからね。。

で、研究レポートを書かずに何をしてたかというと、レスコンで作ったロボットの紹介記事を書いてくれと頼まれていて期限が迫っていたから書かなきゃいかん かったのです。あぁ、もうちょっと前の落ち着いたころに書こうと思ったけど、何を書けばいいかわからなくて後まわしにしてしまったを後悔。
今回も、何を書こうか、書く意味のあることなんてあるのだろうか、読んでためになるものを書けるだろうかと考えてしまうと、何も書けなくて、時間だけがたってしまうのだった。
文章を書いてみても、なんかこんな口だけの文意味ないよなと思って消したり、でも結局めんどくさいとか思いながら引き受けてしまった責任感で書こうとしてるのだから、結局意味のある文章なんて何も書けないことになっちゃうなとか。
こんなことを書いてみようと思っても、文の順序が良くないのを変更したりしてたら中々進まない。

なんか、ダメだなオレ、、、なんか、文章書くのものすごく下手になった気がした。
こちらでロボットアームのレポート書いたときも、文章が浮かんでこなくてすごく苦しんだし。
よく考えてみると、オフィシャルな文章を書くときは、最近いつも苦しんでるなと思った。

最たるものが今年度の卒論。
あんだけ時間かけた割りに、あんな卒論まったく満足してない。
やっぱり書き始める前に、どういうフィロソフィーで書くか、どういう目的で書くかということがしっかりしてなかったからダメだったんだろうな。

オフィシャルなものを書くときは、評価者の目を気にしてしまい、凄そうなやつを書かなければいけない、期待されているものを書かないといけないとプレッシャーを感じてしまい、そのように書こうとしてもやっぱり書けなくて潰れてしまうのだ。

何の目的で文章を書くか、フィロソフィーをしっかり持っておけば、文章は書けるのだと思う。
今回のレスコンの記事に関しては、最終的にはなんとか目的をもって書けたので、自分としては納得である。

●フィロソフィー
シンプルに書く、無駄に長く書かない。
字数は指定されていないのだから、書くべきことがなければ短くすればいいだけのこと。
ウソを書かない、本当に思っていることを書く。

●誰のために書く文章か
１．自分
２．チームメンバー
３．一般人

そう、はじめ書こうと思ったときに悩んだのは読者ターゲットを誰なのか考えていなかったから。いちおうオフィシャルに公開されて色々な人に読まれる可能性 のある記事だけど、自分としては別に誰ともわからない人に面白いと思ってもらう記事を書くモチベーションは持ち合わせていなかったのである。
モチベーションが出るとすれば、自分のために、あのときは何が起こったのか、もう一度整理するということだった。
その次は、同じチームのみんなに、こんな設計思想で取り組んだんだよとか、こんなトラブルがあったんだよ、こんな反省をしたので次に生かしてね、という感じで伝えるということ。
また一緒に製作したチームメイトに。あのときのことを整理したよ、こんなことあったよね、面白いと思うから読んでみてよ

はっきりいって、チームメンバーには読む価値があったと思ってもらえる記事は書けたと思っている。
だってもともと興味をもってくれている仲間だよ。
そして優先順位がもっとも低いのが、今までターゲットにしてしまっていた一番読まれる数の多いだろう見知らぬ誰か。
そりゃあ一番読まれる人に面白いと思ってもらえるものを書きたいけどね、残念ながらそんなネタを持ち合わせていないのだから仕方がない。それでもそんなものを書こうとしたときには、粉飾しないわけにいかなくなるのだ。
そうすると、最も大事なはずの自分が壊れてしまうのである。
自分にウソをつくことになるから。

だから、やっぱり読者ターゲットの第一は自分なのである。
見知らぬ誰かには面白いと思ってもらえれば嬉しいなくらいの気持ちでいいのである。

こんな調子で、こちらのプロジェクトレポート作成のフィロソフィーと想定読者も考えてみた。

フィロソフィー
●読んで面白いものにすること。これは読み物である、ジャンクレポートではない
●高校生が理解できるくらいにシンプルに説明すること。できなければ、Ａｐｐｅｎｄｉｘで詳しく説明すること
●グダグダ書かない、字数を埋めるために書かない。簡潔明瞭に書く！
●後から自分で読んで思い出してニンマリするようなものを。ありのままを書けばよし
●ウソをつかない、うやむやにしない、謙虚であること
●友達に読んで理解してもらえるものを

想定読者
１．自分
２．Ｂｅｎ
３．Ｂｒｅｎｄｏｎ他Ｂｅｎの下でこれからこの分野を研究する学生たち
４．ＣｏｍｐｕｔｅｒＶｉｓｉｏｎのこの分野に興味のある素人
５．Ｆ先生
６．友達


時間がないけど、クオリティの低いレポートを書くのはもうこりごり！
短くても意味のあるものを書きたい。
想定読者はやっぱり自分が一番。
自分のために書くのです。

blue at 22:10 Trackback() Comment(0)

No.90 KLT Kanade-Lucas-Tomasi

土日は腐ってた.
ずっと寝てた.
なーんもやる気がおきなかった.

勉強しなきゃと机に向かっても、やっぱり集中できなくて、ネットサーフィンしたり、つかれて寝転がったら十分寝てるはずなのに、また寝ちゃってた.
ご飯も食べるの面倒くさくて、夜ご飯の最終時間を逃した.
ついでにシャワーの最終時間も逃した.
仕方ない、じゃあ寝るか、、、.

だめだ、こんなのじゃなんのために留学してるかわかんない.
授業も研究も遅れ気味で、やっぱり自分はいつもキッチリ目標どおりにできない人間なんだなと凹む.
でもどうしても何に対してもやる気の出ないときってのがあるんだよな.
いまだにこういうとき、どう対処したらいいのかわからない.
とにかく、もういちど気を引き締めていかないと！

今日は、前日怠けすぎたせいで頭もあまり働かず調子悪かったけど、なんとか怠けずには済んだ.
さて、前回試したOpenCVのHarrisCornnerDetectorはあまり特徴点を見つけてくれなくて、しかもちょっと動かしたらあちこち場所が変わったりして安定でもなく、とてもこのままではフューチャーマッチングに進める感じではなかった.　特徴点として認識する閾値のようなパラメータをいじっても敏感にならず、どうしたもんかと参る.　
画像がシャープじゃなくて悪いのかなと思ってフィルタをまずかけてシャープにしたらいいかなと思って探すが、そんな関数はなさそうで、自分でつくらないといけなさそうな.めんどいな.
まず、今使ってるカメラじゃなくて、ほかのカメラで撮られた割とシャープな画像を読み込んでつかってみたらそれが原因かわかるなと思い試してみた.
そしたら、やっぱりあまり認識しない.
こりゃやっぱりHarrisCornnerが精度悪そうな.

ネットで調べてたらKLTを使って特徴点を表示しているのがあり、かなりいい感じで認識していたので試してみることに.　KLTのヘッダファイルやライブラリファイルにリンク、コンパイルするのがうまくいかず嵌ってしまいかなり時間がかかったが、なんとか解決し今日夕方にやっとKLTでFeatureDetectionできた.

だいぶ重たいけど、かなり特徴点を見つけてくれる（指定しただけ任意の数）し、カメラを動かしてもほぼそのまま認識してくれているので、かなり安定していてびっくりした.
KLTはKanade-Lucas-Tomasi Feature Trackerのことで、金出先生はウチの研究室のボスのボスにあたる人だ.
すごい人だと聞いてたけど、KLTは画像関係でかなり画期的で一般的になった手法のようで、実際つかってみて、金出さんはやはりすごかった.

KLTはトラッキングがメインだと思うんだけど、まだこちらはあまり試してないけどうまくいってないし、FeatureDetectionだけを使おうかな.
マッチングとトラッキングはSAD、SSD、NormalizedCorrelationなどを使って自分でできるような気がしている.
本当はHarrisCornnerの精度を上げて実装できたら、処理も軽くていいんだけど、とりあえず早く目的の動作ができるようにしたいので、KLTで先に試すかなぁ、うーん、、、

blue at 22:56 Trackback() Comment(0)

No.87 handache...

昨日にはFeatureDetectionができた。
といってもOpenCVの関数cvGoodFeatureToTrackというのを使っただけだけど。
なんか結局OpenCVではかなりの関数が誰かの手によって作られているので、自分でつくっていくというより、使えるライブラリを探し当てて、使い方を覚えるというのがほとんどの作業だったりして。

でもほんとに探したり使ったりだけだと、知識もあまりつかないので、その中身もある程度理解するように努めることが大切かな。そして、使えるものがないけど、どうしてもほしいってやつは、気合を入れて自前で作るという態度がいいかなと思う。
とにかく今は、細かい一部分を時間かけて精度よいものをつくるというのよりも、精度は悪くても全体の流れを経験して、それなりの最終形態が見えるようなものをつくりたいと思っているので、使えるものは使いたい。


ところで昨日ロッククライミングに行って、がけの下のほうで練習とかして、ジャンプして着地したときに体勢悪く、手指を地面にぶつけてしまいパキっと音がした。
やってもた、折れたり脱臼してないかと恐れたが、なんとか指は動きそんな痛くもなかったのでとりあえず様子見ることにしたが、今日かなり痛かった。
力が入らないので、キーボートを打つのもドアを開けるのもご飯を作るのも苦労した。

やっぱり念のため病院いったほうがいいかな、、、。
もし脱臼とかしてたら早めに行かないと固まってしまうみたいだし、それはいやだな。触ってみてもよくわからないんだよな、、、

blue at 22:07 Trackback() Comment(0)

No.83 triangulation done

色々遠回りしてやっと、２つのカメラから得られた画像においてそれぞれ対応する２次元座標から３次元座標を得るTriangulationができた。
いちばん簡単なやつで実装したので、別の手法も試したほうがいいかもしれないが、まずはこれでどれほど正確に三次元座標が測れているかチェック。

そしたら以外にかなり正確に測れているんじゃないだろうか。とりあえずTriangulationはこれでいいとして、他にもやることがいっぱいあるので精度はあまり気にしないでどんどん進めていかないと。
とりあえず嬉しくなってさっそくBenに報告。
Hi Ben,

I checked the accuracy today.
That was more accurate than I expected!

These are the quick results before talking to you further tomorrow.
I measured the depth up to the object which is on straight line along
camera ray, with a measure, and with the triangulation.

measure(cm):  triangulation(cm)
30                   : 30.0
40                   : 39.8
50                   : 49.4
60                   : 59.8
70                   : 69.3
200                 : 208

今回は対応点を２つのカメラ画像から目視で選択して、Triangulationを行ったが、実際には自動で対応点を見つけていかなくてはいかない。
基本的にはHarrisCornerという何処か角のようなわかりやすい特徴点を見つけていくことになる。

さらに２つのカメラでそれぞれ特徴点を見つけてから、今度はひとつのカメラのどの特徴点と、もうひとつのカメラのどの特徴点が対応する点かというのを見つけてやらなければならない。

これをするには、２次元空間を探索してやる途方もない作業になると思うかもしれないが、エピポラ拘束というステレオカメラの幾何学的な条件より、実は１次元の探索で済む。

つまり、片方の画像のある点に対応するもう片方の画像の点を見つけようと思ったとき、それは特定の線上のどこかにあることがわかっている。あとはピクセルごとに調べていって対応点を見つけていくなりすることになる。

ところである線上のどこかにあるとわかっていても、斜めの線に沿ってピクセルごとに調べていくというのは中々骨がおれる。
そこで、この線が水平になるように画像を変換してやるのがRectificationである。
そしたらｘ座標だけシフトしていって対応点を探せるのでラクチンである。

対応する特徴点を見つけた後も、これらを追従するとか色々やるべきことはたくさん！
いよいよ加速して、できるとこまで行きたい。


今日はTriangulationの前に大きな問題が解決できて嬉しかった。
前々から、プログラムを走らせていたらものすごく重たくなって、マウス、キーボードがあまり反応しない、そのうち固まってしまう、ということが多かったので困っていた。
原因は２つのうちどちらかと考えた。

○ウェイトが小さいためにイベントキューがたまってしまい、イベントを処理しきれていない。
○どこかでメモリリークしている。

マウスやキーボードのイベントが反応しないので前者の方とにらんでいたのだけど、どうにもうまくいかない。ウェイトを結構おおきくしても、固まるまでの時間は長くなるにしてもやっぱり固まるということを発見して、どうもどっかでメモリの解放を忘れているんじゃないかとループの中を片っ端から調べていった。

そしたら時間かかって怪しいとこがわかった。
ループの中で毎回image = cvCreateImage()としているところがあったのだけど、これはどんどん新しい領域を確保していってしまうようで、メモリもどんどんなくなってしまっていたようだ。
これを別のやり方に変えて実装したら直った。
OpenCVのバグかとか思って、どうしよーもないと思ったけど、原因がわかってよかった！
悩んだかいあった。

C言語はそこまで使ったことなかったけど、やっぱりメモリ管理とか気にしないといけないのが大変だなと思った。ループをがんがんまわすリアルタイムなソフトを開発するときには、メモリをちゃんと使ったら解放するというのが本当に気にしないと固まってしまうという致命的な事態になっちゃうんだね。
ループのなかでのメモリリークは絶対にないように今後気をつけよう。
これDeadlyっ。

まずは短いところからスタート。メジャーで距離はかって比較！
メジャーがたわまないように先っちょをボルトに載せる。
５分でできる実験準備。簡単でいいね。



徐々に距離を伸ばす。画像が暗くて対応点をクリックしにくかったので、
ちょうどあったUSBのLEDライトで照らしていい感じに。



一気に２メートルへ。これがメジャーの最長。
結果は予想以上の精度でした！

 

blue at 21:58 Trackback() Comment(0)