３Dカメラを検討しているあなたは、実際の社会的な課題を解決するために開発しようと思っているんだろうと推測します。 そのタスクの多くは、既に誰かによって十分に解決されています。 それらを、後追いで開発しても、だれもうれしくなりません。
- SLAMによる自己位置推定
- APIの公開
- ROS2のサポート
- gRPCのサポート
- 画像認識のサポート
- 音声認識のサポート これらを満たしている例として、カチャカ があります。
自分たちの目的の要素に、SLAMを利用して自律的に移動できるという要素が必要ならば、最初のPoCには、既存品を流用すべきです。 自分たちが付加価値を付けていく部分は、SLAMでも自律移動でもないのですから。 (そしてPoCに使った既存品をどう作り変えるともっと便利になるのかが、十分に割のあうものになったときに、試作を考えましょう。)
- 実社会の問題を解決することを目標においたときに、むしろ重要なのは、ハンドを使って何をどうさせるかだ。
- 上半身２腕ロボットという選択肢
- 2腕のアームロボットという選択肢
- 1腕のアームロボットという選択肢
− 可能な限り、既存の3Dカメラとその上に作られた資産を流用する。
- ハードウエア： そのまま使う。
- あなた自身が、3Dカメラの細部にわたって理解していない限り、あなたが価値のある3Dカメラを作れる可能性は少ない。
- ソフトウェア：
- 公式のサンプルでさえ、画像認識と組合せた多数の実装例があります。
- github上にある第３者のソースコードならば、もっと多数の実装があります。
- それらをあなたの使いやすいライブラリ構成に改造します。
- そうすれば、１からあなたが開発しなきゃならないソフトウェアは格段に少なくなる。
- 方式の違う3Dカメラで実装されたよい実装を、自分の使っている3Dカメラでもまねよう。
- 特に機械学習の推論の実装は、あるカメラの実装から別のカメラの実装に積極的にまねるべきものだ。
- 供給が停止してしまった3Dカメラに対して、ソフトウェア互換の3Dカメラの提供というのは、ユーザーとしてはうれしい。
- いいアイディアは、共通に使われることによって、そのアイディアを、特定のカメラのEOLを気にせずに使うことを可能にしてくれる。
- いいアイディアは、コンピュータ言語を超えて波及する。
- 例：JSON（JavaScript Object Notation）はJavaScript から波及していった。
自分たちの勝負どころを、どう設定するかだ。
- 何ができたら商業的にうれしいのかを十分に定式化しきれていないのが、ロボット開発の問題点である。
- そのための必要な認識技術がどうだったらうれしいのかを明確にすることです。
- 商業開発におく場合にはなおさらです。
- 「できること」を明確にして、その範囲での商業的な見返りを得ることです。
- 同じ実装が、そのまま横展開できることが大事。
- レストランの配膳用ロボットは、レストランの系列が変わっても同じように使える。
- タブレットによる注文方式は、お店の種類が違っても、共通に利用できるからこそ普及した。
- 横展開をすることによって、会社の収入が確保できる。
- 特定顧客の特定作業だけに特化すると、商業的な見返りは期待しにくくくなる。
- 数がでない分だけ、投資を回収できなくなる。
人検出の学習済みモデルは、既に十分にいいのが存在する。まずは、それを利用することを考えてみよう。 全方位カメラでの人検出とか、かなり特殊な場合じゃないかぎり、それが有効なはずだ。 もし、既存の学習済みモデルで弱点を見出したら、その弱点を検証できるデータセットを作ることだ。 そして、そのデータセットを公開すること。 そして、モデルの作者の目に届くようにすること。 モデルの作者が、気が向いたら、対応してくれるかもしれない。
人検出モデルは、学習用・評価用のデータセットのフルセットを作るのは、覚悟してのぞむこと。フルセットのデータセットを作るのは茨の道です。
自分が独自に作ることに執着することより、いいものを選択して使いこなす目利きが重要になってくる。
- どういうインタフェースで、それを使えばうれしいのかが抜けている。
- 他の機能と組合せて使うためのインタフェース設計がない。
- 論文に発表されてgithubに公開されている実装は、使ってみよう。
- 使ってみてはじめて、可能性と限界とかが見えてくる。
- 論文で評価しているデータセットは、データセットに固有の偏りがある。
- そのため、あなたが使ってみたいユースケースでは性能がでないこともある。
- ライブラリとして使うためには、インタフェースの設計が重要になる。
- 解像度、フレームレート、前提の前処理の有無
- 出力での許容できる遅延
- 確からしさを向上させるために利用できるもの
- ５年１０年というタイムスケールの中でそんなものは存在しない。
- いざとなれば、他のプラットフォームに移行できる（と信じられる）ことが、そのプラットフォームを使い続ける根拠になる。
- NVIDIAのGPUとPytorchの組合せで使っていても、それがopenvinoやonnxruntimeにdeployできることが、安心材料となっている。
- 自社のプロダクトについても、代替可能なプロダクトは必ずでてくる。
- 統計分野のS言語をR言語が引き継いでいった。
- MATLABが従来にになっていた分野の一部は、Python, numpy, matplotlib, pandas が引き継いでいる。
- そのときに、代替品では達成できない価値を追加しているかどうかだ。
- 代替品では達成できない価値を新規に供給し続けることこそが、製品の寿命を伸ばす。
- 特許は、発明者の権限を守るために必要なものです。
- しかし、排他的な強者を多くの人は望んでいません。
- 排他的な強者への対応例
- SIFT特徴量の回避
- GIF画像形式の回避
- 排他的な強者が、全てを牛耳る世界は悪夢だ。
- 排他的な強者のために、社会の富はすべて、彼らのものになってしまう。
- 「Don't be evil」という標語を掲げれば、達成されるものではない。
- 自分が開発する実装は、いずれ消えてなくなるものだということは覚悟しよう。
- 教科書に載っていて世界的に有名な発明者の名前を冠するアルゴリズムだって、もっといい実装がでている状況では、使われないアルゴリズムになる。
- 自分たちが作った実装も、いずれ消えてなくなる実装になる。
- それでも、その時点で、一歩前に進むことに意義がある。
- 自分たちが、どこかを進めることをせずに、進歩はのぞめない。
- 用途によっては、十分に動作が検証されていることが必須の要件になるだろう。
- 機械学習を含んでしまったものは、その動作が十分に性能がでるのかを検証するうえで課題を生じる。
- 「あのとき、カメラにこのように人が写っているのに、人がいると判断しなかった。」となれば大問題である。 そうならないことを防ぐためには、性能の検証を増やすことである。検証が不十分な実装を自動運転車のメーカー、自動運転サービスの提供者は利用しないだろう。
- ロボットの場合も同様なことが起きるだろう。検証が不十分な実装は普及しない。
- 飲食店用の配膳ロボットという需要があることが判明したのにもかかわらず、めだった国産化の動きはない。
- どうような現象が起こるのであれば、もっと汎用性の高いロボットが出現した時に、利用者数の少ない実装は、検証が不足し、そのことによって利用者が伸びないという悪循環をもたらす危惧がある。
- あるタイミングでは、あるチームで解決できることは、そんなに多くない。
- そのタイミングに解決する課題を上手に選ばなきゃならない。
- 課題によっては、今の時点では、どうしようもなく難しすぎて、何の進展も得られないだろう。
- 課題によっては、やればできるだけで、何の汎用性もなく、応用性にも乏しく、すぐに忘れさられるものもあるだろう。
- そういった課題が山ほどあるなかで、あなた達の開発チームが実現することで、先に進める一歩を選ばなきゃならないかもしれない。
- 一時代を築いたロボットでも、時代が変われば、前提となる技術がすっかり入れ替わっているので、そのままでは次に進めなくなる。
- 「明解な指導原理にしたがって、正しいアプローチが分かる」なんていうのは理想だが、そんな都合よくはないだろう。
- 使えることになっていることと、使い物になることとの差は、想像以上に大きい。
- だから、まともな判断をしようとするならば、使ってみることだ。
- どういうインタフェースで、 タスクを定式化すれば使いやすいのか
- どういうライブラリを利用すれば、活用がしやすいのか
- バックエンドに使うライブラリのガイド
- 機械学習
- 並列計算
- 点群処理
- PCL
- Open3D 既存のライブラリをベースに考えるべきだろう。足りないのがあれば、追加する。改良の余地があれば改良を実装して、標準に寄与しよう。
- グラフィックス
- プロセス間の通信
- どういうものをどう組み合せて、どういう価値が作れるというもくろみ
- そこの部分には、現時点で欠落しているのがあっていい。
- いずれ誰かが、その部分の技術を作ってくれるのだから。