はつねの日記

Kinect, Windows 10 UWP, Windows Azure, IoT, 電子工作

Microsoft Group TranscribeがiOSアプリとして登場

www.microsoft.com
Microsoft Translatorアプリでも実現でしていましたが、よりリアルタイム性が高い感じで翻訳ができるMicrosoft Group Transcribeアプリが登場してきました。まずはiOSアプリから。
バイスのマイクを使ってその場で音声を取得するので「スマホは発話者のそばで!」みたいな使い方Tipsが書かれていますね。
回線経由の音声じゃない分、音声認識率はよさそうですね。

どうやって会議室をつくるの?

同じ部屋の中にいる人通しではアプリを立ち上げるとbluetoothでみつけてワンタップで参加できます。
あとは5桁のコード、もしくは、QRコードでも同じ会議室にさんかできるので、遠く離れた人同士は5桁のコードで参加ですね。

どこが便利なの?

5桁のコードが判ってしまうと世界中の誰でも参加できるし、近くにいる人とはbluetoothでサクッと参加できますね。
とにかく不特定多数の人との会話の文字起こしには便利ですね。
一方、企業内の会話とかに外に漏れたくない場合なんかはちょっとダメそうですね。適材適所というところでしょうか。

動作ってどんな感じ?

日本語端末で話をすると、自分の発話の日本語のみが表示されます

英語端末に届くと日本語がでて、その下に英語で翻訳されます。

英語端末で英語を話すと、自分の発話の英語のみが表示されます。

日本語端末に届くと英語が出て、その下に日本語で翻訳されます。

同時に話すとどうなるの?

同時に話すと誰か1人の端末の音声認識だけがONになるようです。
つまり複数人が同時にどんどん喋ったとしても、少しでも早く話し始めた人以外は認識がONにならないようです。
でも、ちょっとでも息継ぎで間を開けると認識していた端末以外の音声をその瞬間だけ取得するような動きです。
「ちょっとまって」とか入れずらいので、話す側が少し工夫したりするといいんじゃないでしょうか。

会議が終わった後のデータは?

会議中の発言(つまり表示されていた状態)は、いつでも履歴から参照できます。
そこから共有もできますね。
端末ごとに履歴の内容が違う(言語ごとに、他国語から自国語への翻訳表示部分が違う)ので端末に保存されているのかな。

使ってみてどうだった?

話し始めて、最初の文字がでてくるまで若干待たされる感じはしますが、そこからは比較的スムーズです。
類似の無料アプリがいろいろありましたが、そのあたりを使っている場合は、これで充分かな。

協力しよう

発話した内容は「会議の録音は、複数の話者の会話を理解して、会議中に同じ言語を話す全員のMicrosoft オンライン音声認識技術の品質向上に役立つ可能性があります。」
ということで会議の録音を投稿する機能があります。
自国語の音声認識率をあげたいときは、社外秘の会話ではないのであれば、投稿するのもいいかもしれないですね。

Microsoft Ignite 2021に合わせてUpdateされた私が注目するAzrue関連について

Ignite 2021が始まりましたね。
開発者していると分かるのですが自社イベントに合わせて自プロダクトの新機能の提供を開始するとかはよくある話です。
ギリギリスケジュールでとりあえず形だけってケースも多いと思うけれど、Microsoftさんの場合は、Private Preview→Public Preview→GAみたいなマイルストーンで確実に提供する感じなのでイベント合わせのリリースもすごくきっちりしていますね。
今回もたくさんのUpdateがありましたが、その中から注目している分野に絞ってご紹介します。

Azure Communication Services

.NETラボ 勉強会 2020年11月 - connpass
.NETラボ 勉強会 2020年10月 - connpass
.NETラボでも何回か登壇させてもらったネタであるACSことAzure Communication ServicesのUpdateをご紹介します。
azure.microsoft.com
ACSの裏側はTeamsと同じアークテクチャーであることは公言されていましたし、ACSでビデオ会議を作るとそのURLはTeamsのそれと非常に似た構造ですし、繋がるようになるよとは書かれていたのですが、いよいよPublic Previewとなって誰でも試せるようになりました。

何がうれしいの?

何がうれしいかといえば、自分のアプリからTeamsにつながることですね(そのままですね)。
Windowsだったら「自分のアプリとTeamsアプリ」みたいな感じで2つアプリを立ち上げればいいのであまり嬉しさは感じられないかもですね。
でも、スマホだったらどうでしょうか。2つアプリ同時起動して使うのはなかなか面倒ですし、自アプリとTeamsの両方で音声を使おうとするとTeams側に全部マイクを持ってかれちゃうなんてこともあります。
そこで登場するのが、ACSを組み入れて自分のアプリの中でTeams会議への参加部分も完結しちゃうアプローチですね。

ACSってどんな技術なの?
ACSからTeams会議にはどうつなぐの?

docs.microsoft.com
ACSのビデオ会議に接続するAPIで接続先をTeams会議に合わせて次のように指定する感じですね。

const locator = {
threadId: [thread id],
organizerId: [organizer id],
tenantId: [tenant id],
messageId: [message id]
}

Teams会議の会議URLの構造は次のようになっているので、そこから抜き出して設定ですね。

http://teams.microsoft.com/l/meetup-join/[thread id]/[message id]?context={"Tid":"[tenant id]","Oid":"[organizer id]"}

Azure Object Anchors

azure.microsoft.com
現実空間とデジタル空間のオブジェクトの位置合わせをAzure上で行うAzure Object AnchorsがPublic Previewになりましたね。
いままでは限られた範囲での公開でイベントで事例などがあっても自分たちで試せませんでしたが、これで誰でも試せます!

Azure Remote Rendering

azure.microsoft.com
3DモデルのレンダリングをAzure側で行って、結果を受信できるAzure Remote RenderingがGAとなりました。
ポリゴン数が多いような場合でもAzureパワーでなんとかなってしまいます。
東日本でも使えるので、より低レイテンシーな使い方ができるようになりましたね。

Microsoft Mesh

techcommunity.microsoft.com
マルチデバイスでリアルとバーチャルを融合するMicrosoft Meshが突然Previewしてきました。
詳細はまだよく調べていませんが、HoloLens 2アプリとAltspaceVRアプリがすでに提供されていて、その間でいろいろ共有できるみたいです。

Cognitive Services

Speech ServicesとかTranslatorとかは特にUpdateないみたいです。

それではDay2も眠いけど楽しみですね。
Day1も日本の昼間にリピートセッションあるので、ぜひ!

Xamarinで作成したAndroid App Bundleを端末にインストールする

2021年8月からは、Google Playに新しくアプリを登録するには、従来のapkではなくAndroid App Bundle(aab)で登録することが必要になります。
Visual Studio + XamarinでAndroid向けアプリを作成するときも、もちろん、apkだけではなくaabで作成できます。
初期のころはaab作成がVisual Studioからはできず、MSBuildを使ってコマンドラインでaabファイルをつくらなければなりませんでしたが、最近のVisual Studioではアーカイブでも可能です。

Androidオプションを設定する

aabを作成するには、Androidアプリのプロジェクトのプロパティを表示して、Androidオプション画面で設定します。
aab作成には本当に時間がかかるので、Release構成のみの設定が推奨されています。

Release構成で設定する

そのため、[構成]を「Release」にしてから設定を変更します。
f:id:hatsune_a:20210218073903p:plain
設定は簡単で、Androidパッケージ形式を「バンドル」にするとaab作成となります。このとき次の2つのチェックボックスが、値固定でグレーアウトします。

  • [選択したABIごとに1つのパッケージにします]はOFF
  • [インクリメンタルAndroidパッケージシステム(aapt2)を使用します]はON
aapt2とは

aapt2(Android Asset Packaging Tool)は、アプリのリソースをコンパイル、パッケージ化するために使用するビルドツールです。AAPT2 はリソースを解析してインデックスに登録し、Android プラットフォーム向けに最適化されたバイナリ形式にコンパイルします。

Debug構成で設定する

2つの設定が固定化されるのであれば、Debug構成でも同じ設定にしておいてデバッグしておくことが安全です。
aapt2については新規プロジェクト作成時はデフォルトONになっていますが、以前から使っているプロジェクトではOFFになっているものも多いでしょう。
それでは、[構成]を「Debug」にしてaapt2をONに設定しましょう。
f:id:hatsune_a:20210218075244p:plain
Visual Studioが至れり尽くせりだなーと思うのは、Release構成側で「バンドル」を指定すると、Debug構成側も自動的に2つのチェックボックスが同じ値でグレーアウトしていました。
もちろん、パッケージ形式は「apk」のままです。

アーカイブを実行する

構成ごとの設定がおわったら、Release構成をアクティブにしてアーカイブします。
f:id:hatsune_a:20210218080119p:plain
アーカイブが成功すると、アーカイブマネージャーにバンドル形式「aab」のエントリが表示されます。
f:id:hatsune_a:20210218080434p:plain

配布用に署名する

アーカイブができたら、[配布]ボタンをクリックして「アドホック」でファイル作成して手動でGoogle Play Consoleにアップロードするか、「Google Play」でアップロードまで行うかを選んで、署名付きaabを作成します。
実機にインストールするためには、「アドホック」を選択して署名付きaabファイルを作成しましょう。

aabを実機にインストールする

署名付きaabを実機にインストールしたいときは、adbコマンドを使って実行します。
f:id:hatsune_a:20210218100427p:plain
Visual Studioのメニューからコマンドラインを起動して、USBに実機を接続してUSBデバッグを許可したらadb installします。
f:id:hatsune_a:20210218100918p:plain
Successが出たら終了です。
実機で動作を確認してみましょう。

Google Play Consoleにアップロードする

実機確認できたら、署名付きaabをGoogle Playに登録してみましょう。
試しに、登録済のapkと同じバージョンとバージョンコードで作成して登録してみると次のようなエラーとなりました。
f:id:hatsune_a:20210218090633p:plain
当然ですが、apkとaabで同じバージョンをアップロードはできないようですね。

Google Playでアプリを署名する

ついでといっては何ですが、配布するならば「Google Playで署名されています」マークを付けておきたいですよね。
新規に登録するときは自動的にGoogle Play Consoleで次のような表示になります。
f:id:hatsune_a:20210218090543p:plain
既存登録済でこの表示がない場合は、手動で設定しないといけないのですが、次のQuitaが分かりやすかったです。
qiita.com
qiita.com
上から順番に読んでみると理解しやすくお勧めです。

それではVisual StudioでのAndroidアプリ開発、楽しんでいきましょう!

NAudioをUWPで使うときの注意点

以下、NAudio v1.10での確認となります。
NAudioですが、音声入出力に非常に便利なライブラリで、.NET Framework以外にも様々なプラットフォームで動作します。
github.com

しかし、UWPで使用する場合、いつくかの注意点があります。

.NETネイティブコンパイル時の注意点

それは、ARM / ARM64に限らずx86をプラットフォームターゲットとしたときも.NETネイティブコンパイル時には次のような実行時エラーが発生します。

System.ArgumentException: 'Unsupported Wave Format'

この実行時エラーは、NAudioのサンプルコードでNAudioUniversalDemoがあるので、そちらで確認することができます。
このサンプルコードを.NETネイティブコンパイルして実行して「Record」ボタンをクリックすると、NAudioの中、具体的には、NAudio.Wave.WasapiCaptureRT.InitializeCaptureDeviceの中で下記のエラーが発生します。
こちらは録音デバイスがサポートしていないWaveフォーマットを指定したからだということです。
こちら、.NETネイティブではないときには、WaveFormatとしてサンプリングレート48000、32ビット、1チャンネルのIeeeFloatなフォーマットが自動的に指定されますが、.NETネイティブコンパイル時はその自動指定が行われず、ソースコードを読む限りはAudioClient.csの中のpublic WaveFormat MixFormatプロパティのGetの中でaudioClientInterface.GetMixFormatのところで取得ができていないようです。

注:Visual Studio 2019を使用し、ターゲットバージョン=2004 (ビルド19041)、最小=1803(ビルド17134)を指定

.NETネイティブコンパイルは必須

それでは、.NETネイティブコンパイルしなければいいのでは?となりますが、ストアに登録して配布するときは.NETネイティブコンパイル必須となっているので、配布手段はどうあれ.NETネイティブコンパイルで動作しないというのは、今後を考えると避けたいところです。

対応策

対応策としては、サンプルコードNAudioUniversalDemoでいえばMainPageViewModel.csのなかでrecorder.StartRecording()を実行する前に、明示的にWaveFormatを指定してしまうことです。
NAudio/MainPageViewModel.cs at master · naudio/NAudio · GitHub

recorder.WaveFormat = new WaveFormat(48000, 32, 1);

なお、この場合、IeeeFloatではなくPCMのサンプリングレート48000、32ビット、1チャンネルとなります。
また、万が一、指定したサンプリングレートおよびチャンネル数が、該当のデバイスでサポートしていない録音デバイスだったときも実行時エラーとなります。
こうなってくるとストアに登録して広く公開するのはなかなか難しい状況だといえるでしょう。
例えば、ARM64 Windows機のLenovo C630のInternal Microphoneは、サンプリングレート48000Hz、16ビット、1チャンネルですが、インテルWindows機だと2チャンネルの場合があります。

解決方法

解決補法としては3つ

  1. NAudioを使わない方法を考える
  2. ストア配布対象をx86に絞る
  3. NAudioのMixFormat取得ロジックを.NETネイティブ対応する

まずは、1か2の検討をして、なんとか3が解決される(もしくはOSSなので自力で解決してプルリクする)のを待つ形になります。

本当の解決を目指して

NAudioのMixFormat取得ロジックは.NETネイティブコンパイルしていないときと、.NETネイティブコンパイルしたときではどのように違うか確認してみましょう。
NAudioのGitHubからソースコードを取得して、AudioClient.csのMixFormatクラスにブレイクポイントを貼って、デバッグ実行をしてみます。

非.NETネイティブコンパイル時の動き

48000Hz、16bit、2チャンネルの録音デバイス
非ネイティブのときは、MixFormatの戻り値は、サンプリングレート48000Hz、32bit PCM、2チャンネルとなります。

{32 bit PCM: 48kHz 2 channels wBitsPerSample:32 dwChannelMask:3 subFormat:00000003-0000-0010-8000-00aa00389b71 extraSize:22}
AverageBytesPerSecond: 384000
BitsPerSample: 32
BlockAlign: 8
Channels: 2
Encoding: Extensible
ExtraSize: 22
SampleRate: 48000
SubFormat: {00000003-0000-0010-8000-00aa00389b71}
averageBytesPerSecond: 384000
bitsPerSample: 32
blockAlign: 8
channels: 2
dwChannelMask: 3
extraSize: 22
sampleRate: 48000
subFormat: {00000003-0000-0010-8000-00aa00389b71}
wValidBitsPerSample: 32
waveFormatTag: Extensible

この中のsubFormatの値がWAVE_FORMAT_IEEE_FLOATを意味しています。
この内部値は外から見えないので、外から見えるrecorder.WaveFormatの値を見てみましょう。
こちらは、IeeeFloatとして取り出せます。

{IeeeFloat}

WaveFormat未指定時に本来期待されている動きは、この動きになります。

.NETネイティブコンパイル時の動き

それでは.NETネイティブコンパイルしたときの値をみてみましょう。
MixFormatの戻り値は、サンプリングレート48000Hz、32bit PCM、2チャンネルとなりますが、クラスの型値がExtensibleのままでPCM表記になりません。

{NAudio.Wave.WaveFormatExtensible}
AverageBytesPerSecond: 384000
BitsPerSample: 32
BlockAlign: 8
Channels: 2
Encoding: Extensible
ExtraSize: 22
SampleRate: 48000
SubFormat: {System.Guid}
averageBytesPerSecond: 384000
bitsPerSample: 32
blockAlign: 8
channels: 2
dwChannelMask: 3
extraSize: 22
sampleRate: 48000
subFormat: {System.Guid}
wValidBitsPerSample: 32
waveFormatTag: Extensible

値を確認すると今回の原因はSubFormatにWAVE_FORMAT_IEEE_FLOATを意味する値が入っていないことがわかりました。
しかしここで注目すべきは、サンプリングレート、ビット数、チャンネル数などは取得ができてる点です。もしこれらの値を取得できれば、new WaveFormat(48000,32,1)のように指定してNAudioに該当録音デバイスのフォーマットが指定できることになります。

さあ、NAudioを書き換えよう

NAudioの内部状態のところでエラー判定されているので、NAudioの外側からどうにかできる問題じゃなさそうです。
そうなってくるとNAudioのどのクラスで対応するかですが、UWPのみの問題だと考えると、WasapiCaptureRTクラスの中で対応するのがよさそうです。

gist.github.com

audioClient.MixFormatメソッドの戻り値を変数名mixにいれて、それがWaveFormatExtensibleであればビット数に応じてIeeeFloatかPCMか明示してフォーマットを作成することにします。
例えば、先ほどの48000Hz、16bit、2チャンネルの録音デバイスであれば、内部変数のwaveFormatは下記のようにIeeeFloatとして処理される内容になります。

{NAudio.Wave.WaveFormat}
AverageBytesPerSecond: 192000
BitsPerSample: 32
BlockAlign: 4
Channels: 1
Encoding: IeeeFloat
ExtraSize: 0
SampleRate: 48000
averageBytesPerSecond: 192000
bitsPerSample: 32
blockAlign: 4
channels: 1
extraSize: 0
sampleRate: 48000
waveFormatTag: IeeeFloat

このオリジナルのNAudio.dllは、Releaseビルドすれば、NAudio\bin\Release\uap10.0フォルダに出力されます。
自分のUWPプロジェクトでnugetではなくからそのDLLを参照するように切り替えれば、.NETネイティブコンパイルしたUWPアプリも正常にNAudioが動作します。
どうせならばと、この件は本家にプルリクしてみました。

Azure Web Appsのランタイムスタックの分類について

[en]
When I try to create a web app in Azure and try to specify the runtime stack, I get the following message.
f:id:hatsune_a:20210104130352p:plain
I think ”.NET 5" should be on the ".NET Core" side, but what do you think?

    • -

[jp]
AzureでWebアプリを作成しようとしてランタイムスタックを指定しようとすると以下のような表示になります。
f:id:hatsune_a:20210104130352p:plain
「.NET 5」は、「.NET Core」側にあった方がよいと思うのですが、どうでしょうか。

      • -

UWPアプリでFilePickerで指定したファイルをリスト表示する

2DなUWPアプリで一覧表示したボタンをクリックすると、FilePickerでファイルを指定してその行に画像を表示したいという質問を頂いたので、まとめます。
なお、少々手抜きをしていて、Modelの中でFilePicker起動しちゃってます。
本来であれば、イベントあたりを使って、ModelじゃなくてViewとかに通知を伝搬して、そこでFilePickerを呼び出して、ファイルから画像設定のModelをView→ViewModel→Viewという感じに読んであげるのがいいような気がします。

UWPに権限を追加する

f:id:hatsune_a:20201127145000p:plain

一覧表示用クラスを定義する

gist.github.com
ボタン押した行をイベントとして外に通知して、外側のImageModelクラスでImageSourceを設定した感じに変えた方がいいと思います。
※後日変えると思います

Modelを定義する

gist.github.com

ViewModelを定義する

gist.github.com

Viewを定義する

gist.github.com

gist.github.com

デジタルインナーミラー ドラレコ AC80を買いました

最近は楽しいドライブの必須アイテム感も増してきちゃいましたドラレコことドライブレコーダーですが、そのお陰か「ほしい!」と思えるようなスペックの製品が意外とお値打ち価格で手に入りようになりました。

今回、購入したのは、AUTOSOCTさんのAC80というバックミラーにかぶせる感じで取り付けることができるドラレコです。


この製品が気に入ったのは次の点です。

  • ミラーに取り付けるのでフロントウィンドウに張り付けるもののように落下の心配がないし、ダッシュボード上とか視界に入らない
  • 右ハンドル仕様で右側にフロントカメラがあり、また、ミラーを運転席側に向けることを前提とした視野となっている
  • バックカメラもある2カメラ構成である
  • フロント2Kカメラで奇麗、バックカメラも1080p
  • HDRなので夜間なども白飛びせずにナンバープレートが撮影できる
  • GPS内蔵なので走行記録がWindows PCであとで見られる

フロントカメラだけなら、ミラーにつけてあとはシガーソケットから電源をとるだけで簡単設置できるのも手軽かもしれませんが、今回、ドラレコを設置するにあたって自分に課したミッションとしては「電源はヒューズボックスから」「配線は極力隠す」「バックカメラもつける」がありましたので、まずはそれに必要なものを追加でそろえましょう。

製品スペック

サイズ:168mm x 81mm x 40mm
重量:1100g
記録メディア:Class 10以上のMicroSD / 32GB~128GB
スクリーンサイズ:12インチ
ビデオフォーマット:MP4
写真フォーマット:JPEG
フロント視野:170度
解像度:2K + 1080p
電源:5V / 2.5A

取付準備

グローブ

まずはグローブですね。以前から愛用している整備用のものです。ピッタリ手にフィットする感じが素敵。耐熱だし絶縁だしで安全ですね。ただ、スマホ操作できないので記録用写真撮るたびに外すのが若干面倒です。

内張りはがし

今回の作業を行ってみて「必須!」だと思った道具の一つがこちらの内張はがし。いろいろなシーンで大活躍です。これを持たずして内装周りの作業しちゃダメだと思いました。

ハーネス結束&保護テープ

そして、もう一つの必須アイテムが、この保護テープ。エーモンさん様々ですね。どんな感じで使ったのかは、取付StepByStepの中でご紹介します。

電源ソケット DC12V/24V60W以下 ヒューズ電源タイプ

あとは、ドラレコ電源が、シガーソケットタイプだったので、そこからヒューズボックスからとれるように変換ケーブルですね。
電源自体は5V/2.5Aなので、付属の5Aの管ヒューズをもうちょっと小さいアンペアのものにしてあげてもいいかもしれなないですね。

取付StepByStep

ヒューズボックスの確認

まずはヒューズボックスを開けて、車のマニュアルと照らし合わせてどこのヒューズから分岐するかを検討します。

ライトやそのほか、車の運航に必要なヒューズは避けた方がいいので、そうなってくると一番おすすめはカーオーディオ用のヒューズからの分岐です。

プジョー206では、写真で下から2段目、左から3つめ(No.24)の15Aのヒューズが該当します(年式によって違うようですので車付属の説明書で確認しましょう)。
このヒューズ位置ですが、段差を合わせえるとACC、つまり、アクセサリー電源といってキーを一段回した段階で電源がONになります。カーナビやカーオーディオ、ETCなどがそうですね。
一方、写真のように半段づらしていると、常時電源になります。
24H駐車監視と衝撃判断でファイルロックもできる機能がついているので、駐車中もドラレコで録画できるようにするためには、常時電源にしておきましょう。
逆にほとんど乗らないしということであればACC電源にしておくのもいいですね。

メモ代わりに記載ですが、隣のNo23の黄色い20Aがシガーソケットです。タバコ吸わないのでシガーソケットは思うにスマホ充電用なので、ついでにこっちは半段下げてACC電源にしておきました。

本体をミラーに取り付ける

ワイドミラーを付けていたのでそれをサクッとはがして、代わりにドラレコ本体を付けます。

いままでつけていたワイドミラーはバネの力でカチッとはまってくれていて、新車購入時から1度も落下することなく今回まで活躍してくれてました。
一方、今回のドラレコは重量が1100gあるのですが、ゴムで止めるタイプ。で、このゴムは劣化するらしくて時々交換しないとらしいです。

このあたりを割り切りと考えるかどうかもあるかもしれないです。
ただ、できれば、数千円高くなってもバネでカチッととめられたらよかったかな。これ結束バンドとで代替できるか、そのうち試したいですね。

Aピラーの内装をはがす

車には、天井を支えるピラーと呼ばれるものには、フロントウィンドウとサイドウィンドウの間のAピラー、前部座席と後部座席の間のBピラー、後部座席とリアウインドウの間のCピラーなどがあります。
つまり、Aピラーとはフロントウィンドウの端っこにあるピラーになります。
f:id:hatsune_a:20201121143011p:plain
今回のドラレコはバックミラーに設置するタイプなので、バックミラーからAピラーまでケーブルを這わせて、ダッシュボード上のGPSユニットまでのケーブルとヒューズボックスまでの電源ケーブルの2本について、Aピラーを通していきます。
そのため、まずは、Aピラーの内張をぺりっとはがします。
上の部分に指をひっかけて、手前に引っ張ると上から順番に外れるような構造になっています。最後は、ダッシュボードの隙間からサクッと抜き出す感じです。

ミラー位置から電源、GPSケーブル、バックカメラケーブルを内装に押し込む

電源、GPSケーブル、バックカメラケーブルを「ハーネス結束&保護テープ」を使って1つにまとめます。

まとめたケーブルをバックミラーの背後から運転席側のフロントウィンドウと天井内装の隙間に「内張はがし」を使ってケーブルをぐぐっと押し込んでいきます。

写真の左側のところをつかって狭い隙間もらくらくに押し込めます。
マイナスドライバーでも可能かもしれないですが、このオレンジのは材質が柔らかいのでケーブルなども傷つけることなく作業ができるので、余計な心配せずにすごく捗りました。
最後はこんな感じに事前に剥がしておいたAピラーのところにでてきます。
f:id:hatsune_a:20201121143349p:plain

Aピラーにケーブルを這わす

f:id:hatsune_a:20201121143517p:plain
Aピラー内部には、ケーブルが止められるような構造になっています。内張りもここにはまっていますので、内張りの足がはまるところ以外をつかってケーブルを挟んでいきましょう。
こうやって挟んでおかないと後々走行時にカタカタ音が鳴る原因となりますのでちゃんとやります。
ここでも「ハーネス結束&保護テープ」が活躍します。ちょうど止める部分に巻くことでよい感じのテンションがかかってくれます。

ダッシュボードの中を通してヒューズボックスへ

Aピラーを通し終えたら、ここで、GPSケーブルと電源ケーブルはお別れです。
GPSケーブルは、そのまま、こんどはダッシュボードとフロントウィンドウの隙間に押し込んで、ダッシュボード上のGPSユニットまでつないでいきます。

一方、電源ケーブルは、ダッシュボードの中に押し込みながらヒューズボックスを目指します。
f:id:hatsune_a:20201121143911p:plain

シガーソケットタイプからヒューズタイプへ変換

f:id:hatsune_a:20201121144113p:plain
変換ケーブルを使って平形ヒューズに電源を変更します。この変換ケーブルですが、ボディアースが必要なので、ヒューズボックス周りにあるボディアースポイントが必要です。
電気周りの作業をするので事前にバッテリー端子を片方外して、通電されないようにしておきましょう。

ボディアース

ボディアースポイントは、ヒューズボックスの奥にあって、ヒューザボックスを外さないと手が入らないところにあります。
これは外すかとおもってみたらダッシュボードのサイドにボディアースポイントにアクセスするためのメンテ口があるじゃないですか。内張はがしでサクッとはずすせば簡単にアースできました。

f:id:hatsune_a:20201121144355p:plain
f:id:hatsune_a:20201121144518p:plain

ヒューズ接続

f:id:hatsune_a:20201121145514p:plain
15Aのヒューズを差し替えてあげることで、15Aのヒューズの役割はそのままで、そこからドラレコ電源へ分岐ができました。ドラレコ電源自体は管ヒューズを経由してなので、そっちで過電流がながれたら管ヒューズがきれてくれる仕組みです。

AピラーからCピラーを目指す

Aピラーの上端で、分岐したもう一つのケーブルであるバックカメラケーブルはドア上と天井内張りの間を「」でこれまた押し込まれながらリアを目指します。
途中Bピラーがあるのですが、これも上端からケーブルが押し込められました。ほんと、フランス車なのかはわかりませんが、良い加減な感じな構造ですね。
f:id:hatsune_a:20201121145910p:plain

Cピラーからハッチバックドアへ

Cピラーまできたら、この先どのように進むかはバックカメラをどこにつかるかによります。
多分、ナンバープレートあたりに着けるのがよいと思うのですが、今回の車は、ナンバープレートが後ろのハッチバックドアと一緒になっているタイプなので、天井内張りからCピラーを下に進むのではなくハッチバックドアに進みます。
f:id:hatsune_a:20201121150035p:plain
ここは可動部なのと、そして、ハッチバックドア側には内張りがないので「ハーネス結束&保護テープ」でドアの開け閉めに引っ張られず、また、ドアが噛まないような長さで止めることにしました。

本当は、反対側には車体とハッチバックドアの間を通っているケーブルの通り道があるので、リアの天井内張りを通って反対側に抜けてそっちからハッチバックドアに進むのがいいのかもしれません。今度、時間をみつけて経路変更するかも。
ただし、今回のルートでもリアウィンドウ下には電熱ヒーター線の口があって、そこからハッチバックドア内部にいけるので、今回は、このルートからドアの中にいれました。
f:id:hatsune_a:20201121150458p:plain

車外へ

最初、車内にリアカメラを設置したのですが、リアウィンドウの反射が映りこんでしまうので、最終的にはナンバープレート脇に設置しました。
そのため、リアカメラケーブルは、最後は車外に出さないといけないのですが、難波プレート周りに車外にアクセスするための穴がどこにも開いていないのです。ナンバープレート灯あたりから通せるかとおもったら隙間なさそうだし、ハッチバックドアのドアノブもダメってことで、ドア下を通して、そこからナンバープレートと車体の隙間をとおって(ここでも内張りはがしの押し込みが活躍)リアカメラにつなぎました。
f:id:hatsune_a:20201121151236p:plain

結果的にはこの位置で正解ですね。
f:id:hatsune_a:20201121151505p:plain
信号待ちで直後に止まってくるまのナンバープレートもばっちり入ります。

まとめ

これって、ホロラボの「TebanashiManual」とかあるとマニュアルと現物両方見ながら確認できたり、「TechniCapture」があればプロの整備士さんの手順と目線で作業ができるんだろうなーと思いました。
すくなくとも「これどこー」とか「これであってるんだろうか?」的な不安感はだいぶなくなるんだろうなと小春日和な中で作業を終えた後の缶コーヒーを飲みながらしみじみ思った1日でした。
hololab.co.jp
hololab.co.jp