Armadilloを使ったIoTデバイスの試作

はじめに

これは SMat Advent Calendar 2024 の12/20分の記事です。

株式会社エスマット エンジニアの若林です。

弊社では「SmartMat Cloud」というIoT重量計 x SaaSでモノの流れを可視化するサービスを提供しております。重量計を使えば多くの商品で数量を把握できますが、世の中には重量での数量の把握が適さない商品もあります。

数量を把握できるモノの対象を広げるべく重量以外でもモノの数を把握できないか実験するため、プロトタイプを作ったりして実証実験をしています。今回はArmadilloというIoTゲートウェイを用いてプロトタイプを作った経験をもとに、どうやって作成したかを簡単に説明しつつArmadilloのメリットデメリットや開発時の注意点を紹介します。

Linux+Pythonスクリプトでソフトウェア開発ができるので、Web系のエンジニアの方でもプロトタイプ作成がしやすいと思いますのでぜひご一読ください。

※こちらのイベントで発表した内容をブログに書き直した記事です。

そもそもIoTデバイスとは

IoTデバイスとはインターネットに繋がる機能を持つ組込みシステムと言えます。

組込みシステムは主に以下の3つの要素から構成され、デバイスを試作する際はこの構成要素をどうするかを考える必要があります。

• センサ（物理世界の情報を電気信号として取り込む部品）
• アクチュエータ（電気信号を物理的な動きに変換する部品とその機構）
• 制御装置（システム全体を取りまとめる部品）

IoTデバイスを製作する前に考えること

一般論

IoTデバイスを製作する際には以下のことを考える必要があります。

1. コンセプト（実現したいことが何か ）
2. コンセプトを実現するためにどんな情報を受け取ってどのように出力するのか

例えば、マルチコプターを作りたい場合について考えてみます。

まずセンサについて考えてみると、姿勢や力の方向を知る必要があるため、加速度センサやジャイロセンサが必要になるでしょう。
また、高度を知る必要もあると思うので気圧センサも必要になるでしょう。
気圧は高度が上がれば上がるほど低くなります。そのため、気圧を測ることで高度を計算できるため、高度を知るために気圧センサを用います。

このように知りたい情報を得るために、既存のセンサをどう活用していくかということも含めて考える必要があります。

次にアクチュエータについて考えてみると、揚力を減る必要があるためプロペラをモータで回すという機構が必要になるでしょう。この辺りを本格的に考えるとなるとメカ的な技術知識が必要になってきます。

最後に制御装置について考えてみます。センサとアクチュエータを制御するためのマイコンが必要で、それぞれを接続したり電源を供給するための回路が必要です。また、制御アルゴリズムをどのようにするかを考え、そのアルゴリズムを実現するためにファームウェアをどのように開発するかを考えなければなりません。

今回の試作では

今回の試作では「特定の位置に物体があるか無いかを把握し、サーバにデータを送りたい」ということを目標にしてみました。どのような物体を把握したいのかという部分が肝になりますが、機密情報を含むため明言は避けさせてください。ｽﾐﾏｾﾝ……

センサについて具体的にどのセンサをつかったかは明記できませんが、NPN出力タイプのセンサを使いました。回路は下図のようにプラス・マイナス・出力の3つの線があります。物体があるなら出力線がON、ないならOFFになるという、いわゆるスイッチの役割をします。

一般的なNPN出力タイプのセンサの回路図

NPN出力タイプのセンサは様々な種類があり、どのような検出方式のセンサを採用するのか検討することが重要です。実際に今回の試作でもいくつかのセンサを試しており、あるセンサでは全然検出できなかったりといった試行錯誤がありました。

例えば、距離センサでは赤外線方式のものや音波方式のものがあります。検出対象が透明なものであれば赤外線方式は使えませんし、スポンジのような音を吸収するものであれば音波方式は使えません。（ちなみに距離センサはアナログセンサでNPN出力タイプのセンサではありません。）

次にアクチュエータに関してですが、今回の試作ではデータを取得するだけなので必要ありません。

最後に制御装置に関して考えます。今回の試作では制御装置に以下のような機能が必要だと考えていました。

• LTE-Mで通信可能
• バッテリー駆動かつ省電力
• 選定していたセンサがつながる

また、プロトタイプを作成するために基板設計などの設計コストや試作コストをかけるのは大がかり過ぎるため、なるべく既製品を組み合わせて作りたいと考えていました。
その中で今回はArmadillo-IoT A6Eという製品を選びました。そもそもLTE-Mで通信可能な既製品は滅多になく困りましたが、数少ない選択肢の中でArmadillo-IoT A6Eは今回の要望をピッタリ満たす製品でした。

Armadillo-IoT A6Eの特徴

Armadillo-IoT A6E(以降「A6E」と記載)について簡単に説明します。
詳しくは製品ページやマニュアルを参照ください。

A6Eの特徴は以下の通りです。

• 入出力が充実している
• 省電力機能が用意されている
• 専用筐体もあり見た目が良い（検証で客先に設置する予定もあったため、そこそこ重視）
• 今後試作するときにも使えそうな汎用性がある
• 専用のOS (Linux)が搭載されている
• モダンな開発環境やFOTAの仕組みなど開発面でいろいろ用意されている
• Pythonで開発でき、Web系のエンジニアでも扱いやすそうである

A6Eの開発環境

A6Eの開発環境について簡単に説明します。具体的な構築方法についてはマニュアルを参照ください。A6E以外のArmadilloの他の機種についてもArmadillo Base OSで動く機種であれば同じように開発できると思います。

デバイス

A6Eの開発をするには以下のデバイスが必要です。

• WindowsもしくはLinuxがインストールされたPC
• A6Eの開発セット一式

ソフトウェア

PCには以下のソフトウェアのインストールが必要です。

• VirtualBox（もしくはVMware）
  • 開発環境は仮想環境内に構築する
• ATED
  • Armadillo用の開発環境本体で、VirtualBox内で動かす
• VS Code
  • ATDE内で動かし、IDEとして使用する
  • Armadillo用のVS Code拡張があるためそれもインストールする

環境構築の躓きポイント

開発環境を構築する際に私は以下で躓きました。もし今後Armadilloの開発環境を構築する読者がいましたらご注意ください。

• 開発環境でネットワークやUSBが使えないと思ったら、仮想環境上でネットワークとUSBデバイスを使えるように設定する必要があった
• ホスト環境で調べた情報やダウンロードしたファイルを仮想環境に受け渡すのが面倒だった
  • 仮想環境の設定で回避可能ではあるが、仮想環境の扱いに慣れていない場合は躓く
• A6Eを使う前に初期設定が必要で、もし設定を間違えてしまったときに初期設定をやり直すのが面倒
  • 設定削除用のファイルをインストールしてからでないとやり直せない
• SDカードでOSの再インストールや更新ができるはずが出来なくて困った
  • 原因はわからぬまま……SDカードのフォーマットの問題か？でもWeb管理画面からも実行できなかった……

ハードウェアの接続

今回の試作では各ハードウェアを以下の図のように接続しました。

ハードウェアの接続図

A6Eの端子の意味はそれぞれ以下の表の通りです。

端子	説明
DC-IN	直流電源のプラス
GND	マイナス
COM	接点入力プラスコモン
DI	接点入力
DI	接点入力
DO A	接点出力
DO B	接点出力

接点出力とはファームウェアから制御できるスイッチです。
A6Eではファームウェアから設定出力をONにしたときにDO AとDO Bが接続された状態になります。今回の試作では省電力化のため、計測が必要なときだけセンサに電源を供給することにしてDO Aに電池BOXの+を接続し、DO Bにセンサの+を接続しました。

接点入力では外部のスイッチのON・OFFを監視できる端子です。
今回の試作では物体があるかないかをセンサが出力するため、センサのOUTをDIに接続しました。COMはセンサの+を接続するという決まりなのでその決まり通り接続しています。

DC-IN、GNDは電力供給のためそれぞれ電池BOXの+と-に接続しています。

ファームウェアの開発

Armadillo Base OSの特徴

A6EのファームウェアはArmadillo Base OS上のアプリとして開発します。
Armadillo Base OSは下図のようにアプリがコンテナごとに分かれています。

コンテナ単位でアプリが運用されている様子
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e-di8ai4_product_manual_ja-2.16.0/ch02.html

アプリの開発パターン

Armadillo Base OSアプリの開発パターンは以下の4通りです。

開発パターン	説明
NODE-REDアプリ開発	ビジュアルプログラミングツールであるNODE-REDを使用した開発。メカやエレキが本業などでプログラミング経験がない人向け。
ゲートウェイコンテナ拡張	あらかじめArmadilloに用意されているゲートウェイコンテナアプリのコンフィグを変更するだけで対応する開発。AWS IoT CoreやAzure IoT との接続を前提としているため、それらを使用しているケースかつコンフィグレーションだけで対応可能なケースで利用。
CUIアプリ開発	シェルスクリプトやPythonでのアプリ開発。上2つより自由度が必要な場合に利用。
C言語アプリ開発	C言語でのアプリ開発。C言語でしか実現できないケースや、C言語で作られた既存のソースを流用する場合に利用。

今回の試作では以下の理由からCUIアプリ開発を選択しました。

• 既存のサーバーに繋げたく、それはAWS IoT CoreやAzure IoTを利用していない
• 省電力で動作するように電源管理を細かく行いたい
• 既存のCソースはマイコンのSDKに依存しているため使いまわせない

CUIアプリ開発の流れ

CUIアプリ開発は大まかに以下のような流れで開発します。この一連の流れでSWUイメージというファイルを作ります。このSWUイメージというのはDockerイメージに近く、コンテナを作成するためのバッチやリソースが入っています。SWUイメージをA6Eにデプロイすることでアプリをインストールします。

1. VS CodeでCUIアプリのプロジェクトを作成する
2. コンフィグファイルを編集する（コンフィグでは以下の設定ができる）
   1. pipやaptでインストールするライブラリの指定
   2. リソースの割当（接点入力やUARTなど入出力の権限や、ファイル権限などの設定）
   3. その他インストール時に実行するバッチ処理の指定
3. スクリプトの開発
4. SWUイメージのビルド

今回作成したアプリの動作フロー

今回作成したアプリは以下の図のようなフローで動作します。
基本的には1日に1回だけセンサの状態を確認し、サーバにセンサの状態を送信します。

このフローのポイントは以下の通りです。

• 6時間間隔で再起動する
• 起動後に計測タイミングかどうかを判断する
• 計測タイミングのときだけセンサの電源を入れる

1日に1回計測するのであれば、起動間隔は24時間で良いと直観的には考えられますが、今回は6時間間隔での再起動にしています。それは、起動間隔を24時間に設定してもピッタリ24時間で再起動するわけではないため、しばらく稼働していると少しずつタイミングがズレていくという理由からです。
今回のような実装にしておくことで、計測タイミングのズレは最大でも6時間以内に収まります。
より短い間隔で再起動すればズレ幅はより短くなりますが、電池持ちが悪くなるため6時間間隔に設定しています。ちなみにこのプロトタイプでは単3電池8本で1か月強の期間連続稼働します。

計測タイミングのときだけセンサの電源を入れるのも省電力で動作させるための工夫として入れています。

プロトタイプのフローチャート

開発で苦労した点

ここからは開発で苦労した点について紹介します。

データの永続化と読み込み

Armadillo Base OSではoverlayfsというファイルシステムが使われており、シャットダウンするとファイルの変更がリセットされてしまいます。
記憶領域の効率的な活用だったり、セキュリティ的に堅牢にするためにこのような仕組みが入っているようです。しかし、意図的にデータを残したいときにひと手間必要であるため苦労しました。

例えばArmadilloの初期設定等で手動でホストOSの設定ファイルを変更した後は永続化コマンドを実行しないと、次回起動したときに設定が反映されず意図しない動作になり困惑するということがありました。

また、計測予定時刻や過去データなど、次回起動したときに参照したいという場合、アプリ開発時に以下のような設定をしておく必要があります。

1. 永続化される領域にフォルダを作成する
2. 上記のフォルダの権限をアプリに割り当てる（アプリ側で永続化したいデータがあればそのフォルダ内に保存する）

ログの確認

アプリの開発時はログを参照しながらデバッグをしていましたが、その場面でも苦労しました。

Armadilloでは以下のいずれかの方法でログを確認できます。

1. Web管理画面にアクセスしてログを見る
2. シリアルコンソールでログを見る

しかし今回のプロトタイプでは動作終了後にシャットダウンするため、ログを確認する操作をしているうちにシャットダウンしてしまって見るのに苦労しました。
ログファイルを出力して永続化するのが正当な対処ですが、今回は簡単に実装するためデバッグ中はシャットダウン前にしばらくwaitする処理をアプリに入れておくことで対応しました。

Web管理画面のコンテナ一覧ページ（「ログ表示」ボタンで選択したコンテナのログを確認する
https://manual.atmark-techno.com/armadillo-iot-a6e/armadillo-iotg-a6e-di8ai4_product_manual_ja-2.16.0/ch06.html#sct.gw-container.log）

シリアルコンソールからログを表示している様子
https://armadillo.atmark-techno.com/blog/15349/13373）

間欠動作の機能が扱いづらい

今回は省電力化のためにArmadilloの間欠動作機能を利用しました。しかし、アプリから間欠起動を利用する手続きが扱いづらく苦労しました。

間欠起動をする場合、以下のような設定ファイルをホストOSに配置します。

# power-utils.conf
TARGET='container' # このコンテナ終了時に
MODE='SHUTDOWN'    # シャットダウンして
WAKEUP='RTC:300'   # 300秒後に起動

これはホストOSが管理するファイルであるためアプリ側から更新できません。したがってインストール時のバッチ処理でファイルを作成することにしました。
また、インストール時にファイルを作成するため、動的に起動間隔が変えられないという問題にもぶつかりました。これは、6時間間隔で起動するようにして起動するたびに予定時刻かどうかを確認する処理にして解決しました。

Armadilloを使った感想

最後にArmadilloを使った感想を以下にまとめます。

開発（ハード面）

• 基板の開発なしに周辺機器を線で繋ぐだけ楽だった
• LTE通信できるハードがなかなかない中で、ArmadilloがLTEに対応していて良かった

開発（ソフト面）

• 仮想化関連で手こずった
• （今回の開発はいろいろ苦労したものの）作成するデバイスが常時起動前提だったり、ゲートウェイコンテナ拡張開発が使えるユースケースであれば楽に開発できそう

試作期間

• 今回の試作にかかったのは約2週間
• 慣れれば1週間ほどで行けただろうという感触

その他

• 保守面の機能が充実しており、保守が楽そう
• 今回のようにひとつのセンサを使う用途では割高感のある価格
  • 複数のセンサを使うような本来のIoTゲートウェイとして用途ならそれに見合う価格だと感じた
• ESP32などのマイコンの開発用キットと比較すると電池持ちは悪い
  • 単3電池8本で1か月

追記

A6Eの後継機である、A9Eが販売されることが発表されています。今後Armadilloを利用する場合はA9Eを選択するのが良いでしょう。