スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

GPSはじめました

自分探しをするなら,GPSモジュール を買うのがいちばんだ.
この四角いデバイスをパソコンにつなげば,自分の立ち位置が天の彼方から示される.
(ただし,電源を入れてから衛星を捕捉するまで30秒~1分かかる.)

さて,GPSモジュールから出てくるのは緯度・経度の2つの角度データなので,これをGoogleマップの小窓に打ち込めば現在位置が地図上に表示される.
しかし,ロボットに使うときは緯度経度のままでは直感的に分かりにくい.
そこで今いる場所を基準にしたX,Y座標に変換してから使う.
その計算式やWEBでの数値変換は国土地理院のサイト で可能だ.
角度の単位(デフォルトは度,分,秒になっている)と直交座標の取り方(北が+X 東が+Y)に注意しよう.
さて,ここのページに変換の計算式が載っている.
sinhやtanhなど,ふだんめったに使わない関数がずらっと並ぶのは,おそらく地球が真球ではなく楕円の形をしているからだと思う.
この計算をエクセルでやる分には何の問題もないが,FPU非搭載のマイコンでやるとなると,ちょっと計算量が多い.
そこで,楕円を平面展開するのではなく,球の一点からの相対座標で表す.
さらに,sin,cosを真面目に毎回計算せずに,ロボットの移動距離が小さいとしてcosΔθ≒kΔθのように線形とみなす.

つまり,以下の計算になる.

緯度の変化 量[°]x 係数KX=南北の移動距離[m]
経度の変化 量[°]x 係数KY=東西の移動距離[m]
KX=-(赤道半径[m] x 2 x PI)/360
KY=KX*cos(測定点の緯度)

例えば,
日本の北緯39° 東経139°地点を原点(x,y)=(0,0)に置いた場合,
KX=-111319.4908
KY=-88903.69831
という係数になる.
そのあと,北緯39.1° 東経139.2°まで移動したなら,
x=0.1*KX=11132[m]
y=0.2*KY=17278[m]
という座標に来たことになる.

さすがにこの近似は乱暴すぎる気もする.
試しに国土地理院の計算式との誤差を見積もってみたところ,100km未満の移動距離なら0.1~0.3%の差だった.
10kmの0.1%だと30m.100kmの0.3%だと300m.
GPSの位置精度が単独測位だと良くて10mぐらいらしいから,まぁまぁ実用になるレベルか.
2方向の係数は最初の1回だけ計算すればよいので,楕円を考慮したもうちょっと正確なもののほうが良いかもしれない.

ちなみにこの座標系で実際にロボットを動かすには,真北の方位が事前に分かっていないといけない.
これには 電子コンパス を使うのが手っ取り早い.
スポンサーサイト

RX220 シリアル通信の隠し受信ビット

新しいマイコンを導入したら真っ先に開通させたいのがPCとのシリアル通信だ.
AKI-RX220には合計5CHものSCI(UART)が付いているのだが,難点がひとつ.
受信レジスタ(RDR)にデータが入ったのを知るためのステータスビットが存在しないのである.
このため受信データは割り込みで取得する必要がある.
しかし,動作確認の段階でイチイチ割り込みの仕様を調べてそれ用のコードを書くのは抵抗がある.
とにかくPCのターミナルソフトで何かキーを押して,ソフトウェアポーリングでサクッと読みたい.

そんなときはSSRレジスタのB6を読もう.

ここがなぜか受信完了フラグビットとして機能するのである.
RX220のハードウェアマニュアルには「予約ビット:読んだ場合,その値は不定」と書いてある.
これはもしかしたら古いSCIのSSRのレジスタ仕様がそのまま残っているからかもしれない.
ただし,ビットフィールドのメンバ変数がiodefine.hに定義されてないので,

while((SCI1.SSR.BYTE&0x40)==0){} //受信フラグがが1にセットされるのを待つ
data = SCI1.RDR; //データを読み出す

のような記述でポーリングする必要がある.


AKI-RX220 あれこれ

このごろは 1300円で広がる小宇宙 を堪能する.
ルネサス32bitマイコンRX220.かつてのAKI-H8-3664TINYと同じ姿かたちながら,中身は32bit高性能マイコンに進化している.



さて,このAKI-RX220マイコンだが,使う上でいくつかポイントがある.

①RxD1,TxD1をRS232CレベルコンバータICから切り離す
64ピンの小宇宙とはいっても,周辺機能テンコ盛り仕様のこのマイコンを使い倒すには,1ピンたりとも無駄にはしたくないところ.
使っているPCにRS232CのCOMポートがない場合,TxD1,RxD1はただのTTLレベルUARTとして,PCとはFT232R等で接続したい.
その際は基板裏側のIC2のすぐ右,C11コンデンサのすぐ左の2本のパターン(TxD1,RxD1線)をカットしよう.

②E1と最小4ピン接続して楽々デバッグ
E1を持っている人は,白い箱から生えている14ピンコネクタの取り回しとはんだ付けのめんどくささにウンザリしているのではないだろうか.
E1を使わず,シリアル経由での書き込み(FDTを使う場合)ならピン数は少なくてすむが,変数ウォッチができないためLEDデバッグになってしまう.
さりとて,自作ボードを作るたびに毎回E1との接続に14ピンを半田付けするのは骨が折れる.
それに,貴重なユーザピンをデバッガに占有されるのはできるだけ避けたいものだ.

RX220では,実は4ピン接続でオンチップデバッグができる.使うピンは
GND
RES#
MD/FINE
VCC
である.
E1接続時の起動モードは「シングルチップモード」に設定する.
デバッガとのデータ通信はFINEインターフェースの1線のみで行われる.
やりかたとしては,E1に接続する2列ピンヘッダ内でGND3箇所を接続し,ターゲット側には上記4ピンのみを伸ばす変換コネクタを作成することだ.


③内蔵高速発振子HOCOを使う
秋月のボードには,20MHzのクリスタルが外付けされているが,RX220の最高クロックである32MHzで動かすには内蔵高速オシレータHOCOを使うのが手っ取り早い.もちろん,追加部品やクリスタル交換は不要である.
HOCOクロックの精度は0~50℃で±1%と悪くないレンジだ.
この内蔵発振子を使うには,例えば以下のようなコードをmain関数の初めに記述するだけでよい.
SYSTEM.SCKCR3.BIT.CKSEL=1; //HOCOをクロックソースに設定
SYSTEM.HOCOCR.BIT.HCSTP = 0; //HOCO動作
SYSTEM.HOCOCR2.BIT.HCFRQ = 0; //HOCOのクロック選択 0**32MHz
32MHzクロックを利用することで,通信系の最高速度は以下となる.
SCI 2Mbps(FTDIのFT232Rで設定可能)
RSPI マスタクロック 16MHz スレーブクロック 4MHz(スレーブのほうが遅いので注意!)
また,CPU処理性能は49MIPSとなる.

注意したいのが,このマイコンをH8やSH,PICマイコンのような感覚で使おうとすると,最初にMPC(マルチファンクションピンコントローラ)なる機能の設定項目の多さに挫折しかねない点だ.
I/Oポートを複数の周辺機能のピンとして割り当てる設定をするのだが,これが正直,初心者が軽く絶望するレベルにややこしい.
設定するレジスタの数もさることながら,マルチプレクスされる周辺ピンが「被っている」ところがミソで,ちゃんと「ご利用は計画的に」やらないとあとで必要な機能のピンが他の機能でつぶれてしまったりするのだ.少ないピン数で多数の機能を実装した結果,こうなってくるのはしかたないのかもしれないが,ピンと機能が1対1の単純な構造のマイコンしか使ったことのない人にとっては混乱の元になりそうだ.
とにかくマイコンから先の部品のはんだ付けの前に,機能とポートの割り振り一覧をエクセルなどで作成してから回路作成を始めたほうがよいと思う.


通信の改良など

また長らく更新が止まってしまったが,ここしばらくはサーボ駆動アルゴリズムの改良などをやっていた.
オブザーバによる瞬時値や時間遅れ補正されたパラメータを制御に使う中で,
制御周期の高速化や周期の振れ(ジッタ)を減らすことで更に制御性能向上が望めることが分かってきたためだ.

 今まで大部分をCPUで処理していた通信処理をDMAを使ってバックグラウンド動作させ,さらにデータの送受タイミングや割り込みを工夫して配置することで通信時間を大幅に圧縮した.
これにより捻出したCPUリソースを制御アルゴリズムに割り当てることで,従来に比べジッタを大幅に減らし,
制御周期もトルク制御50kHz,位置・速度制御10kHzが可能になった.
8000rpmまで回して15000deg回し,また元の位置に戻す指令値での実験結果が以下.






従来はゲイン調整しても位置誤差が±1.5deg程度はあったものが,改良後は±0.2deg程度に抑えられている.
このモータのエンコーダは512pprなので4逓倍の1パルス角度が0.18degに相当する.
つまりスタートから停止までの全軌道でほぼエンコーダの限界分解能である±1pulse以内の追従精度が得られていることになる(ただし,動き出しと停止直前は除く).
単純にエンコーダパルスをディジタル値としてカウントしただけでは±1pulse以下の分解能では制御はできないが,モデルベース制御とオーバサンプリングによってそれ以上の制御が可能になる.
摩擦,慣性などのフィードフォワード項をうまくチューニングできれば,単一イナーシャの負荷では誤差±1pulse以下の完全追従が実現できることがこの実験で確かめられた.

次に2軸プロッタを動かしより実機に近い条件で駆動実験を行った.
軌道サンプルは以下の2種類.
だいたい3分程度の駆動を行い,追従角度誤差の平均値,最大値をアルゴリズムの改良あり・なしで比較した.





こちらも追従精度が全体で約30%UPした.
とくに高速で精度向上が顕著になり,これまでは5000rpm以上で回すとエンコーダ補正の積和演算が10kHzの1周期に終わらず,制御周期が乱れて耳障りなキンキン音がしていたのが,きれいさっぱり無くなった.
追従精度については,もうやることがなくなってきた.
あとやるとしたら適応フィルタによる制振制御だが,もうCPUに全く余裕がない.さてどうするか・・・

Pov-RayのCG

またもや更新が滞り気味だが,このところはCGをやったりしている.

Pov-Rayは工夫次第でいろいろな表現ができるし,写真的な画像に近づけるノウハウなどもいろいろあって奥が深い.

例えばガラスが高熱で赤熱したような表現


これは内部に発光物体を入れてSSS透過で中から外へ拡散させながら照らしたもの.

こちらはシャボン玉風



もとの形状はこれ


表面の面だけ描画して中をスカスカにしたもの.
薄いプラスチックフィルムでできた物体のようにも見せられる.

Pov-Rayではさらに液体・気体のリアルな表現も可能らしい.
ただし,Dynamicsの機能はないのでアニメーションさせるには別プログラムで自力で実装する必要がある.
Ver3.7でマルチコアに対応してから,HD画質でのレンダリングも可能になってきた.
本当に素晴らしい進化だと思う.

ちなみに管理人が10年ぐらい前に一番最初にPov-Rayでレンダリングした画像がこれ.
(これが実寸なので拡大不可)

イスと机があって,机の上には何か乗っているらしいが,それが何なのかはDot単位で見ないとと分からない・・・
今なら携帯ゲーム機でももっとましなCGが出せることだろう.

NEXT≫
プロフィール

もやね

Author:もやね
長野県在住の会社員(メカニカル・エンジニア).
ロボットは完全な趣味としてやってます.
E-mail:
mo_ya_ne[a]yahoo.co.jp
[a]⇒@

最近の記事
最近のコメント
最近のトラックバック
月別アーカイブ
カテゴリー
FC2カウンター
ブログ内検索
RSSフィード
リンク
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。