Linuxを動かすMPU(Qualcomm Dragonwing™ QRB2210)と、リアルタイム制御向けMCU(STM32U585 / Arm Cortex-M33)が同居したボード「Arduino UNO Q」が発表されたので、GPT 5 Thinkingを使って調査した。


( https://store.arduino.cc/products/uno-q )
(注)本記事の内容は正確性を保証するものではない。
Arduino UNO Q とは
概要
- “デュアル脳”構成:Linuxを動かすMPU(Qualcomm Dragonwing™ QRB2210)と、リアルタイム制御向けMCU(STM32U585 / Arm Cortex-M33)を1枚に同居。
AI・映像・ネットワーク処理はMPU、入出力の厳密なタイミングはMCUが担当。
両者はBridge(RPC)で連携します。(arduino.cc) - App Labに最適化:UNO QはArduino App Labの“推奨ボード”。
App LabではPython(MPU側)とC++スケッチ(MCU側)、さらにBricks(AI/DB/Web等のモジュール)をまとめて「アプリ」として開発・実行できます。(docs.arduino.cc) - SBCモード対応:キーボード・ディスプレイを接続してシングルボードコンピュータ(SBC)として単体運用可。
初期設定後はネットワーク経由の開発も可能。(docs.arduino.cc)

Power Delivery 対応のUSB-Cパススルー充電ポートを備えたUSB-C – HDMIマルチポートアダプターを介して給電
主なスペック(抜粋)
- MPU:Qualcomm Dragonwing™ QRB2210(4コアCPU、GPU/ISP内蔵)
RAM:2GB LPDDR4、ストレージ:16GB eMMC(SD不要)
無線:Wi-Fi 5(2.4/5GHz)、Bluetooth 5.1
映像/音声/ディスプレイ:高速ヘッダで周辺機器を接続可能。(Arduino Online Shop) - MCU:STM32U585(Cortex-M33 最大160MHz、FPU、2MB Flash / 786KB SRAM)
I/O:UNO互換ヘッダに加え拡張ヘッダ、5Vトレラントの3.3V系。(DigiKey) - 電源:VIN 7–24V(3系統レールの電源設計解説あり)。(docs.arduino.cc)
- フィードバック:8×13 LEDマトリクスをオンボード搭載。(Arduino Online Shop)
開発フロー(ざっくり)
- App Labでプロジェクト作成(
main.pyとsketch.inoが基本) - 必要なBricks(カメラ/モデル/DB/Web UIなど)を追加
- Bridge/RPCで「Python側の推論結果 → MCU制御」「MCU計測 → Pythonで保存/可視化」をやり取り
- CLIやGUIからアプリ単位で起動・停止・ログ確認。(docs.arduino.cc)
何ができる?(代表ユースケース)
- AIカメラ+アクチュエータ制御:MPUで推論→MCUのGPIO/PWM/モータへ即時反映。(docs.arduino.cc)
- 大量センサのロギング&Web可視化:MCUで精密サンプリング→MPUでDB保存・Web配信。(docs.arduino.cc)

- スタンドアロン端末:SBCモードでディスプレイ表示やローカルUIを完結。(docs.arduino.cc)
公式ドキュメント/リソース
- 製品ページ(概要・FAQ)と技術資料(データシート、チュートリアル、App Lab入門)。(arduino.cc)
- RouterBridge(Arduino_RouterBridge):UNO Q向けのRPCブリッジ公式ライブラリ。(arduinolibraries.info)
最近のニュース(背景)
- 2025年10月7日:QualcommがArduino買収を発表。UNO Q/ App Labを軸にエッジAI開発の加速を打ち出し。
詳細は各報道・公式発表を参照。(Reuters)
UNO Qを PCに接続して使うか、SBCモードで使うか
UNO Qを「PC接続で使う場合」と「SBCモードで使う場合」を、目的・必要物・初期セットアップ・典型ワークフローの順でコンパクトに整理します。
(追記)
ここで言う「PC」は、Windows、macOS、Linux のOSをインストールしたコンピュータのこと。
1) PC接続(PC-Connected / Network運用)
目的
- 手元PCの画面・キーボードを使い、App LabをPC側で起動してUNO Q上のアプリ(Python+Sketch)を実行・管理。
必要に応じてArduino IDE 2でMCUだけ書き込む運用にも向く。(arduino.cc)
必要なもの
- USB-C(データ対応)ケーブルでUNO QとPCを接続
- PCにArduino App Lab(Win/Mac/Linux対応)をインストール。(arduino.cc)
初期セットアップ
- PCにApp Labを入れる → UNO QをUSB-Cで接続。
- App LabからUNO Qを検出し、サンプルAppを起動(AI/WEB/DBなどはBricksで追加)。
- (必要に応じて)Arduino IDE 2やArduino CLIでMCU(STM32U585)側のスケッチをビルド/書き込み。(docs.arduino.cc)
ワークフロー例
- App Lab(PC)でAppを作成 → UNO Q上で実行 → ログ・Web UIをPCから確認。
- Networkモードに切り替えれば、LAN越しにApp LabからUNO Qへ接続・管理も可能。(arduino.cc)
向いているケース
- 普段のデスク環境(PC主体)で素早い反復開発。
- 現場ではLAN経由でリモート運用したい。(arduino.cc)
2) SBCモード(スタンドアロン)
目的
- UNO Qを“単体PC(SBC)”として使う。
ボードにディスプレイ/キーボード/マウスをつなぎ、App Lab(ボード内にプリインストール)をそのまま起動して開発・実行。(docs.arduino.cc)
必要なもの
- 電源(USB-CやVIN)
- HDMI/DSI等の表示出力+USBまたは無線キーボード/マウス(キャリアやUSB-Cドック経由でも可)。(docs.arduino.cc)
(補足)
USB-Cドック:Power Delivery 対応のUSB-Cパススルー充電ポートを備えたUSB-C – HDMIマルチポートアダプターなど。ただし、UNO Qに対応している機種かどうかは確認が必要な模様。
初期セットアップ
- SBCチュートリアルに沿って初期設定(言語/ネットワーク等)。
- UNO Q上のApp Labを起動(自動更新にも対応)。
- 端末(ターミナル)からApp Lab CLIでアプリの起動/停止/ログ監視も可能。(docs.arduino.cc)
ワークフロー例
- ボード上のApp LabでAppを作成→実行→オンボードでWeb配信/DB保存まで完結。
必要ならLANに載せ、他端末からWeb UI/RESTで参照。(docs.arduino.cc)
向いているケース
- ラボ外やフィールドでPCなしのスタンドアロン運用。
- デモ端末/組込み装置として“1枚完結”で動かしたい。(docs.arduino.cc)
どっちを選べばいい?
- PC中心で素早く反復 → PC接続(USB-C、必要ならLAN越し“Network”)。(arduino.cc)
- 現場・展示で単体稼働 → SBCモード(App Labはボードにプリイン)。(docs.arduino.cc)
補足:どちらのモードでも、Linux側(MPU)とMCUはBridge(RPC)で連携します。
AI推論・Web/DBはLinux側、I/OはMCU側、という役割分担は共通です。(docs.arduino.cc)
(追記)
次の「Arduino UNO Q の構造」の項で、Arduino Uno Qに実装された部品について、基板両面の画像に基づいた回答をGPT 5 Thinkingからもらっているが、推定している部分があるので、正確には下記リンクの正式なユーザーマニュアルを参照ください。
公式の User Manual はこちら:Arduino UNO Q – User Manual(公式ドキュメント) (docs.arduino.cc)
あわせて使うと便利な公式資料も載せておきます:
・データシート(PDF) (docs.arduino.cc)
・フル・ピンアウト(PDF) (docs.arduino.cc)
・回路図(PDF) (docs.arduino.cc)
・ハードウェア概要ページ(UNO Q トップ) (docs.arduino.cc)
Arduino UNO Q の構造
表面側に実装されている部品
画像(図1)から読み取れる範囲で、UNO Q 上面の主な実装部品と役割を“ざっくり見取り図”として説明します。
(刻印やシルク印刷に基づく同定/一部は一般的な配置からの推定を含みます)
主要ブロックと役割
- A. USB Type-C(左端)
電源供給・データ通信用。SBCモード時のセットアップやファーム更新でも使用。 - B. UNO互換ヘッダ(上辺・下辺の黒いピンソケット列)
5Vトレラントの3.3V系I/O(UNO互換ピン配置)。センサやシールドを接続。 - C. 無線モジュール(左下:白いラベル “WCBN3536A”等の印字)
Wi-Fi / Bluetooth の無線通信モジュール。エッジAI+Web配信やMQTTなどの無線通信を担当。 - D. 大型チップ “Qualcomm QRB2210”(中央やや右)
MPU(Linuxを走らせるSoC)。カメラ入力・画像/音声のAI推論・Webサーバ・DB など“重い処理”を受け持つ心臓部。 - E. 大型パッケージ(QRB2210の上側に隣接)
LPDDR4メモリ(および近傍にeMMC)の実装域がこのエリアに集約されます(外観・位置関係からの推定)。 - F. “Qualcomm PM4125” 付近(右上小〜中サイズのIC群)
PMIC(電源管理)。複数電源レールの生成・監視、SoCの電力制御。 - G. “STM”“QRB”“JSPI”等の小ピンヘッダ(右側の縦並びや上辺)
それぞれ MCU/MPU側のデバッグ・プログラミング/拡張用の端子群(JTAG/SWD/シリアル/QSPIなど、用途別ヘッダ)。 - H. ロゴ付近の“UNO Q”エリア(中央左)
電源レギュレータやスイッチ類、状態LEDなどの基板インフラ回路が点在。
「右下の白い矩形領域」について
画像で目立つ白い格子状の大きな矩形は、オンボードの低解像度ディスプレイ(LEDマトリクス)です。
- 用途:状態表示/ロゴ・文字・簡単なアニメーション/推論結果の簡易可視化など。
- 意味:UNO Q は“MPU(Linux)+MCU(リアルタイム)”のデュアル構成で、ボード単体での可視化が重要。
外付けディスプレイなしでも簡単なUIを表現できます。 - 実装上の振る舞い:MPU側(Python)・MCU側(C++)のどちらからでも、提供ライブラリやBrick経由で制御する想定です(たとえば進捗バー、エラーステータス、検出クラス名のスクロール表示など)。
なお、右下の隅にある小さな白い4ピンのコネクタはQwiic / STEMMA QT 互換のI²C拡張コネクタです(JST-SH系)。外付けセンサや小型表示器をケーブル1本(電源+SCL/SDA)で増設できます。
そのほかの見どころ
- オンボードLED群(基板各所)
電源・ステータス・ユーザ用LED。開発初期の動作確認に便利。 - 電源系“POWER”付近(左上)
VINやType-Cの入力、各レール(5V/3.3V/他)の電源設計が集まる領域。 - MCU(STM32U585)実装域
右側エリア(“STM”シルク近辺)にMCUコアや周辺回路。GPIO/ADC/PWM/リレー駆動などリアルタイムI/Oを担当。
裏面側に実装されている部品
裏面の画像(図2)から読めるシルク/刻印と一般的な実装配置に基づき、UNO Q の下面にある主な部品・領域の役割を「ゾーン別」に整理します。※品番までの断定が必要な箇所は避け、見える情報+妥当な推定で説明します。
全体の見取り図(下面)
- ① 左右の長い二列ソケット(“MISC”“MEDIA”表記)
高密度拡張用のスタックド・メザニンコネクタ。- MISC 側(左):GPIO/I²C/SPI/UART、低速の管理信号、MCU側I/Oなどが主に出る想定。
- MEDIA 側(右):カメラ用のMIPI CSI、ディスプレイ系(MIPI DSI)、高速I/F、クロック/リセット類などマルチメディア寄りのピン群。
→ 上面のUNO互換ヘッダより高ピン数・高速信号を取り扱うための拡張口です。
- ② 中央やや右:“Qualcomm Dragonwing”ロゴの領域
上面のSoC(QRB2210)直下/周辺にあたり、MPUまわりの信号引き回し・デカップリングが集中。- BGAのブレークアウト配線、電源/リファレンス抵抗、ESD/EMI対策の部品が密集しています。
- シルク“Dragonwing”はSoCブロックの識別を兼ねたマーク。
- ③ 左中央の大きなBGAパッケージ
メモリ/ストレージ系(LPDDR4/eMMCのいずれか)が実装される領域。- UNO QはLinuxを動かすためDRAMとeMMCを搭載する構成で、片面にSoC、反対面にDRAMまたはeMMCを置くのはよくあるレイアウト。
- 外観からはDRAMサイズ感に近い印象ですが、実機の改版で左右が入れ替わる場合もあるため、“メモリ/ストレージブロック”として把握してください。
- ④ 左下~中央下:STロゴのQFN/BGA(“STM32…”の刻印が見えるエリア)
MCU(STM32U5系)およびその周辺。- 近くに水晶発振子(小さなメタル缶)、QSPI/外付けフラッシュ、リセット/ブート関連の受動部品。
- MCUのブート/デバッグ(SWD/JTAG)は、上面の小型ヘッダ“STM”に対応します。
(下面はその信号の引回しと電源/クロック)。
- ⑤ 右下:電源レール/アナログ電源まわり(インダクタ+電解/タンタル+大きめセラミック)
DCDC(降圧)コンバータやLDOの塊。- SoC/DRAM/無線/カメラ/ディスプレイなどへ供給する多出力の電源レールを生成。
- “000”と書かれたジャンパ抵抗(0Ω)や、シャント抵抗、フェライトビーズが見え、電源の分岐・電流検出・ノイズフィルタ用途が推測されます。
- 熱を考慮した銅箔ベタやサーマルビアも多数。
- ⑥ 左上/右上の小ランド群・スルーホール列
製造時のテストパッド、治具用ランド、アンテナ/シールド接続点など。- CE/FCC等の規格マークが近傍にあり、EMC対策の部品(アレスタ、ESD保護)も点在。
- CE/FCC等の規格マークが近傍にあり、EMC対策の部品(アレスタ、ESD保護)も点在。
- ⑦ 中央のQRコードラベル
製造トレーサビリティ(ロット、シリアル、改版)を示す識別。サポート時に参照。
開発環境 Arduino App Lab

これは何?
- Arduino UNO Q 向けの新しい統合開発環境(IDE)。Python(MicroPython)と従来のC++スケッチの両方に対応し、“Bricks” と呼ばれるモジュールを組み合わせてアプリを構築できます。
AIモデルとの組み合わせも想定されています。(docs.arduino.cc) - UNO Qの公式スタートポイントとして案内され、ボード同梱・SBCモード(ディスプレイ/キーボード接続)ではApp Labがプリインストールされています。(arduino.cc)
主な特徴
- 二言語対応:Python(MicroPython)とC++スケッチを同一環境で扱える。(docs.arduino.cc)
- Bricks(ビジュアル構成要素):入出力や機能ブロックを積む感覚でアプリの振る舞いを定義。(docs.arduino.cc)
- CLI(App Lab CLI):コマンドラインからアプリの管理・起動・デプロイが可能。自動化やCIに有用。(docs.arduino.cc)
- UNO Q最適化:MPU(Linux)とMCU(リアルタイム)を跨ぐ開発フローを意識した設計。(arduino.cc)
対応・入手
- 対象ボード:現時点ではArduino UNO Qが前提(App Labの説明やダウンロード導線がUNO Qと紐づき)。(arduino.cc)
- OS/配布:Windows 10/11向けインストーラが案内(SBCモードはUNO Qにプリイン)。(arduino.cc)
- セットアップ手順(概要):
- App Labをインストール/UNO Qを接続 → 2) Python or Sketchを選択 → 3) Bricksやエディタで開発 → 4) 実機へデプロイ(CLIも可)。(docs.arduino.cc)

追加質問:開発環境 Arduino App Labは、Windowsでしか動かないのですか
GPT 5 Thinkingの回答:
いいえ、Windows専用ではありません。
公式ドキュメントでは、Windows / macOS / Linux の各OSに対応と明記されています。
(Windows 10+、macOS 11+、Ubuntu 22.04+、Debian Trixie など)。(arduino.cc)
UNO Q本体(SBCモード)にはApp Labがプリインストールされており、ボード上でもそのまま使えます。(docs.arduino.cc)
付属の App Lab CLI も Windows / macOS / Linux で利用可能です。(docs.arduino.cc)
「PCで使う/UNO Q上で使う」のどちらも選べる設計なので、手元の環境(Win/Mac/Linux)に合わせて導入して大丈夫です。
既存環境との違い(ざっくり比較)
- Arduino IDE 2:従来のC++スケッチ中心。広範な全ボード対応。App LabはUNO Q特化で、Bricksやマルチ環境統合が強み。(Arduinoヘルプセンター)
- Arduino Lab for MicroPython:軽量なMicroPython専用エディタ。幅広いボードで使えるが、BricksやUNO Q統合、CLI連携はApp Labが優位。(labs.arduino.cc)
- (参考)MicroPython Installer:対応ボードへMicroPythonを書き込む専用ユーティリティ。(labs.arduino.cc)
使いどころ(ユースケース)
- UNO Qで「Linux+MCU」のハイブリッド開発を始めたい、ビジュアルなBricksで素早くプロトタイプしたい、CLIで自動化したい——といった用途に最適。(arduino.cc)
周辺トピック(背景ニュース)
- 2025年10月上旬、QualcommによるArduino買収と同時期にUNO QとApp Labが話題に。UNO QはQualcomm系CPU+STM32のデュアル構成と報道され、App Labがプリイン装備と紹介されています(詳細は各報道参照)。(The Verge)
App Lab CLIの具体コマンド例 と Bricksの使い方(典型フロー)
以下は(1)App Lab CLIの使いどころ & 代表的な操作、(2)Bricksの典型フロー(Python×C++連携)を、UNO Q公式ドキュメントに沿って手早く使い始められる形でまとめました。
1) App Lab CLI:できること & 代表的な操作
公式には「UNO Q上でApp(Python+Sketch+Bricks)を起動・停止・ログ確認・デバイス検出」などを行うCLIが案内されています。実体のコマンド名や細かなサブコマンドは配布ビルドに依存するため、まず
--helpで確認するのが確実です。(docs.arduino.cc)
- ヘルプ/バージョン確認
applab --help/applab --version(名称はビルドで異なる可能性あり)(docs.arduino.cc) - デバイス列挙(USB / 同一LAN)
例:applab devices list(UNO QのUSB接続やIPを取得)(docs.arduino.cc) - アプリ一覧・起動・停止
例:applab apps list(作成済みAppの列挙)applab apps run <APP_NAME> --device <IP|usb>(UNO Q上でApp起動)applab apps stop <APP_NAME>(停止)applab logs -f <APP_NAME>(フォロー付きログ)
※サブコマンド名は配布版に合わせて--helpで要確認。 (docs.arduino.cc)
- (参考)MCU側を個別に扱う場合:従来のArduino CLI(スケッチのビルド/書き込み/ボード管理)も併用できます。
- ボード検出:
arduino-cli board list - ボードパッケージ導入:
arduino-cli core install arduino:mbed(例) - ビルド/書き込み:
arduino-cli compile -b <fqbn> ./→arduino-cli upload -b <fqbn> -p <port>(GitHub)
- ボード検出:
補足:UNO QはMPU(Linux上のPython)+MCU(リアルタイムC++)のデュアル構成で、App Labはその両者を1つの「App」として扱います。CLIはこのApp単位の実行を想定。(docs.arduino.cc)
2) Bricksの使い方(典型フロー)

BricksはPythonで書かれた機能モジュール(一部はDockerコンテナを伴う)で、AIビジョン/オーディオ、データ保存、Web UI、クラウド連携などを素早く組み込み可能。Appを起動するとUNO Q上にデプロイされます。(docs.arduino.cc)
2.1 最小フロー(5ステップ)
- 新規Appを作成
App Labで新規作成すると、main.py(MPU側/Python)とsketch.ino(MCU側/C++)が自動生成されます。(Make Things) - Brickを追加
カメラ/モデル/ストレージ等のBrickをAppに追加(GUI操作)。BrickはPython APIを提供(多くはimport ...して使う想定)。※Brick名やAPIはBrickごとに異なるため、App Lab内のチュートリアル/サンプルを参照。(docs.arduino.cc) - MPU側(
main.py)でBrickを初期化
例:カメラBrick→画像フレーム取得、ビジョンBrick→推論、DB Brick→INSERT、WebUI Brick→HTTP配信…など。(BrickはPython実装/一部Docker併用)。(Make Things) - MCU側(
sketch.ino)と連携(Bridge / RPC)
C++側からPython側の関数呼び出し、逆方向の通知などをRouterBridge / RPCliteで行います。
(UNO Q専用ラッパあり)。(GitHub) - CLI or App Labから起動
App Lab GUIまたはApp Lab CLIでAppを起動し、ログを確認。(docs.arduino.cc)
2.2 MCU⇄MPUのやり取り(実コード断片)
MCU側(C++ / sketch.ino):RouterBridgeでPython関数のRPC呼び出しとMCU側関数の公開ができます。
#include <Arduino_RouterBridge.h>
bool set_led(bool state) { // MCU上の関数を公開
digitalWrite(LED_BUILTIN, state);
return state;
}
void setup() {
Bridge.begin();
Monitor.begin();
pinMode(LED_BUILTIN, OUTPUT);
Bridge.provide("set_led", set_led); // Python側から呼べるよう公開
}
void loop() {
float sum;
// Python側の "add" をRPC呼び出し(同期取得)
if (!Bridge.call("add", 1.0, 2.0).result(sum)) {
Monitor.println("Error calling method: add");
}
// 結果を使って何かする…
}
上はArduino公式のArduino_RouterBridgeリポジトリREADMEの例(抜粋)で、provide()でMCU関数を公開、call()でPython側を呼び出す流れが確認できます。(GitHub)
MPU側(Python / main.py):Brickや自作関数をRPCサーバとして公開し、MCUから呼び出させる/逆にMCUの公開関数をRPCクライアントとして呼ぶ、という形になります(Python実装はBrickやテンプレに付属)。
BricksがDockerコンテナを伴う場合もあります。(docs.arduino.cc)
2.3 具体例の設計パターン(よくある組み合わせ)
- ビジョン推論(MPU/Python)→アクチュエータ制御(MCU/C++)
カメラBrick+モデルBrickで分類→しきい値判定→Bridge.call("set_led", True)のようにMCUへ通知。(Make Things) - センサ計測(MCU/C++)→ロギング&可視化(MPU/Python)
MCUで周期計測→MPUへRPC送信→DB/ダッシュボードBrickで蓄積・配信。(docs.arduino.cc) - Web UI(MPU/Python)+リアルタイムI/O(MCU/C++)
Python側でWebサーバBrick、UIボタン→RPCでMCUのset_led()を叩く。(Make Things)
3) つまずきポイントと回避策
- 「MicroPython?」問題:UNO QのMPU側は通常のPython(Linux上)です。
MicroPythonではない点に注意。(Arduino Forum) - Brickの初回起動が重い:AI/DB系Brickは内部でコンテナ取得が走る場合があり、初回に時間がかかることがあります(Make:の実測レビュー)。(Make Things)
- App Lab CLIのコマンド差異:ドキュメントは存在しますが、実行ファイル名やサブコマンドはビルドで差異が出ることがあります。
<cmd> --helpで現物確認→スクリプト化が安全。(docs.arduino.cc)
参考リンク(公式)
- App Lab ポータル(「Getting Started」「Bricks」「CLI」への導線)(docs.arduino.cc)
- Bricksの解説(Python実装・一部Docker利用の旨が明記)(docs.arduino.cc)
- UNO Qの公式ドキュメント(MPU/MCU両対応の開発案内)(docs.arduino.cc)
- RouterBridge(UNO Q向けRPCラッパの公式GitHub、コード例つき)(GitHub)
他開発環境(Arduino IDE 2、PlatformIO)との比較
ざっくり結論
- UNO Qで“Python+C+++Bricks(AI/DB/Web UI)”を一体運用したい → App Lab。
GUI/CLIでApp(Python・スケッチ・コンテナ)をまとめて走らせる設計。(docs.arduino.cc) - 従来のArduinoスケッチ中心、手早く書いて書き込む → Arduino IDE 2。
公式IDEで入門~中規模まで万能。(docs.arduino.cc) - 大規模/マルチボード/高度なデバッグ/CI運用 → PlatformIO(VS Code)。
テスト・CI・JTAG/SWDなど拡張が強い。(docs.platformio.org)
機能比較(要点)
| 観点 | Arduino App Lab | Arduino IDE 2 | PlatformIO(VS Code) |
|---|---|---|---|
| 主目的 | UNO Q上でPython・C++スケッチ・Bricks(AI/DB/Web等)を束ねて“App”として起動 | Arduinoボード向けスケッチ開発の標準IDE | 複数プラットフォーム対応のプロ向け環境(依存管理/テスト/CI/高度デバッグ) |
| 言語/構成 | Python(MPU/Linux)+C++(MCU/RT)+コンテナ化Brick | C++(Arduinoスケッチ) | C++中心(ほか各種) /プロジェクト記述 ( platformio.ini) |
| 代表機能 | Bricks(Pythonモジュールを別プロセスで実行)、 App Lab CLI(アプリ起動/停止/ログ/デバイス管理)、 UNO QへのSBC接続運用 | ボード/ライブラリマネージャ、シリアルモニタ/プロッタ、デバッガ、補完 | ユニットテスト、高度なデバッガ(JTAG/SWD)設定、CI統合、マルチ環境ビルド |
| UNO Q適性 | 最適(UNO Qの「二つの脳」を前提。 Python↔MCUはRPCで連携) | 使える(MCU側スケッチの開発に最適) | 使える(スケッチの大規模開発やCI向けに有利) |
| 習得コスト | 中 (BricksやRPCなど新概念) | 低~中 (Arduino経験者なら最短) | 中~高 (VS Code+設定/タスク/デバッガ運用) |
| 自動化/運用 | App単位でCLI起動・ログ追従が容易 | Arduino CLI併用で可能 | 標準でCI/テストが強い |
| 向いている人/用途 | AI/映像/DB/WEB UIを絡めた“ボード上アプリ”、プロトタイピング | クラシックなセンサ/制御、教育・入門~中規模 | 製品志向/チーム開発、複数ボード横断、高度デバッグ |
具体的に「UNO Q」でどう使い分ける?
- App Lab
- UNO QのMPU(Linux/Python)とMCU(C++)をRPC(RouterBridge / RPClite)で結び、Bricks(AI/DB/HTTPサーバ等)も別プロセスとして動かす前提。
“App”単位で起動・停止・ログをCLIで統合管理。 - 例:カメラBrick→Pythonで推論→
Bridge.call("set_led", True)でMCU側の関数を叩く→LED点灯。(docs.arduino.cc)
- UNO QのMPU(Linux/Python)とMCU(C++)をRPC(RouterBridge / RPClite)で結び、Bricks(AI/DB/HTTPサーバ等)も別プロセスとして動かす前提。
- Arduino IDE 2
- MCU側スケッチをサクッと作って書き込む用途に最適。ボード/ライブラリ管理、デバッガ、シリアルモニタなど一通り揃う。UNO QのMCU片側に集中できる。(docs.arduino.cc)
- MCU側スケッチをサクッと作って書き込む用途に最適。ボード/ライブラリ管理、デバッガ、シリアルモニタなど一通り揃う。UNO QのMCU片側に集中できる。(docs.arduino.cc)
- PlatformIO(VS Code)
- マルチ環境のビルドマトリクス、ユニットテスト、JTAG/SWDまで使い倒したい、CI/CD回したいときに強力。UNO QのMCU側を本格運用したいチームに向く。(docs.platformio.org)
迷ったらこの基準
- AI/画像/音声・DB・Web UIも“ボード内で”完結したい(しかも素早く)
→ App Lab(Bricks+CLIで一気通貫)。(docs.arduino.cc) - 従来通りのスケッチ中心で、とにかくシンプルに
→ Arduino IDE 2。(docs.arduino.cc) - 本番運用・規模拡大・複数ボード・高度デバッグ・CI
→ PlatformIO。(docs.platformio.org)
補足メモ
- App LabはUNO Qの公式スタート地点として案内され、SBC接続(モニタ+キーボード直挿し)やネットワーク越し開発にも対応。BricksはPythonで書かれ、Linux上で別プロセスとして動作するのがポイント。(arduino.cc)
- Arduino IDE 2は公式の定番で、ボード/ライブラリマネージャやデバッガなど基本が充実。(docs.arduino.cc)
- PlatformIOは公式IDEではない別エコシステム(VS Code推奨)。高度なデバッグやCIに強く、経験者・チームに選ばれやすい。(docs.platformio.org)
それぞれの開発環境に適する用途
要点だけギュッと。「どんな用途に最適か」に絞って3環境を比較します。
Arduino App Lab(UNO Q専用の統合環境)
- 向いている用途
- UNO Qで“Linux側(Python)+MCU側(C++)”を同時に使うプロジェクト
例:AIカメラ推論(MPU)→センサ/アクチュエータ制御(MCU)→Web配信やDB保存。UNO QはApp LabでMPU/MCUを一体的に開発できる設計。(docs.arduino.cc) - AI/ビジョン・音声・DB・Web UI を素早く足したいプロトタイピング
App LabのBricksはPython製の機能モジュールで、Linux上で別プロセスとして動作。AIモデルやデータ保存などを“積む”感覚で追加。(docs.arduino.cc) - ボード直結(SBCモード)で完結させたい学習/デモ
UNO QはSBCモードでApp Labプリインストール。キーボード/モニタを挿すだけで開始可能。(arduino.cc)
- UNO Qで“Linux側(Python)+MCU側(C++)”を同時に使うプロジェクト
参考:App LabはUNO Qの推奨IDE(“both MPU and MCU”)。Getting Startedやダウンロード導線もUNO Q前提です。(docs.arduino.cc)
Arduino IDE 2(公式の定番IDE)
- 向いている用途
- 従来型のArduinoスケッチ中心の開発(MCUだけを素早く書いて試す)
UNO QでもMCUのみをプログラムする用途に適する(公式記載)。(docs.arduino.cc) - 教育・入門~中規模の制作
ボード/ライブラリマネージャ、シリアルモニタ&シリアルプロッタ、デバッガなど基本機能が揃い、立ち上がりが速い。(docs.arduino.cc) - **“とにかく手早く書いて書き込む”**反復開発
公式チュートリアルが豊富で、環境依存が少ない。(docs.arduino.cc)
- 従来型のArduinoスケッチ中心の開発(MCUだけを素早く書いて試す)
PlatformIO(VS Code上のプロ志向環境)
- 向いている用途
- 大規模・チーム開発/複数ボード横断/CI/CDやテスト自動化まで回す
ユニットテストとチュートリアルが標準で充実。(docs.platformio.org) - 高度なデバッグ(JTAG/SWD、ウォッチポイント、メモリ/レジスタ閲覧、逆アセンブル等)
VS Code統合のデバッグ機能が強力。J-LINK等のプローブにも対応。(docs.platformio.org) - ビルドマトリクスや環境分離、再現性重視の開発運用
VS CodeのPlatformIO拡張でビルド/アップロード/シリアルモニタ等を一元操作。(docs.platformio.org)
- 大規模・チーム開発/複数ボード横断/CI/CDやテスト自動化まで回す
迷ったらこの指針
- UNO QでAIやWeb/DBも含む“ボード内完結アプリ”を素早く構築したい
→ Arduino App Lab(MPU/MCU一体+Bricks)。(docs.arduino.cc) - 従来通りのスケッチをサッと書いて試したい/教育用途
→ Arduino IDE 2。(docs.arduino.cc) - 規模が大きい/複数ボード/テスト&CI&高度デバッグが欲しい
→ PlatformIO(VS Code)。(docs.platformio.org)
UNO Q(Bricks AI推論)で構成したエッジコンピュータの処理能力
結論から言うと、UNO Q(QRB2210+Bricks)でのマルチモーダル処理は「モバイル級の軽〜中量タスク」に最適です。
リアルタイム視覚(軽量モデル)、音声(キーワード検出/簡易ASR)、センサ連携、Web配信・ローカルDB保存までを1枚で完結できますが、大型LLMや重量級CV(高解像度・大モデル)を高FPSで回す用途は想定外です。
なぜそう言えるか(ハード前提)
- MPU:Qualcomm Dragonwing™ QRB2210(Arm Cortex-A53×4 最大2.0 GHz)+Adreno 702 GPU+Hexagon系DSP。デュアルISPで同時2カメラ入力にも対応。(Qualcomm)
- ボード:Linux(Debian)対応のMPUとSTM32U585 MCUの“デュアル脳”。
AI/グラフィック加速・カメラ/音声/表示のI/Oを備え、2–4 GB RAM/16–32 GB eMMCクラス。(arduino.cc) - 公式トーンも「軽量AI(vision/sound)をリアルタイム制御と組み合わせる」というポジショニング。(arduino.cc)
注:QRB2210は公称TOPSや専用NPU値が一般公開されていません(Hexagon DSP+Adrenoのヘテロ加速で“軽量AI”を狙う設計)。(Qualcomm Docs)
できること(現実的な目安)
- 画像/映像:MobileNet・YOLOv5n/6n 等の軽量モデルを低〜中解像度(例 320p〜480p)で実用FPS。GPU(OpenCL/Vulkan)やHexagon系最適化を使う前提。(blog.tensorflow.org)
- 音声:キーワードスポッティングや小規模オンデバイスASRを低遅延で。
Hexagonの低電力オーディオDSPが有利。(Thundercomm) - Web/UI/DB:FastAPI/Flask+SQLite相当を同時運用(Bricksで抽象化)。
カメラ→推論→Web配信(JPEG/WS)やローカルDB保存のワークロードはボード内で完結。(arduino.cc) - MCU連携:推論結果でGPIO/リレー制御、高頻度センサの精密サンプリングはMCUへ逃がし、RPCで橋渡し。(Arduino Blog)
逆に、多カメラ4K推論や高解像度での多物体検出を高FPS、数十億パラメータ級LLMのオンデバイス生成などは不向き(メモリ/熱/電力の制約)。これはモバイル級SoCの一般傾向にも合致します。(ResearchGate)
実装時の“現実解”とチューニング指針
- モデル軽量化:INT8/FP16量子化、蒸留、小型アーキ(‐n/‐s系)を利用。QualcommのAI Hub / SNPE系ツールやOpenCL最適化を検討(AdrenoはOpenCLが有効)。(aihub.qualcomm.com)
- 解像度とレイテンシの両立:入力を320〜480pで運用し、入力→推論→配信を非同期スレッド化(キャプチャと推論のデカップリング)。
- I/O最適化:デュアルISP/CSIやUVCのゼロコピー/低コピー、GPU前処理の活用。(Qualcomm Docs)
- 発熱と持続性能:小型筐体では熱スロットリングに注意(スレッド/負荷を平準化)。
- Bricks活用:ビジョン・Web・DB Brickを使い、MPU側の重い処理をBrickへ、MCU側の硬リアルタイムをスケッチへ。(arduino.cc)
“どの程度?”を具体化するための観測ポイント(おすすめ検証)
- ベースライン:YOLOv5n(320p)/MobileNetV2(224)などを素のPyTorch/TFLiteで計測 →
① CPUのみ、② GPU(OpenCL/Vulkan delegate)、③ SNPE/AI Hub最適化の順に比較。(blog.tensorflow.org) - パイプ全体:カメラ取り込み→前処理→推論→描画/配信の総フレーム遅延を計測(各段のmsをログ化)。
- 持続試験:10〜30分の連続稼働FPS(熱影響込み)を確認。
参考(公式情報)
- UNO Q 製品/ブログ:デュアル脳・AI/グラフィック加速・Linux対応の位置づけ。(arduino.cc)
- QRB2210 ドキュメント:A53×4、Adreno 702、Hexagon/DSP、デュアルISP等の構成。TOPSは開示なし。(Qualcomm Docs)
- Adreno×OpenCLの推論最適化(TFLite GPU/OpenCLの知見)。(blog.tensorflow.org)
- Qualcomm AI Hub(例:YOLOv5のエッジ最適化)。(aihub.qualcomm.com)
まとめ
- “MPU(QRB2210)+MCU”の一体基盤にBricksを載せて、軽〜中量のマルチモーダル(視覚+音声+センサ+Web/DB)を「現場完結」で回すのがUNO Qの得意領域。
- 目標が軽量CVの実用FPS+制御+可視化であれば適任。大型モデルや高解像度・高FPSを求めるなら、より上位のSBC/SoCや外付けNPUの検討が必要です(例:RB5クラス、Jetson、外付けNPU)。(I-Pi SMARC)
Arduino UNO Q と Raspberry Pi 5 / 16GBの比較
要点が一目で分かるように、用途視点の結論 → 仕様ざっくり比較 → 向き不向きの順でまとめます。
ざっくり結論
- Raspberry Pi 5(16GB)は汎用計算(A76×4/2.4 GHz)とI/O拡張(PCIe/デュアル4K/高速USB)に強い“ミニPC”。重めのCV/ASR、Web+DBサーバ、複数プロセスの同時実行などを高余力で回せます。(raspberrypi.com)
- Arduino UNO QはLinuxを走るMPU(QRB2210)+リアルタイムMCU(STM32U585)の“デュアル脳”。App Lab+BricksでAI/WEB/DBとハード制御を一体運用しやすい“エッジ実装ボード”。汎用性能はPi 5に劣るが、制御とAIの統合・一枚完結が強みです。(arduino.cc)
主な仕様(要点比較)
| 項目 | Arduino UNO Q | Raspberry Pi 5 / 16GB |
|---|---|---|
| CPU/GPU | Qualcomm Dragonwing QRB2210:A53×4(~2.0 GHz)+Adreno 702、Hexagon系DSP | BCM2712:A76×4(2.4 GHz)+VideoCore VII |
| メモリ | 2GB or 4GB LPDDR4X | 16GB LPDDR4X(最大構成) |
| ストレージ | eMMC 16GB/32GB(内蔵) | microSD(標準)/PCIe 2.0 x1でNVMe拡張可 |
| 副プロセッサ | STM32U585(MCU)でRT制御 | なし (必要なら別マイコンやHATで補完) |
| カメラ/表示 | デュアルISP/MIPI CSI/DSIピン(MEDIAヘッダ経由) | 2系統CSI/DSI、デュアル4Kp60 HDMI |
| ネットワーク | Wi-Fi 5 / BT 5.1 | GbE、Wi-Fi/BT(モデル/キットにより) |
| 開発体験 | App Lab+Bricks(Linux/Python+C++を一体管理)/IDE2でMCU単体も可 | Raspberry Pi OS+豊富なLinuxツール/Python, C/C++ 等 |
| 位置づけ | AI+制御の“ボード内完結” | 高性能SBC(汎用計算・拡張) |
(出典:UNO Q 製品/Docsとデータシート、QRB2210資料、Pi 5 公式ページ/ブリーフ)(arduino.cc)
どっちが向く?
UNO Q を選ぶケース
- “AIカメラ推論(Linux側)→GPIO/リレー即応(MCU側)→オンボードでWeb配信/保存”のように、制御とAIを一体で回したい。App LabのBricksでWeb/DB/推論を積み木的に追加したい。(docs.arduino.cc)
- SDカード不要のeMMC内蔵でフィールド運用を簡素化したい。(docs.arduino.cc)
Raspberry Pi 5(16GB)を選ぶケース
- 重めのモデル(大きめYOLO、フレーム高解像/高FPS、音声長時間処理)やWeb/DB/解析の多プロセス同時実行を余裕で回したい。(datasheets.raspberrypi.com)
- PCIeでNVMe/高速NIC/加速器などを増設し、拡張性優先の構成にしたい。(datasheets.raspberrypi.com)
実務視点の補足
- リアルタイムI/O:Piでも可能ですが、OSジッタがあるため即応制御は別マイコン(例:RP2040やArduino)を併用が定番。UNO Qは最初からMCU同居でシンプル。(docs.arduino.cc)
- AIランタイム:QRB2210はA53世代+Adreno/DSPで軽量AI向き。
Pi 5はA76世代でCPU余力が大きく、OpenCL/Vulkan系やONNX/TFLiteのCPU/GPU実行が伸びやすい。(クアルコム) - カメラ:両者ともデュアルカメラ対応だが、PiはISPとエコシステム(libcamera、デュアル4K出力)が成熟。
UNO QはApp Lab+Bricks前提で制御統合が簡単。(datasheets.raspberrypi.com)
まとめ(選び方の指針)
- “制御+AI+Web/DBを1枚で、現場で手早く” → UNO Q(App Lab+Bricks)。
- “計算余力・拡張性・マルチアプリ運用重視” → Raspberry Pi 5(16GB)。
