トイラジコンを作る話(5)

前回、ピーク電力を抑えるための施策を考えましたが、今回はその中に上がっていたステア用サーボモータの自作についてです。

機構を考える

M2ねじとナットによる直動機構

　以前使っていたRCサーボモータ(SG90)は角度維持のために常に電圧をモータにかけておく必要がありました。電源に余裕があれば問題ないですが、今回はそこまでの余裕が無いため電力を使わずに位置を固定できるような機構を採用しました。

　今回はネジとナットを使用した直動機構を作成しました。外部からステア角を変えるような力が加わったとしてもナット自体の位置は動かず、逆にねじを回せばナットの位置が変わる仕組みになっています。この仕組みにより所定の位置になったらモータの電圧を落とせるため、消費電力を落とす狙いです。　

　位置決めについては、ねじの回転角度が分かるように光学式エンコーダを入れます。本当であれば、ナットの位置が分かるようなセンサを入れるべきですが、機構が思いつかなかったのでやむなしです。

光学式エンコーダを作る

　今回は光学式エンコーダについても自作します。光学式エンコーダには発光部と受光部を同じ面に配置する反射型と対面に配置する透過型がありますが、スペースの都合上今回は反射型としました。センサについては実装面積の都合によりNJL5901ARを2つ使用し2相式としました。これはカウント値と回転方向を知るための施策です。

反射板(兼ギア)

　エンコーダの反射板ですが、最初は白黒の紙を貼っていましたが黒でも相当反射を拾ってしまうことが分かりました。また今回反射板作成に使用したVisiJet® M2R-TNは赤外線を結構反射していることもわかりました。結果として、反射部分をぎりぎりまでセンサに近づけ(設計時で0.5mm程度)、それ以外の部分は穴をあけたり黒く塗ったりして赤外光が反射しないようにしました。また、反射板の外周にはM0.5の33枚歯のギアをつけており、反射板と駆動用のギアを兼ねた構造にしています。反射する部分としない部分は3つづつ作成し、結果として1周24カウントとしています。

実際に作成した反射板(裏面)

　回路側は抵抗とフォトトランジスタの電圧変換回路を入れたうえで、後段にコンパレータを入れただけのシンプルな回路としました。電圧変換回路の抵抗値は調整が必要でしたが、それさえできれば特に問題なく動いています。本当であれば電圧変換後にフィルタやゲインアップを行い、チャタリング防止等の回路も入れるべきですが、今のところはなくても問題なさそうです。

動作確認

　それっぽい感じには動きました。波形等も特に問題なさそうです。また意図した通り、電源を切っても位置は固定されたままなので、動作時の電源OFFも問題なくできそうです。

次回

　今回は光学式エンコーダを作成しました。裏でこれ以外の試作したりもしていたりしましたが、結構失敗しています(モータのピニオンギアを自作して失敗、反射板とフォトトランジスタのギャップを1mm程度にしたら電圧波形が全然変化しない、抵抗値を上げすぎて電圧波形ピークが小さすぎるetc)。オペアンプで波形増幅+オフセット調整+フィルタ等を行えばよかった等の反省点もあるのでそのうち反映したいなと思います。

　次回はそのほかの省電力についても見ていきたいと思います。

©2025 shts All Right Reserved.

トイラジコンを作る話(4)

いつの間にやら親知らずを抜いた中の人です。前回予告していたUnitVをつなげて動かす話です。

UnitVから画像を転送する

撮影の様子

　UnitVの接続については、GroveのUART接続を使用しました。ESP32とUnitVの間は4Mbpsで接続しています。画像の引き抜き方法についてですが、UnitVで内でRGB565の画像を作成後、UnitV-ESP32間はUART、ESP32-PC間はBluetooth Serialで引き抜くようにしました。最終的にPC内でPNGに直して生成するようにしています。

　Bluetooth Serialを使用してデータ転送を行う場合、あまりに長いデータを送るとデータ破損して使い物にならなかったです。トライアルの結果、上り下りのデータを交互に転送することでこの問題を回避できることが分かったので、画像をH方向に分割し、適宜PCからESP32への同期用データを送付することで解決しました。

PCに転送されたデータ

もろもろ結合したら動かず...

　とりあえずここまでやってきた内容をすべて統合(駆動系制御+画像転送)し動かしてみたのですが、バッテリー駆動にしたとたんUnitVの起動に失敗することが分かりました。残念。

電源系統図。今回問題になったのはAI Acc.のところ。

　電源系統を見てみると、UnitV+ESP32用の5V系統(制御系)と、サーボモータと走行用モータ用の5V系統(駆動系)の2種類に大別できます。今回問題を起こしたのはUnitV+ESP32の系統ですが、画像転送ができていることから、この系統のみを使用する場合は問題がないことが分かります。また、走行用モータの系統+ESP32のみ使用でも問題がないこともわかっていることから、今回は複合動作をさせたことが原因と推測しました。

　シナリオとしては、"駆動系用のDCDCと制御系のDCDCが同時に電流を引こうとした結果、バッテリーの電源供給能力が追い付かなくなり、結果としてDCDCの出力電圧低下を招いた。そして電圧変動に最も弱いUnitVが瞬停したのではないか(ESP32は5V->3.3Vの電圧降下を実施しており、5Vラインの変動にある程度対応可能?)" といった具合です。詳しく電力計測を行ったわけではないのであれですが...。

　これを踏まえて、対策を考えてみます。

対策を考える

　バッテリーが出せる電力をシステムが要求する電力が上回ってしまっていることが問題なので、バッテリーを変更するか、回路側でピーク電力低減をするしか方法はありません。

バッテリーを変更する場合、前々回話した通りLiPoのようなバッテリーは使わずに行きたいので、同種の電池を追加することになります(例えば、単三電池2本から3本に増量)。ただしこの案には問題点もあり、電池を増やすことで重量増になり、結果として駆動系の電源系統への負荷がさらに上がることが危惧されました。

　となると、回路側で工夫するほかなさそうです。どれぐらいの量/幅で電力を削ればよいかわからないので、大きく削れそうなところを探して修正していく方針で行きます。

駆動系統の低電圧化

検討中の電源系統図(SubMCUは検討途中でドロップした)

　一番大きなアイテムとして駆動系の電圧を落とします。駆動系のテスト結果から、思った以上に速度が出てしまうので、もっと速度を落としてもよさそうに思いました。モータの電圧を落とせばよいのですが、思い切ってMDの電源をバッテリー電源につないでしまいます。こうすればもともと5V駆動だったものが2.4V程度(Ni-MH*2前提)まで落とせるため、定常動作時の電力は半減します。ピーク電力もある程度は落とせるでしょう。

　課題としては、走行用モータのトルク低下と、サーボモータとMDの最低電源電圧が2.4Vよりも高いことが挙げられます。トルクの低下についてはギアをもう一枚かませることで速度を犠牲にトルクを3倍程度増やすことで解決します。また最低電圧の話について、MDについては新たに最低1.8V駆動が可能なものに変更し、サーボモータについては自作することで解決します。

ESP32のDCDC直接駆動化

　ESP32の電源については、もともと制御系の5VラインからLDOを介して3.3Vに落としたものを使用していました。ですがLDOを使用するよりもDCDCの方が効率が良いのでDCDCで直接駆動する方式に変更します(短いスパンの電力変動に効くかどうかは不明)。

次回

　といった感じで、途中まではうまくいっていたのですが最後に躓いてしまいました。この後ステア用のサーボモータを自作するのですが、その話は別の機会にしようと思います。

©2025 shts All Right Reserved.

トイラジコンを作る話(3)

前回、改善したいところを書き連ねましたが今回はその改善の話です。

前回の振り返り

前回見つけた課題をもう一度見てみます。

• Grove経由の信号のレベル変換がないので、5V信号が来ると破損の可能性あり
• IMUを搭載したい
• 基板をフレーム替わりに使いたい
• 分解組み立てが難しいので改善したい

　上二つについて、レベル変換はMOSFETを使ったレベルシフト回路を挟めばよさそうで、IMUはその辺に転がっていたMPU6500を入れればよいでしょう。

　少し難しいのが下二つです。組み立て手順が相当難しい(ねじ止めの順番を入れ替えてしまうと組み立て不可になる)のでそこを改善しつつ、フレームをMJFから単価の安い基板に入れ替えることを考えます。

基板でフレームを作る

実際に作成した基板

　前回の作った構造を振り返ると、メカ部品を上下2枚の板で挟み込む構造になっていました。これを踏まえて、この上下の板をプリント基板に置き換えることを考えます。

　設計の流れとしてはメカ周りの設計を行った後、電子部品を置くと干渉しそうなところを抽出、その後回路側の設計を行う流れで設計しました。内部のメカについてはギアボックスを作成してプリント基板でサンドイッチする方針としました。また、回路図自体はレベル変換とIMUの追加以外は前回と同じものを流用しています。

今回作成した改良版(左)。以前のもの(右)と比べるとずんぐりむっくりになった。

　合わせて基板やメカの固定方法も見直し、サンドイッチ構造を上下からねじとナットで止めて固定するように変更しました。これによって、分解・組み立てが非常に楽になりました。

表面の様子。電子部品が多いのでわかりにくいが、ナットが6つある。

裏面の様子。
ねじが表面まで貫通しており、挟み込む格好になっている。

動かしてみた

駆動系はメカ・回路含めて特に問題なく動作しました。

次回

次回はUnitVを実際に接続して動かしてみようと思います。

©2025 shts All Right Reserved.

トイラジコンを作る話(2)

前回の記事では、回路とメカを作ったものの上手く動かなかった話を書きました。今回はその続きで、再設計を行った話です。

再々設計

再設計後のアームを前方から見た図

まずは強度不足の箇所があったので修正しました。

曲がってしまった下側のアームについては肉厚を3倍に増やしました。合わせてハブ周りも変更を入れました。回路周りについてはDCDC周りの改善をしました。

最終的にアクチュエータが動くところまではできました。

再々設計の問題点

再々設計をしたのですが、いくつか問題点も出てきました

• バッテリーや電源子基板を置く場所がない
• ステアリングの機構に問題があり、ステアリングセンターを出してもずれる
• LiPoバッテリーの保管/廃棄に不安あり
• モータを回すと通信が途切れる

というわけで再々々設計をすることにしました(~ここまでが2021年ごろ)

再々々設計

さて改善点を上げて再々々設計に取り組み始めたのですが、メカ周りの部品が上がってきたのが2023年末、実機が具体化したのが2024年の8月ごろでした。修論~社会人は全然休みが取れず、相当スローペースながらもこそこそ進めていました。

メカ周り

バラした図。メカは右最上段のやつ。

まずは部品配置を大幅に見直しました。もともとの構成では、回路系を車体中央に集め前方のステアリング系と後方の駆動系でサンドイッチするようになっていたのですが、今回からは回路をステアリング/駆動系の上に置くように変更しました。この構成は、無線が切れる問題(アンテナの位置を上面に持ってくる)や回路置き場がない問題(まとまった平面が欲しい)を回避するための施策でした。

メカ部分の上の蓋を外した様子。解体すると戻すのが難しい。

ステアリング周辺ではサーボをGS1502から入手しやすいSG90に変更しました。消費電力が少ないGS1502が良かったのですが、今回考えたタイロッド周りの構成に合わせてSG90に変更しました。回路系を移設する都合上、元々デフの直上にあったモータを前方に倒す形で実装しています。

回路周り

制御基板。MDを交換した際にランドがはがれたのでジャンパを飛ばした。

回路については電源子基板をやめ、1枚の基板に全回路を収めました。

大きな変更点としては、バッテリーがLiPoからニッケル水素の単三乾電池x2になっています。電源電圧が落ちることになりますが、変更したDCDCでも昇圧できるレベルではあったので問題なしとしました。またLiPoの充電回路は削除しました。

そのほかの点では、DCDC・USB-UART変換・MDを変更しました(それぞれTPS63001/63002からPAM2401、FT231XSからCH340K、TB6612からTB67H450)。

USB-CのD+D-のピンアサイン間違いや書き込み回路の不備があったのでマイナー修正版を作りました。

動かしてみた

bluetoothでPS3のコントローラをつないで動かしてみました。

目標どおり動きました🎉

課題と次の話

全てバラした様子。

トイラジコンとして機能するものができました。作っていく中で課題や改善策もいくつか出てきました。

• 分解組み立てが難しいので改善したい
• Grove経由の信号のレベル変換がないので、5V信号が来ると破損の可能性あり
• IMUを搭載したい
• 基板をフレーム替わりに使いたい

次回はこの辺の改良に加えてM5UnitVをつなげてみたいと思います。

p.s. 作成ログ

https://x.com/shtsno24/status/1746185220435620317

©2024 shts All Right Reserved.

トイラジコンを作る話

前回の投稿から1年以上放置していた中の人です。定期更新ができないのは中の人の性格()なのでご承知おきください。以前トイラジコンを作る記事を出していたのですが、その続きを書いていなかったので書いておこうかと思います(2020/4ごろの記事なので、4年以上も前ですね)。

さて前回の記事をざっくりまとめると、

• メカ部品を設計して3Dプリンタで作ったが、サイズと強度が足りず再設計
• プリント基板を設計したら旧正月にバッティングして1カ月遅れで到着

となってました。この後メカ側は再設計した部品が届いたので仮組みをし、並行して回路側の評価を行いました。

メカの再設計

メカの方は設計方針を大幅に変更しました。機構周りの部品についてすべてを3Dプリントで自作するのではなく既製品を流用することにより耐久性や精度を得る方向にシフトしました。

この方針変更に伴い、設計の参考にしていたMINI-Z AWDのシャシーからデフを流用し、それに合わせたマウント等を設計しました。

リア周りの駆動系(ガワ無し版)

MINI-Z AWDの駆動系をそのまま移植することも考えたのですが、トレッド幅を狭くする必要があったため短縮版のドライブシャフトを3Dプリントで作成しました。またもともと後輪駆動の想定だったため、プロペラシャフトはMINI-Z FWDのものを流用し、モータを含めた駆動系一式を車軸の上に建てる設計としました。モータはMINI-Z AWDのFA-130からタミヤのミニモータセットに変更しました。

フロント周り

フロント周りはハブとサーボ以外は3Dプリント品にしました。特筆すべき点はないですが、アッカーマンジオメトリになるように設計しました。

機構確認

部品が来たのでとりあえず組んでみました。

パッと見はよさそうな設計でした。しかしながら、いろいろ試すうちに至らない部分が何か所かあることが分かりました。

下側の受けの一部が、強度不足で曲がってしまった

ステアリングを切ると、壁に接触してしまう

これらの改善点と回路側の不具合内容を鑑みて、メカ側は再設計を実施することにしました。

回路評価

設計した回路が届いたのでテストを実施しました。が、昇圧回路の出力側に負荷を接続し忘れたためDCDCが数分で壊れました。また、モータを回すとUART-USBの通信ができなくなるといった不具合もあり、再設計をすることにしました。

数分で破壊された電源基板
白色LEDが付いている5V系統は正常な出力が出ている

終わりに

さてここまでが2020/5~2020/8月ごろまでの話でした。とりあえず初物尽くしだったので手探りでやってましたが、その結果としていろいろハマってしまった感じでした。この後作り直したのですが、その話はまた別の記事で。

©2024 shts All Right Reserved.

NNCase V1.7を試す話(実機実行編)

前回のSim実行編にて、NNCaseのSimが動くところまで確認しました。今回はその続きで、実機で動かす話になります

1.テスト環境

今回の環境(ホスト)は以下の通りです

• RPi4 4GB(Raspbian 11:bullseye)
• Docker(23.0.5, build bc4487a)
• NNCase(v1.7.1)
• nncaseruntime(v1.7.1)
• kendryte-standalone-sdk
• kendryte-gnu-toolchain

基本的な流れとしては、toolchainを入れてからstandalone-sdkを入れ、nncaseのruntimeを入れる形となります

またK210のボードとして、Maix Bitを使いました

Sipeedのプロダクトページ
スイッチサイエンスの販売ページ

千石電商の販売ページ

2.インストール

まずはtoolchainのインストールからになります。

$ git clone --recursive https://github.com/kendryte/kendryte-gnu-toolchain
$ cd /kendryte-gnu-toolchain/riscv-gcc
$ ./contrib/download_prerequisites
$ cd /kendryte-gnu-toolchain
$ ./configure --prefix=/opt/kendryte-toolchain --with-cmodel=medany --with-arch=rv64imafc --with-abi=lp64f
$ make -j4

今回は/opt/kendryte-toolchainに突っ込みました。次にsdkを入れます。

$ git clone https://github.com/kendryte/kendryte-standalone-sdk

kendryte-standalone-sdk/srcにビルドしたいプロジェクトを突っ込んでいくみたいです。最後にnncaseruntimeを入れていきます。

$ wget https://github.com/kendryte/nncase/releases/download/v1.7.1/nncaseruntime-k210.zip -P ./kendryte-standalone-sdk/lib/nncase/v1
$ unzip -o ./kendryte-standalone-sdk/lib/nncase/v1/nncaseruntime-k210.zip -d ./kendryte-standalone-sdk/lib/nncase/v1

sdkのディレクトリにsrc/lib/nncase/v1があり、この中にruntimeを入れている格好になっています。アップデートの際にはここを上書きすることで対応することができます。

参考：とりあえずKendryte K210に触れる(1) - 環境構築

3.コンパイル

前回のSim実行環境のサンプルコードと実機用のコードをまとめたものを上げておきます。

build_yolox.sh内のcompile_pathをsdkの場所に書き換えることで実行できるはずです。

差分としては、Maix Bitのへの対応がメインになります。

コンパイルをすると、モデルの変換結果や実機に入れるbinなどが生成されます。

参考：https://github.com/kendryte/nncase/tree/v1.7.1/examples/yolox

4.実行結果

実機実行の結果。Simと微妙に異なる

実際に動かすとちゃんと認識していることが分かるかと思います。しかしながらSim結果とは異なっている部分もあり、何起因の差分化は考える必要がありそうです。

実行結果(UART)
1回目実行では1100ms程度かかるらしい

実行速度は1100ms程度のようでした。起動直後の1回しかは測定していないので、もう少し条件を詰めて確認する必要があるかと思われます。

5.まとめ

今回はSim編の続きとして実機実行までの流れをやってみました。とりあえずどんな感じで動かせばよいかぐらいは分かったかと思います。この話の発展として別のDNNモデルを実行したり、性能改善を行ったり、カメラをつけて実行等があるかと思いますが、今回はここまでにしたいと思います。

©2023 shts All Right Reserved.

NNCase V1.7を試す話(Sim実行編)

社会人2年目になり業務量が増えてきた中の人です。今回は以前やっていたが公開していなかったNNCaseのv1.x系(kmodel v5)を試す話になります。

2023/5/20追記：サンプルコードを公開

1.NNCase v1.xの特徴

以前のバージョンと比較した際の一番の変更点としては、従来のコマンドラインベースのものからPythonの1ライブラリとしての実装に変更されています。kmodelの元ネタになるonnxやkerasのモデルを生成するコードに追加することもできます。ビルド済みのwhlが公式から提供されており、CPUはx86-64、OSはWin/Linux/Mac版があります。

これ以外の点では、対応する演算の種類が増えている、K210の上位機種に当たるK510への対応といった部分のアップデートがなされています。これに合わせる形?でkmodelのバージョンもv5に上がっています。

2.テスト環境

今回の環境は以下の通りです。

• RPi4 4GB(Raspbian 11:bullseye)
• Docker(23.0.5, build bc4487a)
• NNCase(v1.7.1)

NNCaseのv1.xはarm64に対応するwhlを出していないのですが、中身を一部変更してビルドしました(基本的にはx86-64と同じコードになります)。またビルドのデバッグがやりたかったので、Docker環境にねじ込みました。今回はK210を動かすところまではいかないので、NNCaseのみの紹介にします

3.インストール

x86-64環境であればインストールは簡単で、公式のリリースからwhlを持ってきてインストールするだけになります。(今回試しているarm64の場合は自前でビルドする必要が出てくるので面倒でした)

4.コンパイルとSim実行

v1.7.1でのコンパイルとSim実行手順は基本的にはここにいろいろ書いてあります。このディレクトリを手元に落としてきて動かすのが最初はよいかと思います。
このディレクトリは以下のような感じになっています。

.
|- tools：モデルの変換とSimを実行するためのコード
|- images：入力画像
|- model：もとになるモデル(onnx)
|- cpu
`-k210：実機実行用のコード

README.mdを見たところ、画像の入ったディレクトリを見に行くオプションがすべてimagesではないところだったのですが、手元で試したところimagesに変更しても動くことが分かりました。

python tools/compile.py model/yolox_nano_224.onnx yolox_nano_224_quant.kmodel --imgs_dir ./images/ --legacy --target k210

python tools/simulate.py yolox_nano_224_quant.kmodel ./images/dog.jpg

環境内でmatplotlibの表示機能が使えるのであれば、Sim結果としてこんな感じの画像が得られるはずです

Sim結果
実機実行の結果とは異なるので要注意

5.まとめ

今回はNNCase v1.7を使ってSimを実行してみました。変なことをしなければすんなり動くはずであり、K210の実機が無くても結果が確認できるのでお手軽に試せるかと思います。

次回はK210搭載のボードを使って実機実行していきたい思います。

n.おまけ

以前使っていたM5StickV+MaixPyの組み合わせではkmodelのv5に対応していなかったのですが、まさかのkendryteがMaixPyではない別のツールを作って対応しようとしていました。(boardのディレクトリにm5stick的なものがあったが、M5StickVで動くかどうかは不明)。

参考1:https://github.com/sipeed/MaixPy/issues/434

参考2:https://github.com/kendryte/canmv

©2023 shts All Right Reserved.

Verilator使ってみた

https://www.veripool.org/verilator/より引用

Verilog初心者の中の人です。今回はVerilogシミュレーションツールであるVerilatorをお試ししてみました。またこのツールの売りであるSim実行速度を簡易的に計測したので、併せて紹介します。

1.Verilatorとは何か

VerilatorはVerilog/SystemVerilog向けのRTLシミュレーションシステムの一種になります。LGPL3/Artistic License2.0で配布されており商用利用も可です。この手のツールは大体がライセンス必須のクローズドソースであることが多いですが、Verilatorはその点で異なったものになります。Verilatorの売りはSimの実行速度であり、有償のツールと同等かそれ以上の性能が出ると主張しています[1]。

2.お試ししてみる

今回は簡単なUART送信回路を作成し、そのテストベンチをVerilatorで書いてみました。

(コードはこちらから)

今回はFPGA開発日記さんの記事を参考にしながら、.vcdの波形出力まで行うテストベンチを書きました。またUART送信回路自体は、FPGA上での実機動作が確認できているものを流用しました。書いてみた感想としてはTB本体の準備はそこまで差がないのですが、Verilator(C++)の方が入力するデータの準備や出てきたデータを料理が楽でした。また実行時間もVerilogのTBを実行していた時と比べ何となく速い気がしました。

3.Verilog版TestBenchとの比較

実行時間が体感で速そうだったので、実際に計測してみました(Verilator公式でも高速実行アピールがあるので、本当だとは思っていましたが)。計測方法としては、対象回路に対して同じタイミングで信号を印加するTBをVerilogとVerilator(C++)で準備し、Simにかかった時間をパラメータごとに10回計測し均しました。計測の諸条件は以下の通りです。

• PC：XPS13(9310)
• CPU：Intel Corei7-1185G(3GHz)
• RAM：16GB
• OS：Ubuntu 20.04.5 LTS (GNU/Linux 5.4.72-microsoft-standard-WSL2 x86_64)
• Icarus Verilog version 10.3
• Verilator 5.005 devel rev v5.004-76-g5ef373500
• g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
• Sim内で変わるパラメータは終了ステップ数のみ(100スタートで10倍毎に計測)
• 実行時間はLinuxのtimeコマンドで計測
• .VCDファイル生成時間を両者ともに含む
• コンパイラの最適化設定は両者デフォルトの状態

実測結果は以下のようになりました。

x軸実行ステップ、y軸実行時間のグラフ
(両対数グラフなことに注意)

このグラフから実行ステップ数が短いとVerilatorを使ってもそこまで高速化の恩恵が得られないのですが、ある程度以上のステップ数になるとVerilatorの方が10倍のオーダで高速に実行できそうなことが分かりました。(生データはこちら)

4.その他

不定が扱われない様子
(左：Verilog、右：Verilator)

Verilog側で出ていた出力波形の不定がVerilator側では出ていないことに気が付きました。これはVerilatorが信号を4値(0, 1, Z, X)としてではなく2値(0, 1)として扱うことに起因しているようです[2]。不定伝搬等を検出するためにはいくつかの工夫が必要だと思われます。

©2023 shts All Right Reserved.

2022年にやったことまとめ

手が滑って買ったオシロ

5月以来の更新になった中の人です。社会人になり休日のありがたみを実感しているこの頃であります。今回はブログに載せていないものも含めて、2022年に作ったものを振り返る話になります。

1.PYNQとVitis HLSで作るFMA演算IP

テストで使用したFPGA(PYNQ-Z2)

一応ブログとして挙げたネタなのでそこまで詳しく解説はしないのですが、FMA用のIPを高位合成で作成して性能評価を行った話でした。

記事へのリンク

2.Rust初心者が、Rust+RPi PicoでST7789使用TFT LCD(Waveshare Pico LCD 1.3)を使う話

とりあえずLCDを動かしてみた

こちらもブログネタで、Rust+RPi PicoでLCDを操作する話でした。これについてはブログを上げた後に裏でいろいろいじってました(が諸事情で非公開)。

記事へのリンク

3.激安プロジェクタ分解

カバーを外したプロジェクタ

完全なる好奇心で\4k弱のプロジェクタを購入し分解しました。今は動作する状態まで組み立てて使っていないのですが、そのうちLEDの換装とかをして遊ぼうかと思っています。記事を書け。

プロジェクタの販売ページ

4.TinyFPGA BX用拡張ボード

左から試作(1)、試作(2)、完成品

TinyFPGA BX用に拡張ボードを作ってました。実は以前にも作っていたのですが、出来がそこまでよくなかったので再設計してみました。あとはHDLの学習もかねて74HC595を制御するドライバの作成なども行っていました。記事を書(ry

5.nncase V1.x試してみた

実際に画像を読ませて認識させた結果

以前nncase V0.4の動作確認記事を書きましたが、あの後で更新がいろいろ入ったので新しいバージョンでの動作確認環境の構築を行いました。aarch64+Dockerの環境でnncaseの実行とK210向けのバイナリ生成まで動く環境を作ることができました。記事を(ry

6.レゴで作る90°ステッパー

作成したステッパー

レゴでシーケンシャルミッション等を作る際に必要な90°ステッパーを作りました。たまたまできてしまった代物でした。記事(ry

7.電源基板を作る話

試作中の基板

ちょっと気が向いたので、電源基板を作っています。オレオレ規格を策定するところから始まっているので先は長そうですが、いろいろ試すいい機会だと思っています。記(ry

8.終わりに

MFTokyo2022に行ってました。

今年は業務でいろいろ作る方に気力を吸い取られたため、あまり活動できなかった部分がありました。来年以降はもう少しいろいろやりたいところです。

...そんなことより記事を書け。

©2022 shts All Right Reserved.