Visual Parts SDK を使ってフリートマップを作ってみた

f:id:aptpod-tetsu:20210425000532j:plain

こんにちは。Visual M2M Data Visualizer の開発を担当している白金です。

この度、Visual M2M Data Visualizer Ver3.0.0 のアップデートとあわせて 可視化用パーツ「ビジュアルパーツ」を開発するための開発キット(以下「Visual Parts SDK」) をリリースしました。

Visual Parts SDKを使用して可視化用パーツをカスタマイズ開発することで、Visual M2M Data Visualizerに、ユーザー様自身やパートナー企業様の手で新しい可視化方法を追加することが可能になります。

早速、Visual Parts SDKを使ってフリートマップのビジュアルパーツを作ってみたので Visual Parts SDK とあわせて紹介したいと思います。

f:id:aptpod_tech-writer:20210423163058p:plain
作成したフリートマップのビジュアルパーツ

続きを読む

intdash SDK for Swiftを公開しました

f:id:aptpod_tech-writer:20210423144440j:plain

製品開発グループで主にネイティブアプリケーション開発を担当している上野です。

この度、弊社製品のintdashというデータストリーミングプラットフォームをモバイルアプリケーションで利用することができるSDK、「intdash SDK for Swift」をリリースしました。

このSDKはモバイルアプリのintdash MotionVM2M StreamVideoで利用されているものです。intdash MotionやVM2M Stream Videoは、PCやターミナルデバイスを用意せずとも、お手持ちのスマートフォンやタブレットにて手軽にデータ収集や伝送、可視化を可能とするアプトポッドのプロダクトです。

公開したリポジトリにはいくつかのサンプルアプリケーションを同梱しております。 今回はサンプルアプリを用いながらどんな事が出来るのか解説したいと思います。

続きを読む

EDGEPLANT T1 + Dockerでかんたん!ディープラーニング

f:id:aptpod_tech-writer:20210415201233j:plain

こんにちは。製品開発グループに所属しております、きしだです。

前回の記事でもご紹介の通り、弊社でついにハードウェアブランドが立ち上がり、その第一弾としてEDGEPLANT T1がリリースされました! 🎉

個人的にはデザインがとてもイケててずっと見つめていたくなる製品ですが、もちろん素敵な点はそこだけではありません。

EDGEPLANT T1 (以降、T1とよびます)は、NVIDIA® Jetson™ TX2を搭載している産業向けハードウェアで、GPUを利用したエッジコンピューティングが可能になります。そのため、自動車や建機などのデバイスに搭載することで、簡単にエッジAIコンピューティングが実現できます。

とはいっても、「エッジAIコンピューティングを構築するためにT1を買ったものの、何から手をつければいいのだろう」という方もいらっしゃると思います。 今回はその方々向けに、簡単なディープラーニング環境を構築する手順をご紹介します。

続きを読む

EDGEPLANT T1 リリースまでの軌跡

f:id:aptpod-tetsu:20210401212015j:plain

HW/OTチームの織江です。

今回は先日リリースされた弊社の新製品「EDGEPLANT T1 」の製品開発の軌跡を紹介したいと思います。 開発者視点から見た製品が出来上がるまでの経緯を眺めてもらえばと思います。

製品の企画や量産に伴うアレコレは別途改めてこのブログで紹介させていただきたいと思います。

続きを読む

Rustにおける非同期ストリームの関数呼び出しコストを検証する

f:id:aptpod_tech-writer:20210316130944p:plain

OTチームの大久保です。

エッジデバイス上でのデータ処理やネットワーク周りの実装に、速度と生産性の両面で優れるRust言語を利用できないかをここ最近は検討しています。特に、tokioのバージョン1.0がリリースされたように、最近はRustの非同期関連のエコシステムが充実してきたので、エッジデバイスでも応用できそうです。Rustのasync/awaitはゼロコストを謳っているので、安心して使うことができます。しかしながら、極めて高頻度に呼び出される関数がasyncであった場合、普通の同期的(asyncではない普通のfn)な関数に比べて、asyncであることによる関数の呼び出しコストの増加は無いのでしょうか。実用上は、asyncな関数は内部で非同期IOを行うはずなので、それに比べれば関数の呼び出しコストは微々たるもので気にする必要はありませんが、以下のような場合には問題に成りえます。

  • async関数だが、稀にしかコストのかかるIO操作を行わない。例えば、大抵はキューに保存されているデータを返すが、キューが空の場合になって初めてファイルを読み込むなど。
  • 内部でIO操作を行わず、async関数にする必要が無いが、他のIO操作をする関数とインターフェイスを合わせるため、asyncを指定している。

今回は、このうち2番目のような状況を想定し、何度も値を取り出すイテレータの非同期版、つまりストリームを複数の方法で作って、実行速度を検証してみたいと思います。

続きを読む