2018年10月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

カテゴリー

ブログパーツ

無料ブログはココログ

« 2010年8月 | トップページ | 2010年10月 »

2010年9月

2010年9月29日 (水)

SoftModemからの信号を受信する

リモートブレインの夏休み:iPhoneロボット

まず、SoftModemTerminalのボーレートを変更します。デフォルトでは1225bpsですが、モデムに使う予定のクロック8MHzのPICでなので、安全を見て315bpsに変更します。(あとで試したら1225bpsでも十分対応できました)

ダウンロードしたSoftModemTerminalのプロジェクトファイルから、FSKModemConfig.hを開き、315bpsのパラメータセットのコメントを外し、現在のパラメータセットをコメントアウトします。

これでビルドすればOK。試しに何か送信してみると、ジーという感じだった音が、ピロロという感じになっています。

さて、入力回路ですが、オーソドックスにこんな風にしてみました。iPhoneのヘッドホン出力をロジックレベルの矩形波に変換します。

Fskinput_2

ヘッドホン出力から47uFで直流遮断して、負荷抵抗100オームで終端します。これがヘッドホン代わりの負荷になります。ここ(A点)での信号はこんな感じ。濃いところがスペース(周波数の高い信号)で薄いところがマーク(周波数の低い信号)です。

Dscn0915

±1.2Vくらい振幅がとれてますから、トランジスタのベースに加えれば簡単に矩形波になります。これだと、ベースにマイナスの電圧がかかりますが、これくらいの電圧なら何の問題もありません。信号のスレショルドは、トランジスタの物理特性から電源電圧に関わらす約0,7Vになります。電源電圧に依存しないので使い易い回路だと思います。

もう昔のハナシになりますが、カセットテレコにデータを読み書きしたり、電話の受話器経由でデータを送ったりするには、こんな回路が大活躍したものでした。
いろいろ工夫しても、やっぱりシンプルなのが一番だったりしてですねえ。まさか21世紀にもなってこんなことをするとは思わなかったですが。

で、こんな風に矩形波になります。下がA点の波形、上がFSK-INの波形です。これがPICへ行きます。

Dscn0916

おなじみPicKit2のオマケ基板をプログラムして、モデムとして動作させてみます。上が復調結果です。FSKの信号がロジックレベルのシリアルデータに復調されているのがわかると思います。

Dscn0922

というわけで、シリアル受信のプログラムを追加して、SoftModemTerminalからのASCIIデータを、LEDに表示させてみました。
iPhoneの数字をタップし、右下(見切れてます)の送信ボタンをタップすると、基板のLEDのパターンが変わります。ASCIIコードで0x3n(n = 0-9)が数字コードです。よく見ると読めると思います。
一応受信は成功です。文字化けもありませんでした。意外と安定です。まあ、FSKジェネレータはへろへろのカセットテレコではなく、デジタルオーディオなんだから当たり前ですが。

2010年9月28日 (火)

AR.Drone来ました

管理人のページ

空飛ぶネットタンサー?AR.Drone本日届きました。

WiFi?、カメラ搭載?、SDKまである空飛ぶ円盤? エーイ買っちゃえとAmazonで衝動買いしてしまいました。
詳しくはメーカサイトを見てもらうとして、ともかく気になるところをチェックしましょう。

外箱はこんな感じ、結構大きいのです。

Dscn0932

中身はこれだけ。ローターガードがあるハル(船体)は室内用です。右下のカラフルなシールがAR用のマーカーです。ゲームモードで相手の機体に貼るそうです。
修理などのサポートはラジコン模型の老舗、京商に委託しているそうです。これなら安心ですね。

Dscn0937

これが機首のカメラです。まだ保護シールがついています。

Dscn0943

そしてこれが、機体下側のソナー(銀色の丸い部品が超音波スピーカーとマイク)とカメラ(真ん中の小さい穴がレンズ)です。ソナーで高度を一定に保ち、画像認識でホバリング位置を固定している?ようです。

Dscn0940

ともかくフライトさせた動画です。これはiPhoneアプリのスタートアイコンをタップしただけです。だれも操縦していません。まだ嫁さんには無理のようで… でも安定です。ビデオにはありませんが、ホバリングしている機体を押すと押し返してきます。現在位置を保とうとする制御がかかっています。

おもちゃのヘリコプターに比べれば、ものすごくうるさいです。ウチの猫はモーター音とかは平気なんですが、室内飼いのためか風が苦手で、最初は好奇心いっぱいですが、ローターの風を食らって、あわてて逃げていってしまいました。

ああ、カメラの画像を見るのをすっかり忘れてました。週末にでももっといろいろ試してみたいと思います。

2010年9月27日 (月)

ソフトモデムは一筋縄じゃあいかないね

リモートブレインの夏休み:iPhoneロボット

件の書籍のHPはここで、オーディオ端子からFSKで外部機器と通信できる、Serial Modemのソースコードもダウンロードできます。

とりあえずこれをXcodeでビルドしてみましたが… 残念ながらうまく行きません。Xcodeのバージョンが違うためか、日本語環境のためなのかわかりませんが、iOS2用にビルドしてみると、シミュレータでは何となく動きますが、実機ではダメでした。
この本を読むような本物のハッカーなら、なんとかできるのでしょうが… 

ということで他を探してみたら、このSirial Modemのソースを元に、ちゃんと動くiPhoneのシリアルターミナルを作っている方がいらっしゃいました。こちらです。

この方はすごいですね。iPhoneのターミナルだけでなく、Arduinoの通信ドライバやアナログ部分の基板まで作っちゃってますからね。Arduinoを使っているヒトは、簡単にiPhoneとの連携ハードが作れちゃうというわけです。こちらのブログに開発記があります。
(ところでArduinoってなんて読むんでしょう?アウヂューノ?アルディーノ?)

今回はこの方のSoftModemTerminalのソースコードを使わせていただいて、PICマイコンでFSKモデムを作り、coronのシリアルポートと通信をさせてみようと思います。

iPhoneとロボットボディの通信を見直す

リモートブレインの夏休み:iPhoneロボット

最初のフィールドテストを終えて、いろいろと問題が見えてきました。

一番の問題は、野外を自律移動することの難しさです。

現在のiRoverは、とても臆病なので、わずかな障害物にも反応して、移動を停止してしまいます。このまま進むべきかどうかは、オペレータなりネット上の人工知能なりが判断しなければなりません。
そのためには情報が必要です。ロボットボディに搭載したセンサの情報は、最も欲しいものの一つです。でも、現在のiRoverのシステムでは、ロボットボディからの情報をiPhoneにあげるチャネルはほとんどありません。唯一出来るのは、iPhoneを前に傾けることで、指示されたアクションの終了を知らせることだけです。

以前書いたように、iPhoneのSDKは頑に外部インタフェースへのアクセスを拒んでおり、正式に内蔵のシリアルポートを使うためには、僕がオバマ大統領に面会するほどの困難を伴います。

そこでこの本の出番です。この洋書には、iPhoneのサウンド機能を使った、FSKモデムの解説があります。これを使うべき時が来たのでしょうか。

Dscn0926

僕は、喋るロボットが作りたかったので、iPhoneの音声チャネルは通信に使わない計画でした。アクエストークのSDKも購入し、ぼちぼちとおしゃべりのテストも進めていました。

でも、そうも言っていられないですね。光カプラ方式は、室内などの、もっと単純で、人間とのインタラクションの必要な環境で働くロボットで使うことにして、今回は音響モデムで行くことにしましょう。

2010年9月21日 (火)

iRoverのフィールドテスト(1回目)

リモートブレインの夏休み:iPhoneロボット

少し涼しくなってきたので、iRoverを抱えて近所の公園へ出かけました。

今回は、超音波センサの野外テストと、iPhoneからのパラパラ動画のパフォーマンステストです。
コントロールにはiPhoneを使わず、coronに組込んだ自律アルゴリズムで行っています。

本当は道無き道をダイナミックに走破させたかったのですが、超音波センサが道の凸凹に反応してしまい、ぐるぐる回るだけになってしまいました。そこで、やむなく歩道の走行になりました。歩道でも、丸まった枯れ葉なんかが落ちてると、敏感に感知して方向転換をしてしまいます。安全第一という点ではこれでいいんですが… 「探検ロボット」としての運用にはちょっと問題ありです。

ソナーは野外でも順調でした。気になるのは風の影響です。この日はあまり強い風が吹いていませんが、強い風がマイクに当たると、風きり音が問題になるのでは?

iPhoneからのリアルタイム画像は残念な感じです。2秒毎に更新されるのですが、ときどきこなくなることがあります。
これには理由がありまして、実は家で画面録画担当の嫁さんに、iPhoneから電話でスタートの合図を送ったところ、通話が切断されないまま、iRoverのソフトを起動してしまったからみたいです。通話とデータ転送を同時におこなっているので、それでなくとも細い3G回線には負担が大きかったようです。

本当はもうちょっとスムーズに行きます。また、ビデオはパソコンのモニタをデジカメで撮影したので、実際の画像はもっと鮮明です。

それから、アクションとアクションの間でお辞儀をするのは、礼儀正しいわけではなく、アクションの終了を動きでiPhoneに知らせているのです。

2010年9月13日 (月)

ソナー(超音波センサ)を考える(その3)

リモートブレインの夏休み:iPhoneロボット

いままでの分析を踏まえて、iRoverで起こっている超音波センサの問題を考えていきましょう。

■床面の反射を考える
LV-MaxSonarシリーズのように、送受信のセンサを共用している場合、検出範囲は上下左右とも対象になります。つまり、センサを中心にして円錐状に検知領域が広がっていくのです。

このことは、センサの床面からの高さによっては、床面がセンサの視野に入ってくることを意味しています。フローリングなどの滑らかな床面では、センサから発信した超音波パルスは、床面で反射し、方向を変えてさらに前方へ進みます。
しかし、床面が凸凹していたり、板きれや棒のようなものが置いてあったりしたときには、そこで散乱反射が起こり、一部の超音波がセンサに帰ってきます。
このような路面では、超音波センサは路面の状態を障害物として誤認識します。

iRoverでも路面による問題が発生しました。特定の路面で障害物を誤検出する問題が発生し、いろいろ試してみると、路面のタイルのつなぎの溝を、障害物として感知してしまうようです。今回はセンサをより検知範囲の狭いものに取り替えることで解決を見ました。

この図は、iRoverに当初搭載したあったEZ1と、その後交換装備した検知範囲の狭いEZ2が床面をどのようにとらえているかを示しています。右のマンガがiRoverでセンサは床面から200mmの高さにあります。青い線が床面です。上が問題のあったEZ1のパターンで、下が交換装備したEZ2のパターンです。

Photo


EZ1では、大分「深く」検出領域が床面に食い込んでいます。このため、人造大理石の継ぎ目を障害物と検知してしまい、うまく働きませんでした。EZ2では食い込みは浅くなり、この結果、継ぎ目のあるタイルばりの床でも、障害物としての誤認識は無くなりました。

もっとも、このEZ2でも背の低い障害物には敏感で、この動画は床に置いたTVのリモコン(高さ約25mm)を検出し、約1m手前で停止する様子を示しています。

2010年9月10日 (金)

ソナー(超音波センサ)を考える(その2)

リモートブレインの夏休み:iPhoneロボット

■検知パターンを決めているのは?
LV-MaxSonarシリーズには検知パターンの異なる5つのモデルがあるのですが、手元にあるサンプルをじっくりと眺めても、見た目は全く同じです。どこに違いがあるのでしょうか。

ちょっと考えると、送受兼用の超音波ユニット(黒い円筒形の部品)の特性の違いかなと思いますが、たぶんそうではありません。
以前、ある製品に使おうかと超音波マイクとスピーカーを調べたことがあるのですが、出力や多少共振周波数の違いがある(だいたい40KHz前後)くらいで、指向特性はどれも変わり映えしませんでした。そもそも、メーカーもモデルのバリエーションもあまり多くはありません。

代表的な特性を見てみましょう。下の図は日本セラミックの送受兼用ユニットの送信特性です。(クリックで拡大します)

Photo_2

超音波の周波数は40KHzなので波長が8mmくらい、指向性はかなり強いはずですが、測定するとこんなもの、かなり広範囲に超音波を送り出しているのがわかると思います。
見た目では角度による信号強度の変化はそんなに大きくないように見えますが、デシベル目盛りなので、例えば、センターから±40度ずれた方向では、-10db、つまりセンターの1/3くらいの音圧、エネルギーで言えば1/10しかありません。±60度では1/100のエネルギーです。側面への信号は、メインビームに比べると、かなり弱いということができるでしょう。

この、側面への超音波の漏れを利用すると、超音波センサの検知パターンを、ある程度コントロールすることが出来ます。

簡単に言えば、受信機の増幅度をあげて弱い超音波エコーも拾えるようにすると、側面からのエコーも拾うので検出範囲が広く、遠距離になり、増幅度を下げて強いエコーしか拾わなくすると、正面へのメインビームのエコーしか拾わなくなるので、検出範囲は狭くかつ短距離になります。

LV-Max-Sensorシリーズでも、検出範囲の広いEZ0は最も遠距離までカバーし、範囲が狭くなるにつれて検出可能距離も短くなっています。

次回はiRoverで起こった問題をとおして、超音波センサの使い方について考えてみたいと思います。

2010年9月 6日 (月)

ソナー(超音波センサ)を考える(その1)

リモートブレインの夏休み:iPhoneロボット

■iRoverでソナー(超音波センサ)を使うわけ
なんといっても太陽光の影響を受けないのが最大の理由です。野外用の探査ロボットですからね。
また、センサの検知領域がPSDに比べて広いのも魅力です。正面に向けたセンサ一つで、車幅分の領域をチェックすることも可能でしょう。
さらに、消費電力の少なさも重要です。PSDは平均30mAくらい電流を食いますが、今回使用したLV-MaxSonarシリーズは、5Vでたった5mA程度です。

■LV-MaxSonarシリーズを選んだわけ
まず、検出パターンの異なる5モデルが用意されていることです。選定時に比較したのはSRF02ですが、これにはそれがありません。
それに、最初からアナログ、シリアル、PWMでの距離出力が同時に得られるので、面倒な初期設定も要りません。iRoverではアナログ出力をA/Dで読んでいます。SRF02にはそもそもアナログ出力がありません。
海外の製品ですが、日本で販売されているのもポイント高いですね。海外の通販サイトからだと送料がバカになりません。特に「あと1個だけ必要なんだけど」なんて時でも50ドル以上の送料を払って取り寄せなければなりません。
国内ではメカロボショップやアキバのテクノロジアで入手できます。テクノロジアは店頭販売もしていますから、AKB見物のついでに買うこともできますね。

■LV-MaxSonarシリーズの特性
LV-MaxSonarシリーズのデータシートには、各モデルの特性表がありますが、インチやフィート単位なのでわかり難いですね。そこで、その辺を日本対応にした表を作ってみました。

Photo

検出対象となっているのは、原文では「ダウエル」となっている、棒状の突起物です。ラジコン飛行機ではおなじみですね。
これを見るとEZ0が格段に検出範囲が広く、EZ4が最もシャープな特性を持っていることがわかります。
黒い線が5V駆動のときの領域で、赤い点が3.3V駆動の時のポイントです。駆動電圧での極端な変化はないようです。

このグラフから読むと、例えばEZ1では、距離にして3m以内、センサの中心軸から±600mmの範囲内に、段ボール箱などの大きな物体(一辺80mm以上)が入ってくると、反応して距離情報を出力するということになるでしょう。PSDなどの光学センサに比べると、検出範囲が広いですね。
また、同じくEZ1は、3Φくらいの細い物体でも±150mmくらい、距離900mm以内にあれば、検出可能なこともわかります。

次回は、この検出範囲の違いについて考えてみます。

2010年9月 5日 (日)

ソナーで失敗する

リモートブレインの夏休み:iPhoneロボット

前回の実験をうけて、超音波センサをシリコンチューブで固定してみました。

Dscn0879

エンジン模型用燃料チューブを使いました。内径2.5φ、外形は6.3φと普通の燃料チューブより太めです。3φのビスを押し込むことで柔らかい基板スタッドとして使えます。これで衝撃はかなり減衰できるでしょう。

ところが結果が芳しくありません。前回と全く変わらない感じです。振動が原因というのは見立て違いのようです。

床面をよく見ると、大理石のタイル同士の間には5ミリほどの隙間があり、その目地は3ミリほど凹んでいるようです。ロボットを床の上に置くと、いくつもの隙間が下の写真のように、ロボットの前方を横断しているのがわかります。
この隙間の立ち上がり部分で、超音波が反射しているのではないでしょうか。

Dscn0870_2

もうちょっと、ソナー(超音波センサ)の研究をした方が良さそうです。

2010年9月 3日 (金)

まだまだ続く夏休み

リモートブレインの夏休み:iPhoneロボット

もう9月ですね。でも、リモートブレインの夏休みはまだまだ続きます。

あまり時間が取れなくて、フィールドテストも、ソナーの再チェックも出来ていません。特にフィールドテストは、猛暑がもうちょっとなんとかならないとですね。

最近は、夜中にウィスキーを一杯やりながらの、Objective-C三昧です。

iRoverのソースコードを整理しながら、いい加減なところをきちんと作り直すという作業と、ライブ映像の配信がなんとかできないかという課題に取り組んでいます。

パノラマは進行方向の決定には重宝ですが、荒くてもリアルタイムの画像があると楽しいですね。

「ライブの配信」というのはちょっとばかり大げさです。試してみたのは、UIGetScreenImage()という非公開APIを使って、カメラの画像を連続的に取得、それを数キロバイトのjpgファイルにしてウェブサーバにアップロードする、という10年以上前のテクノロジーです。

UIGetScreenImage()はiPhoneの画面をキャプチャする非公開APIですが、便利なので結構使われているようです。
iPhoneで一枚の画像を取得しようとすると、カメラを起動してシャッターを切り、カメラを停止する、という一連の操作が必要です。これには5秒ほどもかかります。
このAPIを使うと、カメラを起動し画面に表示するところまでは同じですが、あとは任意のタイミングで何回でも、画面イメージのキャプチャという形で、カメラ画像を取得できます。

ネットタンサーのカメラのように、毎秒10回くらい取得すれば、ぱらぱらマンガくらいの動画は作れますが、問題はサーバへの送信にかかる時間です。

3G回線でのFTPで試してみると、ログインの時間もいれて、一画面の送信に2〜5秒ほどかかるようです。サーバ側のcgiをうまく作れば何とかなるでしょうか。

« 2010年8月 | トップページ | 2010年10月 »