Raspberry Pi3でturtlebotを動かしたいのだけど

ラズパイ３は好評のようで、僕のまわりでも使い始める人が増えています。僕のturtlebotコンパチ機、Hanabot 2もラズパイ３にしたいところですが、簡単にはいきません。turtlebotを動かすにはROSのhydroかindigoが必要です。最近のjadeやkineticには対応していません。

ラズパイ３で提供されているubuntuのディストリビューションはUbuntuMateで、15.10と16.04LTSだけです。indigoの動く14.04LTSは提供されていません。

以前の投稿でラズパイ3で14.04LTSを動かす裏技を紹介しました。僕もこの方法でindigoを動かすことには成功しましたが、 apt-get upgrade（updateではありません）してシステムを更新しようとすると、当然ながら起動しなくなります。組み込みではOSのバージョンを固定するのは当たり前なので、そういう意味ではアリだと思いますが、教材として使うにはちょっとどうかなと思います。

と、なると誰かが、今後のメインストリームとなる16.04LTSとkineticでturtlebotを動かしていないかな、と探してみました。この議論によると「進行中」といった感じで、インストールスクリプトの紹介もあります。いずれ使えるようになるのではと思いますが今試してみるのはちょっと大変かもしれません。先日米国で開催されたMaker Faireに出展したみたいです。

もちろん、rasbianをインストールしたラズパイ３でROS indigoを動かすには、このサイトの手順で、ROSをソースからインストールすればよいです。ただし、パッケージをインストールするにはapt-get installではなく、ソースからインストールする必要があります。また、インストールできない場合もあるようです。残念ながらturtlebotもインストールで失敗しました。

さあ、どうしましょう。

STM32F4のAD変換トラブル（その２）

ロボット作ろう：STM32F4編

ちょっと昔になりますが、STM32F4のAD変換のトラブルについて投稿したことがあります。AD変換の読み出し値が極端に大きくなってしまうというもので、この時は初期化のシーケンスをいじって直したようなつもりになっていました。

しかし、これはおかしな状態になる確率が下がるだけで、抜本的な解決になっていたわけではありませんでした。このへんできちんとしておかないと具合の悪いことになります。

異常時のADの読み出し値を調べたところ、正常な値の16倍になっていることがわかりました。STM32F4では12bitの変換結果を16bitデータとして読み込みます。これを右詰で出力するよう設定しているのがうまくいかずに左詰（12bitなのでちょうど16倍になる）になるときがあるようです。うまくいくときもある訳ですから、リセットに問題があるのは間違いないようです。

いろいろとサンプルコードをしらべるとADCの設定前にADC_DeInit()という関数を呼んでいるようです。これはADCの設定をリセット状態に戻す関数だそうです。ためしにコレをいれてみました。ADの設定はこんなふうになります。

//ADC3の基本設定
//
ADC_DeInit(); //いままではこれがなかった
//
ADC_CommonInitStructure.ADC_Mode = ADC_Mode_Independent;
ADC_CommonInitStructure.ADC_Prescaler = ADC_Prescaler_Div2;
ADC_CommonInitStructure.ADC_DMAAccessMode = ADC_DMAAccessMode_Disabled;
ADC_CommonInitStructure.ADC_TwoSamplingDelay = ADC_TwoSamplingDelay_5Cycles;
ADC_CommonInit(&ADC_CommonInitStructure);

//ADC3の変換モード設定。入力2本をスキャン変換モードで逐次変換
ADC_InitStructure.ADC_Resolution = ADC_Resolution_12b;
ADC_InitStructure.ADC_ScanConvMode = ENABLE; //スキャン変換モードに
ADC_InitStructure.ADC_ContinuousConvMode = ENABLE;
ADC_InitStructure.ADC_ExternalTrigConvEdge = ADC_ExternalTrigConvEdge_None;
ADC_InitStructure.ADC_DataAlign = ADC_DataAlign_Right;
ADC_InitStructure.ADC_NbrOfConversion = 2; //入力を２本（チャネルを増やしたらここを変える）
ADC_Init(ADC3, &ADC_InitStructure);

テストプログラムはこの投稿のものです。

現在のところこれでうまくいっています。本来ならリセットするだけで問題ないはずなんですが、いったいどうしたわけでしょう。デバイスのバグなんでしょうか？

TrueSTUDIOからEclipseへ乗り換える（拾遺）

今回は拾遺というとで、いくつかのトピックを取り上げます。

■浮動小数点演算について
普通にfloatやdoubleを使って演算する分には、FPUを使わないデフォルトの設定で問題ないようです。ただ、引数がfloatの関数にdoubleを渡したりすると、エラーが出ます。シェーキーのプロジェクトでは、fmod()にdoubleの変数を渡したときに起こりました。
「乗り換えガイド」に書いたように、FPUを使う設定にするとエラーはなくなります。理由はよくわかりません。

また、doubleの定義時に0以外の初期値を設定するとシリアルポートのボーレートがおかしくなると書きましたが、僕の環境でもそうならない場合もありました。どうも不思議ですが、やらないほうが無難でしょう。

■sprintfとsscanfのサンプル
サンプルプロジェクトを参考までに公開します。PA2がパソコンへの送信、PA3がパソコンからの受信でレベルコンバータを通してパソコンのCOMポートと接続します。ボーレートは9600bpsです。

プログラムは実数（10とか0.123とか）をターミナルから入力してリターンキーを押すと、"10 *2= 20"のように入力値の2倍をタイプアウトします。

ファイルサイズの関係で、srcフォルダのみ公開します。

「src.zip」をダウンロード

■使い勝手
商品であるTrueSTUDIOに比べると気配りが足りません。たとえば、修正したソースを保存し忘れてビルドしてしまい、デバッグしようとして初めて「保存してないファイルがあるがどうするか？」なんて聞かれてしまいます。わかってんならビルドのとき聞けよといいたくなります。まあ、ロハだからしょうがないかとは思いますが、このへんカスタマイズできるならなんとかしたいところですね。

■コードサイズ
ツールチェインが無償版のせいか、結構大きくなります。シェーキーのソフトはTrueSTUDIOでは約60KBでしたが、こちらでは1.5倍くらいのサイズになりました。
[Project]-[Properties]-[C/C++ Build]-[Settings]でToolchainタブをクリック、Arm Sourcery Windows GCC CompilerのOptimizationをクリックして、Optimize level を　Optimize(-O1)に設定してビルドすると、少し小さくなって1.2倍くらいに収まりました。これ以外のレベルを選んでもあまり変わらないようです。

TrueSTUDIOからEclipseへ乗り換える（その３）

今回はsprintfとsscanfを使えるようにしました。これが使えると変数の値を文字列にしたり、また文字列を数値にしたりできるので、TeraTernなどで情報を表示したり、数値を入力したりするインターフェイスが簡単に作れます。

例によってこちらのブログを参考に、ダウンロードしたnewlibのsyscalls.cを改造しました。
主な改造内容は、一文字出力と思われるputch()と一文字入力と思われるgetch()を追加しただけです。これらは（たぶん）printfやscanfで標準入出力とやり取りする部分だと思います。今回はこれらは使いませんので、putch()はなにもせずにリターンするだけ、getch()はリターンコード(0x0d)を返すだけになっています。
今回はヘッダファイルなしで使えるようにしました。実装は改造したsyscalls.cをプロジェクトのsrcフォルダにコピーするだけでOKでした。（改造したsyscalls.cはこの投稿の最後の「乗り換えガイドV2」にあります）

ここまでは難なく進みましたが、シェーキーのプロジェクトは相変わらずおかしな動きをしています。そもそもボーレートが明らかにおかしい。設定を変えても思ったようにかわりません。やむを得ず、プロジェクトを「再構築」しながら問題を探りました。その結果ようやく原因がつかめました。（ほんとに苦労しました）

double abc = 10.0;　のようにdoubleの変数を定義する際に0以外の初期値を定義すると、なぜかボーレートの設定がでたらめになったり、Hard_Faultに落ち込んだりするようです。intやfloatなどでは問題ありません。なぜかdoubleだけがこうなります。全ての環境でこうなるかどうかはわかりませんが、僕の環境では必ず起ります。

これを修正したところ、シェーキープロジェクトはすんなり動作しました。だいぶ紆余曲折はありましたが、とりあえずTrueSTUDIOからEclipseへの乗り換えは出来たようです。
乗り換えを検討中の方の参考になればと、「乗り換えガイドV2」を作成しました。

「truestudioeclipse_v2.pdf」をダウンロード

文章ばかりでは寂しいのでこの写真を。R2ユニットがご先祖Shakeyと記念撮影といった感じでしょうか？（この大きなR2-D2は昔のニッコーの製品でDVDプロジェクターになっています）

TrueSTUDIOからEclipseへ乗り換える（その２）

前回いきなりシェーキーのプログラムを試してひどい目にあいましたので、もっと簡単なプログラムから始めることにしました。

まずはラジコンサーボのパルス発生です。シンクロで確認したところ、これは問題なし。

次にUSARTを使ったシリアル通信をテストしました。ここで問題発生、ボーレートが狂っています。いろいろ調べていくうちにHSE_VALUEが間違っていることに気づきました。これは外付け水晶の周波数を定義するので、8000000（8百万ヘルツ）でなければなりませんが、80000000（8千万ヘルツ）になっていました。コピペした元がそうなっていたようです。おそらくUSARTとかを使わないと気づかないのでしょう。
コレを直して試しましたが、シンクロで見るとまだおかしい。3倍くらいのボーレートになっています。そういえばこのソースコードでは3倍のボーレートをセットしています。その顛末はこの投稿を見てください。コレがいけないようです。当たり前ですがボーレートをそのままセットしたところ、無事に通信できるようになりました。

ソフトの中身とは関係ないのですが、EcｌipseのデバッガだとSTM32F4 Discoveryのリセットがかかりにくい感じがします。デバッガにはボードをリセットするボタンはありません。しかし、最初の実行時にはリセットがかかり、main関数の入り口でブレークするはずなのですが、ときどきHard_Faultトラップに落ちたりすることがあります。最初のうちはリセットの問題とは気づかずに、プログラムを疑って時間を無駄にしてしまいました。
どうも手動でリセットしたほうが無難なようです。トラップされた状態からリセットするには、ボードのリセットボタンを押したままデバッガの実行ボタンをクリックし、その後リセットボタンを離せばOKです。

今回はここまで。次回はsprintｆとsscanfを使えるようにします。
もうちょっとまとめたら「乗り換えガイド」の加筆訂正をしようと思います。

残念なお知らせ

Eclipseで開発環境が構築できたので、やれうれしやというわけで早速シェーキーのコードを移行してみたところ、残念ながらエラー発生です。

まず、浮動小数点演算関係のエラーがでました。
floatの関数にdoubleの変数を与えたりしているところで出ているようです。先輩のブログでせっかく書いてくれているのに端折った僕のせいですね。自業自得です。書いてあるとおりに設定したところ、そのエラーはなくなりました。

次にsprintf関係のエラーです。こちらも先輩の言うことを聞かなかった僕のせい。まったく恥じ入るばかりです。とにかく何とかするということで、必要なファイルをインクルードしてエラーが出ないようにでっち上げ、なんとかビルドを通しました。

恐る恐るシェーキーに転送、プログラムを走らせると・・・　なんとサーボがあらぬ方向に回ってしまい、あわててスイッチを切りました。うーん、そう簡単にはいかないようです。

テストで作ったシリアル通信やらADやらのプログラムを順次移行して、一つずつ動作を確認しながらやっていく必要がありそうです。じっくり取り組みましょう。

これは、アタマが後ろを向き、カメラが真下を向いてしまったシェーキーさんの残念な姿です。あわててスイッチを切ったからコレですんだものの、下手をすれば壊れていたかもしれません。トホホ

STM32F4の開発環境をTrueSTUDIOからEclipseへ乗り換える

以前の投稿にあるように、TrueSTUDIO Liteは32KBのコードサイズ制限がついてしまい、アマチュアレベルでも使い続けるのは難しくなりました。

僕はコード制限なしの古いバージョンをインストールしたままなので、シェーキーのプログラムのように32KBを大きく上回るものも開発できますが、古いバージョンを新たにインストールすることはできないので、クラッシュしたらおしまいです。製品版を購入するにしてもサンデープログラマ向きのお値段でないことも、以前の投稿にあるとおりです。

そこで、先日の週末を丸々使ってEclipseによる開発環境を構築しました。奥さんが土日実家に帰ることになり、丸々二日間、ひとり（と猫一匹）の時間が取れるということで、思い切って挑戦しました。

以前、花岡ちゃんファンさんからMacでの開発環境の紹介をしてもらいましたが、デバッグ環境を構築するのが難しそうなので、オーソドックスにWindowsでの構築となりました。基本的にTrueSTUDIOで生成したプロジェクトファイルのライブラリやTrueSTUDIOのデバッグサーバなどを借用し、IDEとコンパイラ、デバッガを無償ソフトで構築するという、ちょっと怪しい構成になります。まあ、製品開発に使用するわけではないので大目に見てもらいましょう。

参考にさせていただいたのはこのページです。かなり具体的に構築手順を説明してくれているので助かりましたが、それでも満足に動くようになるまで2日間、のべ10時間以上もの時間と、おそらく10本以上のバドワイザーを消費しました。いやあ、ホントに大変でした。
仕事以外でこんなにパソコンに向かったのは、HyperCardの英語版とHyperTalkの英文の入門書をイケショップで買って以来ではないかと思います。かれこれ20年以上前の話ですが。そのコンセプトの斬新さに衝撃を受け、丸2日間、夢中になっていろいろなスタックを作ってました。あの時は楽しかったなあ。

とまれ、現在ではこんな感じで動作しています。

構築時のメモを多少編集したものを、これから挑戦される方のために掲載します。読みにくいですが、ご自身の環境に構築するときの参考になればと思います。構築手順にそって書き出してあるので、上から順に読んでいってください。ただし、環境によってはそのとおりにならなかったり、抜けがあるかもしれません。

【後日訂正】
メモにインクルードファイルの画像が入っていませんでした。また、多少わかりにくいところもありましたので、下のメモの代わりにこちらのPDFを見てください。

「truestudioeclipse.pdf」をダウンロード

メモはこちらから（右クリックで）ダウンロードしてください。

「truestudioeclipse.txt」をダウンロード

【またまた後日訂正】
このインストールだけでは浮動小数点演算やsprintfなどを使ったプログラムが正常に動作しません。おれもやってみようという方は、今後の投稿もチェックすることをお勧めします。そこらへんは今後の課題として逐次投稿していこうと思います。

【またまたまた後日訂正】もろもろを加筆修正した「乗り換えガイド」を作成しました。この投稿とこの投稿をご覧ください。

Shakey式マップ作成の実験

ロボット作ろう：シェーキー製作記

シェーキーは頭部を300度回転させて、周囲の壁や障害物との距離を測定し、簡易マップを作ることが出来ます。フロアの領域を10X10cm単位のグリッドに分割し、障害物の位置をこれに量子化してマップを作ります。
こんな感じです。縦横比が1:1でないので、見た目が縦長になっています。

+は未知の領域、*が障害物の表面、Rがロボットの現在位置、@が原点です。空白部分が安全な領域になります。

まだ自動化していませんが、基本的には場所を変えて何回かスキャンすることで、マップの確度をあげていくことにします。そのデモの様子がこの動画です

>

移動テストの動画です

ロボット作ろう：シェーキー製作記

移動テストの動画を撮りました。

シェーキーにコマンドを送るには、パソコンからTeraTermで内蔵したネットタンサーのネットワークユニットに接続します。TeraTermはTCP接続にも対応しているので、こんなときには重宝します。

これは動画撮影のためにROLLTOコマンドでロボットを動かした様子です。

ロボットは最初 X=0 Y=0 においてあります。"ROLLTO 100 0"はX=100,Y=0へ移動しろというコマンドで、実行後、座標値と方向をタイプしてDONEを返します。この例では、99.6 0.0 0.0ですから、X=99.6、Y=0.0、方向0.0ということになります。このログは実際に動画でロボットに送ったコマンドです。動画とあわせてご覧ください。なお、座標の単位はcmです。

動画がこれです。床にテープで50cmごとに印がつけてあるので、移動精度の目安としてください。

気になる精度ですが、思った以上によいようです。実際のところ、数十回コマンドで動かしても大きくずれていくようなことは感じられませんでした。まあまあ目的の位置に素直に移動します。

近いうちにマップの作成機能の動画も撮ろうかと思っています。

PSDの出力を距離に変換する簡単な方法

ロボット作ろう：シェーキー製作記

以前、PSDの電圧出力を距離に変換する方法について投稿しました。その記事では変換式については説明しましたが、式の係数の求め方は、５球スーパーのトラッキング調整のように、近い距離、遠い距離で交互に調整していくという方法で、値は目の子で決めるようになっていました。

改めて考えてみると、未知のパラメータが二つの連立方程式なので、これを解けば一発で係数を決めることが出来るはずです。そこで、エクセルでこんな変換表を作ってみました。

おさらいをしておくと、浮動小数点での変換式は下記のようになっています。
　距離(cm)=係数A / (電圧 + オフセットB)
つまり、PSDの電圧／距離のグラフを双曲線で近似しようという訳です。

PSDを動作させ、最近距離付近での電圧と距離の実測値と、最大距離の70%くらいでの距離と電圧の実測値を黄色のセルに入力すると、自動的にA,Bを計算し、変換式を完成させてくれます。PSDの種類は問いません。シェーキーではミドルレンジのGP2Y0A02YKとロングレンジのGP2Y0A710Kを使っていますが、いずれもこの表で変換式の係数を決めました。

実測するには写真のようにPSDをしっかり固定し、写真のようにPSDの最前面から対象物までの距離を測ります。

対象物は十分に大きなも白っぽい平面を用意します。写真ではノートパソコン用のトートを使っていますが、壁を使う手もあります。電圧はデジタルテスターで、距離はスチールメジャーなどで測定します。

先ほどの計算表の値は、実際に手持ちのGP2D12（GP2Y0A21の旧品番）を測定したものです。テストのセルに任意の距離での電圧を入れ、計算値と実測値をくらべたところ、おおむね0.5〜3cmくらいの誤差には入っているようでした。全体的に実際の距離より近めになるようです。また、近い方の距離の実測値がたとえば10cmだったとき、これを10.5cmなどと少し大きめに入力すると、距離の誤差が小さくなるという現象もみられました。
この計算式で別のGP2D12も試してみました。やはり個体差はあり、誤差は大きくなりますが、同じ計算式でも実用上は問題なさそうでした。

計算表のエクセルファイルはこれです。簡単ですがインストラクションも書いてあります。
「psd.xls」をダウンロード
浮動小数点の式だけではなく、mV入力でmm単位の距離を返す32bit整数版の式も同時に作れるようになっていますので、PIC16シリーズなど、浮動小数点演算が苦手のマイクロコントローラにも応用できます。

この計算表で作った変換式をプログラムに組み込んでおけば、距離が直接読めるので何かと便利です。
ただ、もともとPSDの測距結果は対象物によって精度はまちまちですから、この変換式も目安として使うべきでしょう。