Salem Roboticsが産業用点検ロボット向けソフトウェアを発表

> 私たちは、意味理解と柔軟性が役立つ場面、例えば構造化されていない情報の解釈や、馴染みのないシーンで手順に関連するものの理解などにAIを使用します。システムが実行すべき物理的相互作用を把握したら、可能な限り明示的なジオメトリ、プランニング、最適化、制御を好みます...

> 廊下を移動する際には数センチの誤差は問題にならないかもしれませんが、センサーが曲面に対して法線を保つ必要がある場合には重要です。

これは、AIの創造性（言い換えればランダム性）が壁にぶつかる具体例として素晴らしいです。モデルが改善されるにつれてこれは変わっていくと思いますか、それとも安全上重要な/非常に特化したタスクには常により明示的な命令セットが必要だと思いますか？

頑張ってください！非常に明確なフレーミングで、間違いなく必要なサービスです。2011年に福島の近くで原子炉の問題があった後を覚えています。ここの会社は、瓦礫の中を含む非常に困難な検査問題に直面していました。いくつかの問題に対処できるロボットもありましたが、日本にはなく、とにかく迅速に行動する必要があったため、人を送りました。どうやら十分に安全だったようですが、対応可能なロボットがいればはるかに安全だったでしょう。

技術的な質問：表面を正確にスキャンするために、センサーの隣のエンドエフェクタにスイッチを置き、アームがスキャンする表面の上に大まかに位置決めし、スイッチが作動するまで押し付け、スイッチをオンに保ちながらスキャンする方が良いと思います。基本的に単純なタッチセンシングです。多くの平らな面や曲面を滑らかに追従する従来のロボット工学です。ここでAIに反対しているわけではありません。スレッド全体が、具体的な目標に最適なツールを組み合わせる建設的なアプローチのようです。あなたのシナリオでは実現可能なアプローチではないのでしょうか？

あなたの結論の質問についての考え：

> ロボット工学における抽象化の境界はどこにあるべきか。ロボットメーカーから提供されるべきもの、アプリケーション層に属するもの、そして施設固有のまま残るものは何か？

私は「二重SDK」があるのが好きです。低レベルのものはアクチュエータとセンサーを個別にターゲットにし（脚4のモーター2など）、高レベルのものは事前定義されたシナリオ（前進など、ロボットが二足歩行でもクアッドコプターでもナメクジでも）を備えています。これらの2つのAPIタイプは、アプリケーションでの作業を容易にすることがよくあります…

ローンチおめでとうございます。私はロボット工学業界で10年働いてきましたが、その境界はさまざまな場所にあるのを見てきました。明確な答えがあるとは思いません。

自己宣伝：私はClipperの創業者です。これはDockerHubよりも10倍速いプルと7倍速いビルドを実現する、ロボット工学向けのコンテナレジストリです。ロボットのデプロイに一日中かかるのにうんざりして、自分で直しました。興味があれば、または単に仕事の話をしたいなら、話しましょう。

ローンチおめでとうございます。「軌道を正常に実行しても、検査が機能したとは限らない」というのは素晴らしいフレームです。測定自体のループを閉じることが難しい部分です。