ARM CMSIS DSP_Lib PID

　CMSIS DSP_LibのPIDを試してみた。

　実際にそのままのコードを使うとワインドアップ(wind-up)してしまうので、その対策とか。

　CMSIS DSP PIDは、入力値が0になるような操作を行う。そのため、入力値には目標値-現在値を与えることになる。

　上はPIDをそのまま使ったときのグラフ、下はワインドアップ対策を行ったときのグラフ。
　CMSISのPIDはよくあるPIDの解説とはちょっと違う感じの処理になっている気がする。いまいちパラメーターを煮詰めきれていない。
　傾向として、Kiが1を超えると発散し、Kiが1を下回れば収束する感じ。今回はKp = 10, Ki = 2, Kd = 0としている。
　もしかしたら、Kp, Ki, Kdは0-1の範囲で与える必要があるのかもしれない(q15やq31は0-1の範囲しか与えられない)。その場合は入力・出力も-1 - +1の範囲になるのかも。

　arm_pid_instanceのstate[]は、0が前回の入力値、1が前々回の入力値、2が前回の出力値、を保持している。
　ワインドアップは操作量が操作可能量を超えたときに発生し、操作量はstate[2]に保存されている。操作可能量を超えた場合は、state[2]にクランプ後の値を入れてやればいい。


　テストコード

arm_pid_instance_f32 pid = {};

pid.Kp = 10;
pid.Ki = 2;
pid.Kd = 0;

arm_pid_init_f32(&pid, 1);

const float32_t speed_limit = 100;
const float32_t acc_limit = 10;

float32_t position = 0;
float32_t target = 0;
float32_t speed = 0;

for (uint32_t i = 0; i < 10000; i++)
{
    switch (i)
    {
    case 1000:
        target = 10000;
        break;

    case 4000:
        target = -10000;
        break;

    case 8000:
        target = 0;
        break;
    }

    const float32_t prev_speed = speed;

    const float32_t diff = target - position;

    const float32_t tmp1 = arm_pid_f32(&pid, diff);
    const bool is_over_limit = check_over_limit(tmp1, -speed_limit, +speed_limit);

    const float32_t tmp2 = !is_over_limit ? tmp1 : clamp(tmp1, -speed_limit, +speed_limit);
    speed = clamp(tmp2, speed - acc_limit, speed + acc_limit);

    if (is_over_limit)
    {
        pid.state[2] = speed;
    }

    printf("%f\t%f\t%f\t%f\t%f\t%f\t%f\t%f\n",
            position, target, diff, speed, speed - prev_speed,
            pid.state[0], pid.state[1], pid.state[2]);

    position += speed;
}

***

　久しぶりにL6470で遊んでいる。
　L6470のSPIっていわゆるモード3なのね。モード0で負数を読んだときに変な値になってハマった。データシートのタイミングダイヤグラムを見るとたしかにモード3の形。

　L6470は複数のドライバを連携させて動作させられるので、そのあたりを作り込むのがなかなか大変。いまいち良い使い方がわからない。
　L6470のコマンドの発行とかを管理するクラスと、L6470の通信を管理するクラスに分けて、コマンドクラスはドライバ1個毎に紐づけ、通信クラスはそれらを管理、というふうにしたほうがいいのかな。
　いろいろ試行錯誤中。

　だいたい、この時期は天文関係のヤツに興味を持ち出す。去年の9月はアンドロメダを撮ってたし、11月は衛星追尾カメラを作ってた。もうちょっと暖かい時期にやってれば外での実験も楽でいいのにねぇ。
　ここ1年で自分のプログラミングスタイルもだいぶ変化したので、衛星追尾カメラを作り直し中。でもモータードライバで四苦八苦。

ユニ基板にSOT-89

　ユニ基板にSOT-89の3端子レギュレータ。
　コネクタ直近にはんだ付けしてINとOUTに0.1uFのコンデンサを付けてる。今回はスズメッキ線で引き出したけど、コネクタ直近に取り付けても良さそう。
　フットプリントが狭いし、部品面に高さのある部品が飛び出たりしないので、消費電力が小さいモノには良さそう。

　もう一回り細いコテ先がほしいなぁと思う今日このごろ。

STM32F303K8Tx

　STM32F303K8Txが最近のお気に入りで、QFP変換基板で使うので使うパーツのメモ。

　コンデンサはだいたいデータシートに書いてあるとおりの定数です。

　マイコンのVDD直近に0.1uFを2個と4.7uFを1個、VDDAに0.01uFと1uFを配置。VDDAとVDDの間にはインダクタを入れておきます。
　リセット端子は0.1uFで時定数を作っています。データシートの図を見る限りは外部のプルアップ抵抗は不要っぽいですが、なんか気持ち悪いので47kで釣っています。47kで釣るなら内臓だけでもいいじゃないか、という話なんですが。。
　BOOT0は47kでプルダウンしています。

　部品点数だけで言えばかなり簡単な部類です。が、ジュンフロン線の切った張ったが大変で、かなり時間を食います。積セラは文字通り焼き物なので、ちょっと力を入れるだけで簡単に割れます。そのあたりの力加減がよくわからなくて、必要以上に慎重になってる、というのもあるかもしれません。

　QFP32は0.8mmピッチなので、STMのはんだ付けは非常に簡単です。電源周りが面倒なだけで。
　プリント基板を作っちゃえば簡単だろうなぁ。

マイコン内蔵RGBWLED OST45050C1A-W

　シリアル制御な4色LEDです。結構前に買ってたのですが、他が忙しかったり、停電だったりで、なかなか手がつけられませんでした。ってのは言い訳ですが。

　オプトサプライのシリアルLEDは不思議な3値制御と、WS2812Bで使われるような2値制御の2種類があります。これは後者の方で、簡単に制御できます。
　データシートによるとRed, Green, Blue, WhiteをそれぞれMSBファーストで8bitずつ送るようです。2812はGRB順だったのでちょっと違和感がありました。ちゃんと修正したんだ、関心関心。と思って試してみたら、GRBW順でした。フザケンナ!!

　赤と緑は綺麗な色ですが、青はちょっと微妙です。whiteの蛍光体がblueで励起されてるっぽいです。これはまぁしょうがないので諦めるしか無いかな、と思います。

　白色は若干黄色っぽい感じです。わずかに青と緑を入れればクールホワイトみたいな色になりますし、赤と若干の緑を入れればウォームホワイトっぽくなるはずです。白は白でガッツリ出しつつ、RGBで色温度をいじる、というのは結構便利かもしれません。

　上の画像で分かる通り、このチップは2.54mmピッチのユニバーサル基板に実装できます。ちょっと面倒ですけど。


　某プラモデルの電飾に使いたいんだけど、いったいいくつ必要なんだろうか。10個でこの大きさとなると、全部で60個くらい必要かも。LEDの値段はそれほど高価というわけでも無いですが、物量で攻められるとはんだ付けが面倒です。

生存報告

　まぁ報告が必要なほど揺れた地域でもないんですが、それはそれということで。

　無事、昨夜電気が復旧しました。
　地震の直接的な被害はなかったようです。正確に言うと、立て付けの悪い低い本棚から本が落ちたらしいという話を聞きましたが、まぁアレは風が吹いても落ちそうな感じなので、実質被害は皆無でしょう。
　この地域は上水は大丈夫でした。町中では下水のポンプが動かないので、排水が必要な事は自粛するように、と町のHPに書いてありました(ような気がします)。家は浄化槽なので、特に気にせずトイレとか使ってましたが。

　停電が復旧したのが昨夜10前後だと思いますが、停電になったのが前日の3時半頃とかだったと思いますが、およそ30時間位停電していたみたいです。冷凍庫の中身は全滅なので、間接的な被害と言えば被害かな。停電した日の朝からアイスとか食べまくってたのでお腹がフカ次郎ってました。
　少し前に超音波の実験で保冷剤をいくつか買い足していましたが、そのおかげか、比較的長く保冷できていたようです。少なくとも24時間程度は大丈夫だった気がします。冷凍庫に鉄の固まりとか、熱容量の大きなものを入れておくのは停電対策としては有効かもしれません。

　携帯電話やモバイルルータはUSBから充電できるので、携帯でワンセグを見つつ、モバイルルータとipadで簡単にfacebookで様子見したり、くらいはできました。ただ、いつ復旧するかわからず(特に「1週間程度はかかる」との話も有ったため)、できるだけ長持ちさせようと、能動的に情報を取りに行ったりはしませんでした。災害が有るとネットニュースサイトはこぞって豆知識みたいなのを書きますが、被災した方からすると全然役に立たないですね。あとちゃんとしたニュースサイトでも、毒にも薬にもならないような記事を置いてたりします。毒にならないならまぁほっときゃいいわけですが、薬にもならないので貴重な電源リソースが失われていきます。
　モバイルルータは月々の帯域制限が厳しいので細々と使っていましたが、9月中の帯域制限は行わないという方針になったそうです。ただそれも地域が明記されてないので、自分が対象なのかはわかりません。AC100Vが復旧してしまえばバッテリー非内蔵のWiMAX2端末で無制限に使えるので、しばらくは気にしなくても良さそうです。計画停電の話もありますが、数時間くらいならネットがなくてもどうにかなるでしょうし。
　普段、最近は音楽ストリーミングで音楽を聞いていたので、停電になるとネットが使えない+スマートスピーカーが使えない、あとipad等も温存するために使わない、で、かなり静かでした。PCの音や扇風機の音もないので、かなりひっそりとしてます。ま、周りの農家は停電とか気にせず農作業機械を使ってるので、そういう音はありますが。


　このあたり、というか、周辺市町村は街灯が多く、普段は星空の撮影には不適な地域です。が、あたり一面停電だったので、ちょろっと星空を撮ってみました。

　北から南西にかけて特に光害がひどく、普段は長時間露光は不可能です。せっかくなので、その方向の北斗七星とか。あと、地平線近くの天の川も停電でもしない限り撮れないですね。天の川の方向は雲がかかっていますが、これはこれで僕の好みです。

***

　正月頃に"赤いオーロラの街で"という小説を読んでいました。
　小説の中ではGPSの影響が過大に書かれてた印象が有ったのですが、それ以外はかなりリアルです。今回の停電でニュースになった数々の話が結構そのまま出てきています。

　家の周りは地震の影響はなく「ただの停電」だったわけですが、ただの停電でもボイラーやストーブは使えなくなるわけで、水道や燃料が問題なくても、暖を取ったり風呂に入ったり、ということができません。これが冬だったらかなり恐ろしい事態になってるはずです。現代社会(に使われる機器)は電気に依存してるんだなぁと実感。ストーブのような石油を燃やすモノでも、セーフティーは電気で動いてるので、電気が止まると使えません。ほかにもいろいろ。


　あと、あまりにもやることがなくて、"CPUの創り方"を最初から読み直してしまいました。これ読むのいつ以来だろうか。最初に読んだときはほとんど理解できませんでしたが、今読み直すと、理解できたとは言えないものの、結構スルスルと読めます。かなり分厚いので躊躇していましたが、ある程度基礎がわかっていれば簡単に読めます。ロジックICってほとんど使ったこと無いんですが、こういうのも作ってみると面白そうです。


　ということで、生存報告というにはダラダラと書きすぎな感もありますが、生存報告でした。

PRF:パルス繰り返し周波数

　レーダーのPRFについて、自分なりに考えてみたのでメモ。

　レーダーのパルスは、単発だと以下のような形になる。

　このパルスのパワースペクトルは以下のようになる。

このパルスは5Hzの正弦波を主成分としているので、5Hzの位置にピークが有る。ただし、純粋な正弦波ではないので、山成なスペクトルとなる。このスペクトルからドップラー成分を取り出す場合、山がどれくらい移動したかを計測する必要があるので、信頼性が低い。


　ここで、パルスを繰り返してみる。PRTは1sec、PRFはPRTの逆数なので、PRF=1Hzとなる。

スペクトルが細くなっていることがわかる。PRF=1Hzなので、1Hzごとにピークが有る。

　PRT/PRFを変えてみる。今度はPRT=2sec、PRF=0.5Hzの波形。

PRF=0.5Hzなので、ピークも0.5Hzごとになる。

　ドップラーシフトを計測する場合、このピークの位置がどこに有るかを計測することになる。
　例えばPRF1Hzの場合、ピークが5Hzにある場合はドップラーシフトが0Hzということになり、ピークが5.3Hzにある場合はドップラーシフトが0.3Hzということになる。
　ここで問題になるのは、PRFが0.5Hzの場合。もしもドップラーシフトが0.3Hzだとすると、5.0Hzのピークよりも5.5Hzのピークのほうが近いため、「ドップラーシフトは-0.2Hzである」と誤認してしまう。つまり、PRFを低くした場合は高速な目標の速度を誤認することになる。


　PRFの低高の差について。
　最大探知距離は、PRFに反比例する。PRFが高い場合は遠くの目標を近くにあると誤認する。
　更新レートはPRFに比例する。鋭いスペクトルを作るにはある程度のパルス数が必要であり、PRFが低い場合は同じパルス数を観測するのにより長い時間が必要なため。
　観測可能速度はPRFに比例し、エイリアシングはPRFに反比例する。PRFが低い場合はピーク間隔が狭く、ドップラーシフトの絶対位置を誤認する。高速な目標を見るにはPRFを高くする必要がある。


　なお、上記の図は周波数空間で処理する場合の話。時間空間で処理する場合は当然別の処理になるが、PRFの関係は変わらないと思う。

　また、パルス圧縮を使う場合は全く別の処理になる気がする(遅延線を使うならドップラーも直接取り出せるんだろうか?)。

　あと、ピークのドップラー検出を行う場合、複数のドップラー成分があると面倒な気がする。ということは、ファンビームはドップラー検出に不向きで、ペンシルビームはドップラー検出に有利、ということか?
　そもそもファンビームは捜索がメインで、追尾はペンシルビームで行うだろうから問題ないのかも。

　戦闘機のレーダーの解説を読んでいると、PRFと捜索距離が比例する、というのが定説らしい。PRFが高い場合は遠くの目標からのエコーが帰る前に次のパルスを出すので、PRFと探知距離は逆比例するはず。戦闘機のレーダーはそのあたりうまく処理しているのかもしれない。積極的に2次エコーを使うとか?


　ちなみに、F-15のレーダーは10GHzあたりを使っているらしい。また、高PRFで200kHz程度、中PRFで10kHzらしい。それぞれ100kHz、5kHzのドップラーシフトまで計測できるので、高PRFではマッハ4程度まで、中PRFでは300km/h程度までを計測できる。近年の巡航ミサイルの高速化でマッハ4を超えることを目標にしたものも出てきているようだが、そうなると旧来のレーダーでは正しく処理できないかもしれない。

　船舶レーダーだとSバンド(2.4GHz)やXバンド(9GHz)が使用されているらしい。船舶の速度を最大50km/hとすると、Sバンドで250Hzくらい、Xバンドで900Hzくらいまで、ということか。もっとも、船舶だと自分が移動しているので、真正面・真後のシークラッタのシフトがこれくらいの量、ということになる。正面から対向するなら倍のシフトになるし、同じ方向に進むならシフトはゼロになる。

　戦闘機のレーダーでも、巡航でおよそ1000km/hとすると、真正面の地面は常に20kHzのシフトが有ることになる。ドップラーレーダーの場合は20kHz程度のシフトは表示せず、それより大きい・あるいは小さいシフトのエコーは表示する、という実装になるはず。

***

　細かい理論はサッパリだが、レーダーは調べてみるといろいろ面白い。
　でも、実物を試すことができない、という点はつまらない。
　昨今、自動運転に向けて車載レーダーを目的としたシミュレータもいろいろと出てきているが、もうしばらく経てばフリーソフトでレーダー反射をシミュレーションできるソフトウェアとかも出てくるだろうか? 細かい機能はあまりいらないので、空間にいくつか簡略化した物体を配置して、ビーム幅を指定して電波を出したら受信波形をシミュレーションしてくれる、みたいなのがあると楽しそう。多少のことは実空間の超音波でも模擬できるだろうけど、一定のドップラーシフトを作る、といったことは不可能。

　最近は超音波で遊ぶというとパルス圧縮ばっかりだったけど、固定周波数のパルスを送って解析というのもアリかもなぁ。
　マイコンだと処理速度やメモリの制限が強すぎるので、PCで超音波を送受信できるインターフェースが有ると良いかもしれない。例えばライン出力でIQ信号を出して、40kHzを掛けて送信、受信波をヒルベルト変換して40kHzを掛けてライン入力に入れる、みたいなハードウェアが有れば良いわけで。
　STM32でもUSB Audioはできるけど、USB FSだと帯域幅が足りないらしい。市販のUSBラインIN/OUTインターフェースに接続したほうが良いだろうな。
　ハイレゾオーディオだと192kHzのDACがあったりするけど、ADCも必要だし、そもそも192kHzだからといって50kHzが出せるとも思えない。
　STM32のADCを2chでIQを受信して、2値化、あるいはPWMで40kHzを出して、ADCで信号を受信して、それをDAC2chでIQ信号として送信、という感じだろうか。十分できそうな気もするけど、ヒルベルト変換がよくわからないんだよなぁ。C#でオーディオを気軽に扱えない、という問題も有る。

　とりあえず、しばらくはパルス圧縮の方を進めていく予定。

接着剤を買う季節

　ペーパークラフト用の接着剤は、コニシのペーパーキレイを愛用している。



　この間、新しいのを開封して使おうと思ったら、中身が全部固まっていた。一緒に買った数本も同様。

　これを買ったのは18年2月末だった。どうやら、輸送中に冷やされたのが原因らしい。
　マヨネーズを凍らせてから解凍すると油と卵が分離するらしいが、接着剤でも同じで、水分が分離して硬化してしまう。

　ということで、寒冷地に輸送する場合はこの接着剤は冬に買ってはいけない。他の接着剤でも同様。



　たまたま、工具箱に木工用速乾ボンドが入っていたので、詰め替えて使用している。
　ペーパーキレイのボトルはニッパー等を使用してノズルを取り外すことができる。硬化した分を取り出すのが非常に大変だが、中身がなくなれば速乾ボンドを充填して再利用できる。
　成分はほとんど同じで、木工用速乾は若干水分量が少ない。


　ところで、冬期のマヨネーズの輸送ってどうやっているんだろうか? 保温できる車両で輸送するんだろうか。