【Jetson Nano 2GB】PyTorchのインストール

engetu21.hatenablog.com
で導入したjetson-inferenceにあるシェルスクリプトからPyTorchをインストールできる。

$ sudo ~/jetson-inference/tools/install-pytorch.sh

スペースを押すことで「*」がつくため、この状態でEnterを押下。
必要となるパッケージを自動で取得(apt)してくれます。すごい楽・・・。
終了すると以下のメッセージが出力されます。

Using /usr/local/lib/python3.6/dist-packages
Finished processing dependencies for torchvision==0.7.0a0+78ed10c
[jetson-inference] restoring /usr/bin/ffmpeg from /usr/bin/ffmpeg_bak

[jetson-inference] installation complete, exiting with status code 0
[jetson-inference] to run this tool again, use the following commands:

$ cd /build
$ ./install-pytorch.sh

【Jetson Nano 2GB】Dockerコンテナの導入とカメラモジュールが認識されなかった話

実家に帰っても暇なので、Jetson Nano 2GBとモバイルモニターを持ってってセッティングの続きを実施。
Jetson Nano 2GBで物体認識や物体検出を行うにはDockerを入れるのが手っ取り早いらしい。

以下のページを参考に実施してみる。
arkouji.cocolog-nifty.com

１．Dockerの導入

github.com

上記のGitHubからコンテナを導入する。
どうやらJetPack-L4Tのバージョンは記載しているものに合っていないといけないらしい。
JetPack-L4Tってなんぞや？っと思って調べてみると、L4Tは「JetPack SDK includes the Jetson Linux Driver Package」のこと？らしい。
では、自分が入れているバージョンはどれなのか、というのは、以下の２つのコマンドでそれぞれ確認可能。

cat /etc/nv_tegra_release
# R32 (release), REVISION: 6.1, GCID: 27863751, BOARD: t210ref, EABI: aarch64, DATE: Mon Jul 26 19:20:30 UTC 2021

$ dpkg-query --show nvidia-l4t-core
nvidia-l4t-core 32.6.1-20210726122000

１つ目は、R32とREVISION: 6.1で「L4T R32 6.1」と判断できる。
２つ目は、32.6.1と出てくれるので、そのまま読み取れる。

GitHubに記載されているContainerTagはr32.6.1とあるが、該当するL4T versionはL4T R32 6.0とある。
先程のコマンドで使用しているバージョンはR32.6.1と出たが、これは問題なく動くのだろうか・・・？
まぁとりあえず、説明に沿って実行してみます。

$ git clone --recursive https://github.com/dusty-nv/jetson-inference
$ cd jetson-inference
$ docker/run.sh

※先に取り上げたL4Tのバージョンについては、上記GitHubで取得したjetson-inferenceのtool配下に、l4t-version.shを叩くことでも確認が可能。
$ ~/jetson-inference/tools/l4t-version.sh
reading L4T version from /etc/nv_tegra_release
L4T BSP Version: L4T R32.6.1

docker/run.shを実行すると以下の画面が出てきます。


好みの？モデルを選択することができます。
選択後に自動でダウンロードされるため、あとは待つだけ。


モデルインストール後に以下のようにメッセージが出るため、他のモデルもインストールしたいな、というときにはこの通りにするといいらしい。

[jetson-inference] to run this tool again, use the following commands:

$ cd /tools
$ ./download-models.sh

あとはカメラモジュールでテストすればいいのですが・・・

２．カメラモジュール(OV5647)が認識しない

ラズパイで認識されたので、てっきりJetson Nano 2GBも認識すると思いましたが、
どうやらOV5647と呼ばれるカメラモジュール（Raspberry Pi Camera Rev 1.3）は認識されないようです。
does Jetson Nano support CSI camera with sensor ov5647? - Jetson Nano - NVIDIA Developer Forums

どうやらEOLとのことで正式にはサポートしていない模様。
一応ドライバインストールを自力で実施する方法はいかに記載されてますが・・・これを頑張るくらいであれば、素直にUSBカメラをつけたほうが良さそう。
自宅だったらUSBカメラがあるのでリアルタイムでのカメラ確認ができるけど、あいにくと実家なのが悔やまれる。
Omnivision Linux Drivers | OmniVision OV5647 Linux Driver for Jetson Nano | RidgeRun

とりあえず、サンプル動画で色々試してみることとし、カメラによるリアルタイム分析を利用するのはまた今度。

【Windows10/WindowsServer2019】PowerShellで日付ログローテート

１．前置き

Windows10/WindowsServer2019でログローテートをやる場合は、PowerShellで組んでしまうのが便利。
ここに記載しているのは日付での対応なので、ファイルサイズによるものは別のサイトへどうぞ。

２．ローテートプログラム

例えば1年に一回ログをローテーションするとした場合、
大まか流れとしては、ファイルを複製⇒複製したファイルのファイル名に昨年日付を付与⇒元のファイルは内容を削除、かつ作成日時も現在時刻に変更、という流れ。
元のファイルの内容を削除せずファイル丸ごと削除でもいいけど、それはログに書き込むプログラム側がログがないから作ろ！って作りになっていたらそれでも問題ない。
というわけでプログラム。
gist.github.com

一番最初の記述は、ログローテート自身のログ出力設定です(ややこしい)。
毎年ではなく毎月でやりたい、といった場合は、以下のように変数を作ってそれを使うようにします。

$sengetu = (Get-Date).AddMonths(-1).ToString("yyyyMM")

作成日が数年経っているログはもういらない、という場合、
例えば2年以上前の特定のフォルダ以下のファイルをまとめて削除する場合は、パスを指定する形でこのように記述。

Get-ChildItem -Path $Path_file_uploader -Recurse | Where-Object{$_.CreationTime -lt (Get-Date).AddYears(-2)} | Remove-Item -Force
G

このPowerShellファイルを先日取り上げたタスクスケジューラで毎年の1月1日や毎月1日に指定してあげれば、ログローテートの完成です。

【Windows10/WindowsServer2019】タスクスケジューラの設定

毎回忘れるのでメモ。

１．タスクスケジューラの設定

タスクスケジューラ画面の起動方法は二つ。
1つ目はデスクトップ左下の検索アイコンから「タスクスケジューラ」を検索する。
2つ目はナビゲーションウィンドウのPCアイコンを右クリックし、「管理」を押下。

タスクスケジューラライブラリを右クリックし、「タスクの作成」を押下。

１．１　[全般]の設定

名前は適当でもいい。が、作成した後に変更はできない。
変更する場合は、作成後にエクスポートを行い、それをインポートするときに名前を変える。
その後元々作成していたものは削除する形になる。

セキュリティオプションについて、サーバ運用の場合は
「ユーザーがログオンしているかどうかにかかわらず実行する」
を選択する。

１．２　[トリガー]の設定

スケジュール指定で起動させる場合は「スケジュールに従う」を選択。
該当日時に一回だけ動かすこともできるし、特定の曜日、月の特定の日だけとかなり自由に設定できる。

マシン起動と同時に動かすプログラムがある場合は、「スタートアップ時」を選択する。

１．３　[操作]の設定

動かすプログラムを指定する。

PythonがC直下にインストールされている場合、プログラムがprogram配下にある場合は以下のように設定。

プログラム/スクリプト：C:\Python\Python310\python.exe
引数の追加：test.py
開始 ：C:\program\test_py_program

プログラム/スクリプトはPythonのEXEファイルを指定する。
引数の追加は動かすPythonプログラムファイルだが、ここにパスは記述しない。
パスの記述は開始欄に設定する必要がある。(パスの最後に\は不要)

また、PowerShellで作成したps1ファイルの場合は、以下のように設定する。

プログラム/スクリプト：%Systemroot%\System32\WindowsPowerShell\v1.0\powershell.exe
引数の追加：-ExecutionPolicy Bypass .\test.ps1
開始 ：C:\program\test_ps_program

基本的にはpythonの時と同じだが、注意すべきは引数の追加の部分。
「-ExecutionPolicy Bypass」で実行ポリシーを設定している。
Bypassは一番強い権限となるため、基本的にはこれを設定すれば、どのps1も動く(はず)。
恒久的に変更する場合については以下のコマンドをPowerShellで実行する。
> PowerShell Set-ExecutionPolicy Bypass

詳しくはこちら↓
qiita.com

１．４　[設定]の設定

※[条件]の設定は適宜設定で、特に触れることがないので飛ばします。


[設定]も特に変更なくてもいけますが、サーバとして動かす場合は、「タスクを停止するまでの時間」のチェックは外しておいたほうがよいかと思われます。

【Ubuntu20.04】ConoHa VPSでSSHポートフォワーディング(リモートフォワード)を実現

１．前置き

MCPCのIoTシステム技術検定中級の受験も終わり（追記：無事受かりました）、前からやろうと思っていた、Alexa(Echo Flex)による自宅照明の操作を実現したくなったので、今回はその準備を行うことにしました。
　
Alexaから自宅照明をつけるには、まず自宅サーバを作る必要がある。サーバで用意しておいたAPIの受信をトリガにして、赤外線モジュールを利用するようにすればいい。
そこらへんは昔人感センサで作った時にもまとめたので、それの通りにやれば問題ない。
engetu21.hatenablog.com
　
で、Alexaの方は自作スキルをPythonで作成し（これは今度まとめる）、その自作スキルから用意した自宅サーバのAPIにHTTPを飛ばすようにしてあげればいい、となります。
→まとめました。
engetu21.hatenablog.com

　
で、自宅サーバの公開方法をあれこれと考え、結局採用しようと思ったのがVPSを経由したSSHポートフォワーディング(リモートフォワード)による接続。
今思うと、直接自宅サーバ公開したほうが手間なかったのでは？と思わなくないけど、ルータの設定が不要になるといった部分のメリットはある。
【追記】でも後述のようにVPSへのIPTABLES設定とかautosshとかが必要なので、手間はやっぱりかかった。

手軽にローカルサーバを簡単に展開するの手段として、ngrok(エングロック)がいいというのは調査して見つけたけど、どうも有料で利用しないとドメインころころ変わるみたいだし、だったらVPS借りてSSHポートフォワーディングできるようにしつつ、他の用途にも使えるようにした方がいいわ、となりました。
Alexaからのアクセス元IPアドレスが分かれば、それで接続元を絞り込むつもりだけど、そこは今後の調整。→どうやらIPアドレスはコロコロ変わるようなので、接続元を絞ることは不可能な模様。
　
SSHポートフォワーディングのイメージは以下の通り。

暫定の形として、インターネットに接続できるブラウザからConoHa VPSで提供されているホストかIPアドレス+ポート番号50001にアクセスする。
ConoHa VPSとラズパイ3は事前にSSHポートフォワーディングによるSSHトンネルができており、アクセスされた通信がラズパイ3のポート8080に転送される仕組み。
Alexaの自作スキルの準備が整えば、このブラウザ部分がEcho Flex(より正確にはその先のAlexaのサーバ)になる。
　
肝となるのは、ConoHa VPSとラズパイ3で事前にSSHトンネルを作っておくというところで、これはConoHa VPSにSSHサーバが入っている前提であり、かつファイアーウォール設定などを設けておく必要がある。というわけで設定内容を以下に記載。

２．ConoHa VPSでの設定

２．１　SSHサーバの設定変更

$ sudo vi /etc/ssh/sshd_config
#GatewayPorts no
↓
GatewayPorts yes

PasswordAuthentication yes
↓
PasswordAuthentication no

【追記：どうも時間が経つとSSHトンネリングが切れるので、以下の設定を追加しておく】
#ClientAliveInterval 0
↓
ClientAliveInterval 120

#ClientAliveCountMax 3
↓
ClientAliveCountMax 3

GatewayPortsは今回の対応でyesにするのが必須です。いくつかのサイトを参考にしましたが、これをちゃんと書いてるところが少なく、繋がらない原因がわからず時間がかかりました。バインド設定の変更(要するに転送を許可)するかどうか、の設定らしい。
パスワードの認証は不要とします。そもそも公開鍵認証で接続するため、わざわざパスフレーズを入れなくていい。

２．２　ポートの開放

ConoHa VPSでは、ポータルでいくつかのポート設定ができますが、今回の対応にてこれは使用しないように(全て許可に変更)します。
また、OSはUbuntu20.04を使用しているため、マシン側でIPTABLESを使ってIPパケットフィルタリングによる通信制御をします。
　
まずはIPTABLESの設定を永続化(再起動しても同一の設定を受け継ぎ)するように、iptables-persistentをインストールします。

$ sudo apt install iptables-persistent

　
インストール後、IPTABLESを構築するシェルスクリプトを作ります。
IPTABLESコマンドを逐次叩いてもいいけど、シェルスクリプトを作って一気に構築できるようにしておいた方がいいです。
昔からシェルスクリプトで作ってたので今回もそうしてますが、Pythonで作っても問題ない。

$ sudo vi iptables.sh
#! /bin/bash
echo "### iptables_sh起動 ###"

# $IPTABLESパス
IPTABLES='/sbin/iptables'

#自宅のIPアドレス or あるんだったらドメイン
zitaku='hogehoge.com'

# 最初にすべてのルールをクリア
$IPTABLES -F # テーブル初期化
$IPTABLES -Z # チェーンを削除
$IPTABLES -X # パケットカウンタ・バイトカウンタをクリア
$IPTABLES -t nat -F #natテーブルを指定と初期化

# 内部から外に接続した通信に対する、外部からの応答アクセスを許可 #
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# 自宅からの22番ポート(SSH)へのアクセスを許可 #
$IPTABLES -A INPUT -p tcp --dport 22 -s $zitaku -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 22 -d $zitaku -j ACCEPT

# 外部から50001番ポート接続許可 #
$IPTABLES -A INPUT -p tcp --dport 50001 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 50001 -j ACCEPT

# 設定ルール外のINPUT/FORWARDアクセスはログを記録して破棄。OUTPUTは基本的に許可 #
$IPTABLES -A INPUT -j LOG --log-prefix '[iptables INPUT DROP] '
$IPTABLES -A INPUT -j DROP
$IPTABLES -A FORWARD -j LOG --log-prefix '[iptables FORWARD DROP] '
$IPTABLES -A FORWARD -j DROP
#$IPTABLES -A OUTPUT -j LOG --log-prefix '[iptables OUTPUT DROP] '
$IPTABLES -A OUTPUT -j ACCEPT

# 設定の反映 #
sudo /sbin/iptables-save

# 設定の永続化 #
sudo /etc/init.d/netfilter-persistent save

echo "### すべての設定完了 ###"

　
作成後、パーミッションを変更し、実行

$ chmod 755 iptahles.sh
$ sudo ./iptahles.sh

設定の反映を確認

$ sudo iptables -nL

　
マシン側でパケットフィルタリングをしたため、ConoHa VPSの設定をポータルで変更します。
接続許可ポートを「全て許可」に変更。

　

３．ラズパイ3での設定

設定というか以下のSSHコマンドを打ちます。

$ sudo ssh -l hoge xxxxxxxxxxx.budb.static.cnode.io -p 22 -i conoha_ssh_key.pem -R 50001:127.0.0.1:8080 -T -N

それぞれのオプションについては以下の通りです。

-l hoge：ConoHa VPSに接続するSSHのユーザ名
xxxxxxxxxxx.budb.static.cnode.io：ConoHa VPSのドメイン名。IPアドレスは固定らしいので、そちらを指定してもいい
-p 22：ConoHa VPSに接続するSSHのポート番号
-i conoha_ssh_key.pem：ConoHa VPSに接続するSSHの公開鍵(VPSを作る際に作ったものを指定)
-T：仮想端末の割り当てを禁止
-N：リモートコマンドを無効 (-T -NがないとConoHa VPSにSSHログインする感じになるので、これを抑止)
-R 50001:localhost:8080：リモートフォワードの設定。ConoHa VPSでポート50001に来たものをlocalhost(自分)の8080ポートに転送する設定。

このコマンドによって、常にSSHトンネルがラズパイ3とConoHa VPS間で構築されていることになります。
動かしっぱなしにする場合は、screenを利用したり、Pythonプログラムでコマンドを実行するように作り、Pythonプログラムは自動起動にしておく必要があります。
　
　
【2022/07/05追記】

４．autosshとsystemdによる自動化

どうやら常時接続するためにautosshなるものがあるらしい。なんて便利な。
ただ、autosshを利用していても、そのプロセスそのものがお亡くなりになってしまうこともあるよう(指定した回数分再接続に失敗したりするとautosshは停止するらしい)で、autosshをsystemdで管理することで完全に自動にすることができる模様。
参考：autosshをサービス化してSSH接続を強化 - RemoteRoom

とりあえず、以下の順で準備していきます。

４．１　autosshのインストール

$ sudo apt update
$ sudo apt install autossh

４．２　systemdへの登録

以下のGitHubにあるソースを使います。
Systemd service for autossh · GitHub
　
以下のコマンドを打って、ファイルを取得すると共にファイルの格納も行います。
Githubでは「sudo tee /etc/default/autossh@example」となっていますが、ここは
「sudo tee /etc/default/host1」に変更して実行。

curl -sSL https://gist.githubusercontent.com/ttimasdf/ef739670ac5d627981c5695adf4c8f98/raw/autossh@host1 | \
sudo tee /etc/default/autossh@host1
curl -sSL https://gist.githubusercontent.com/ttimasdf/ef739670ac5d627981c5695adf4c8f98/raw/autossh@.service | \
sudo tee /etc/systemd/system/autossh@.service

/etc/systemd/system/autossh@.service
については、内容を変更する必要はなし。
　
/etc/default/autossh@host1については、以下のように中身を変更する。

$ sudo vi /etc/default/autossh@host1
　
以下の設定値を自分の環境に応じて変更。
TARGET_HOST=host1
FORWARDS=-R 50001:127.0.0.1:8080
　
※TARGET_HOSTは後述するsshのconfigファイルに設定するホスト名を指定します。
また、ポートフォワードは-L(と-g？)でもできるらしい？ですが、これはまぁ実施する(サーバの)場所によって異なるようなので、今回の場合は-Rに書き換えます。
詳しくはこちら。
混乱しがちな「SSHトンネルの確立方法」をイメージ図とセットでまとめたコマンド集 - GIGAZINE

４．３　SSHポートフォワーディング用のユーザを作成

GitHubの手順に則って以下のように実行します。

$ sudo useradd -g nogroup -s /bin/false -m tunnel
$ sudo -u tunnel mkdir -p ~tunnel/.ssh

４．４　ssh-cofigファイルの作成

最近のSSHでは、configファイルを作って、その中に接続先などを記載して楽できるらしい。autosshを実行するためにも必要なので作成します。

$ sudo -u tunnel vi ~tunnel/.ssh/config

Host host1
    HostName xxxxxxxxxxx.budb.static.cnode.io
    User hoge 
    Port 22
    IdentityFile ~tunnel/.ssh/conoha_ssh_key.pem

※Host行で設定した名称(ここではhost1)がsshコマンドの際に指定するホスト名になります。
※IdentityFile で秘密鍵ファイルを指定

秘密鍵については、権限を600にしておかないとパーミッションエラーになるので注意。

$ sudo chmod 600 ~tunnel/.ssh/conoha_ssh_key.pem

４．５　あらかじめsshログインを行う

known_hostsファイルが作られていないといけないので、手動で初回SSH公開鍵認証を行います。ちゃんと接続できるかの確認も含め、いずれにせよ実施は必須。

$ sudo -u tunnel ssh host1

※yesかnoを聞かれるのでyes

４．６　systemdにてautossh実行

/etc/default/autossh@host1
の名称でファイルを作ったため、今回は以下のように実行します。
startで実行。enableで永続化です。

$sudo systemctl enable autossh@host1.service
$sudo systemctl start autossh@host1.service
● autossh@host1.service - Keeps an ssh tunnel to host1 open
Loaded: loaded (/etc/systemd/system/autossh@.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-07-05 23:59:28 JST; 10min ago
Main PID: 9721 (autossh)
Tasks: 2 (limit: 2059)
CGroup: /system.slice/system-autossh.slice/autossh@host1.service
tq9721 /usr/lib/autossh/autossh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=10 -o ServerAliveCountMax=3 host1 -R 50001:127.0.0.1:8080
mq9724 /usr/bin/ssh -NT -o ExitOnForwardFailure=yes -o ServerAliveInterval=10 -o ServerAliveCountMax=3 -R 50001:127.0.0.1:8080 host1

7月 05 23:59:28 raspberrypi systemd[1]: Started Keeps an ssh tunnel to host1 open.
7月 05 23:59:28 raspberrypi autossh[9721]: port set to 0, monitoring disabled
7月 05 23:59:28 raspberrypi autossh[9721]: starting ssh (count 1)
7月 05 23:59:28 raspberrypi autossh[9721]: ssh child pid is 9724

【Python】CSVのデータをPostgreSQLに格納

CSVのデータをそのままポスグレに設定する場合は、以下のようにPythonファイルを作ります。
PythonファイルからSQLファイルを実行させて、SQLファイル側でCSVファイル内をコピー→INSERTする形になる。
一度tmpテーブルを作成し、それにコピーする形になるのが肝。
これによって、例えばCSVファイルのデータだけでは足りない情報（テーブルへの登録日時や更新日時）を後から追加することができる。後述のSQLファイルではINSERTにて末尾に登録日時と更新日時を追加しています。
　
Pythonで一度取り込んでINSERTする形をとってもいいけど、psqlコマンドでSQLを実行する形にしておいたほうが、呼び出す側がどんな言語を使っていてもSQLの内容に影響を与えない(疎結合)の形になる、というメリットはあるかと。
まぁそこらへんは好みの問題。あと性能的な側面では考慮していないので、悪しからず。
　
ちなみに、Windowsで実行する場合、psqlを実行するのにパスワード入力を省略させるために以下の場所にpasswordファイルを作って格納しておく必要がある。ファイル名は「pgpass.conf」で固定です。
C:\Users\<ユーザ名>\AppData\Roaming\postgresql\pgpass.conf

<host名 or IPアドレス>:<ポート番号>:<DB名>:<ユーザ名>:<パスワード>
例：yyy.yyy.yyy.yyy:5432:postgres:postgres:password

Linuxの場合は、psqlを実行できるユーザでpythonを実行すればパスワードを要求されることはない。
　
【Pythonファイル】
gist.github.com
psqlの -vで変数を設定できます。文中の「file_name=」はSQLファイルに渡す変数です。SQLファイルのほうでは「:file_name」と記述することで渡された変数の中身を参照できます。
　
【SQLファイル】
gist.github.com
変数の指定は「:XXX」の形で書けば勝手に参照してくれます。シングルクォーテーションはいちいちエスケープ文字書くのが面倒なので変数で用意し、それを結合で利用してます。結合に特に＋とかは不要。続けて書くだけ。

なんでcopyコマンドを変数に入れてから実行する形にしてるの？というと、
まず前提として、copyコマンドには「copy」コマンドと「\copy」コマンドがある。(SQLファイル上、\\copyとなっているが、これはエスケープ処理の都合上こうなる)
前者の「copy」は、ポスグレが入っているマシンのローカルディスクのファイル(今回はCSVファイル)を指定することになる。
なのでポスグレが入っているマシンでSQLファイルを実行する場合は「copy」を使えばいい。
問題はアプリ層とデータベース層が分かれているシステムの場合で(まぁ普通はこの構成なんだけど)、
特にAWS Auroraを利用していた場合などは、Aurora内にSQLファイルやCSVファイルを置いておく、ということはできないので「copy」は使えない。
なのでその場合は後者の「\copy」を使う。これはSQLファイルを実行したマシンのディスクにあるファイル(CSVファイル)を指定することになる。
ただ厄介なのが、「copy」コマンドはSQLファイルに直書きしても動いてくれるが、「\copy」のほうはエスケープ文字の関係上、書けば簡単に動いてくれるわけではない。で、そこら辺を調べてると、海外の掲示板でコマンドをあらかじめ変数に入れて用意しとけばいいんだよ、との書き込みがあったのでその通りにしている、という感じになります。
　
SQLファイルのパスの指定はどちらかのプログラムファイルに寄せたほうがいいんだろうけど、まぁとりあえずこれで。

NVIDIA Jetson Nano 2GBのセットアップ

NVIDIA Jetson Nano 2GBをAmazonで買いました。

まぁGPUパススルーでCUDA環境を整えるのは前にやってるし、GoogleColaboratoryもあるんですが、
せっかくだし！
あと普通にラズパイの代わりにも使えそうなので、IoTデバイスを付けて運用してもいいし、何ならGPUでゴリゴリ動画エンコードさせてもいい。
まぁとにかくセットアップします。

１．OSイメージのダウンロード

以下サイトからイメージファイルをダウンロードします。
Getting Started with Jetson Nano 2GB Developer Kit | NVIDIA Developer

Windowsで書き込む場合の直リンクはこれ
https://developer.nvidia.com/jetson-nano-2gb-sd-card-image
6.1GBあるので気長に待ちます。

DLしたzipファイルを解凍すると、sd-blob.imgというファイルがあるので、
それをSDカードに書き込みます。
ガイドではEtcherというアプリを使っていますが、私はRufusというアプリを使ってるのでそれでやります。

書き込み完了後にSDカードを抜いて、Jetson Nanoへ。

特に問題なく起動しましたね。
OSはLubuntuなので、動作は軽いです。ただし日本語にはなってないので、別途対応は必要。
まぁ普通にラズパイですね、これは。
しかし、ただ動かしているだけでヒートシンクはかなり熱くなるため、小型でもいいのでやはりファンは必要ですね。