- このトピックには8件の返信、2人の参加者があり、最後ににより7ヶ月前に更新されました。
-
投稿
-
https://github.com/tesla-android/android-raspberry-pi
上記リポジトリで公開されている、Raspberry piでAndroidを実行し、テスラのブラウザからアクセスして、ディスプレイ上でAndroid Auto等を動かすプロジェクトについて。
何度もInstall Guide通りに書き込んでもAct LEDが7回点滅の「kernel.imgの読み込みエラー」になっていました。これについて、2025/4/1時点の最新のブートローダーでは起動しないことが分かりましたので情報共有です。
2025/4/1時点の最新のブートローダーは以下。
Tue 11 Feb 17:00:13 UTC 2025 (1739293213)
起動確認が取れたブートローダーは以下。
Mon 15 Apr 13:12:14 UTC 2024 (1713186734)したがって、もしブートローダーが新すぎる場合、ダウングレードする必要があります。
Raspberry pi OSを起動し、
sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader-2711/default/pieeprom-2024-04-15.binを実行して再起動すれば、ブートローダーはダウングレードすることを確認しました。
ちょうどRaspberry piを入手したばかりでとてもタイムリーでした。
貴重な情報ありがとうございますこのラズパイにGPSセンサーを追加して、AndroidにYahoo！カーナビまたはmoviLinkをインストールして動かせるなら最高だと思うのです。
誰か試したこと無いのですかね…
CarPlayやAndroidAuto経由で使えるだろうとおっしゃる人も居ますが、それだと簡易機能になっちゃってあまり便利ではないんですよね。
ラズパイでフル機能の日本製ナビアプリが動くなら、わたしゃ必死になってラズパイ制作がんばると思います！すみません、いろいろ調べてみたら、GPSセンサーを取り付けなくても、テスラのブラウザーからロケーション情報を取得してAndroid側にはGPSセンサーとして認識されるような機能が既に搭載されているのですね。
恐るべし、Tesla Android Project! やっぱり私もひとつ作りたくなりました。
Carplayドングルを付けなくても、余ってるAndroidスマホがあればラズパイにUSB接続するとそれをAndroid Autoとして使える方法があるという報告もあるようだし。
では、作る際に私もトラブったら改めて質問させてください。Tesla Android Projectは、GMAPやWAZEみたいなカーナビアプリや、速度違反取締装置ナビゲーターなどの便利なアプリを含む、独立して動くAndroidデバイスとして使えます。Android AutoやCarPlayを使う必要はありません。
以下のアプリもインストールしました：
Shazam（自動で歌詞を検索できますが、別途マイクのインストールが必要です）、
S3XY Commander Dashboard「私も作ってみよう」と、言ってしまったので実際に作ってレポートしようと思いました。
まず、ここのタイトル通り、ブートローダーのダウングレードは必要でした。
（その前にファームウェアを最新に更新することが前提です。なお、ファームウェアを最新にしないとパフォーマンス問題が起こります。）
なので、TeslaAndroidを入れる前に、普通のRaspbianなどのLinuxを入れて起動して操作が必要になるのでご注意を。作業が終わったらそのSDカードを消してTeslaAndroidを入れてかまいません。TeslaAndroidをインストールする前に、注意事項としては、Raspberry Piにファンは必須だよということです。
結構負荷がかかりますし、オーバークロックで動かす前提になってますしね。
ということで、ヒートシンクだけでなく、3ピンのPWM制御ができるファンをケースに取り付けました。
TeslaAndroidの場合、青ケーブルをどこに刺すかというと18番ピンに刺せばよいように構成されています。
(制御ツールがアホなんでしょうね、単に50度超えると全開で回るだけっぽくてPWMの意味ないぢゃんとは思うが)※ ここから先「モッサリで使い物にならん」という話がやたら出ます。
※ 結論から先にいうと、日本ではラズパイの5GHzのWifiをテスラに繋げる方法が無いのが諸悪の根源です。で、ここからですけれど、最新のTeslaAndroid(2025.14.1)で作ってみてしばらく使ってはみたものの、画面がガクガクのモッサリで正直驚きました。YouTubeとかで動かしているところの動画とは比べ物にならないひどさです。車両側の過去のアップデートで、ブラウザからの音声が出せなくなって、いまはBluetoothで音を出さなければいけないのですが、それをやるとさらにモッサリになって動画の映像も音声もぶつ切れで完全に使い物になりません。オーバークロックの量を調整する設定を入れて、force_turboとか最大クロックも2100とかにしたのですがほとんど効果なし。
ちなみにテスラの車両からGPSの位置情報がTeslaAndroidで利用できる機能についてですが、これは壊れているようです。まったくGPS情報がとれないです。車両側の過去のアップデートで不安定になった、とか書かれていますが、不安定どころではなくて一切とれません。
そこで、外付けのUSBタイプのGPSセンサを取り付けました。USBGPS4DROIDというオープンソースアプリを入れれば動作します。が、これがAndroidの開発者モードを有効にしたうえでfake locationとして位置情報を入れるからなのか、しらんけど、カーナビソフトの多くがまともに動きません。・Yahoo!カーナビ → 東京駅を表示したまま全く動けず。
・moviLink → 東京駅を表示したまま全く動けず。
・COCCHi → 初回起動でタイトル画面がループして進まない → OSの画面分割機能を使って左右2画面にするとなぜか進む → 初期設定さえ済めばもう2画面にしなくていいけど、東京のどこかを表示したまま全く動けず。
・Googleマップ → 現在地の認識がめっちゃ遅い。さらに、不安定でダメ。
・Sygic → 日本地図をダウンロードしたのに、地図がまっしろ → 設定メニューに位置情報の設定がある。これを「カスタム」に設定したら、キターーー！！(笑)ナビとして使えるが案内はちょっと糞。
・Waze → はじめっからキターーー！！(笑)ナビとして使えるけど案内も地図もクオリティが低すぎて使えないよね。
・ゼンリン地図ナビ → あれ？よく覚えていない。使えたような気がする。ユーザ登録すれば課金の前にお試しできるらしいがユーザ登録しないと道案内はさせてくれなかった。
・カーナビタイム系統 → くやしいほど超安定っぽい。課金しないと何もできない。お試し期間すら課金してから無料になるってことで全く手が出せなくてごめん。GPSセンサーを後付けしたのにこの勝敗結果。くやしい。無課金だとSygicしか選択肢がない。まぁ、Sygicは日本地図をWifiでダウンロードしておけば、それ以降はギガを消費しないし、海外製のくせに地図だけはいい地図使ってる。妥協もしがいがあるかも。
ところで、実は外付けでUSBマイクも付けたのだ。案外これもちゃんと動く。つまり目的地はどのナビも音声入力でテストしている。
ところが、だ。例のモッサリと、Bluetooth接続の音声の場合はカックカクになるので、ナビの案内の音声はさっぱり聞き取れないほどズタズタだ。いみねーしよ・・・ちょっと長くなったので、次に続く。
(続き)
さて、このモッサリについてだ。いろいろ調査したんだよ。
順に説明してゆこうと思う。まず、TeslaAndroidのバージョンだが、これを執筆時点で最新の2025.14.1より、2024.24.1のほうがパフォーマンスが良いという噂があって、これ、やってみたけど本当です。
この差となる更新内容としては、車両側アップデートのせいで動かなくなったブラウザオーディオ機能の削除ってことになってる。そんなことでパフォーマンスダウンするかよ！？むしろ機能削ってるのにアップぢゃなくてダウンしたのかよ！！って全力でツッコんだけど。体感では2割か3割速くなった気がしていて、別途のクロックアップをせず標準のブースト程度のままでも安静時にはYouTubeで動画を流してBluetoothで音声を出しているのにギリギリ途切れずに動くことがあるほどだ。(のちにいろんなアプリを入れるごとに全体がモッサリしてきてこの希望は打ち砕かれたのだが。Androidあるあるだな。)あ、ところで、ウチのTeslaはIntel Atomだよ。Intel Atomだと、車両側のブラウザがモッサリだからTeslaAndroidもモッサリだという指摘があちこちあることは承知している。
でも、そう言ってくる人って、この状況がどういう程度なのか分かりもしないのに、定型文のごとくそういう態度である。ほかにも、停車時は良くても運転時はブラウザへのパフォーマンスの配分が低くなるからモッサリになるとか、そういう意見もある。
しかしだ、テスラのブラウザではなくてiPhoneのブラウザで繋げてもガクガクは一緒だったのだ。言っておくがiPhoneのブラウザはテスラのRyzenと同等か、むしろ上だと考えると、もはやテスラのブラウザのせいではない。
さらにだ、YouTubeの動画を探せばわかるように、外国人の人がIntelAtomで運転中に録画したテレビ動画を音声付きでスムーズに流しているのがわかる。彼のほうがよっぽど古いTeslaAndroidであるし、私が経験しているようなカクカクのガクガクはもはや外国人の皆様には想定外のモッサリなのだと思った。さてもう八方ふさがりか？俺だけこんなガクガクなのか？ラズパイ壊れてんぢゃね？(笑)と思ったところで、ある事に気づいた。
今まで言っていなかったが、TeslaAndroidはWifiの設定で2.4GHz帯と5GHz帯(W52のうち数チャンネルとW53のうち数チャンネル)を選択できる。もちろん5GHz帯のほうが高速なのだが、テスラの日本国内車両は5GHz帯はW56しか電波をつかまないので日本でTeslaAndroidは2.4GHzに設定しないと繋がらないから、みんなそうすることが必須である。
ある日、モッサリ調査との闘いのために自宅にラスパイを持ち込んだ。自宅だからWifiを5GHzにしてみっかと。それで、iPhoneのブラウザから繋げて、そしてBluetoothは適当にその辺りに転がっているAmazon Echo Dotスピーカーに繋げて・・・
動画を再生っと・・・ウワ！！キターーーぁぁ！！
いままでのモッサリガクガクが嘘のように、ヌルヌルだ。音のほうも全く途切れる気配すらしない。
ネットで確認してみると、「Wifiを2.4GHzにするとBluetoothも2.4GHzだから電波干渉が起きてBluetoothの音が途切れるっぽいのでTesaAndroidはWifiを5Ghzにして少し良くなった」的な内容があったけど。これは電波干渉っていうよりラズパイのWifi/Bluetoothチップのファームウェアがおかしいか、TeslaAndroidが使っている元のAndroidのWifi/Bluetoothドライバが未熟なのか、どっちかだろがい！！
電波干渉のせいで音だけでなく、画面のほう、というか本体自体の処理能力が低下するなんておかしいし、そもそもTeslaAndroidがBluetoothの電波を出さなくても、車に乗ったらiPhoneとか別の機器が電波出してるのに、電波干渉によって本体の処理能力が落ちたりってありえんだろう、というかそれはさすがに無かったし。
あー、いずれにしても、TeslaAndroidでWifiの2.4GHzとBluetoothを両方使う、ということがいまのところ大バグだと確信するに至った。この日はかなり満足であった。日本でTeslaAndroidを運用するなら、Wifiは2.4GHzにするとしても、Bluetoothは内蔵のを使うのではなく、ラズパイの3.5ミリオーディオジャック出力を使って、別途Bluetoothトランシーバーを購入して接続してやることになるかなと。それを今日アマゾンで発注したから、明日届きます。(笑)
結論的には、もうこの運用しかないだろうなと。そういうことです。結論が出たところで、ちょっと長くなったので、次へ続く。
※ 実はこの結論が出る前に、マニアックなもうひと悪あがきをしていて、どうしても気になる人は次のおまけをみてください。
(続きというか、おまけ)
きっと、電波干渉なんか関係なく、かなりモッサリは解消されていったんほらな！！となるはずだと思うけれども、5GHzのWifiを使った時のようなヌルヌルにはならないことが分かっている。
これは2.4GHzのWifiが遅いからかな、と一瞬思ったんだけど、一般的には30FPS程度の画像処理をしている画面データを2.4GHzのWifiに乗せたとして通信帯域の頭打ちをするわけがない。まぁ、動画再生は事前にバッファリングするけど、こういう画面操作のストリーミングの場合はリアルタイムだから、コマ落ちはあり得るけどね。
でも、どうもラズパイのハードウェアなんだかAndroidのドライバ側なんだか、Wifi自体がまだ未熟な気がしてる。さきほどの結論が出る前は、実はこんなことをしようとしていたのだ。
そもそも、なんで日本の場合は5GHzのWifiが利用できないのかなんだけど。
これは気象観測機器などのレーダー波とかへの電波干渉があるからとかで、日本の場合は5GHz帯のW52とW53は屋外での利用が禁止、そしてW56についてはDFSといって電波干渉が発生したら停波する仕組みを具備して有効化している場合のみ屋外利用が可能であると電波法で決まっていた。
だからテスラはW56のみ繋がるように日本向けの車両は対策していると思われる。
ところが、この電波法が2022年頃だったかに一部緩和があって、5GHz帯のW52については車内についてはOKとなった。
だったら今はW52でいけるぢゃん！ということだが、残念ながらテスラの車両側がまだこの法改正に対応してくれていないようでして。(どこかのタイミングでアップデートしてほしい！！)
このままだとTeslaAndroidで日本の5GHz帯運用はできないんだけど、ちょっと待てよと。TeslaAndroidがW56に対応していないのが悪いと考えることもできる。TeslaAndroidでW56の電波を発射するというテーマに挑んでしまった結果を書いておこうと思う。
(ご存じのとおり、結果はあきらめたのであります。だからテスラよ！W52のアプデたのむー(再))まず、半日かけてGithubのソースコードを読んだ～。
1)
https://github.com/tesla-android/android-vendor-tesla-android/blob/main/overlays/ServiceWifiResources/res/values/config.xml
これによると「100,104,108,112,116,120,124,128,132,136,140,144,」とあるので、W56のチャンネル100～144が全て記載されており、対応できる可能性をにおわせている。
2)
https://github.com/tesla-android/flutter-app/blob/main/lib/feature/settings/widget/hotspot_settings.dart
これがTeslaAndroidのWifi設定画面を生成しているあたりのコードである。
ちなみに、設定画面はウェブ画面なので、HTMLとか解析してやりゃ何かわかるかなと思いトレースしてみると、ものすごく難読でさっぱり追いかけることができなかった。
ソースコードのほうを読んでいてこれを見つけたときは、これか！！となった。
でもこの内容はほとんどレイアウトを決めているだけで、何かロジックがあるわけではないんだなと。
3)
https://github.com/tesla-android/flutter-app/blob/main/lib/feature/settings/model/softap_band_type.dart
これがTeslaAndroidのWifi設定画面で選択可能なチャンネルのリストである。
5GHzだと、W52からチャンネル36と44だけ。そしてW53はナシ。W56もナシ。そして確か日本では利用禁止なW58からチャンネル149と157だけ、なんとも偏った選択肢しか提供されていないのだ。
ここに、W56のチャンネル100とか、追加してくれればいいのに、とか思った。
下のほうには少しロジックがあり、番号を入力するとさきほどのチャンネルのリストから1つ該当のオブジェクトを返すようである。
36が入力されたら、44が入力されたら、149が入力されたら、157が入力されたら、というふうに条件分岐になっており、万が一それ以外が来たら36だったことにするという具合のようである。ほかのソースコードにも見どころはあったけど。
例えば、通常のAndroid OSのソースコードでは、Wifiはちゃんと国を判別して、その国の電波法規に従うようなコードが書かれていて、適切かつ利用可能なチャンネルをオートで判別して接続する。しかしTeslaAndroidはそのOSのコードにパッチを当てて、国の判別をつぶし、さらにはチャンネル選択をオートで行う部分も、さきほどのTeslaAndroidの設定画面で指定されたWifiチャンネルに固定して利用するようになっていたり。話を戻すと、TeslaAndroidのWifi設定画面にW56を増やすには、そのようにコードを修正してビルドしなおせば良いのは当然だが、きちんとビルドを通せるような開発環境を作るのが結構だるいんよ(笑)
Android OS程度であれば、出来上がっている実行ファイルをデコンパイル(ソースコードに戻す)して、ちょちょっと書き換えてリコンパイルすると、ピンポイントでパッチを当てることができる。
ところが今回はだ、よりによってFlutterというフレームワークのDartという言語で書かれている。これをデコンパイルできるツールがあるんだか無いんだか、ネットで調べたけど存在を発見できなかった。
TeslaAndroidの開発者さん、なんでよりによってFlutterなんだよ・・・泣けてくる。
まぁ、今回に限っていえばぶっちゃけ149を100に書き換えれば済むから、実行ファイルを直接ゴリッと書き換えてしまったらどうだろうかとも思ったが、それすら簡単にできるかどうかわからんし、ここであきらめてしまった。いったん、あきらめてしまったのだが、全体のソースコードを読んだからだいたい仕組みはわかってきていた。
TeslaAndroidの設定画面はウェブであり、そこで選択した内容はLighttpdに設置したWeb APIが呼ばれることによって反映している。
ならば、例えば36チャンネルに設定したときのAPI呼び出しを書き換えて、APIを再度呼び出せばよいのではないかと。
(のちに書きますが、これは失敗に終わるので真似しないように！！)パソコンのChromeでデベロッパーツールを開いて、コンソールにポーン！！
fetch(“https://device.teslaandroid.com/api/softApChannel”, {
“headers”: {
“accept”: “*/*”,
“accept-language”: “ja,en-US;q=0.9,en;q=0.8”,
“content-type”: “text/plain”,
“sec-ch-ua”: “\”Google Chrome\”;v=\”135\”, \”Not-A.Brand\”;v=\”8\”, \”Chromium\”;v=\”135\””,
“sec-ch-ua-mobile”: “?0”,
“sec-ch-ua-platform”: “\”Windows\””,
“sec-fetch-dest”: “empty”,
“sec-fetch-mode”: “cors”,
“sec-fetch-site”: “same-origin”
},
“referrer”: “https://device.teslaandroid.com/”,
“referrerPolicy”: “strict-origin-when-cross-origin”,
“body”: “100”,
“method”: “POST”,
“mode”: “cors”,
“credentials”: “include”
});
このsoftApChannelというAPIは、100をぶちこめばそのまま100を受け取るはず！
あとは、TeslaAndroidを再起動すれば・・・！？どうなる！？
・・・結果はあぼーん！！オワッタ～～～
パソコンからも、iPhoneからも、なんとテスラからもつながらなくなってしまいました。
ということは、APIが受け付けずにW52のままになっているわけではなく、つながらないからわからないけど何らかの変化があったのは間違いない。
チャンネル100に、本当になっているのだろうか？？
しっぱいだぁぁぁそして、ようやく今回の物語のいったんのオチである。
仮に、チャンネル100になっていたとしても、接続が拒否されるっぽい気がしてきた。
W56の場合はDFSが有効にしておかないと、サッパリ使えない可能性がある。
おそらくテスラもDFSのチェックをしているような気がしている。(チャンネル100～140は繋がるとマニュアルに書いてあるけど、DFSについては言及されていなかったので、どうせDFSチェックはナシだろうともくろんでいた。すいません)
しかしながら、iPhoneやパソコンまでもが繋がらないとは想定外ではあったな。
でも、Android OSのソースコード読んでても、DFSチェックしてるっぽいのでiPhoneやWindowsも同様にチェックしているんだろうな。iPhoneがダメだったからMacOSは試してもいないっす。
そう考えると、WifiルータとかでDFSをオンにするかオンにしないかの選択ができる製品が多いけど、それってオフだとほとんどの機器がW56をつかんでくれないってことだよね。早く言ってよね～(笑)
この結論になっているワケとしては、まず、TeslaAndroidはDFSをオンにする設定にはなっていないこと。そして、だったらオンにするよう改造すれば？ってことだけど、これまた不可能に近いようである。
まず、DFSの前提はACSである。チャンネルを動的に切り替える機能がまずあって、DFSはその仕組みを使うことになっている。まぁ、TeslaAndroidはチャンネルを固定で指定する方式なんだけど、それは動的に変わる仕組みに変わったところで別に不便は無い。ところが、ラズパイはACSを有効にできない想定で作られているらしいとのこと。(ネットでそんなこと言ってる人がいた)
これで詰んだね。
まぁ、そもそもAndroidのテザリングとかって、ほとんどのスマホメーカーがDFSに対応していないらしいと聞く。
つまり、DFSって実現しようと思ったら機能開発して独自に実装しないといけなさそうってことかと思うと、おそらく超えられない壁はここらへんだと思った。報告、以上。
なんか、もっとマニアックな人がいたら、これを参考に何か解決策を検討してくれたらなと思います。では、明日届くBluetoothトランスミッターを心待ちにして。さようなら。
