2019/12/22

対気速度によるプロペラピッチの自動制御

Team 'F'の速度世界記録挑戦用の機体Nextz AVANTの運用が再開されました。

Nextz AVANTには対気速度によりプロペラのピッチが自動で変化するシステムが搭載されています。
このシステムは、2015年の年末くらいから開発を始めて、2016年春頃にひとまず完成し運用を行ってきています。
効果については搭乗したパイロットがTwitterでコメントしていますが好評のようです。
備忘録も兼ねて、主に電装側がどのようなシステムになっているのかを書きたいと思います。

全体の構成

機構としてはボールねじ付きのステッピングモータでナットブロックを前後させ、リンク機構によりプロペラから伸びたホーンを動かすことでピッチ角を変化させるものです。

自動ピッチ制御システムの機構部。中央の赤紫色の部分がステッピングモータで、灰色のナットブロックが上下に移動する。この動きが青紫色のリンク機構で回転運動に変換され、プロペラピッチが変化する。

完成した自動ピッチ制御システム。組み立ての都合で上に示した設計からホーンの形状が変化している。先端部(右側)には、ピッチ角が逸脱した際にステッピングモータを止めるためのリミットスイッチが見える。

システムの開発は機構側を作業場に来るメンバで、電装側を私が行うことで分担しました。

電装側のシステムは対気速度計のデータ取得・処理を行うコックピット側と、ステッピングモータの制御を行うプロペラ側に分かれます。
両者の間で通信を行う必要がありますが、回転部をはさむ通信で(スリップリング等を使わない限り)有線を使うことは難しいため、無線でリンクしています。
開発当初は、データの送受信に無線と光の2重冗長系を用いる予定で、どちらの方式でも通信が可能なところまでは確認しましたが、システムが複雑になるので無線のみの構成としています。

コックピット側(1)

コックピット側では対気速度を測定し、プロペラ側にプロペラピッチ指令値を無線で送信します。
対気速度の測定やプロペラピッチ指令値の計算には2016年まではHPA_Navi IIを、2019年からはHPA_Navi IIとほぼ同じ構成のTinyFeather拡張基板(詳細は未公開)を用いています。
Nextz AVANTでは5孔ピトー管およびプロペラ式の対気速度計を用いて対気速度を測定していますが、より実績のある後者のデータをプロペラピッチの制御に用いています。
プロペラ式のもので対気速度はロータリーエンコーダにより測定しているので、単位時間のパルス数として測定結果が出力されます。これを、対気速度(単精度浮動小数)・対応するプロペラピッチ(単精度浮動小数)・ポテンショメータ角度(単精度浮動小数)・プロペラピッチ指令値(16ビット符号付整数)と順に変換し、TWE-Liteにシリアルデータを送信、無線によりプロペラ側に送られます。
通信フォーマットはいつもどおり人力飛行機用拡張Sylphide形式を用い、可変ピッチユニット用にVページ(Variable Pitch PropellerのV)を新たに定義しました。
CRC16によるエラー検出等を行うため、TWE-Liteのファームウエアには自前のものを用意しています(データの送受信が可能。コックピット側とプロペラ側で共通)。

プロペラ側のピッチ角検出用角度センサのゼロ点ばらつき等により発生するプロペラピッチのオフセットはコックピット側基板で調整します。
HPA_Navi II等のコックピット側基板には、2つのタクトスイッチ(ピッチのプラス・マイナスに対応)が接続できるようになっており、±0.1度刻みでオフセットが調整可能です。

プロペラ側

プロペラ側では、受信したプロペラピッチ指令値をもとに、5相ステッピングモータMB0601のフィードバック制御を行います。
基板の構成は、データ処理・制御・ロギング用のHPA_Navi IIIとステッピングモータの制御基板の主に2枚です。ステッピングモータの制御基板にはエレ・メカ・ホビーショップSECで販売されていたサンケン電気 SI-7510 + SLA-5073 + SLA-5074を組み合わせた基板を利用しました。
HPA_Navi III(白い基板) + TWE_Lite(赤い基板)。左上と右上のセンサ入力ポートはファームウエアを書き換えることで状態表示用LED出力として利用している。また、左下のポートからはステッピングモータ制御信号が出力され、ピッチ角検出用の角度センサも接続されている。右下のポートにはステッピングモータの電流・電圧を検出した信号が入力される。基板下部に取り付けられている紫色の部品が小型GPSアンテナ。未接続のJST PH 3ピンコネクタ x 2にステッピングモータ用のLiPoバッテリを接続する。写真左側にはLiPo保護基板がわずかに見えている。
モータドライバ基板。電源(左)、ステッピングモータ(右)、HPA_Navi IIIからの制御信号(左下)、リミットスイッチ(中央下)につながるコネクタが取り付けられている
バッテリは、HPA_Navi III用に1セル400 mAhのLiPoを使用しています。また、ステッピングモータ用には2セル330 mAhのLiPo (Hyperion G5 SV)を2直列で使用しています。このLiPoバッテリには過放電・過充電保護回路が内蔵されておらず、油断するとバッテリをダメにしてしまうので、外付けの4セル用保護回路 PCB-S4A5-GSを取り付けています。
(この保護回路はバッテリと常にセットで使うことを前提としていて、バッテリの接続直後には電圧が出力されない仕様のため、リセット用[VMP-VDDショート]のタクトスイッチが取り付けてあります。詳細はデータシートの「注意事項」の項に記載があります。)

HPA_Navi IIIでは、TWE-Liteで受信したプロペラピッチ指令値をもとに主にステッピングモータのフィードバック制御を行います。
プロペラピッチに対応する角度はフィードバック用の角度センサで検出されます。検出した角度と指令値との差分を求め、必要なステッピングモータ操作量(=パルス数と回転方向)を求めます。
脱調が起こらない範囲では、ステッピングモータは送信したパルス数分だけ正確にナットブロックを送ると考えられるので、単に(ゲイン1倍の)P制御しか行っていません。
ステッピングモータの駆動は回転方向の切り替え時に脱調が発生しない範囲の5 kHzのパルスを与えることで行っています。

5相ステッピングモータドライバ基板は専用のICを用いたもので、回転方向を指定し、駆動パルスを入力するだけでステッピングモータを動かすことが可能です。
ステッピングモータの駆動の元となるパルスは、Verilogで書いたパルス発生モジュールをPSoC 5LPに組み込むことで生成しています。
また、ドライバ基板にはEnable入力がついていますが、ここにはリミットスイッチが接続されており、プロペラピッチがプラスまたはマイナス側に行き過ぎた場合には、モータドライバの出力がカットされるようになっています。
このリミットスイッチは、プラス側とマイナス側の超過を1つのスイッチで検出できるように機構側に工夫が加えてあります。

HPA_Navi IIIの基板上にはロガー時刻の同期のため、小型(9 mm角)のGPSアンテナも搭載しています。
その他にも、HPA_Navi IIIの標準機能として9軸センサが搭載されているので、ジャイロセンサによる回転数の計測も可能です。

また、HPA_Navi IIIでは、バッテリの電圧・電流やデータ通信の監視も行っています。
大量にLEDがついていますが、
外付け1 [] LiPo電圧(HPA_Navi III)
外付け2 [] LiPo電圧(モータドライバ)
外付け3 [] 無線受信データのCRCエラー、無線データ受信、無線データ送信、ステッピングモータ駆動パルス
基板上 [] micro SDエラー、GPS可視衛星数、GPS 1PPS、micro SDアクセススランプ
となっていて、バッテリやデータ通信の状況等を監視できるようになっています。
プロペラ側基板で取得したバッテリ電圧等のデータは、TWE-Liteにより無線でコックピット側に戻されます。
運用中の自動ピッチ制御システム。通信等の状態を表示するLEDが20個近く取り付けられている

コックピット側(2)

プロペラ側基板から送信されたデータには、バッテリ電圧(HPA_Navi III用・ステッピングモータ用)が含まれており、受信した値はパイロットディスプレイとして用いているAndroid端末に表示しています。
また、Android端末にはコックピット側とプロペラ側基板のリンク状況が表示されており、1秒以上プロペラ側基板側からのデータが途切れると通常は緑色の「LINK表示」が赤くなることで、通信ロストを知ることができます。

むすび

自動ピッチ制御システムはひととおり動いていますが、2016年春のテストフライトに間に合わせるために作りはかなり妥協したものになっています。 現在のバッテリ容量だと、こまめに電源を切ってもテストフライト中にバッテリ交換が必要な場合があり、使い勝手が悪い等の問題もあるため、春のテストフライト再開までに改良を加える予定です。
原因のひとつはステッピングモータ制御に使っているMOSFETのオン抵抗が高く、かなりのエネルギが熱として失われているためなので、モータドライバを自作するつもりです。
また、現在の構成だと複数枚の基板でシステムが構成されており、多数の配線が飛び交っていたり、基板の実装密度が低く重量がかさんでもいるので、基板を1枚にまとめ、システムをよりシンプルにもするつもりです。

2018/05/23

Nucleo-H743ZIでFatFSを使う(SDカード・DMAモード)

STM32H7はじめました。

まずはHPA_Naviの全機能をNucleo-H743ZIに移植すべく、各種ペリフェラルのテストを進めています。
大抵のペリフェラルはそれほど苦労なく動かせましたが、FatFSをSDMMC1のDMAモードで動かすまでに少し時間がかかったので、詰まった点を書き残しておこうと思います。

Nucleo-H743ZIにはSDカードスロットがついていないので、手元にあった秋月のマイクロSDカードスロットDIP化キットを取り付けました。
micro SDカードの接続状況
あまり褒められた方法ではありませんが、プルアップ抵抗は省略し、STM32H7の内部プルアップを有効にしています。
144ピンのNucleoボードにはSDIOに高速信号を流した際に問題になるスタブを切り離すための0オーム抵抗(SB116, 117)があるので念のために取り外しましたが、必要はないかもしれません。

コードの雛型はSTM32CubeMX (Ver. 4.25.1) + STM32CubeH7(Ver. 1.2.0)で生成しました。
SDMMC、FatFS周りの設定はほぼデフォルトです。

基本的にはSTM32CubeMXで生成したプロジェクトを開いて(今回はSW4STM32を使いました)、FatFSのAPIを叩けば終わりなのですが、DMAを使いたい場合さらにコードに追記が必要です。

HALドライバを使った場合、SDMMCのDMAでのデータ転送完了後には、HAL_SD_TxCpltCallback/HAL_SD_RxCpltCallbackが呼ばれます。
しかし、STM32CubeMXで生成されるコードにはこれらの関数の実体が含まれておらず、FatFSのDMA Templateを有効にするとデータ転送でタイムアウトが起こってしまい、うまく動きません。
そこで、HAL_SD_TxCpltCallback/HAL_SD_RxCpltCallbackを適当なところに(今回はmain.cに入れました)実装し、データ転送を制御するフラグWriteStatus/ReadStatusをセットする関数BSP_SD_WriteCpltCallback/BSP_SD_ReadCpltCallback (sd_diskio.c)を呼び出す必要があります。

行う作業は極めて単純で、
void HAL_SD_TxCpltCallback(SD_HandleTypeDef *hsd)
{
  BSP_SD_WriteCpltCallback();
}

void HAL_SD_RxCpltCallback(SD_HandleTypeDef *hsd)
{
  BSP_SD_ReadCpltCallback();
}
を挿入するだけです。

STM32H743I-EVAL用のファイルstm32h743i_eval_sd.cには、上記の実装が行われているので、これはNucleo-H743ZIや自前のSTM32H7ボードを使う場合に起こり得る問題かと思います。

作成したサンプルプロジェクトはgithubにアップロードしてあります。
サンプルプロジェクトは準備中です。

これでHPA_Naviの機能を移植するために必要なペリフェラルのテストは終わりました。
最終目標はINS/GNSSによる姿勢角の推定ですが、まずはHPA_Naviが有する機能の動作を確認したいと思います。

2018/01/19

スカイスポーツシンポジウム概要・プレゼンテーション資料ほか

製作した計器類の運用結果は毎年行われるスカイスポーツシンポジウムなどで発表していますが、日本航空宇宙学会講演原稿の著作権の取扱いに関する内規を読むと個人のwebページでの公開は問題ないようなので、これまでの概要・プレゼンテーション資料を公開しようと思います。

第50回飛行機シンポジウム 1D11 人力飛行機用アビオニクスの研究開発
概要
論文
プレゼンテーション資料

第19回スカイスポーツシンポジウム 1-12 人力飛行機用計測システムの開発
概要
プレゼンテーション資料

第20回スカイスポーツシンポジウム 1-15 鳥人間コンテスト滑空機の飛行データ計測

第21回スカイスポーツシンポジウム 1-16 IMU/GNSSロガーを用いた鳥人間コンテスト滑空機・人力飛行機の飛行データ計測

第22回スカイスポーツシンポジウム 1-14 Android 端末とIMU/GNSSロガーによる人力飛行機用計測システム

第23回スカイスポーツシンポジウム 1-12 人力飛行機用地上機上総合飛行システムの開発
プレゼンテーション資料

第25回スカイスポーツシンポジウム A-8 人力飛行機の航法システムへの2周波GNSSの導入
概要
プレゼンテーション資料

上記のリンクからダウンロードできる概要の著作権は日本航空宇宙学会にあります。

2017/12/12

[PSoC Advent Calendar 2017 12日目] PSoC 5LPでSWVを使う

PSoC 3/5LPのデバッグ機能の中でSWV(Serial Wire Viewer)の機能は使ったことがなかったので試してみました。

開発しているIMU/GPSロガーHPA_NaviではUSB付きのPSoC 5LPを利用しているのでデバッグ情報をUSBUARTで流すこともできますが、
  • データとデバッグ情報を異なるチャンネルに流せる
ことがメリットとして挙げられます。
また、デバッグ情報送信用にUARTを使った場合と比べると、
  • (ソフトウエアUARTでない場合)UDBを消費しない
  • (10ピンコネクタを使っている場合は)遊んでいるSWV端子が使える
  • USBシリアルアダプタが不要
等のメリットがあります。
未検証ですがクロック設定によってはUARTよりも高速、かつソフトウエアUARTより低CPU負荷かもしれません。

テストは開発中のIMU/GPS基板を用いてGitHubにあるサンプルプロジェクトを動かすことで行いました。
やることは基板に合わせて細かな設定を変える程度ですが、2014/10/18から更新がないので、利用するためにはPSoC Creatorのアップデートに伴う手直しが必要です。
(今回はPSoC Creator 4.1を用いました。)


古いプロジェクトファイルを開いたときの常ですが、まずは各種モジュールのアップデートを行います。
これだけで問題なくプロジェクトの移行が行える場合も多いのですが、PSoC Creatorのprintfがnewlib-nanoを用いるようになったためか、それに伴う問題がいくつか発生しました。
王様の耳はロバの耳!PSoC3/4/5LPでprintfの出力先をUARTにしたいとき」に関連する情報がまとまっています)
ダウンロードしたデモプロジェクトの設定ではheapサイズが不足してうまくpritntf出力が行えないので、十分大きなサイズまでheapを増やします。
今回は2048byteまで増やしてうまくいきました。


また、浮動小数点まわりのライブラリはデフォルトではリンクされないので、利用する場合はビルドオプション"Use newlib-nano Float Formatting"の有効化が必要です。


データの受信は専用のプログラムで行います。
これもGitHubにソースがあり、インストーラ付きバイナリもあるのでどちらかを用います。
受信用のプログラムは設定項目も少なく、ほぼ迷いなく使えましたが、ボーレートの設定がひとつずれている(?)ようで、6,000,000bpsをPSoC 5LP側で設定した場合には5,333,333bpsに設定するとうまくデータが受信できました。


以上で、SWVを用いたprintfデバッグが可能になりました。
デバッガとの併用でファームウエア開発がより効率的に行えそうです。

2017/09/03

クランクひずみによるパイロットパワーの計測3

前回に引き続きひずみゲージによるパイロットパワー計測の話です。
今回は取得したデータからパイロットパワーへの変換について書きます。

パワーはトルクと回転数の積から計算することができます。
取得した回転数、ひずみのデータと計算して求めたパワーのグラフを以下に示します。
今回は、左クランクのみにひずみゲージを取り付けたので、右足も同じパワーを出していると仮定して、パイロット出力は左足のものを2倍した値としました。
回転数、ひずみ、パイロット出力。パイロット出力は市販のパワーメータでも測定を行い、一番下のグラフの黒点で示した。
取得したひずみデータは、キャリブレーションから求めた係数を用いることで、トルクの値に変換することができます。
しかし、トルクの値はクランク1回転中に変化する振動を含んだデータなので何らかの形で平均を取ることが必要です。
平均を取る方法としては、移動平均、指数フィルタ等の各種IIR、FIRフィルタ等が使えますが、試してみたところこれらのフィルタでは時定数が長めのフィルタが必要なようなので、クランク1回転の平均を取ることにしました。

クランク1回転の平均値を計算するためには、クランクが1回転する時間の情報が必要になります。
1回転を検出する磁石式の回転数計の場合には直接この値が得られます。
しかし、今回用いた回転数計はフォトインタラプタ+スリットを用いたもので、1スリットが通過する時間を測定するため、直接的に1回転の検出はできません。
(スリットが通過する数を数えれば測定することはできます)
そこで、クランク回転検知は数値的に行いました。
回転数 [rpm]はその定義から回転回数 [回]の時間微分に相当します。
したがって、回転数を数値的に積分した値の整数部が変化する時刻がクランクが1回転した時刻と推定されます。
この方法で推定したクランク回転検知時刻を図中段の青印で示しました。
このデータでは後処理で回転検知を行いましたが、コックピット表示用にマイコン内でも同等の計算を行っています。

図下段のパワーのデータはクランク1周分の平均化を行ったトルクに回転数の値をかけて求めたパイロットパワーです。
薄青色の点は生データ、実線は弱い指数フィルタをかけたデータです。
1秒の平均時間で測定した市販のパワーメータ(ペダル式)の値と多少のずれはあるもののよく一致していることがわかります。

クランクひずみによるパイロットパワーの計測の話はここまでです。
現在はさらに詳細な解析として、クランク上下のひずみゲージの出力からペダリングのベクトルを求められないか試みています。
うまくいった場合にはさらに追加の記事を書きたいと思います。

2017/08/27

クランクひずみによるパイロットパワーの計測2

前回に引き続きひずみゲージによるパイロットパワー計測の話です。
今回はキャリブレーションについて書きます。

ひずみゲージの取り付け状況。左クランク上面、下面に1枚ずつ取り付けた
ひずみゲージは上の写真の通り、左クランクの上面、下面に1枚ずつ貼り付けました。
パイロットパワーを求めるのに必要なのは曲げひずみの値で、2ゲージ法を使うと圧縮ひずみの除去が可能です。
今回は、圧縮ひずみも含めて測定することでペダリングの向きも測ることを目論んで、上下のひずみゲージを独立したブリッジ回路に接続し、1ゲージ法x2で測定を行いました。

1ゲージ法での測定を行う場合には、各種の温度補償の恩恵を受けられないので、温度を含めたキャリブレーションが必要になります。
そこで、クランクに与えるトルクと環境温度の両方を変えながらキャリブレーションを行いました。

キャリブレーションの様子。クランクから奥に延びる青い配線は熱電対につながる
キャリブレーションの結果を下の図に示します。
使用した錘は[0, 2, 14, 20]kg、温度は[18, 24, 28]℃程度です。

キャリブレーション結果。上のグラフは温度を、下のグラフは荷重を固定したものを同じ色で示した
計36点のデータを取得し、
(ADC出力)=(オフセット)+(荷重比例部分)+(温度比例部分)
として重回帰分析を行い、校正係数を求めました。

荷重比例部分の校正係数は市販のパワーメータPolar Keo Powerとの比較も行い、誤差が1%以下であることを確認しました。

「温度」として採用するべきものは、キャリブレーション時に測定したひずみゲージ部分の温度なのですが、外付けの温度センサをつなぐ設計にはなっていないため代わりにADC内蔵温度計のものを採用することとします。
また、この校正試験時にはコネクタを介してひずみゲージを接続していたり、ひずみゲージとブリッジをつなぐケーブルが長かったりしたので、鳥コン本番で使った構成より温度係数が大きめに出ているようです。
このあたりは次に新しく基板を作る際には反映するつもりです。

次回は取得したひずみデータからパワーを計算する部分について書く予定です。

2017/08/18

クランクひずみによるパイロットパワーの計測1

以前の記事に書いた通り、ANT+モジュールにより市販パワーメータGarmin Vector 2Jのデータを受信しパイロットパワーを測定するつもりでしたが、どうもGarmin Vector 2Jではリカンベント式人力飛行機のパワーをうまく計測できないようなので、ひずみゲージを使って自前のパワーメータを作ることにしました。

パワーメータの作製は学生時代(~10年前)に行ったことがありますが、その際にはひずみゲージのゼロ点を半固定抵抗で補正しつつ10~12bitのマイコン内蔵ADCで読み込み、EEPROM/Flash ROMにデータを書き込む構成としていました。
最近は高分解能ADCや無線モジュールが利用しやすくなったこともあるので、クランクひずみの測定回路にはゼロ点調整等は設けず、ひずみゲージを含むブリッジ回路の出力電圧を適当に増幅した後にAD変換し無線で送信する構成としました。
ひずみゲージ用のブリッジ回路は(左/右)足 x (上/下)面用に4系統用意し、1~4ゲージ法のすべてに対応可能なようにしました。

製作したひずみゲージデータの送信機。無線モジュールのアンテナとアンチエイリアスフィルタのキャパシタは未実装。サイズは20 x 67.5mm、重量は5g
上の写真は製作したひずみゲージデータの送信機です。
設計時に何を考えて各種部品を選定したかなどを以下に記します。

ひずみゲージの選定

ひずみゲージは特定材料の線膨張係数の補償を行うように設計されているので、クランク材質に合わせたものを選びます。
今回の場合はアルミ用(東京測器研究所のものだと緑色のもの)です。
その他に決めなくてはならない仕様としてはゲージ長がありますが、今回はクランク歪みの測定で、局所的な情報が必要ないので簡単に手に入るものの中で最長の5mmを選びました。
また、基板との配線の手間を減らすためにリード付きのFLA-5-23-1LJCを選びました。
(余談ですが、東京測器研究所のひずみゲージは個人でも購入可能なので、e-ゲージショップに並んでいるものから選ぶ必要はありません。)

抵抗の選定

ひずみゲージの抵抗変化は抵抗ブリッジにより電圧変化に変換される場合が多いですが、ブリッジを構成する抵抗の良し悪しによっては、電圧変化に大きな温度依存が乗る場合があります。(ある意味ではセンサの一部と言えます)
温度係数の小さな抵抗は高価なので、その他の回路とのバランスを考えて25ppm/degCの薄膜抵抗 進工業製RR1220P-121-Dを選定しました。
また、許容電力にある程度の余裕を持たせるためにサイズは2012としています。

電源回路の検討

クランクひずみ送信機の電源には重量の観点からLiPoバッテリを利用します。
低ノイズの電源回路をコンパクトに作るにはリニアレギュレータを利用するのが簡単です。
また、基板専有面積を抑えるためにデジタル・アナログの電源は共有することにしました。
LiPoバッテリの容量をフルに活用するために、システムの電源電圧は2.85Vとしました。

AD変換器の選定

クランクひずみによるブリッジ回路の電圧変化は小さいので、高分解能(24~16bit程度が目安)のものを使用します。
また、クランクが1周する間に30点程度のデータ(平均誤差1%に対応)を取得しないと、振動するデータを平均する際に誤差が乗るので、サンプリングレートが小さすぎると問題になります。
さらに、基板面積の節約のために、PGA内蔵のものが望ましいです。
これらに電源電圧の条件を加えて検討し、128倍PGA内蔵、8入力、24bit、2ksps Delta Sigma型ADCのTexas Instruments ADC1248を利用することにしました。
同社のADCにはビット数が16bitで他のスペックが同じものもありますが、値段があまり変わらないようなので24bitのものを使いました。
使用する条件(128倍増幅、320sps)だと実効ビット数は16.2bitなので、16bitのものを使っても問題ないとは思います。
ADCには基準電圧源が内蔵されていますが、今回はratiometricな測定を行いたいのでADCの基準電圧には外からフィルタをかけたシステム電圧を供給します。
ブリッジ回路とADCの間には簡単なアンチエイリアスフィルタを入れました。
アンチエイリアス回路に利用するキャパシタは、手持ちの部品の関係から低誘電率系(CH)のセラミックコンデンサとPMLCAPを利用しました。

無線モジュールの選定

基板サイズ・重量を考えるとADCと無線モジュールの間にはマイコンを挟みたくないので、プログラマブルなモジュールを使います。
手軽に入手でき、技適の問題もクリアしているものの候補としてはXBeeTWE-Liteがありますが、表面実装可能なことからTWE-Liteを使いました。
アンテナが基板中央に来る配置になっていて、アンテナの性能は十分に発揮できない配置ですが、受信側基板との距離が1mもないことからこの部分は妥協しています。

その他

回転数の測定用に裏面にジャイロのパターンを設けました。(実際には利用せず)
また、動作確認用に4色のLEDをTWE-Liteにつなげています。

この手のアナログ・デジタル混載回路では定石ですが、アナログ・デジタルグラウンドの分離やリターンパス等を意識して基板のパターンを引きました。

基板の組み立て後は、ブリッジ回路部を中心に念入りにフラックスを洗浄しました。
大抵の場合は大丈夫だとは思いますが、フラックスの絶縁抵抗が低く、かつその抵抗に温度・湿度等の依存性がある場合には測定結果が不安定になる要因となるので、念のために行っています。

ひずみゲージの接続用にコネクタを用意しましたが、接触抵抗の変化や異種金属接合部での起電力とその温度依存が問題になり得るので、コネクタは用いず、ひずみゲージから延びるケーブルを直接基板にはんだ付けしました。

TWE-Liteのファームウエアはソフトウエア開発環境 TWELITE NET SDKを用いて開発しました。
個人的にはわかりにくいと感じた資料だったのですが、SDK全部入りファイルをダウンロードすると開発に必要な情報は全て手に入りました。

測定した結果はデータロガーHPA_Navi IIIで受信しますが、受信側に用いるTWE-Liteにも専用のファームウエアを用意しました。

以上でひずみ測定部分が完成しました。
次回はひずみとトルクの換算係数を得るために行った荷重試験について書きたいと思います。