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年1月 | トップページ | 2010年3月 »

2010年2月

2010年2月27日 (土)

PWM方式でモヤモヤ

ロボット作ろう:シェーキーの製作

ブログに製作記を書いているひとつの理由には、開発したり実験したりした結果を見直す機会を作るということがあります。一回文章にまとめるとおかしな点が明確になったり、新しいアイデアが見えてきたりする経験は皆さんもお持ちでしょう。

前回、PWMのテストをしましたが、ブログを書き終わった後に、どーもモヤモヤすることに気づきました。ブレーキPWMの時の発熱量が、大きすぎるのではないでしょうか。フリーPWMではあまり発熱しないのに、ブレーキPWMにしたとたん、サーマルプロテクションがかかるほど発熱するような経験は今までありません。

勘のいい方ならお気づきでしょう。そうです、貫通電流が流れているのです。

Hブリッジでは回転方向を変えたりブレーキをかけたりするとき、間にストップ状態をはさむ必要があります。こうしないと上下のトランジスタやFETが両方ONになり、モーター電源をショートする可能性があるからです。この詳しい説明は諸先輩方の参考書に譲ることにします。(こればっかり)

ともかく、ストップをはさむ時間は、小型のモータードライバでは、数百ナノ秒から数マイクロ秒が普通なのですが、今回使用したTA8428は、なんと100マイクロ秒と100倍近くの時間が必要です。今回はこれを見逃して、1マイクロ秒くらいの時間しか見ていませんでした。これが異常な発熱の原因です。

データシートに確かに書いてあるのですが、100という数字をみて、勝手に100ナノ秒だと思ってしまったようです。まさに先入観ですねえ。それにしても遅いスイッチング素子です。PWM周波数(現在約150Hz)もみなおす必要があるかもです。現在でもかなり低いのですが。

これを手直ししたら、さすがに発熱は減りました。小さな放熱機でも対応できそうです。

2010年2月25日 (木)

モータードライブとPWM

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

ドライブサーバ基板をシャーシに載せて、こんな感じでテストを行っています。

Dscn0485

バッテリーは数年前に秋月で購入したこれです。手持ちの実験用電源が1Aしかとれないので、大電流の実験用に購入したものです。シェーキーの電源にはちょっと大きすぎるかもしれません。
手前にぶら下がっているグレーのステレオジャックにPCからのシリアルケーブルを接続すると、TeraTermで内部シリアルバスにアクセスできます。

閑話休題。いまちょっと考えているのはモーターのPWM制御の方法です。PWM制御とはモータを早い周期で繰り返しON-OFFすることでパワーを調節する手法です。詳しい説明は諸先輩の参考書に譲るとして、シェーキーでのPWMのイメージを示します。ドライブサーバはこの制御をソフトで行っています。

Pwm

問題はグレーの「モーターOFF」の部分です。

ラジコンカーなんかではここを「モーターフリー」にします。多くのロボットビルダーもフリーにすることが多いのではないでしょうか。デューティを急に下げても滑らかにパワーダウンする感じです。そのかわり負荷に比べてモーターのパワーが大きいと、パワーを下げてもスピードがあまり落ちません。ホビー用のラジコンカーを運転した経験のある方なら、低速で走らせる難しさは理解できると思います。

一方、機械制御系ではここを「モーターブレーキ」にする場合もあります。これはPWMで回転数を制御したい場合に良く用いられます。以前実験用ロボで使ったTB6552FNGにはPWMのための専用入力がありますが、これはモーターブレーキです。このようなドライバは小型モータのドライバに多いようです。
この制御を行うと、負荷の影響をあまり受けずに回転数を制御することが出来ます。位置サーボモーターなどではこのような制御が有効です。

シェーキーのモーターはパワーが十分に大きく、実はモーターフリーのPWMではあまりスピードが変わりません。元々遅いのでそんなに気にはならないのですが…。そこでモーターブレーキのPWMに切り替えると面白いように速度が変わります。ところがモータードライバの過熱してしまいました。十秒ほどでドライバのサーマルプロテクションが働いてしまいます。

モーターブレーキのPWMは、いうなればアクセルとブレーキを同時に踏んでいるようなものです。モータードライバはモーターへの駆動電流と回生制動の電流が交互に通過する訳です。発熱が多くなるのも理解できます。

また、同じデューティでモーターフリーの場合と比べると消費電流も多いようです。コイルというか回転子というべきか、とにかくモータに貯められたエネルギーを、いちいち熱に変えて捨てながら回転している訳ですから、これもやむを得ません。

そのかわり、デューティを下げるとそれに比例してきれいにスピードが落ちてきます。

うーん、どうしましょう。パフォーマンス重視で放熱器を付けてモーターブレーキにするか、はたまた省エネ路線で行くか…

2010年2月21日 (日)

ドライブサーバをテストする

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

ネットワークの仕様を決めたので、ドライブサーバのフレームワークを製作しました。
まだ、移動などの具体的なコマンドを決めていませんが、とにかくモーターを駆動するテストをしてみたいと思います。

組込んだメッセージ(コマンド)はAD変換の結果を返すCコマンドと、テストプログラムを実行するTコマンドだけです。ドライブサーバとPCをレベルコンバータで接続してPCからメッセージを送ります。

例えば、PCのTeraTermをID0として(仮に)ここからADの結果をモニターするCコマンドをID1のドライブサーバに送るには

 @10C

とTeraTermに打ち込みます。するとドライブサーバから

 @01aaabbbcccdddeeefff.......

といった感じで8チャネル分のAD変換結果(10ビット)がaaaのように16進数3桁で帰ってきます。
Tコマンドは受信すると速度制御で走行する無限ループを実行します。
これらのコマンドはデバッグ用です。

Dscn0482


さて、今回テスト走行させてみたところでは、やはり、このように分解能の低いエンコーダでの速度制御は困難です。ウィーンウィーンとモーターの回転が脈打つ感じで、走行させるとアタマを少し左右に振ります。直進性も非制御よりはかなりいいですが、満足な精度ではありません。

エンコーダの1周期(駆動輪1回転で50周期)を一定の値に保つように制御しましたが、これが40ms-100msくらいと遅いので、単純な制御では振動が出易いのです。せめて10msごとにモーターパワーの調整を行えるくらいの分解能は欲しいところです。
ファジー制御のようなものを導入すればいいかもしれません。人間が速度計を見ながら、アクセルを調節するように、短期的にはばらつくが、長い目で見るとなめらかに速度が保たれているような速度の調節法です。

ただ、この方法だと左右の駆動輪を常に等しい速度に保持するのは困難なので、直進補正は何らかの方法で掛けなければなりませんね。

2010年2月15日 (月)

シェーキーの体内ネットワークを考える(その3)

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

今回はネットワークの通信制御を考えます。

体内ネットワークの通信路は1本なので、すべてのネットワーク機器はこれをシェアして通信することになります。他の機器が使っているときには自分のメッセージは流せません。そのため、常に通信路をモニターして、使用状態をチェックしている必要があります。使用中のときは、そのメッセージの送信が終わるまで待たなければなりません。

さらに、通信路が空いたからといって、すぐさまメッセージを送信するのは考え物です。他の機器も送信を待っているかもしれないからです。どの機器が優先的に待機中のメッセージを送るかのルールも必要です。

ここではとても簡単なルールを設定することにします。それはこれ↓です。

■メッセージを送信する前に通信路の状態をチェック、使用中なら送信を待機する

■待機中のメッセージは、通信路が空いた後、IDms経過してから送信する

機器はすべて異なったIDを持っているので、待機メッセージの送信タイミングが同じになることはありません。ID2とID3の機器が待機メッセージを待っているとき、通信路が空くとID2が1ms早く送信を開始します。ID3の機器はそのメッセージの終了を待って(さらに3ms待ってから)自分の待機メッセージを送信します。

これでOK!のように見えますが、実は本質的な問題をひとつ抱えています。それは、ほとんど同じタイミングで複数の機器が送信を開始する場合です。このネットワークシステムは非同期なので必ず発生します。発生確率はシステムのデザインしだいで高くも低くもなります。

コレが起こると、信号の論理和が取られるので、メッセージは完全に化けてしまいます。自分が送信したメッセージを受信し、元のメッセージと比較することで、競合が起こったことを判断できるので、再送信することが可能です。そのため次のルールを追加します。

■送信時、モニターしたメッセージがオリジナルと異なる場合、そのメッセージを再送信する

実際やってみるといろいろありそうですが、机上ではなんとかこれでいけそうですね。

2010年2月14日 (日)

シェーキーの体内ネットワークを考える(その2)

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

ネットワークの物理層は前回決めました。今回はここを流れるメッセージの仕様を決めます。前提条件は↓これです。

■メッセージはアスキーで送受信される(バイナリの転送は行わない)

これはデバッグ時にTeraTermでメッセージを読み書きしたいからです。これができるとデバッグの効率がよくなります。

メッセージの内容は下記の図のとおりです。

Messageformat

メッセージは必ず@が頭につきます。次の1キャラクタは、そのメッセージのあて先です。IDは16進で0-Fまでの16IDが使えるようになっていますが、ASCII文字(@とcr以外)ならいいわけですからもっと増やすことも可能です。

その次の1キャラクタはそのメッセージの送信元のIDで、レスポンスを返す必要がある場合はこれを参照することになります。

その次の任意長の文字列がメッセージの本体です。任意長といっても、バッファサイズや通信路占有の問題があるので、そんなに長くできません。64バイトくらいが上限と考えましょう。

最後にターミネーターとしてcr(0x0D)を付加しメッセージを完了します。

ところで、今回、このような単純なネットワークを自作するのは、PICなどの比較的シンプルな組み込みマイコンに実装できる、自由度が高いネットワークが見当たらないからです。ここでいう「自由度」とは、「ネットワークに接続されたどの機器間でも通信ができる」ことです。

I2Cではだめなの?という声が聞こえてきそうです。今回のシェーキーの企画では、クライアントが1台で他がサーバという位置づけなので、実はI2Cでいけるのですが、たとえば、クライアントが複数で、しかも非同期にサーバにアクセスするとなってくると、マスタ・スレーブモデルのI2Cではちょっと難しいことになってきます。

クライアントが複数とはどんな状況でしょうか。たとえば、ひとつのクライアントはセンササーバからの情報を受けて障害物回避をコントロールし、もうひとつのクライアントはインターネットに接続し、ネット上から走行をコントロールする、なんてことが考えられます。

もっとも、ネットワークの物理層が貧弱ですから、制限は大きいですが。

ネットワークシステムの「模型」を作る気持ちで、気楽にいきましょう。

2010年2月11日 (木)

シェーキーの体内ネットワークを考える(その1)

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

サーバソフトの仕様を明確にするには、まず、ネットワークの性能を決めなければなりません。

まずは電気的な通信を行う物理層の検討です。

「ちゃんとやる」にはおなじみのイーサネットを搭載するのがスジかとは思いますが、アマチュア向けの資料がすくないのでちょっと難しそうです。カニの絵で有名なリアルテック社でも、データシートはNDAを結ばないともらえません。

また、今回のネットワークの要求仕様はイーサネットの高速性を必要としないので、ここは図のようなワイヤードオアのシリアルバスを使うことにします。【図をクリックすると拡大します】

Photo

マイコンのシリアル端子直接接続なので、バスの論理は負論理、Hが0でLが1です。受信側を100Kでプルアップしているので、サーバ・クライアントの総数は20ユニットくらいが上限です。20ユニット接続時の合成負荷抵抗は5K、TXポートの引き込み電流は1mAくらいですから、いいところだと思います。

シェーキーの規模ならまったく問題ありません。

シリアル通信の仕様は下記のように定めます。

■伝送速度 38400bps

■1スタートビット、1ストップビット【任意】

■パリティなし

38400bpsは「早すぎず、遅すぎず」です。理屈の上ではもっと早くても何の問題もなさそうですが、むやみに早くして電気的なトラブル(波形の乱れなど)を起こすと面倒です。

車の電装品の通信によく使われるCANバスは平衡伝送で1Mbpsだそうです。こんな簡単な物理層では0.0384Mbps(!)くらいが身の丈にあった仕様でしょう。

次はネットワークを流れるメッセージを検討します。

2010年2月 8日 (月)

ドライブサーバの基板を作る

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

ドライブサーバの基板を作りました。

Dscn0474

基板は秋月のこれです。シェーキーは大きいように見えますが、メンテナンスの都合などを考えると案外スペースがありません。なるべくコンパクトにします。この基板にはジャイロや加速度センサは取り付けません。別基板に組み立てる予定です。これはレイアウトの自由度を上げるためです。

右側の大きな部品がモータードライバ、東芝のTA8428Kです。PWMなどのインテリジェントな機能のない素朴なドライバなので、PWMはソフトで行います。

マイコンは実験用ロボでも使ったPIC16F886です。PicKit2でインサーキット書き込みを行うので、ソケットは要らないのですが、モーター用に12Vを引き込むこともあり、万一の過電圧破壊に備えてソケットを使用します。ユニバーサル基板で28PのICの取り替えは結構大変です。

いままでは内蔵の8MHzクロックを使用していましたが、ちょっと速度不足なので、今回からは20MHzの水晶を外付けします。秋月のこれは、一見面実装ですが、足が平べったいワイヤーなので、写真のように起こしてユニバーサル基板に挿入できます。


Dscn0472

次回はサーバーソフトの仕様についてです。

2010年2月 7日 (日)

反射行動とPSDの距離変換のソースコード

ちょこっとCoron:ねずー製作記のつづき

記事の頭にこんな↑ヘッダーをつけることにしました。「ロボット作ろう」のカテゴリーでシェーキーの製作記、「ちょこっとCoron」のカテゴリーで、この、ねずー製作記をやっているのですが、なにせどっちも知能ロボットの話なのでわかりにくいようです。

あるひとに「ねずーに車輪エンコーダーを追加してるの?」と聞かれてしまいました。シェーキーとねずーの内容がごっちゃになっているのですね。確かにブログで読むとわかりにくいですね。

さて、今日はねずーの反射行動のおさらいです。ソースコードはこれです。↓

「main100128.c」をダウンロード

今回のコードで追加した関数は

exploreBehaviorとavoidBehavior、それにPSDの電圧を距離に変換するadj_psdです。

ビヘィビア関数の内容はこの動画と、基本動作関数についての説明を見てもらえば、すぐわかると思います。ポイントはいずれの関数にも、終了条件を設定して、終了した状況を返すようにしていることです。こうすることで、終了時のロボットの置かれた状況を推測することができます。

PSDの出力電圧を距離に変換する関数adj_psdはこれを12bitADに対応させたものです。元のコードはADが10bitの場合です。

ただ、距離がちょっと(30cmで数センチくらいの誤差)違っていたので、return(220000 / (xd - 200));の部分をreturn(220000 / (xd - 100));に調整しました。このくらいの誤差はこの値で調整できます。   

« 2010年1月 | トップページ | 2010年3月 »