3 ポイント 投稿者 GN⁺ 2024-01-04 | 1件のコメント | WhatsAppで共有
  • スマートフレームを自作する際に必要なレンダリング・デプロイ・ディスプレイ制御を デバイス内実行 を中心にまとめ、Raspberry Pi または ESP32 ベースのフレームを独立して運用できるようにする
  • バックエンドは Docker または Home Assistant アドオン としてローカルにインストールし、SSH または書き込み済み SD カードでデプロイした後は、フレームはバックエンドなしでも動作を継続する
  • シーンはイベント・データアプリ・レンダーアプリ・状態をつなぐ ノードグラフ で作成し、成果物は単一バイナリにコンパイルされてフレーム上で実行される
  • Raspberry Pi は Pi Zero 2 W 以上で WiFi デプロイ、TrueType フォント、SVG、6色 e-ink ディザリング、TLS、iCal パース、headless Chromium スクリーンショット、独自 Web サーバーをサポートする
  • ESP32-S3 は Waveshare SPI e-paper パネル向けに、ブラウザからのフラッシュ、デバイス内レンダリング、OTA アップデート、リフレッシュ間の deep sleep をサポートするが、ファームウェアイメージには選択したパネルドライバー 1 つだけが含まれる

FrameOSの役割

  • FrameOS は Raspberry Pi または ESP32 とディスプレイを組み合わせ、カレンダー、ダッシュボード、アートフレームのように自律動作するスマートフレームを作るためのオペレーティングシステム
  • e-ink、HDMI、LCD ディスプレイを対象とし、レンダリングは デバイス内 で処理される
  • クラウドやサブスクリプションなしで動作し、2023年から AGPL-3.0 ライセンスの無料オープンソースとして提供されている
  • バックエンドは Docker でインストールでき、プロジェクトのリポジトリは GitHub にある

インストールとデプロイの流れ

  • FrameOS は、バックエンドのインストール、ハードウェア接続、シーンのデプロイという流れでフレームを構成する
    • バックエンドをノートPC、サーバー、NAS 上で 1 つのコマンドで実行するか、Home Assistant アドオンとしてインストールする
    • Raspberry Pi または ESP32 をディスプレイに接続する
    • あらかじめ用意されたシーンを選ぶか自分で設計してからデプロイする
  • バックエンドはサブスクリプション型サービスではなく、ローカル Web アプリ として動作する
  • デプロイは SSH または書き込み済み SD カードを通じて行われ、その後フレームはバックエンドなしでも独立して実行可能
  • ディスプレイは 120種類以上の対応パネル を接続でき、Raspberry Pi では HDMI ケーブルも利用できる
  • フレームは独自の QR コードと HTTP API で制御され、ESP32 の HTTP API はまだ実験的段階

シーン編集と実行方式

  • シーンは実際のコードに支えられた ビジュアルエディター で構成される
  • シーン構成はノードグラフの形に分かれる
    • 赤: イベント
    • 緑: データアプリ
    • 青: レンダーアプリ
    • 黄: 状態
  • 構成したシーンは 単一バイナリ にコンパイルされ、フレーム上で実行される
  • キュレーション済みのギャラリー、カレンダー、予定表、メッセージボード、天気、ウェブカメラ、AI アートのシーンをワンクリックでインストールでき、ソースレベルまで編集可能

Raspberry Pi と ESP32 の選択肢

  • FrameOS は実際の Linux 環境で最もよく動作し、$15 Pi Zero 2 W 以上の Raspberry Pi を対象としている
  • Raspberry Pi 環境では、ファームウェアを再フラッシュせずに WiFi でデプロイできる
  • Linux ベースのフレームでは次の機能を利用できる
    • あらゆる解像度の TrueType フォントと SVG
    • 6色 e-ink 向けディザリング
    • TLS
    • iCal パース
    • headless Chromium スクリーンショット
    • フレーム自体の Web サーバー
  • ケーブルのないフレームを求める場合は、ESP32-S3 上で Waveshare SPI e-paper パネル向けに実行できる
  • ESP32-S3 構成は、ブラウザからのフラッシュ、デバイス内でのシーンレンダリング、OTA アップデート、リフレッシュ間の deep sleep によるバッテリー駆動をサポートする
  • 各 ESP32 ファームウェアイメージには、選択したパネルドライバー 1 つが含まれる

ケース作成と完成例

  • FrameOS Case Maker は、対応パネルと Raspberry Pi レイアウトに合わせたパラメトリックな 3D プリント用エンクロージャを生成する
  • ユーザーはテンプレートを選び、奥行きとベゼルを調整した後、壁掛け、キックスタンド、USB-C カットアウト、ネジ柱を追加して STL をダウンロードできる
  • Case Maker はドキュメントと同じハードウェアデータベースを使用し、Waveshare と Pimoroni 構成の基本寸法を提供する
  • Case Maker は Open Case Maker で利用できる
  • 完成例では、Waveshare と Pimoroni Spectra 6 パネル、3D プリントのスリムケース、USB-C 電源、FrameOS ソフトウェア設定を一体で示している

1件のコメント

 
GN⁺ 2024-01-04
Hacker Newsのコメント
  • 面白い小さなプロジェクト。2年前にプレゼント用に7色eInkのArduinoフォトフレームを作ったけれど、画面でそこそこ見えるようにするには、画像を自分で切り抜き、ディザリングし、カラーパレットを合わせる必要があったのが一番大変だった
    FrameOSがこれを代わりに処理してくれていたら、手作業の編集とテストにかかった時間を何時間も節約できたと思う
    結局今年は、リモートで写真を追加するのがあまりにつらくて、同じ相手にAuraのフォトフレームを買ってあげた

    • ImageMagickなら、制限されたパレット向けに画像を一括処理できる。全部を手作業でやる必要はなかった
    • 誰にも画像を自分で切り抜いたり、ディザリングしたり、カラーインデックス化したりさせたくない。これはFrameOSソフトウェアが処理すべき部分
      Inky Impressionの7色フレームのようなものを使えばすでに動作するが、多くの場合、そのソフトウェアとドライバーがこの処理をすでにやってくれるから
  • これは医療用キオスク、デジタルアート、サイネージに大きく役立つ可能性がある
    病院でのデジタルアート需要はかなり大きい。私はSFGH、UCSFのテクノロジー設計者で、El Camino Hospitalの技術実装マネージャー、Vizio TVのオペレーションディレクターも務めた
    こうしたシステムや病院の案内システムを評価・購入・設置してきたし、エレベーターロビーや病室の画面でループ再生するデジタルアートに数十万ドルを使ったこともあるが、ソフトウェアはひどいものだった
    El Camino Hospitalのロビーでは、デジタルサイネージシステムがあまりにひどく、一部の機器をMac Miniに置き換えてVLCでMP4をループ再生させる必要があった
    だからPi Zeroと一緒にこういうシステムを使うのはよさそうだ
    ただ、案内表示もこれでスマートに実装できる気がする。「インタラクティブ」というのが、Pi上でWebアプリ/アプリを表示し、アイドル時にはデジタルアートのループ再生に戻れるという意味だといい
    デジタルアート・サイネージ・案内表示の市場には、この市場を揺さぶる大胆な新興プロジェクトが必要だ。今Piが手元にあったらすぐ試していたと思う
    T-Mobileでもらった安っぽいAndroidのTCLタブレットにもインストールできるのか気になる。Feit Electricの電球制御も見てみるとよさそう
    こうしたデバイス/OSで最も収益性の高い選択肢は、BARTのような地域交通の交通案内サイネージだと思う。組織内で一番テクノロジーに弱い人でも、設置・設定・表示をミスなくできるようにすればいい
    Sacramento地域交通には画面がたくさんあるのに、有用な情報はほとんどない
    APACの列車に乗ると、上の壁に運行状況マップが表示されるLCD画面がある。米国の列車に乗ると、上の壁には小便と大便はあるが、運行状況マップはどこにもない

    • 米国の列車に画面を設置したら、結局その画面にも小便と大便が付くと思う
    • MP3ファイルを再生するためにMac Miniを設置するのは、あまりにも金の無駄。10ドルのとても安い携帯MP3プレーヤーを使えばいい
      米国ではこうやって金が無駄にされている一方で、路上では食べ物を物乞いしている人たちがいるというのは、正気の沙汰とは思えない
    • BrightSignをどう見ているのか気になる。標準ソフトウェアはかなり微妙だが、プログラム可能性は私たちにとって非常に良かった。まだ深く掘り下げている段階ではない
  • Chumbyを思い出す。潜在力は本当に大きかったのに、あまりにも早く見捨てられた製品だった
    家の中には、賢くて制御でき、ローコードで扱える画面の使いどころがたくさんあるのに、自分で調べる時間がほとんどない。今日このプロジェクトを見られて本当にうれしい

    • 既製品のeInkカレンダーを作っている。自分でコンテンツを開発したあと、Web URLから.png.jpegとして画面に提供することもできる
      https://shop.invisible-computers.com
    • 私も自分で調べる時間がないので、単に中古iPadを買って壁に取り付けるつもり
      明るい画面が手に入るし、見たいものはWebブラウザで表示できさえすればいい
  • 本当に素晴らしい。昨年、Gmail経由でe-ink画像を交換するスクリプト群を作ってDispatchPiと名付けたが、こういうプログラムがあれば開発がずっと早くなっていたと思う
    https://github.com/malcolmosh/dispatchPi/blob/main/README.md
    いつもターミナルからPiにSSH接続し、FileZillaのFTPクライアントとVSCodeでスクリプトを更新しなければならず、かなり面倒だった
    さっきダッシュボードプロジェクトも完成したので近く公開するつもりで、フレームのドライバーをESP32に替えてバッテリー駆動にしようかとも考えている。ESP32はPi Zeroよりも消費電力がはるかに少ないからだ
    時間があるなら、ESP32互換性に一票入れたい

    • ESP32開発をどの程度まで進めているのか気になる。画像レンダリングは予想より簡単ではなかった。私の場合、ディスプレイはeInkではなくLCDだった
      任意の画像をESPライブラリで表示しようとするより、ESP32/ディスプレイへ送る前に、画像を特定のサイズと形式に合わせておくほうが簡単で安定していた
    • どんなハードウェアを使っているのか気になる。最近似たプロジェクトを終え、e-inkをもっと試したいのだが、Piに挿すハードウェアのドライバーボードがe-inkディスプレイと同じくらい高い
  • ページの最初の画像はエディタなのですが、いや本当にすごいです。説明の中にこんな部分があります。
    “Diagram Editor: Nimアプリをシーンとして組み合わせるドラッグ&ドロップインターフェイス。‘OpenAI image’や‘Text overlay’のような既存アプリをフォークして修正し、用途に合わせられる。すべてのフィールドはインラインコード片で上書きできる。”
    本当に洗練されて見えます。ものすごい作業量が入っていそうです。何で作られているのか気になりますし、エディタもNimで書かれているのかも気になります。
    シーンを作成した後に何を実行するのかも気になります。エディタに似ているがプレゼンテーションモードのあるランタイムを動かすのか、それとも別のNimプログラム群を実行する新しいNimプログラムを吐き出すのか分かりません。
    アプリは1回ずつ呼び出されるのか、それとも常時実行されて永続的に通信するのかも気になります。フレームの開始は何がトリガーし、合成はどう行われるのかも気になります。
    スマートフレームに使われているだけで、実際にはとてもクールな汎用フローベースプログラミングシステムを作ったように感じます。

    • フィードバックありがとう。
      エディタ/コントローラ自体はReact+Keaアプリで、ダイアグラム部分はReact Flowを使い、バックエンドはFlaskです。
      今は作ったアプリが動くかテストするにはフレームにデプロイする必要があります。テスト用に高速なRPi 5を使うとフィードバックループは通常約30秒で、Zero W2は約1分、Zero Wは約2分です。理想的ではないので改善したいです。
      理想的には、NimのJSバックエンドを使って、ブラウザ上でそのまま実行できる「フレーム」を作ってテストしたいです。
      他の質問に答えると、FrameOSシステムは起動時に実行され、すべてのアプリは1つのバイナリにコンパイルされて、シーンの指示どおりに実行されます。レンダーイベントが渡されると新しいフレームがレンダリングされ、このイベントは周期的に自動発生させることも、要求に応じて発生させることもできます。
      フレームはログをコントローラに送りますが、それ以外は完全に独立して動作できます。
    • スクリーンショットだけ見るとdear imguiのようです。ここで似たウィジェットを見られます: https://github.com/TimoSalomaki/awesome-dear-imgui
      訂正: 間違っていて、実際にはReact Flowです。
      https://github.com/FrameOS/frameos/blob/037af53e94a3b47ce5df...
      https://reactflow.dev/
  • 本当に興味深そうです。これは実際にはOSではなく、PiのOS上で動くソフトウェアと理解すればよいのでしょうか。

    • 技術的にはその通りです。最良の意味でその通りでもありますが、この質問には少しニュアンスがあります。
      FrameOSはLinux上で実行されるコンパイル済みバイナリです。現時点ではFrameOS自体をインストールする前に、SDカードへデスクトップ環境なしの「Raspberry Pi OS Lite」をインストールする必要があります。なので「ただのアプリケーション」と見ることもできます。
      ただし、これはプロジェクト初期で最速に始める方法だったからです。次の段階は、どこまで削れるかを見ることです。FrameOSは静的にコンパイルされた単一バイナリなので、Linuxカーネル以外にはあまり多くを必要としないかもしれません。そうだとしたら本物のOSになるのでしょうか。AndroidもLinuxカーネルを使っていますが、独自のOSと見なされています。
      有効化されるとFrameOSはシステム全体を掌握し、独自のapps/drivers/フォルダを持ち、多くの面ですでにオペレーティングシステムのように動作します。ESP32で動かすことも考えていて、drivers/wifi/を追加する必要があるかもしれません。下にどんなOSもなく動作するなら、その時はOSと呼んでよいのでしょうか。それは皆さんに判断してもらえればと思います。
      これがオペレーティングシステムかと聞かれれば、私にとってはそうですが、別の見方をしても構いません。
      実際の職場であるPostHogでは、時々自分たちを「Product OS」と呼ぶのですが、こちらのほうがもっと気に障ります。Webアプリの集合は、伝統的な意味でのオペレーティングシステムでは明らかにないからです。純粋なOSではないものの末尾に-OSが付くのも見たことがあります。少し気に障りますが、主に「何のOSを使っていますか?」がアイデンティティを分ける質問だった時代を生きてきたからでしょう。
      言葉は変わっていて、「オペレーティングシステム」は今や、私やあなたが考えるよりも人によってもっと多くのものを指すようです。
    • そう見えます。だとすると、他のボードでも小さな修正だけで動く可能性が高いです。
    • その通りです。リモート制御可能な全画面アプリケーションに近く見えます。
    • OSとは何なのか、本当に気になります。皮肉ではありません。「OS」は今ではかなり緩く定義された用語です。AndroidとUbuntuはほぼ同じカーネルを使っていますが、明らかに非常に異なるオペレーティングシステムです。
      FrameOSはNimを使っているので、カーネルなしのベアメタルで実行されるよう移植できます。非同期ディスパッチのおかげで、Nimは軽量な協調的マルチタスクも提供します。
      FrameOSは現在Linuxカーネル上でのみ実行されるOS、あるいは望むならユーザー空間と見なせます。しかし、マイクロコントローラ上で直接実行されるよう移植できない理由はありません。
  • かっこよさそう。Home Assistant と一緒に e-ink ディスプレイを設定したいと思っていたので、これを試してみるつもり
    「Why FrameOS」の記事には、Home Assistant のダッシュボードを表示している e-ink ディスプレイのように見える写真があり、その下に「しかしソフトウェア側はめちゃくちゃだった」と書かれている。FrameOS を作る前に具体的にどんな問題があったのか気になる。少なくとも写真ではうまく動いているように見える
    この文言が実際に何を意味するのかも気になる: 「GPT4 Support: お気に入りの LLM に FrameOS アプリの作成とデバッグを頼みましょう。」

    • 作者が FrameOS のカスタムビュー作成用 アプリビルダーに GPT-4 を統合し、基盤コードの改善を GPT に依頼できるようにしたもの。https://frameos.net/blog/gpt4-support
      これを見た瞬間、今後の新しいアプリは最初から LLM 統合を含める流れになるのだと感じた。やらない理由がないのでは。LLM を適切に使えば、ほぼすべてのアプリでユーザー体験を大きく改善できる
    • ChatGPT については、追加の統合が不要な製品であることを強調する気の利いた冗談のように見える
      最近のプライベートエクイティ市場で売れ筋の、ブロックチェーンベースの自動運転ソーシャル AI クラウドみたいなものを作る必要はない、という類いの冗談
  • 古い Amazon Fire タブレットを電子廃棄物にしないで済む良い代替策はあるだろうか?Android ベースのもの

    • Fire Toolbox で不要なプリインストールアプリをすべて無効化すればいい。Fully Kiosk のライセンスを買えば、いろいろ実用的な用途に転用できる
      個人的には、家の中で Amazon Fire タブレットを Snapcast 用のオーディオドライバーとして使っている。各タブレットには USB、Wi-Fi、3.5mm Aux、内蔵バッテリーがあるのでこの用途にはかなりよく、セール時には1台45ドルなので特にいい
    • そこで何が問題なのか気になる。普通に任意の Android アプリをインストールして表示できるのでは?
    • ブートローダーがロックされている。記憶が正しければ、2015年モデルが一部のピンをショートさせるバグでロック解除できた最後のモデルだった
      ロック解除されたブートローダーがなければ、Android の root 化はできるかもしれないが、Android や ROM 自体を置き換えることはできない
      いずれにせよ大した意味はない。MediaTek なので、当時のパーティション構成やドライバーモデルはだいたいひどいものだ。そのハードウェア上で FrameOS を合理的かつきれいに動かすのは難しいだろう
  • 本当に素晴らしい。似たものを再現しようとするプロジェクトは多いが、特に制作面でここまで 完成度があるものはほとんどない
    個人的には InkPlate シリーズのような、ESP32 内蔵の低消費電力 eINK デバイスをサポートしてくれるとうれしい。それでもこれを見ると、Pi に乗り換えてみようかと思ってしまう

    • FrameOS が ESP32 をサポートしてくれるといい。2日前までは FrameOS は遅く、インタプリタで実行される Python アプリだった。今日は 3MB の静的リンクバイナリになっている
      余裕はかなり厳しく、おそらくスレッド処理のような一部機能は削る必要があるだろうが、理論上は実行可能なはず
      ただし Raspberry 版を優れたものにするためにまだやることが多いので、当面この作業を引き受ける予定はない
  • この分野にソフトウェアがもっと出てくるのは歓迎
    間接的に関連する話だが、写真フレームとして使える 32インチ以上の画面を探している。Samsung The Frame 以外に製品を見つけられていないのが、この単純なユースケースにしては驚き
    これまで見つけたのはこの程度。TV やモニターは24時間つけっぱなしにするには消費電力がよくない。カラー e-ink は通常最大13インチ程度。Samsung The Frame は機能と外観は良いが高価で、さらに Samsung であるという欠点がある
    おすすめできる製品があるか気になる

    • 専用の額縁デバイスが一般的な TV ディスプレイよりどうやって電力を節約できるのか気になる。結局は同じ 基本部品に行き着くのではないか?