本物DL運転台によるフルサウンドNゲージコントローラの開発

冬コミに出す薄い本にしようかと思ったのですが、1冊にするほどの内容でもない気がしたので、ここで供養します。

この度、所属している鉄道研究会で学園祭に出すため、本物のディーゼル機関車(DE15/DE10)の部品を使用したフルサウンドNゲージ鉄道模型コントローラを製作した。本記事では鉄道に関する知識がない方にも分かるように配慮しつつ、その技術解説を行う。

システムを構成するコンポーネント

• PWMコントローラとソフトウェア : コンピュータから指令されたレベルの電気を出力し、レールに接続する
• マスコンユニットとソフトウェア : 自動車のアクセルに相当する「マスコン」から現在のレベルを読み出し、コンピュータにシリアル伝送で間欠的に送信する
• ブレーキ統合ユニットとソフトウェア : ブレーキハンドルの角度と、その他のボタン操作やペダル操作をコンピュータに間欠送信し、同時に速度をコンピュータから取得して、速度計に表示する
• スピーカーとウーファー振動モジュール: コンピュータのアナログオーディオ端子から出力してスピーカーから音を出しつつ、椅子の裏に固定されたウーファーモジュールで運転士にリアルな振動を与える
• DE10クラス : マスコンレベルとブレーキレベルから、DE10形液体式ディーゼル機関車の0.1秒ごとの加速度を計算することで、現在の車両の速度を求めるソフトウェア
• Sounderクラス : そのタイミングに応じた音を呼び出し、Pygame(SDLのPythonラッパー)でALSA Audioに渡すソフトウェア
• NControllerクラス : 以上のコンポーネントを呼ぶ、中心となるソフトウェア

ソフトウェア群は著者のGitHub (https://github.com/mipsparc/NController) で公開されている。

PWMコントローラ

2018年の4月ごろ、PICマイコンに入門することを主目的として、コンピュータからレベルをシリアル伝送(UART)で指示すると、PWM信号が出力されるファームウェアと基板を製作した。

PIC開発の入門に当たっては「C言語による PICプログラミング大全(後閑 哲也)」を参考とした。この書籍にはPIC16F1シリーズで現代的なCプログラミングをする方法が丁寧に書かれており、C言語をしっかりと触れたことがあれば楽に組み込みプログラミングができるようになっている。もっとも「大全」というには情報量が少々足りないような気もするが。

新世代PICは安価で十分な機能が備えられており、MCCやHarmonyを使えば、今からでも選択するのは正解だと思うが、なぜオワコン扱いされるのか不思議である。
今回は16bitPWMを複数備えており、扱いやすいPIC16F1579をコントローラに採用した。1つ140円なので、たくさん買っておくと大抵のことはこれで済んで便利。

PIC16F1579 8bit PICアーキテクチャ、最大動作周波数:32MHz、駆動電圧:1.8V-5.5V、プログラムメモリ:14KB、SRAM:1KB、10bitADC:12ch、16bitPWM:4ch、UART

コンピュータからのレベル指示は、0x21(ASCIIコード通常文字で一番小さい「!」)を0として、1文字で行われる。0x0から0x20までの任意のコードを送信すると、方向が転換する。これは、特別なソフトウェアなしにターミナルエミュレータのみで制御することを第一目標としたため。1回の受信だけで出力してしまうとノイズ耐性に問題があったので、2回連続同値受信で実行されるようにし、送信側では3回連続で送信する仕組みにした。

コンピュータとPICとの通信は、UARTで行われる。これは3.3Vまたは5Vによるシリアル通信で、RS232Cをレベルシフトしたものだ。USB-UART変換ケーブルというのがAmazonで200円程度で売っているので、極めて扱いやすい。ただし、3.3Vと5Vが混在しているのが罠で、これを同じにしないと文字化けを起こす。

PWM変調周波数は50kHzとかなり高く設定した。その結果、超低速での走行もできるようになったが、レールにスパークが原因と思われる汚れが多く付着するようになり、速度が低下する問題が発生した。いろいろと定数が変わってしまうので今回はこのままで運用したが、機械的反応速度は全く追いついていないと思われるので、メリットがなく、推奨はされない。

今回、出力レベルが上がるときに0.02秒間最大出力を出す仕組みを入れてある。これは超低速駆動するための仕掛けで、停止状態から動き出すための勢いをつけるのに有用である。

コントローラ装置はDCDCコンバータ・PICの乗っている制御基板と、トランジスタ・リレーの乗ったスイッチング基板の2つで構成されている。本当はHブリッジにより方向転換もフルデジタルにしたかったのだが、万が一プログラムにミスがあった時に短絡してしまうので、安全性を優先してリレーでの切り替えとした。FETでなくトランジスタを採用したのは、単純に制御電圧と動力電圧の橋渡しをする回路をつくるのが面倒だったからだ。消費電力を気にしなければ、高速トランジスタを使用することで回路をシンプルにするのは1つの策だろう。しかし、結果的に条件によっては素子の温度が高くなってしまったのは、反省である。製作に当たってはブレッドボードに試作して、プログラムを書き、回路図に起こし、実体配線図を書き、実装するという手順を踏んだ。

試作時、リレーが駆動する方向転換時にコントローラがリセットしてしまう不具合があった。これはリレーのL成分により電圧が不安定になるのが原因だったため、パスコン(積層セラミックコンデンサ)を電源ラインへ挿入することで解決した。ノイズは常に意識して設計しないといけないことを学んだ。

シリアルとPythonの受け渡しにはPySerialを使用する。このとき、まれに壊れたデータが送られてくるのを前提にしてtimeoutとwrite_timeoutを設定して、不正なレスポンスは読み飛ばすプログラムを書く必要がある。実際、直前の動作テストで、数十分に一回異常データが送られてきたときに落ちるバグが発覚して原因究明に焦ることになった。

マスコン

そもそも運転台を作ることになったきっかけは、ヤフオク巡りでDE15形ディーゼル機関車のマスコンを見つけたことであった。25000円程度で落札することができた。届いてみるとだいぶ大きく、一人では持ち上げるのも困難なほどの重量があった。後になって、実はディーゼル機関車そのもののマスコンではなく、除雪モジュールであるラッセルヘッドのマスコンであることに気がついた。そのため目標としていたDE10形ディーゼル機関車のものとは左右は逆になってしまったが、気にしないことで解決した。実は、マスコンが左にある機関車は、小移動を繰り返す入換(駅構内で客車や貨車を繋ぎ変えること)機に限られ少数派である。

ノッチ(出力レベル)位置を検出する仕組みはシンプルだ。レバー操作に従って下にある切り欠きのある銅板が貼られたドラムが回転し、固定された接点が銅板に触れて、接点への加圧・非加圧で2値となる。接点は6個あり、0から14までが区別できる。

これをまたPIC16F1579で読み出し、0.1秒ごとにPICへシリアル伝送をする基板を製作し、Pythonで受信するプログラムを書いた。

マスコンは単体では自立しない不安定な形状をしているので、机の天板をピッタリのサイズにくり抜いたものが必要となる。電動工具のジグソーとドリルで木工をすることで、単体で自立する机状のマスコンユニットが完成した。

ブレーキ統合ユニット

右手が用意できたら、次は左手のブレーキが欲しくなる。
残念ながら、ブレーキはレバーのみしか本物を入手できなかった。そのため、アルミケースにポテンショメータを固定して、そこにブレーキハンドルを取り付けることで実現した。

ブレーキハンドルの軸穴にネジを通して、ナットでネジと固定、ネジをカップリングに取り付けて、反対側にポテンショメータの軸を固定することで締結をした。しかし、ここが構造上の弱点となってしまい、本番中に何度か緩まることがあったのが残念だった。改善方法としては、ネジロック剤の塗布、旋盤でカップリング接続部のネジ山を削るなどが考えられる。

ブレーキハンドルの実物はだいぶ回転トルクが高い(回すのに力を要す)が、ポテンショメータと直結しているので、回転は相当に軽くなってしまう。メーカーは小ロットでも特注で回転トルクの高いものを作れると言ってくれたが、納期が全く間に合わない。苦肉の策で高張力バネで紙やすりを押し付けることである程度の向上はできたが、ギヤなどで重くするのが正解と思われる。

スピーカーと振動ユニットとSounderクラス

フルサウンドNゲージ鉄道模型コントローラということで、操作に応じた音がアナログ出力される。アナログ出力を直接分岐して、運転士座席の裏に固定されたウーファーが振動しつつ、音がスピーカ+ウーファーから出力される。

音は、主に小坂レールパークで録音したDD13液体式ディーゼル機関車のものとなっている。

コンピュータからの出力はSounderクラスを使用する。PygameでALSAから出しており、これを呼び出すことで音が出る。

DE10クラス

知恵袋に記載されていたDE10の加速度を参考にして、ノッチとブレーキハンドル角度から0.1秒ごとに速度を計算する。もっともこれは単機のときのものなので、適当な係数を掛けた。

将来的には、元空気溜めの空気量を管理すると、コンプレッサの作動も制御できるかもしれない。

NControllerクラス

シリアル通信との送受信は非同期に実施したいため、threadingによりマルチプロセスを起動することで管理する。共有メモリによりシリアル送受信プロセスと通信する。

広告

Linux(Xubuntu18.04)からNATを通してL2TP/IPsecクライアント接続する

network-manager-l2tp-gnome とかでやろうとしたのですが接続の確立に失敗します。

原因を探るのにはjournalctl -e でログを見ました。INVALID_ID_INFORMATION hash n(inval_id) と怒られていて、理由はNAT環境のせいで送信元IPアドレスと伝えているIPアドレス(192.168.x.x)が異なるからでした。

ワークアラウンドとしてはIPsecのコンフィグでleftidとしてNAT外側のIPアドレスを指定するのがよさそう(しかし、これは可変する環境ではめちゃくちゃ面倒。0.0.0.0とかで効かないかな?)なのですが、NetworkManagerを挟んだ状態でleftid(実際の送信元IPアドレス)を書き換える方法が不明だったので、コンソールベースで行いました。

方法はこちらを参考にしました。

Linux上でのL2TP/IPSecのクライアント設定 – Qiita

投入したコマンドは以下

sudo vim /etc/ipsec.conf
sudo vim /etc/ipsec.secrets 
sudo systemctl restart ipsec
sudo ipsec status
sudo vim /etc/xl2tpd/xl2tpd.conf 
sudo vim /etc/ppp/options.l2tpd.client
sudo systemctl restart xl2tpd.service
sudo vim /etc/xl2tpd/l2tp-secrets
ip link
xl2tpd-control connect l2tp-nat
journalctl -e
sudo ip route add 10.200.0.0/24 via 10.200.0.101 dev ppp0

OpenResty(nginx)とLuaとRedisでデモWebサービスをつくった

Luaは速いことで有名ですね。実はnginxにはLuaを埋め込めるのですが、これでWebサービスを作ったらかっこよさそうなので、技術デモとして作ってみました。

今回は素のnginxではなく、Luaを便利に使えるようにしたOpenRestyを使用しました。自宅サーバでやってもいいのですが、デモ後に環境を綺麗にするのが手間なので、Google Compute Engineを使いました。

configurationに直接書くのもできますが、100行弱まで長くなったので分離しました。

worker_processes 24

location / {
  default_type text/html;
  content_by_lua_file /home/mipsparc/luachat/main.lua;
}

https://github.com/mipsparc/luachat/blob/master/main.lua

Luaプログラミングは初めてです。ライブラリに基本的なものしかない上に、Webプログラミングなんて前提にされていないので、自分で1から作る感覚が面白かったです。

しばらくはここでホストしておくので、試してみてください。
http://35.243.116.247/

測定結果

条件: GCE(vCPU x 8、メモリ 9.25 GB)のlocalからApacheBenchでテスト

参考: 404静的ページ 23589req/s, 2ms(95%) 下記と同じ

GET / (CookieのセッションIDが正規かRedisで確認、Redisから投稿一覧を取得して表示)

$ ab -c 32 -n 10000 -C 'sess=IQHUKNJXEfb5XzBXa72SfsOi4xfmZpJB' http://35.243.116.247/

14375req/s, 3ms(95%)

POST / (CookieのセッションIDがPOST内容と同じで正規かRedisで確認、Redisに投稿を追加してリダイレクト)

$ ab -c 32 -n 10000 -C 'sess=IQHUKNJXEfb5XzBXa72SfsOi4xfmZpJB' -p postfile http://35.243.116.247/

12747req/s, 4ms(95%)

割と高速にレスポンスを返せているかと思います。Webサービスを作るのにはプリミティブすぎてあまりおすすめはできないかもしれないですが、複雑なルーティングや認証基盤としては手軽で高速なのでありかもしれないです。

実際には一番重いのがRedisだろうとおもうので、コネクションプールなどの工夫をすれば更に高速にできそうです。

サイバーエージェントのDSPを作る3日間ハッカソン型インターン「アドテクコンペ」に参加して準優勝してきた

サイバーエージェントのアドテクコンペで準優勝しました!
インフラ担当やって、高拡張性、高可用性の分散アーキテクチャを設計と実装して、2000QPSに4時間100%正常レスポンスできました。チームメンバーの皆さんが有能でよかった……! pic.twitter.com/02DZJv0YS6

— mipsparc (@mipsparc) September 23, 2018

きっかけは、所属している若手エンジニアサークル「Cpaw」代表のpallocさんにサイバーエージェントがハッカソン型インターンを実施すると教えていただいたことです。教えてもらわなければチャンスもなかったので、本当に感謝しています。実はインターンは初めてなので不安でしたが、無事選考を通過し参加することが出来ました。

今回は広告ネットワークにおいてDSPと呼ばれるものを作って、利益率や安定性を競うのがテーマです。詳細は省きますが、なかなかおもしろい仕組みになっています。

運営によって割り振られた[サーバ2人+データ分析2人] x 8チームで戦い、なんと準優勝することが出来ました。賞品の文鎮ももらい、こうしてドヤ顔で参加記を書けています。本当に良かった…

普段はピクシブにてバイトなんでもエンジニア(主にPHPでサーバサイド)をやっていますが、その経験により、「実プロダクトとして運用できる?」 「それスケールすんの?」 「可用性は?」 という発想を持てていたのも生きました。お世話になっている皆さんにも感謝です。

最初に分担を決めたのですが、Goをしっかり書けるもう一人にサーバサイドコードの7割くらいをお願いしたことで、私は全体設計とインフラと残りのサーバサイドコードに集中できました。また、データの二人が予測器の製作に特化できるようにするための支援も行いました。

1日目に全体の構成を考えた結果、以下のような構成になりました。今回のコンセプトは「高スケーラビリティ・高可用性な分散型DSP」です。

これをGCE(Google Compute Engine)で展開しました。お金はいくらでも使っていいという話だったので台数を豪勢に20台+1台使いましたが、APサーバを4コアにしたため、トータルでも18000円程度に収まりました。

当時の私は最高に冴えていたのですが、この予算をMaster walletから各APサーバのLocal walletに分散する仕組みはかなり良くて、講評でも高く評価されました。ポイントとしては

• ほぼ無限にスケールする。Masterをさらに階層構造にすることもできる
• 運用中にAPサーバを自由に増減できる

ということがあります。今回はAPサーバ20台とMaster walletサーバ1台の21台で構成しましたが、何台でも増やせます。今回は2000QPSでしたが、リソース利用率は20%程度だったので、この台数で9000QPSくらいまでは耐えられるはずです。それ以上増えても構成は変えずにGCEのコントロールパネルから台数を増やして、デプロイスクリプトを実行するだけの数分で対応できます。今回は十分な余裕を確保したのもあって、正常レスポンスを100.0%のリクエストに対して返すことが出来ました。これは他のチームに比べてもダントツの信頼性だったようで、誇らしいです。

systemdでコア数ぶん(今回は4つ)のAPデーモンとそれに対応するPythonの予測エンジンを立ち上げて、各APデーモンのポート番号を直接ロードバランサに指定することで、APサーバ内にはロードバランサが存在しません。こういったムダをなくした構成により、95パーセンタイルレスポンスタイムを10msまで縮められました。

最初は予測エンジンのレスポンスが遅すぎて困ったのですが、line_profilerというモジュールで行ごとの実行時間を計測してボトルネックを発見し、高速なレスポンスを返せるようになりました。

GCEから呼び出せるStackDriverというモニタリング画面も便利でした。実施時間は13:32 ~ 17:32です。それ以降は気にしないでください。

こちらが本番中の画面です。他チームとの違いとしては、本番中にパラメータを調整できるようにしたことがあります。便利だったコマンドは journalctl -f | grep Win で、デーモンが標準エラー出力に吐き出したログをリアルタイム監視ができます。このように監視プログラムやデプロイプログラムを複数用意したので、本番中にすぐに異常に気が付けました。

今回学んだこととしては、細かい単位での動作チェックを繰り返すことが大事というのがあります。開発はGitHubを軸に行いましたが、これのwikiにcurlでAPIを叩くテストパターンと想定レスポンスを数パターンずつ記載しました。機能を実装する前に明示しておくことで、チームで理解の齟齬が生じにくくなります。これは後半になってから実施したのですが、役立ちました。

結局時間は全く足りず、2日目の夜にカラオケで1曲も歌わずにひたすら作業をする羽目になりました。とりあえず、徹夜は向いていないことがわかりました。脳が動かなくなって効率が20%くらいまで落ちます。もう1日あれば、少なくとも徹夜はしないで済んだかもしれないです。

デバッグでどうしようもなくなったときや、監視が本当に動いているのか心配になったときには、 tcpdump -w out.pcap でキャプチャしたデータをscpで手元に転送してWiresharkで見て解決できました。結局本当に流れているデータはキャプチャを見るのが一番確かなので、今後もtcpdumpは積極的に使っていきたいです。

リモートでGitHubのプライベートリポジトリからpullするのには、ssh -A でエージェント転送するとよいです。自分以外も管理者権限を持っているサーバ上においた秘密鍵をGitHubに登録はしたくないので。 ssh -A は多段もできるので、適当なAPサーバにsshしてからさらにDBサーバにsshすることもできます。

デプロイはシェルスクリプトで前述のssh -Aを順番に打ってサーバでpullしていくシンプルな方式にしました。今思えば、最後に&をつけて並列にしても良かったかもしれません。また、CircleCIなどの今時の方法を使う手もあったかもしれません。

しかし、当時のベストを尽くせた気はするので満足しています。開催してくださったCAの皆様、素敵な機会を提供してくださってありがとうございました。楽しかったです!

MIPSコアのPIC32を始めた

以前から挑戦したかったPIC32 32bitマイクロコントローラをついに始めた。石は適当に買っていたDIPのPIC32MX230F064Bを使用。

PIC16F1しかやったことがなかった身としては、引っかかるポイントが多かった。

ICSPの配置が異なる

単純に異なる。PICといえばPIC16で、情報がないので、書き込み回路の結線すらデータシートとにらめっこする必要がある。PGED1とPGEC1を使用した。

駆動に必要なピンが多い。キャパシタが必要

4.7uFをVcapに接続する必要がある。

__delay_ms() がないので、タイマーを作ってコールバックで呼んであげないといけない

コールバック関数としてmain.cに作成した
void MAIN_TMR1(void) {
IO_RB15_Toggle();
}
を指定することで、1秒間隔でタイマーは駆動するようになった。

駆動電圧が 2.3~3.6VなのでUSB直結で動かせない。レギュレータなどが必要

ちょっとつらい。とりあえず安定化電源でやっているけど…

PORTBの一部のピンがGPIOで制御できない。

これは本当に苦しんだ。しかたなく他のポートを使ったけど、気づくのに時間がかかった。JTAGとかと干渉しているのか?

ともあれ、MIPSデビュー。現状8MHz、最大60MHzだけど間違いなくMIPS。USBデバイスとかを作ってみたい。

IPv6の功罪 知らぬ間にインターネットにポートが露出していることの危険性

先日、これまでVDSL onlyだった自宅マンションにNURO光が引かれたので、速度に惹かれて即座に回線を乗り換えました。NURO Bizではなく、家庭向けの回線ですが、コンスタントに高い速度が出るので、とても満足しています。家庭向けの回線なので、これまでの回線で使えていた固定IPv4アドレスと逆引きが使えなくなったのは残念ですが、仕方ありません。もっとも、調べてみるとIPv4アドレスはほぼ変わらないようです。こちらは要確認です。

代わりに、以前は使えていなかったIPv6が使えるようになりました。ほぼ変わらないグローバルIPv6プレフィックス(/64)がONUに割り当てられています。ICMPv6のRS(Router Solicitation)とRA(Router Advertisement)により、端末のインターフェイスのMACアドレスから生成されたグローバルIPv6アドレスをインターフェイスに割り当てることができます。

ここでポイントは2点あります。ひとつめは、DHCPv6ではなくRAによる生成なので、割当プレフィックスに変化がなければアドレスは不変です。また、各端末のインターフェイスにグローバルIPv6アドレスが割り当てられます。今日はこれが本題です。

ルータ(ONU)は挟まっていますが、NAPTやNATは行わないので、インターネットに各端末が直結している形になっています。これはなかなか不安になりますね。試しに [::]:適当なポート にHTTPを割り付けてみただけで、ネットワークの設定はせずに外部からのアクセスができてしまいました。とても便利ですが…NAT設定を変えなければ大丈夫という古い考えの場合、大きなリスク要因です。

自宅のサーバについてnetstat -aしてみたところ、Sambaがインターネットから直接アクセスできる状態でした。そのため、アタッチするIPアドレスを固定して、v6では使えないようにしました。パスフレーズは設定していたので、直ちに問題になる状況ではありませんでしたが。

考えられる事故事例

• 家庭内にNASを設置している場合、プライベートネットワーク内からしか見られないと勘違いしてパスフレーズを設定していなかった。しかし、NASにもグローバルIPv6アドレスが割り付けられ、外部から参照可能であり、情報流出・改ざんが発生した。
• NASを設置しており、パスフレーズは設定していた。しかし、メンテナンス用にtelnetが開いており、簡単な既知のパスフレーズでシェルに入ることができたため、情報流出・改ざん、ネットワークへの侵入が発生してしまった。
• イントラネットのみに公開していた社員専用Webサービスにアクセスされ、いたずらでSQLインジェクション攻撃をされ、データベースが破壊されてしまった。

以上のように、これまではNATにより守られていた機器がインターネットに露出することにより、危険性は上昇します。

不特定多数への攻撃なんてあるのかと疑問に思うかもしれませんが、現実的にありえます。NICTのNICTERの資料などをご覧ください。先日のNICTオープンデイでも、当該研究をされている研究員の方にお話を伺いましたが、特に家庭用ルータ管理画面の脆弱性を狙ったものが無差別に来ているようです。

もっとも、IPv6はアドレス空間が極めて広大なため、ランダムなIPv6アドレスへの攻撃は難しいです。現状でIPv6にもそのような攻撃が存在するのかを調べてみたところ、2013年の研究( https://www.idsv6.de/Downloads/2013-13-06-BMBF_10_darknet.pdf )では、9ヶ月ハニーポットを運用して、1IPv6アドレスにつきTCP反射パケット(IPアドレススプーフィングなど)が1157パケット、ACKスキャンが15パケット来たそうです。現状ではランダムな攻撃を受けるリスクは大きくないですが、IPv6アドレスが攻撃者の手に渡らない前提のセキュリティは危険でしょう。

 

 

Yahoo! Japan主催のハッカソン「HackU 法政 2018」にCpawとして出場して、最優秀をもらった話

大学とヤフーが共同でハッカソンをやるという話が来たので、最近関わっているサークルの「Cpaw」で出ることになり、学部1年の私と院生5人の6人チームで参加してきました。なぜか開発期間は1ヶ月もありました。

ハッカソンはHackUという名前で、大学個別のものと一般参加のできるものがあり、今回は大学別のものです。一般参加のほうが勝負しがいはあったかもしれませんが。

作ったものは「顔認識でユーザーを識別して、音声コマンドで物品を購入すると、ドアが開いてユーザーが取り出せる」ボックスです。名前は「Chash BOX」といいます。私は箱そのものの製作、電子回路設計、実装、PICファームウェア実装、ネットワークまわりなどを行いました。

制御基板 pic.twitter.com/zaS6PuKTtL

— mipsparc (@mipsparc) August 5, 2018

今年は各チームともレベルが高かったのですが、技術の高さを評価され、結果的に最優秀賞をいただけました。各位に感謝です。

動作している様子の動画はこちらです

Hack U 法政大学 2018 プレゼンテーション・作品展示会・表彰式 – YouTube

詳細についてはこちらのCpaw公式ブログに載っています
https://www.cpaw.site/2018/08/07/hackuhosei2018/

上の段に普通のコンピュータが2台も入っているので、排熱と消費電力が問題でした。業務用1Uルータについていたファンを取り付けて強制空冷しています。

電子回路とPICファームウェアはノイズ耐性に重きをおいて開発をしたので、一度も問題は起きませんでした。木製ボックスを採用したことにより、歪まないように天板を取り付けるセッティングの手間がかかったのは、改善の余地があります。

扉の開放には定格DC36Vのソレノイドに0.3sだけ40Vをかけることで、どうにか確実な開放を実現しました。ちょっとマグネットキャッチャーの磁力を高く設定しすぎましたね…

余っていたノートPC用の15VACアダプタと昇圧・降圧DC-DCコンバータを組み合わせることで、5V(PIC・LEDライト)/15V(ソレノイドラッチ)/40V(ソレノイドオープナー)の3電圧を供給しました。床に転がっていた中国製謎DCDCコンバータを採用することで、低コストで実現できました。

開発のながれ

最初に仕様を決定

回路図(っぽいイメージ図)を設計

最低限の可動部分をブレッドボードに実装、動作確認

PICでファームウェアを書く

PICを使った回路をブレッドボードに実装、動作確認

パラメータの変更、プログラムの調整

部品配置図、実体配線図の検討

ユニバーサル基板に実装、動作確認

反省点

反省点としては、技術偏重になってしまい、ユーザーから見えないところに重きを置きすぎてしまった点があります。また、中央のサーバで処理するのではなく、小型のボックスとして各事業所に置くわけなので、シンプルで信頼性の高いことを優先して開発を進めるべきでした。

このような知見が得られたことも含めて、よく勉強になりました。近日中にまた機会がありそうなので、楽しみです。