田舎の組み込みプログラマーがわざわざ趣味でも色々開発してみようとあがく様を綴るブログです。
DMM.makeのクリエイターズマーケットに出品しています。
しゃべるラップカウンター「ラップユーガー」爆誕 ― 2021年03月14日
構想を始めてから4年ほど経ってしまいましたが、ようやくしゃべるラップカウンターが完成しました。
名前は「ラップユーガーType.1」です。
”ユーガー”は土佐弁の「言うがぁ」から来ていまして、要するにラップを言ってくれるヤツということです。
概要
ラップユーガーは、いにしえのパーソナルラップカウンター「測るんジャー」のポンダーを使ったラップ読み上げガジェットです。
読み上げには「ゆっくりボイス」でお馴染みの AquesTalk の IC タイプを使っています。
Type.1はただラップを読み上げるだけで記録機能などはありません。もっと高機能な物も考えてはいますが、次はコーナーウエイトゲージを作りたいので後回しです。
デバッグ風景
使用しているマイコンはルネサスのR8C。デバッグにはE1エミュレータを使っています。
AquesTalk との接続は一番シンプルな UART です。
UART 接続では、AquesTalkのリセット解除後にマイコンから"?"を送るとAquesTalkがマイコン側のボーレートに合わせてくれます。
このボーレートの自動設定機能はリセット解除後とスリープ解除後に有効になっていて、それ以外の場合に"?"を送信するとそれ以降は発声してくれなくなりま す。
デバッガでソフトを実行していてソフトをリセットした場合にこの状態になって不便なのですが、SLEEP端子をマイコンのポートに接続しておくことで解決できます。
マイコンの立ち上がり時にSLEEPをLow(負論理)にしておき、SLEEPをHighにした後で"?"を送信するようにしておけばOKです。
目的が時間のカウントですので、クロックは外付けのクリスタルオシレータを使っています。
クロックがどの程度正確なのかを調べるため、タイマーで1msecカウントする毎に出力ポートを反転する設定にしてオシロで計測してみました。
半周期が1msecですので500Hzになっていて欲しいところでして、500.00xxxはかなりいい感じだと思います。
ただ、温度補償のないオシレータですので現場で使うとどうなるかは分かりませんが。
その他
ケースの穴開け加工用に3Dプリンタでテンプレートを作ってみました。これをガイドにして下穴を開け、それから本加工しましたが、かなり効率よく作業ができました。
電源にはLi-Poバッテリーを使い、USBで充電が出来るようにしました。この部分は市販のモジュールを使いましたが、ケースの次にコストがかかっている部分でもあります。
充電中はインジケーターの明かりが背面パネルから透けて見えるんですが、明るいところでは分からないと思います。
そんなこんなでようやくラップカウンターが完成しましたが、実は今走れる状態の車がなかったりします。
ということで、次の作業は車の整備ということになります。
ハードはほぼできた ― 2021年03月10日
あまり進んでいませんが ― 2021年02月14日
レイアウト反転 ― 2021年02月10日
しゃべるラップカウンター設計中 ― 2021年02月05日
で、サーキットに持って行って試運転していたところ、売って欲しいと 言ってくれる方が何人かいたのでちゃんと格好良く作ろうとして・・・何年か経ってしまいました。
その時は 3D CAD は使っておらず、3Dプリンタも持っていませんでしたので、たった10個作るのにも設計段階で挫折してしまったんですが、今はどちらも使える環境になりましたので何とかできそうな気がしています。
と言うわけで今再設計しています。
ケースは市販品を使いますが、パネルは加工の手間を省くために 3Dプリンタで作るつもりです。
どうにも不慣れなもので、時々写真のように表示をほぼ実物大にして実物と並べて眺めたりしています。
回路図CADはまだサッパリ分からないので、今回はユニバーサル基板を使い、ボリュームなども 3D 形状のみです。
他にも色々作りたい物があるので当面は量産するつもりはありませんが、いずれはちゃんと基板も作 りたいとは思っています。
といったところで、今日はここまで。
ずいぶん長い間放置してしまいました ― 2021年02月03日
hx711の仕様を読み解く ― 2018年11月30日
先日、hx711の動作にミステリーな点があると書きましたが、結論から言うと、思い込みよる勘違いでした。
今回はその辺りについて書いてみようと思います。
やっちゃだめなやつ
今回の失敗例は、4個のhx711から同時に重量値を読み出そうとして、1つのシリアルクロック(PD_SCK)で4個まとめて処理する方法です。
つまり、4個のhx711が全てreadyになったら読み出しをかけていたんですが、その結果がこちら。
readyになるタイミングがバラバラなだけでなく、数周期の間readyにならないやつまで出てくる始末です。
4個全てがreadyにならないと読み出しをかけられないため、しばらく待っていたんですが、他の3個はその間一定周期で短時間だけhighになっています。
ここでようやくhx711のアウトプットレート(10SPS or 80SPS)の意味に思い至ったわけです。
そもそも
実はこれまでA/D変換は逐次比較型しか使ったことがなくて、変換は任意のタイミングで出来るものだと思っていました。
hx711の場合、24bitということは多分ΔΣ型で、あらためて調べてみると、常時変換をしているタイプでワンショットやマルチプレックスには向かないとのことでした。
常時変換しているということは、読み出しをかけなくてもずっと動いているということなので、その辺をロジアナで確認してみました。
ご覧のように、それぞれ一定周期で一瞬だけhighになっています。
highになっている間はbusyなので、この時にA/D変換を行っているわけですね。
なので、busyになる直前に読み出しをかけると、読み出し中にA/D変換が行われてしまうことになり、その時のDOUT出力はおかしなことになってしまうわけです。
今使っている4個だけでもA/D変換周期の個体差が結構あるため、徐々に互いのタイミングがずれてきて問題が発生したというオチでした。
というわけで
hx711を複数使うシンプルな方法は、それぞれにそれぞれのシリアルクロックで読み出しをかけてやることですね。
まぁ、横着せずに最初からそうしておけば余計な苦労をせずに済んだのですが、趣味ですのでこういうのもありかなと思います。
なんとなく理解が深まった気もしますしね。
本題に進む前に
今まで使っていたモジュールは推奨回路と違っていたり出力周期が変えられなかったりと気になる点が多かったので、他のモジュールを取り寄せてみました。
右のモジュールはコンデンサの容量は分かりませんが部品構成は推奨通りで、出力周期も変えられます。
あと、コンパクトで裏面がベタなのもポイントが高いですね。
せっかくなので周期設定を80SPSにしてみました。
いよいよ本題
配線とソフトを変更して実行した結果がこちらです。
ソフトは大がかりな変更をしましたが、珍しく一発で動いてかなり感動しました。
そしてそのソフトがこちら。
メインループで直に処理していますが、今回はスマートに構造体風に処理してみました。
一回のループで1パルスだけ処理するようにし、次のhx711に切り替えるようになっています。
一見何の言語か分からないかもしれませんが、R8Cの構造化アセンブラです。
マクロ機能が便利なので調子に乗って使いまくってしまっているのが、正体不明な感じに拍車をかけていますね。
ifとか++があったりしてC言語風でありながら、アセンブラですので普通にニーモニックが使えますし、マイコンのフラグも記述できます。
R8C自体もビット処理が使いやすかったり、アドレスレジスタ以外にもSBとかFBが相対アドレッシングに使えたりと、アセンブラでプログラミングするのが楽しいマイコンですね。
もう一つの方法
今回はやっていませんが、複数のhx711を使用するもう一つの方法として、複数のhx711に同一の外部クロックを供給してやる方法があります(たぶん)。
個々の内臓オシレータで動作している状態ではタイミングが徐々にズレていくのは当然と言えば当然なわけで、ならば、同一の外部クロックで動作させれば(たぶん)同期がとれるはずなわけです。
その際、外部クロックは最大20Mhzまで使え、RATE端子がhighの場合は20MHz÷138240で約145SPS、lowの場合は20MHz÷1105920で約18SPSとなります。
つまり、外部クロックを使う事で変換周期も変更できるということですね。
あともう一つ
データシートに「セトリング時間」という項目があり、A/D変換4回分の時間になっています。
A/D変換の場合、ステップ信号入力に対してデジタル出力が対応した値に収束するまでの時間ということで、例えばロードセルに100gの重りがスパンと乗ったとして、デジタル出力値がその100g相当の値になるまでには4回のA/D変換が必要というわけです。
ということで、今回はhx711の仕様を少しばかり読み解いてみました。
ラジコン用のコーナーウエイトゲージ3回目 ― 2018年11月11日
訂正やら変更やら
先日、今使っているHX711モジュールはRATE端子がどこにもつながっていないと書きましたが、ICの下でちゃんとGNDに接続されていました。
なので、レートは10SPSになっているはずで、readyになるまでの時間が4個のHX711でバラバラになっている理由が分かりません。
そこで、別の用途のために買ってあった赤いヤツを繋いでみました。
あと、先日はPD_SCKの立ち下がりクロックで割り込みをかけていましたが、PD_SCKの立ち上がりに対してDOUTは最長でも0.1μsecで準備ができるとのことで、割り込みのオーバーヘッドよりもはるかに短時間のため、立ち上がりクロックでの割り込みに変更しました。
となると、無理にHIGH時間を短くする必要もなく、PD_SCKの配線を4個のHX711に引き回していることもありますので、HIGH時間も長めにしました。
で、きっと赤いヤツはきっちり10SPSなんだろうと期待して波形を見てみると・・・。
違ってました orz
しかも、この接続に変えるまではずっと1番が10SPSだったのに、この接続にしてからはずっと3番が10SPSだったりします。
(赤いヤツは4番)
ミステリーは放置して
次のステップに進みます。
HX711から読み込んだ値を観察していると、下位8bitは常時変動している感じです。
赤いヤツについては繋いだばかりの時は変動は7bitで、流石SparkFunだと思ったんですが、ICが温まってくると8bitになっちゃいました。
しかしまぁ、生データをいくら眺めていても何にもなりませんので、重量値に換算してみましょう。
最近仕事で2点校正をよく使っていたので、それで行ってみます。

この時のために、ちゃんと分銅も用意しましたよ。
で、100gと500gの分銅を乗せたときのデータを記録して、その値を元に換算します。
1番のロードセルだけ負の値を出しますが、そこはきっちり対処して負の値もちゃんと扱えるように作り込みます。
24bitは扱いづらいので符号拡張して32bitにし、平均を取る→2点校正で1mg単位で重量値に→ゼロ点補正→100で割って0.1g単位に・・・といった手順でやってみます。
が、アセンブラではかなり大変そうなので・・・
苦しいときの神頼み
C言語の力を借ります。
C言語を使うのは久しぶりすぎて、こんな感じでいいのかどうか分かりませんが、一応ちゃんと動作しているようなので良しとします。
注意点は、整数演算なので有効桁確保のために掛け算を先にやること、その時32bitでは足りなくなるので64bitで演算することくらいでしょうか。
RAMモニタの数値は実際にラジコンを乗せて量ったもので、1行目の左から順に左フロント、左リア、右リア、右フロントとなっています。
HX711の計測値は今のところ加算平均5回で処理していますが、0.1g単位だとほとんどバラつきません。
精度については、多分ロードセルの温度特性なんでしょうけど、これまでのところゼロ点は最大5gくらいズレますし、ゲインは500gの重りで0.2gぐらいズレたりします。
値がバラつくことに関してはシールド線を使ったりコンデンサを入れたりで改善できそうな気もしますが、温度特性は頭の痛いところですね。
まぁ、自分用のコーナーウエイトゲージということを考えると、4個が同じ様にズレるのなら特に問題はないんですけどね。
といったところで、今回はここまで。
最近のコメント