通信遅延発生時にTurtlebot3を安全に遠隔制御する技術

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

先進技術調査グループのエンジニアの酒井 (@neko_suki)です。

過去に2回、Turtlebot3の遠隔制御について紹介をしました。

tech.aptpod.co.jp

tech.aptpod.co.jp

今回は、ネットワークの切断やほかの要因によって大幅な通信遅延が発生した際に、Turtlebot3を安全に遠隔制御技術する技術として以下の2点についてご紹介します。

①フェールセーフ機能

②メッセージの遅延への対応

続きを読む

Visual M2M のデザインについて

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

はじめに

デザイン室 @tetsu です。

弊社aptpod製品 Visual M2M (以下VM2M) について、ありがたいことにお客様から「デザインが良い」とお褒めをいただくことが多いとのことで、デザインについての記事を書いて欲しい。

そんな話で営業チームからおだてられてオファーがありまして、本記事を書かせていただきます。

VM2M初期のコンセプトから現在の形にいたるまで、振り返りながら書いてみようと思います。

「デザインが良い」と言われた時に、ヴィジュアル(全体の雰囲気、カラー、レイアウトなど見た目の印象)のことを言われている方と、使い勝手を含めたシステム全体のことを指して言われている方といらっしゃると思います。

この記事では、主に前者のヴィジュアル面のデザインに寄った形で、UI(ユーザーインターフェース)の設計について書いています。

続きを読む

fastaiで学習に使う関数をApache MXNetで真似してみた

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

はじめに

先進技術調査グループのせとです。本ブログでは、Apache MXNetを用いてfastaiで実装されている実践的な関数を真似てみた結果を紹介します。この試みのゴールは、完全一致の結果を目指すのではなく同じような傾向を得られるかを目指したものになります。完全一致を目指したいところですが、各フレームワークで用意しているモデルの構造が少し違ったり、各関数の計算方法が異なるので結果が等しくなりませんでした。もちろん、他方に併せて関数を自作すればほとんど一致する結果を得ることができますが実装のコストが高かったため、今回は行いませんでした。

モチベーション

弊社のプロジェクトでAI部分をAmazon SageMaker(以下、SageMaker)を使って実装したい要望がありました。しかし、プロジェクトで利用していたフレームワークはfastaiであるために簡単にSageMaker上で実行できないことがわかりました。この課題を解決するために、はじめは単純な学習を行えば達成できると思っていたのですが、実際にためしたところfastaiで達成した精度を再現できませんでした。このため、ファーストステップとしてfastaiで用いた関数をSageMakerのベースに使われているApache MXNetで真似て精度を再現を行えるかを試みました。

続きを読む

音声データをAmazon SageMaker上で自動分類してみる

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

  • 検証のアプローチ
  • 実際にためしてみる
    • 使用するデータをさがす
    • 音声からスペクトログラムに表現する
    • データセットを作成する
    • Amazon SageMakerでトレーニングする
    • ハイパーパラメータ調整ジョブを使用して精度向上を試みる
    • 実際にモデルを使用して推論してみる
  • まとめ
  • 最後に

みなさまこんにちは。先進技術調査グループのキシダです。私自身は4つめの記事投稿となりました。ネタ切れ感が否めないですが、前回に引き続き音声データにまつわるテーマをご紹介したいと思います。

さて突然ですが、最近AWSが展開している注目の機械学習サービス「Amazon SageMaker」に関連した記事をよく見かけるようになりました。さらには今年の初旬あたりに Amazon SageMaker Studioなど多数のサービスが発表され、より盛り上がりをみせています。

一方で、私自身は「音声解析」系の技術検証をひっそり行っており、ふと「今話題となっているAmazon SageMakerで音声分類アルゴリズムがサクッと作れたりしないかな?」と思い立ったので、実際に試してみました。

続きを読む

CAN FDの物理層を理解する

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

  • はじめに
  • そもそもCANの1ビットはどうやって決まるのか
    • 物理層 :Physical coding sub-layer (PCS)
    • Bit Timeを構成するSegment
      • Synchronization Segment (Sync_Seg)
      • Propagation Segment (Prop_Seg))
      • Phase Buffer Segment 1 and 2 (Phase_Seg1 and Phase_Seg2)
    • Synchronization:ノード間のビットタイミング同期
      • Hard synchronization
      • Resynchronization
    • Transmitter Delay Compensation (TDC) : 伝播遅延補償
  • おわりに
  • 脚注

はじめに

ハードウェアチームのおおひらです。 本稿では車載の制御通信バス規格として一般的なController Area Network (CAN)の物理層について、その上位側を中心に説明します。

一般的にCAN/CAN FDの仕様について調査するとフレームの種類や構造などのデータリンク層の情報が記載されたドキュメントを目にすることが多いと思います。過去エントリとしては弊社Embeddedチームの久保田の記事(CAN FDことはじめ)だったり、Google検索して出てくるところだとこちらこちらなど。または、Vector社の『はじめてのCAN/CAN FD』 もしかり。

弊社アプトポッドでも、モバイル回線を利用した遠隔車両データ計測を主たるユースケースとしてintdashプラットフォームのCAN FD対応が進んでおり、改めてハードウェア担当として物理層の理解をすべく規格を調査した次第です。 なお用語に関してはCANの規格書 (ISO 11898-1[^1] および BoschのCAN FD仕様書[^2])を参照できるよう、過度に日本語翻訳していません。毎度のことながら、認識に誤りがありましたらご指摘いただけると有難いです。

続きを読む