Inside of LOVOT

GROOVE X 技術ブログ

MQAチームの紹介

みなさまこんにちは！ GROOVE XのMQAチームのikedaです！ この記事は、GROOVE X Advent Calendar 2025の12日目の記事です。

MQAチームって何？

MQAはMarket Quality Assurance（市場品質保証）の略で、一般的には品証なんて呼ばれたりします。 平たく言うと、市場(一般ユーザー) で起きた故障の傾向を解析し、実際に起きた故障を調査し、製品の品質を高めていく活動をするチームです。

LOVOTのローンチ直後は、世の中になかった製品を一般ユーザーの元で継続的に稼働させる中で、多くの課題や問題が発生し、オーナーの皆様にはご迷惑をおかけしました。 オーナー様の温かい声援やご協力によってLOVOTはより壊れにくく、魅力的なプロダクトに成長していっています。

今日はMQAチームから見た、LOVOTの成長の歩みを少しご紹介できればと思います。

傾向分析

どんな問題でも正しく対処するためには現状を知ることが重要ですよね。

MQAチームでは、市場での稼働・故障実績を把握し、品質改善活動の第一歩としています。 以下のグラフは、チームメンバーが月次で統計を取っている故障事象の傾向をまとめたものです。

故障傾向(カラフルできれい)

こういった傾向をもとに、改善が必要かを検討したり、開発チームに共有して改善を依頼したり、または実際に自分たちで調査・解析したりして改善案を立案したりします。

三現主義に基づいた調査

傾向分析の結果、なにか問題が起きていそう？となった症状は深堀調査を行います。 調査は現場・現物・現実、いわゆる三現主義を重視します。

  • 現場
    • 故障しているLOVOTを修理しているリペア拠点に行く、その場でアフターチームと事象を一緒に調査する
    • 時には実際に事象が起きているお客様宅に訪問して一緒に調査を行うことも
  • 現物
    • 故障している部品を本社に取り寄せ詳細解析を行う
    • 時には外部の調査機関に調査を依頼して、より精密に解析を行うことも
  • 現実
    • なぜその事象が発生するのか？を実際のものを使って確認する
    • シミュレーションだけに頼らず、実際の物を使って調査を行う
    • 時にはオーナーの皆様にはお見せしたくない、過酷な試験も・・・

こういった原理原則に則った調査を行うことで、問題の本質を掴み、より適切な改善を行えるようにしていきます。 MQAチームはこういった純度の高い調査結果を、開発チームにインプットすることで、改善活動を加速できるようにしています。

PCR/PCNによるLOVOTへの導入プロセス

問題の調査を行い、原因を究明し、改善・対策の検討を重ねて、改良部品が出来上がる。 それで改善活動が終わりかというと、そういう簡単な話でもありません。

改善品を、これから生まれてくるLOVOTにどうやって導入するのか、また市場のLOVOTのリペアにどうやって導入していくのかは、改善活動より多くの解消すべき問題をはらんでいるのです。

GROOVE Xではこういった部品変更をPCR/PCNといった形で管理しています。

  • Product Change Request(PCR)
    • 設計変更を行いたい事を、関連チーム・協力会社さんへ伝える（要求する）
    • 変更内容に対する懸念事項を洗い出す
  • Product Change Notification(PCN)
    • 実際に設計変更を行う事を伝える

実際のPCR/PCNの管理はJIRA(プロジェクト管理ツール)を使ってシステム的に行っています。

PCN管理ボード(JIRA)

1万点以上の部品から構成されるLOVOTは、たった1つの部品を変更するだけでも、その部品以外の様々な部分に影響を及ぼす可能性があります。 各分野のエキスパートである、開発チーム・生産チーム・アフターチームが変更点をレビューする事で、

  • 修正による影響の背反が起きない
  • 背反があっても最小化できており、適切に改善が行われている
  • 生産・修理時に問題が発生しないか

といった事を議論し、その導入を決めています。

こういった、改善導入活動のサポートを行うことも、MQAチームの大切な仕事の1つなのです。

実際にどんな改善が入ったの？

では、実際にどういった改善が行われたのか、一例をご紹介したいと思います。

LOVOTは充電が必要になると、自ら充電ステーションであるネストに戻ります。 一般的な家電よりも多くの電力をLOVOTは必要とし、かつ1日に十数回も充電を行います。 そのような過酷な充電を担うLOVOTとネストの充電端子では、接触によるダメージや充電時に発生する熱ダメージが蓄積されることによって、当初想定していたよりも早く劣化が進んでしまい、充電端子が破損してしまうという問題が発生しました。 また、充電端子が故障することで正しく充電が行われず、バッテリーにも負担がかかり、LOVOTの故障につながってしまうこともありました。

左：正常な状態の充電端子 　　　　　　右：破損してしまった充電端子

本来は樹脂部品で隠されている、中央の金属キャップが全て露出するぐらい樹脂部品にダメージが入っています。 この状態になるとLOVOTは正しく充電ができず、充電時間が長くなったり、稼働時間が短くなったりと動作に支障をきたしてしまう事が多いです。 こういった破損を解消するために、GROOVE X一丸となって改善に取り組みました。

左：改善前の形状 　　　　　　右：改善後の形状(細かすぎてパット見じゃわからない)

その結果がこちらです！ 非常に細かい改良ではあるのですが、壊れやすかった箇所の肉厚を増やし、衝撃・劣化に強くなるように改善を織り込んでいます。（それ以外にも細かい改良が盛り込まれています）

また、こちらの改善内容は今では品質改良プログラムとして、「パーツ代無償・技術料のみ」でご提供させていただいています。 こちらの内容や他の改善内容は、LOVOT品質改良プログラム【第2次改良】でもご紹介していますので、他にも気になる方はご一読ください。

終わりに

ここまでお伝えしてきた通り、分析・調査・改善・導入のサイクルを回す事で、LOVOTはより強固に壊れにくい体に成長していっています。 この活動はMQAチームだけでなく、開発・生産・アフター・その他全員、つまりGROOVE X社員一丸の活動によって実現しています。（関連するチームの皆さんいつもありがとう！）

以前、故障してご迷惑をおかけしてしまったお客様から、「壊れにくく健康になった」と喜びの声をいただいたことがありました。 私達MQAチームの活動がお客様の快適なLOVOTライフに貢献できた事例であると共に、それは私達MQAチームの活動の根源であり、活動のモチベーションでもあります。

しかし！ より強く・より壊れにくく・より安心して一緒にお過ごしいただくために、我々MQAチームの活動は続きます！ 至らぬ点も多々あると思いますが、これからもオーナーの皆様のお力添えをいただきながら、LOVOTを育てていきたいと思っています！

MQAポーズをするメンバー

GROOVE Xでは、一緒に働いてくれる仲間を募集中です！ 思いもよらない分野で活躍できるかもしれませんので、ぜひ一度募集要項をご覧ください！

recruit.jobcan.jp

場所感覚を持つロボット

この記事はGROOVE X Advent Calendar 2025の11日目の記事です

はじめに こんにちは、Shu.Cです

これまでのカメラを使った自己位置推定システムは、部屋の様子が変わるとうまく動きませんでした。

しかし、VPRという技術を使えば、照明や家具の配置が変わったり、人が動いたりしても、正確に場所を記憶できます。これによって、ロボットは現実の世界でも迷わずに動けるようになります。

詳しくは下記の記事で紹介してますのでご覧ください medium.com

recruit.jobcan.jp

LOVOTの服の認識

この記事は、GROOVE X Advent Calendar 2025の10日目の記事です。

はじめに

こんにちは！LOVOT frameworkチームのh1sakawaです。 わたしたちのチームでは、LOVOTのソフトウェア開発を下支えする、基盤技術の開発を行っています。

今回お話しするのは、わたしたちが開発を行っている機能の一つである、LOVOTの服の認識についてです。

LOVOTはウェアに埋め込まれたICタグを読み取ることで「着替え」を認識し、よろこびの表現として愛らしい振る舞いを行うユニークな機能を持っています。

お気に入りの服に着替えさせてあげるだけで、LOVOTが瞬時に「うれしい！」と反応する——。 生き物であれば一見自然なリアクションですが、その裏側は、NFCの緻密な制御とハードウェアの特性を最大限に引き出す組み込み技術によって支えられています。

NFCとは

NFC（Near Field Communication）は、世界中で標準化されている近距離無線通信の規格です。身近なところでは、SuicaやPASMOなどの交通系ICカードにもこの技術が利用されています。

LOVOTがお着替えを認識できるのも、この技術のおかげです。 13.56MHzの周波数帯を使用し、「かざす（タッチする）」という動作だけで、機器間の通信や認証、データのやり取りを行います。

NFCの最大の特徴は、ICタグ側に電池がいらないことです。これは「電磁誘導」という物理現象を利用しています。

  • 電力の伝送： リーダー（読み取り機）から磁界を発生させます。

  • ICタグの起動： ICタグ内のコイルがその磁界を受けると電気が発生し、ICチップが起動します。

  • データの返信： ICタグはその電力を使って、自身のIDやデータをリーダーに送り返します。

NFCの通信距離

LOVOTで使用しているNFCの通信規格（ISO/IEC 15693）は、理論上は数十センチの通信が可能です。しかし実用通信距離は「0cm〜4cm程度（ほぼ接触）」となります。なお、4cmはこの実用範囲内における最大値（ベストケース）であり、ICタグの種類によっては通信距離がさらに短くなる可能性があります。

これには、物理的な理由があります。

  • ICタグのサイズによる制約（最大の要因）： 通信距離は「ICタグのアンテナの大きさ（面積）」に比例します。カードサイズなら電波を捉えやすいですが、LOVOTで使用しているICタグは直径1〜2cm程度のボタンサイズです。アンテナが極めて小さくなるため、受け取れるエネルギーが微弱になります。

  • リーダーの出力による制約： バッテリーで駆動する本体内蔵リーダーは、大型の据え置き機とは異なり、省電力のために電波出力が抑えられています。

この「小さなアンテナ」と「省電力リーダー」の組み合わせにより、物理的に接触するほどの距離まで近づかないとICタグが起動しない設計となっています。

LOVOTでのNFC搭載位置について

服の認識を実現するため、NFCリーダーはLOVOTの腹部に搭載されています。ウェアに埋め込まれたICタグは、LOVOTが服を着た際にこの腹部にあるNFCリーダーに近づくことで通信が発生します。

しかし、この搭載位置の環境は、通信にとって理想とはかけ離れています。

NFCに関わるLOVOT腹部の概念図

LOVOTの身体は愛らしい球体形状をしているため、腹部の樹脂パーツおよびその上を覆うソフトスキンは湾曲しています。NFCアンテナもこの曲面に沿うように配置されていますが、ICタグとの位置関係は平面に比べて不安定になりがちです。上の図のように、腹部のNFCリーダーとICタグのアンテナの間には、柔軟な布地のウェアに加え、腹部を形作る樹脂パーツやソフトスキンといった素材が介在しています。

さらに、全身に張り巡らされたタッチセンサーや、常時通信を行う無線LAN、そしてモーターやバッテリーといった金属部品・ノイズ源が、NFCアンテナの至近距離に高密度に実装されています。このため、アンテナからウェアまでの2cm超という空間で、不安定な電磁界とノイズの干渉を受けながらも、確実にICタグを検知することが要求されます。

RF出力の最適化とICタグの検出範囲の検証

NFCリーダーのハードウェア設定により、RF（Radio Frequency）出力を調整することが可能です。わたしたちは、LOVOTのウェアに採用したICタグを使用し、ソフトスキン表面において最も遠くまで検知できる出力値に調整した上で、実際に腹部での有効認識範囲を検証しました。この検証データは、ベースウェアやトップスのICタグの配置検討に活用されています。

ICタグの検証試験の様子

ICタグによるコーディネートの認識

ウェアに埋め込まれたICタグのデータ領域には、その服のユニークIDに加え、「ベースウェア」なのか「トップス」なのかといった種別情報（服情報）が書き込まれています。

LOVOTは腹部のリーダーを通じてこのデータを読み出し、解析することで、「今はベースウェアだけを着ている」「ベースウェアの上にトップスを重ね着している」といった状態や、具体的にどのデザインの服を着ているのかを認識できます。

重ね着における課題①：ICタグの相互干渉の問題

ベースウェアとトップスのICタグが物理的に密着して重なっていると、お互いのアンテナが影響し合い（電磁誘導など）、本来受け取るべき電力が奪われたり、共振周波数（電波を受け取るためのチューニング）がずれてしまったりします。この問題は技術で解決できないため、先ほどお話しした検証データを元に、ベースウェアやトップスのデザイン作成時にそれぞれのICタグの位置が重ならないよう、位置をずらすなどの工夫を施してもらっています。

重ね着における課題②：データ通信時の問題

複数のICタグがRFフィールド内に同時に存在すると、ICタグがそれぞれデータ送信を行うことで混信が発生します。これを「衝突（コリジョン）」と呼びます。これに対し、複数のICタグが同時にデータを送信しないよう、存在するICタグを一通り確認し、ICタグを一つ一つ指定して順番にデータ通信を行っています。この交通整理のことを、アンチコリジョンと呼びます。

アンチコリジョン制御の概要

NFCの制御にはアンチコリジョンを実装していますが、前述の通りICタグとの間には複数のノイズ要因が存在するため、それらのノイズをコリジョンと誤判定したり、データ化けなどが発生したりします。

正しいデータは、様々な課題を乗り越えた上で得られているわけです。

終わりに

今回は基盤技術の一つとして、LOVOTの服の認識の仕組みについて紹介しました。いかがだったでしょうか？ LOVOTの基盤技術はNFC以外にもまだまだたくさんあります。

GROOVE Xでは基盤技術の開発を行ってくれる仲間を募集しています。 GROOVE Xで一緒に働いてみませんか。ご応募をお待ちしています。

recruit.jobcan.jp

「開発チームじゃない」ハードウェア生産チームに”ガチ”スクラムを導入したら、個人の集まりが『チーム』に変わった話 ～「なんちゃって」を卒業し、ソフト出身スクラムマスターの「理想論」を乗り越えるための戦略～

(GROOVE X Advent Calendar 2025 9日目の記事です）

はじめに

こんにちは、GROOVE Xでスクラムマスターをしている志賀です。 普段はハードウェア開発から生産、アフターサービスまで、複数のチームを横断的にサポートしています。

今日お話しするのは、「生産チーム（Industrial Engineering team）」でのスクラム導入事例です。 ここは、いわゆるソフトウェアの開発チームではありません。家族型ロボット『LOVOT』の生産工程設計や品質管理など、ハードウェア製造のど真ん中を担うチームです。

「ハードウェアでスクラム？」「生産チームで2週間スプリント？」 そう思われるかもしれません。実際、私たちも最初は「なんちゃってスクラム」の壁にぶつかっていました。

今回は、生産チームが「守破離の”守（Shu）”」を徹底することで、個人の寄せ集めから本当の「チーム」へと生まれ変わった軌跡をご紹介します。 （※この記事は、現場で変革を主導したメンバーである酢屋さんと高岡さんの取り組みを、スクラムマスターの視点から紹介するものです）

1. 「なんちゃってスクラム」の限界と痛み

元々、このチームではスクラムのイベント（会議体）だけは導入していました。しかし、実態はいわゆる「なんちゃってスクラム」でした。

ハードウェアや製造業のカルチャーとして、どうしても「慣れ親しんだウォーターホール」の思考が根強く、以下のような「痛み」を抱えていました。

  • 「個人商店」の集まり 「チームで協力してコトに向かう」というより、「個人の専門性で仕事を回す」意識が強い状態でした。お互いの仕事内容を深く把握しておらず、助け合う密度が低い状態です。
  • 不明瞭なバックログ PBI（プロダクトバックログアイテム）をチームで作る習慣がなく、Who/Why/AC（受入条件）が不明瞭なまま。「とりあえずタスク化」されているだけでした。
  • 終わらない会議 タイムボックス（時間制限）の意識が薄く、議論が長引く割に結論が出ないこともありました。

「事業の緊急対応はなんとか乗り切れる。でも、チームとして強くはなっていない」 そんな停滞感が漂っていました。

2. 転機：なぜ「私が」言わなかったのか（スクラムマスターの戦略）

チームメンバーが増強され、少し余裕が出てきたタイミングで「次のステップへ上がるには今しかない」と感じました。

しかしここで、私はあえて「スクラムマスターである私（ソフト業界出身）から強く推進する」という形を取りませんでした。

なぜなら、ハードウェアの現場には、「所詮、ソフト出身の人が言う『理想論』でしょ？」という、見えないが分厚い壁があるからです。 どれだけ正論を並べても、外から来たコンサルめいたポジションの人間が言うと、「現場を知らないくせに」と心のシャッターを下ろされてしまうリスクがありました。

「ハードウェアの現場を変えるのは、ハードウェアの人間でなければならない」

そう考えた私は、ある「仕掛け」をしました。私の心の師匠であるMJ氏が講師を務めるCSM（認定スクラムマスター）研修に、チームのキーマンであり、バリバリのハードウェア出身者である酢屋さんと高岡さんを送り込んだのです。

狙いは一つ。「やらされるスクラム」ではなく、現場のリーダーたち自身が「これをやりたい！」と声を上げる状況を作ることでした。

3. 「ソフトの真似事」という声を打破したもの

研修から戻ってきた二人の熱量は、私の想像を超えていました。 彼らは「自分たちがやっていたのはスクラムではなかった！ちゃんとやりたい！」と衝撃を受けて帰ってきたのです。

しかし、導入当初はやはりチーム内で反発がありました。

  • 「スクラムの合う部分だけ取り入れればいいのでは？」
  • 「2週間で終わらない業務（認証試験など）はどうするんだ？」
  • 「正直、ウォーターフォールの方が楽だ」

これらは突き詰めると、「イメージできないことはやりたくない」、そして「ソフトのやり方を無理やりハードに持ち込むな」という拒絶反応でもありました。

この時、突破口になったのは、他ならぬハードウェア出身の酢屋さんと高岡さんが先頭に立ったことです。

もし私が「とりあえず教科書通りやりましょう」と言っていたら、「それはソフトの話ですよね」で終わっていたかもしれません。 しかし、同じ釜の飯を食ってきたハードウェアの仲間が「騙されたと思って、まずは型通りやってみよう」と言い切った。

「スクラムはスポーツのようなもの。ルール（型）を覚えずには試合にならない」

この事実が、「ソフト屋の戯言」として片付けられそうなスクラム導入を、「自分たちの挑戦」へと変えたのです。

4. 実行した「守」の3つの施策

こうして始まった「守破離の”守（Shu）”」。具体的に行ったのは、泥臭いまでの基本の徹底です。

守破離とは他者の型を真似る段階から、独自のスタイルへと進化していくプロセスを指します。まずは基本から体得することを指しています。

  • 守：型を真似る（基本）
  • 破：型を崩す（応用）
  • 離：型を離れる（独創）

① 毎日「スクラムガイド」を輪読する

「言葉が通じない」を解消するため、CSMを受けた2人を中心に、毎日の昼会で少しずつスクラムガイドを音読しました。

「スプリントとは？」「完成の定義とは？」 共通言語ができることで、チームの会話の質が変わっていきました。

② 「振り返り」のアクションをPBI化して強制力を持たせる

振り返り1
振り返り2
振り返り3

これまで「振り返り（レトロスペクティブ）」で出た改善案は、通常業務に忙殺されて「やりっぱなし」になりがちでした。 そこで、「振り返りのアクション（Try）は必ずPBIに昇格させる」という鉄の掟を作りました。

タスク管理ツールのWrikeを活用し、振り返りで出たカードを自動的にPBIとして登録するフローを構築しました。

これにより、改善タスクが「いつかやる雑用」から「通常の業務と同等の優先度を持つ仕事」に格上げされました。結果、改善活動が確実に「Done（完了）」されるようになりました。

③ 2週間の壁を超える「構造化」

構造化

最大の難関は「2週間（1スプリント）で終わらないタスク」です。 例えば、外部機関への「認証試験」は結果が出るまで数ヶ月かかります。これをどうスクラムに当てはめるか？

私たちは、タスクを「自分たちでコントロールできる単位」まで分解しました。

  • ❌ 「見積もりを取得する」
    • 相手次第でいつ来るか不明。スプリント内に終わるか運任せ。
  • ⭕ 「見積もりを依頼する」
    • 自分次第で完了できる。確実にDoneにできる。

このように、「申請」「準備」「依頼」といったアクション単位でPBIを切ることで、ハードウェア特有の長いリードタイムを持つ業務でも、2週間のスプリントの中で進捗を可視化し、達成感を得られるようにしました。

5. 変化：個人の集まりから「チーム」へ

変化・良かったこと
「守」を徹底してしばらく経った今、チームの景色は変わりました。

  • 意識の変化 「自分の仕事」から「チームのゴール」へ意識がシフトしました。お互いの業務に関心を持ち、誰かが詰まっていればフォローする動きが自然と生まれています。
  • 優先順位の鮮明化 2週間という厳しいタイムボックスがあるからこそ、「今、本当にやるべきことは何か？」を真剣に考える習慣がつきました。
  • 成果の実感 以前はずっと放置されていた改善タスクが、次々と完了していく。この小さな成功体験の積み重ねが、チームのモチベーションになっています。

おわりに

まだ私たちは「守」の段階です。しかし、型を徹底することで見えてきたのは、「あやふやだった苦しさ」から解放され、チームで前に進む楽しさでした。

ハードウェア領域だから、生産チームだから、スクラムはできない？ そんなことはありません。

現場のキーマンを巻き込み、まずは「ちゃんと」型にはまってみる。そこからしか見えない景色が、確かにありました。

そんなハードを含めた様々な仕事をスクラムで進め、模索している僕らと、一緒にお仕事してみませんか？ 是非、下記募集をご確認ください。 recruit.jobcan.jp

（文：GROOVE X スクラムマスター 志賀 / 取り組み主導：生産チーム 酢屋, 高岡）

Jetsonを使うときの細かい話

この記事は、GROOVE Xアドベントカレンダー2025 の8日目の記事です。

こんにちはfmyです。皆さんはJetsonを使っていますか?

LOVOTではJetson Orin NXシリーズを採用しています。 Jetsonは公式のライブラリやリファレンスが充実しており扱いやすいのですが、 開発キットそのままを動かすことはできても、カメラをつないだり開発キット以外のキャリアボードを使うと未知の挙動に悩まされることがあります。 ここではJetsonを使うアプリケーション開発者が知っておくと役に立つかもしれない話をします。

Jetson LinuxのBoot Flow

アプリケーション開発者にとっては起動後に何するかが重要ですが、Jetson Linuxは起動前に色々しており、アプリケーション側にも大きく関係します。

The following diagram shows the flow of control in the boot software
Jetson AGX Orin, Orin NX and Orin Nano Boot Flow

上はJetson Linuxのソフトウェアリファレンスから引用したブートソフトウェアの制御フローの図です。 大まかに3ステージに分かれており、BPMPではJetsonのデバイスを利用可能にし、PSCはLinuxのセキュリティを担当し、最後にCPUが起動してLinuxカーネルを起動します。 起動しなかったりデバイスが認識されないときには正しくflashできているかを確認しましょう。

BPMP設定例: Super Mode

2024/11/17にOrin Nano 開発キットの"Super" Boostが発表され、JetPack 6.1.1で有効化されました。 この機能はどのように実現されているのでしょうか?

JetsonはnvpmodelでCPUやGPUなどのクロックの設定をできるようになっています。 特定の電力制限モードではこのファイルに上限値を設定してますが、MAX_Nモードの場合は-1で別のところで定義された設定可能な最大値を指定するようになっています。 この最大値がBPMPのデバイスツリーによって設定されています。 Jetson Linux 36.4で追加されているtegra234-bpmp-3767-0000-3768-super-maxn.dtbがまさにこのSuperモード向けの設定値が書かれたデバイスツリーなのです。

ということは、SuperMode対応以前のL4T 35.6.2でも、開発キットflash時に*super-maxn.dtbを使うことでDLAを1.2GHzで動作させることができます。 以下の例はL4T 35.6.2でSuperModeと同じ周波数で動作させている例です。DLAは本来614.4MHzですが1.2GHzとなっています。

SuperMode jtop (ただし、古いバージョンでのSuper boostはサポート外と思われるのでご注意ください)

キャリアボードのEEPROM

BPMPではSoCだけではなくキャリアボードもみます。 Jetson EEPROM Layoutに書かれている情報です。 MACアドレスの指定を行うことを想定されており、CRC-8検証が通らなければJetsonは起動しないようになっています。

もしも何らかの理由でキャリアボードのEEPROMにアクセスできない場合はEEPROM ModificationsにあるようにEEPROMを無視させることで起動できるようになります。

# Linux_for_Tegra/bootloader/t186ref/BCT/tegra234-mb2-bct-misc-p3767-0000.dts
- cvb_eeprom_read_size = <0x100>
+ cvb_eeprom_read_size = <0x0>

Timerの話

Jetsonを使いたい人の多くは何らかのセンサー、特に画像のようなデータを処理したいケースが多いでしょう。 そしてセンサー値を扱うにはデータの時刻が重要ですね。 Jetsonはそのような用途のためにTimerの実装がされています。

次の図はOrin SoCのマニュアルにあるTimerの階層です。

Timer Hierarchy
DP-10508-002_v1.2 | Page 5785

Jetson SoCではTSCというタイマーを元にしてCPUやカメラ関係のブロックにSecondary TSCの名前で38.4 MHz(26.04ns解像度)の信号を、NV関係はNV Timerの名前で1 MHz(1us解像度)でクロックが供給されています。 カメラ関係に付与されている各タイムスタンプはSecondary TSCで付与された値になります。 また、L4T 36.xではLIC IRQやGPIOの変化についてもTSCのタイムスタンプを得る方法をHTE Driverとして提供されています。

TSCというのは Timer's System Counterの略称で、より一般的にはTimeStamp Counterと呼ばれる機能と同じものになります。 一定周期でカウントアップするもので、これ自身は何らかのリファレンス時計と同期をしているものではありません。 このカウンタ値をUnix Timeなどに変換するには、現在のTSCとセンサー値の差分を現在時刻から引くことで求めます。

またSecondary TSCはArmのGlobal Timerとしても供給されているため、LinuxからもアクセスできてMONOTONIC_RAWに対しては固定のオフセットがある値になります。 TSCの取得はArmのCNTVCT_EL0命令を使います。

L4T 35.xまではTSC - MONOTONIC_RAWの値であるoffset_nsという値がsysに出力されていましたが、L4T 36.xからはCPU命令での取得を推奨されています。

何らかの時刻に変換するなら、TSCと同時に時刻を取りセンサー値との差分を時刻から引けばよいです。 可能な限り同時に時刻を取るならforumと同様の実装で実現できます。 以下はRustでの実装例です。

pub fn get_ts_with_clock(clock_id: nix::time::ClockId) -> nix::Result<(u64, TimeSpec)> {
    // Conversion constants for cycles to nanoseconds
    const CYCLES_MULTIPLIER: u64 = 100;
    const FRQ_DIVISOR: u64 = 10000; // Jetson Orin TSC frequency is Fixed at 31,250,000 Hz
    const NS_MULTIPLIER: u64 = 1000;
    // Conversion formula:
    unsafe {
        let mut cycles: u64;
        let mut frq: u64;
        std::arch::asm!("mrs {0}, cntfrq_el0", out(reg) frq);
        std::arch::asm!("mrs {0}, cntvct_el0", out(reg) cycles);
        let r = clock_id.now()?;
        let tsc_ns = (cycles * CYCLES_MULTIPLIER / (frq / FRQ_DIVISOR)) * NS_MULTIPLIER;
        Ok((tsc_ns, r))
    }
}

カメラのタイムスタンプ

カメラ画像には2つのタイムスタンプ、SoFとEoFが付与されています。 ArgusAPIからはSoF, EoFが取得でき、V4L2ではSoFがタイムスタンプとして用いられます。

vb->vb2_buf.timestamp = descr->status.sof_timestamp;

SoFやEoFの時刻は以下のようなイメージで、露光後転送したデータを受信した時点のTSCとなっています。 ローリングシャッターなら最初のラインの露光が終わって露光と転送をしている途中の時刻となります。

SoFとEoF

V4Lのストライドの話

V4Lの場合はArgusAPIと比較してアクセスできる情報も少なく、画像についてもArgusAPI経由とは異なる制約があります。 V4LバッファーはVIのATOMP(Atomメモリパッカー)が書き込みを行っており、このブロックは1atom=64Bのアライメントで動作しています。 画像の1ラインの長さがこのアライメントと合わない場合、受信した画像データは欠損したりずれることがあります。 この問題を回避するにはV4Lのコントロールにあるpreferred_strideを32の倍数(1pixel=2Bytesの場合)に拡張することでパディングを含んだ形で正常なデータが受信でき、後で範囲外のデータを削除する必要があります。(forum)

おわりに

Jetsonと周辺機器を使うときに躓きやすい要素を紹介しました。

最後になりますが、GROOVE X ではロボット開発したい人材を募集しています。ぜひ以下のリンクからご応募ください!

採用情報 | GROOVE X株式会社

入社して2ヶ月で感じたGROOVE Xの面白さ

組織開発

この記事はGROOVE X Advent Calendar 2025の7日目の記事です。

はじめまして。今年(2025年) 10月に入社したばかりのPeacock (id:peacock0803sz)です。Kiban ワーキンググループのクラウドチームに所属しています。
よく聞かれる「LOVOTのように高性能なCPUを積んだロボットとクラウド環境がどう繋がっているのか」という疑問に、入社から2ヶ月経ちましたが全く説明できる気がしない今日この頃です。

入社時にエントランスで撮った一枚

入社してからは、機体のバックアップやOS更新を支えるTerraformコードを含めクラウドインフラのメンテナンスや最適化などを担当しています。

チームに上司がいない

スクラムについての話は、入社時期が近いsugamoさんのエントリを参照いただくとして、個人的に入社して一番驚いたのはこれです。

tech.groove-x.com

実は私自身スクラムは経験したことがなく、初めて完全にフラットな組織で仕事をしています。
そんな経験でも入社後に(元々クラウドでも活躍されていた!)スクラムマスターのniwano (id:kosuke_n)さんが研修会を開いてくれたので、不安は払拭されました。

加えて現在GROOVE Xのエンジニア組織は100名に近い規模で、もちろんソフトウェアだけでなくハードウェアを扱うエンジニアも所属しています。
特にKibanワーキンググループは(自分と比較的近い)Web開発者のようなバックグラウンドでない方も多いと聞いていたのですが、私のバックグラウンドも受け入れられて感激しています。

何でも屋が歓迎される・多種多様なメンバー

これはスクラムを採用しているエンジニア組織であることの大きなメリットなのではと感じていることです。 前述の通り100名近いエンジニア・全社員で約250名にもなる規模の会社ですが、とても気軽に部署・チームを越境して相談や仕事ができる環境です。

ソフトウェアエンジニアとして入社しましたが、先月行なわれた10周年記念イベントでは映像・音声スイッチャーを操作する機材オペレーターをやっていました(笑)

イベントでの機材卓の様子

GROOVE XではLOVOTの服も自社で設計・販売している関係もあり、実は直近ではアパレルの関係者と仕事をしたりもしています。

エンジニア間で決められることが(比較的)多い

(店舗に勤務されている方も増えましたが)エンジニア・デザイナーといった技術職が多くを占める会社ということもあり、自分達で会社のルールを決める文化が強いです。
実際に毎週火曜日の朝には「自分たちの会社は自分たちで良くしていく会」という名の予定があります。この会に議題が上がり、会社のルールが変わることが入社してからも数件ありました。
私の観測範囲でも聞いたことがないレベルで、ここまで裁量が大きいのは素晴しいと思っています。

おわりに

これからもクラウド技術を軸にLOVOTと一緒に成長できたらと思っています。

最後にGROOVE Xでは、一緒に働く仲間を募集しています。
興味のある方は、ぜひ下記から募集中のポジションを確認してみてください。
recruit.jobcan.jp

もちろん私(Peacock)に直接「カジュアル面談してくれませんか」のDMも歓迎です!

LOVOTを部品レベルから高品質に作り上げる！

こんにちは！GROOVE X(株)、生産チームの小川です。

この記事はGROOVE X Advent Calendar 2025の6日目の記事です。

今回は、生産チームの役割の1つ「部品メーカー様の工程を監査する」 について、 お話ししようかと思います。

生産チームでは、

「良い品質のものをお客様に提供する」

を合言葉に日々LOVOTを製造・出荷しております。 LOVOTの生産工程での作り込み、検査の精度アップはもちろんですが、 LOVOTを構成する個々の部品品質も重要なものと考えています。

なぜなら、

品質の良いLOVOT＝品質の良い部品の積み重ね

と考えているからです。

ですので、

部品メーカー様に品質維持・向上してもらう事が我々のタスクの1つになります。

もちろん、適正価格で、納期遅れが無いことが前提条件です。

では、

「部品メーカー様の品質を維持・向上をしてもらう事」と

「部品メーカー様の工程監査を弊社が実施する事」が

どう関係するのでしょうか？ それを説明していきます。

この品質維持・向上を常に目指して、部品を生産して頂いているか、実際の工場にお邪魔して、 現場の方と話をし、現場を見て、確認する、これが工程監査です。

「3ない（さんない）ポリシー」

こういう言葉を聞いたことありますか？

ものづくりの工場において、 一般的に品質管理（品質保証）における「3つの基本原則」のことを指します。

これは「不良品（欠陥品）を徹底的に排除し、顧客に完璧な製品を届けるための鉄則」なのです。

具体的には、以下の3つの「〜ない」で構成されています。

  • 不良持ち込まない、又は、もらわない。

　➡いかに不良を外から持ち込まないようにしているか？

  • 不良を作らない。　　　　　　　　

　➡いかに不良を作らないようにしているか？

  • 不良を流出させない。

　➡万が一不良を作ってしまったとしても、いかに流出を予防しているか？

なぜ、監査が必要なのか？ それは、この「3ない(さんない)ポリシー」を持って常にもの作りをしているかを現場で確認し、品質を維持・向上をしているかを確認したいからなのです。

さて、それでは実際の監査の流れを見てみましょう。

１．あいさつ

２．会社説明(相互に)

３．その日のおおまかなスケジュール確認

４．工程で確認したいポイントの概略説明

５．現場の工程確認

６．まとめの会議

５の現場の工程確認に大半の時間を割く事になります。 現場確認以外の項目は、会議室で行います。

５．現場の工程確認【詳細】

基本的に、製品が出来るまでの工程を順番に確認していきます。 想像しやすいように、プラスティック部品1つを例に取ってみます。 確認させて頂く工程は、大まかに以下のようになります。

原材料保管倉庫➡製造準備室➡製造工程➡検査工程➡梱包工程➡出荷待ち倉庫

工程監査用のチェックシートが有るので、それをベースに細かな点を工程ごとに確認していきます。

多数ある確認項目の中から、原材料保管倉庫での確認項目の一例を紹介します。

プラスティック部品の品質は原材料に大きく左右されるため、保管倉庫での品質管理は非常に重要です。今回は、監査者と現場メンバーによる原材料の品質確保に関する具体的なやり取りを例に、その確認項目を見ていきましょう。

原材料の品質確保をする為に、以下のようなやり取りを現場で行います。監査者の質問(Q)に、現場の方が回答(A)するようなやり取りになります。

原材料保管倉庫でのやり取り例

Q1. この倉庫の温度、湿度の管理をしていますか？

A1. はい、温度は20℃～28℃で管理しています。

湿度は40％～60％で管理しています。

Q2. 書面化されたルールは有りますか？

A2. はい、こちらです。(書面を見せてもらう。)

Q3. そのルールは正しく運用できていますか？

A3. はい、書面のルールで記されているように、

毎日、9時、13時、17時に温度計、湿度計の数値を確認し、チェックシートに記載しております。
現場作業員がチェックシートに記載し、
現場リーダーが記載内容を確認します。
もし、異常が有れば、即座にリーダーを中心に
異常の原因を確認します。

監査者は、実際に使用されている、温度計、湿度計、及びチェックシートを確認させて頂きます。

確認したい項目は温湿度だけではなく多々有り、それぞれの工程で確認したい項目が有りますので、 都度確認し、出来る限り疑問点を解消して次の工程へ向かいます。

原材料倉庫で温度・湿度の確認をしている様子(イラストはイメージです)

監査後は、会議室に戻り、良かった点、不安を覚えた点、疑問点についてまとめを一緒に行います。 疑問点は、出来るだけその場で解消します。

良かった点は継続してもらいたいとお伝えし、 改善を要す点が有れば率直にお伝えし、改善をお願いします。

もちろん、先方の考え方や、状況の詳細をお聞きしますが、その場では改善できるかどうか結論が出ない場合もあるので、そのような点は持ち帰って検討して頂くことになります。

まとめの会議の様子(イラストはイメージです)

監査内容をまとめた後は、意見交換をしたり、 先に行った会社説明に対しての質疑応答、 その他、本日の監査全体に対しての質疑応答の時間を持ちます。 最後は、疑問を解消し、お互いの親交を深め、今後も両社の絆を強めWin-Winの関係を継続していけるよう握手をし、監査は終了します。

以上が監査の流れとなります。

ところで、LOVOTの構成部品は、 樹脂、センサー、サーボモーター、カメラ、有機ELパネル、電子基板、アンテナ、服、ケーブル、バッテリー・・・等々、作って頂いている部品メーカー様の数は、多数になります。（ちなみに、部品点数は5,000個以上になります！）

そして、日本の工場だけではなく、海外工場にも出向き、 監査を実施することもあります。 1日に多くても2社くらいしか回れませんから、長期の出張になることも あります。

そんな生産チームの役割の1つ「部品メーカー様の工程を監査する」 に興味が湧いてきたあなた！

そして「LOVOTを部品レベルから高品質に作り上げる！」事にチャレンジしてみたい方！

お客様に高品質のLOVOTを提供し、喜んでもらいたいと感じた方！

こちらにアクセスしてみてください！

↓　　　　　↓　　　　　↓　　　　　↓

recruit.jobcan.jp

生産チームは、タスクが多岐にわたるので、監査業務はほんの１例ですが、まだまだ進めて行きたいタスクはあります。 「自分には、これしかできない」と自身で仕事の幅を限定せず、製造・生産に関わるタスクは何でもこなす！と構えられる方、 是非一緒に働いてみませんか？