ãƒã‚¹ã‚±ã®è©¦åˆæ˜ åƒã«ãã‚Œã£ã½ã„è¡¨ç¤ºã‚’é‡ã­ã‚‹è©±

こちらは ドワンゴ Advent Calendar 2025 6日目の記事です。

AI生成した写真に表示を重ねたイメージ画像です

はじめに

私には小学生の息子がいて、現在ミニバスケットボールをやっています。

たまに公式試合や練習試合が行われ、観戦や手伝いのために会場に行き、そのついでにスマホのカメラで息子のプレーを録画しています。

そして稀に良い内容の試合があると、これは記録に残さねばと動画編集ソフトを開いて撮影した動画を繋げて一つの試合映像としてまとめることがあります。親バカですね。

 

さて、そういう試合映像をまとめていると、特に試合展開が接戦の場合、テレビ放送の試合映像のように得点やタイマーの表示が欲しくなることがあります。

 

ただそういう編集を一般的な動画編集ソフトでゼロから地道にやろうとするとめちゃくちゃ大変なので、プログラミングの力を借りてコストを抑えつつ、それっぽい表示を目指してみました。そしてそのイメージ画像が冒頭のスクショです。

全体の方針

大きく分けて以下の4ステップを行います。

1. デジタイマの定点撮影映像からの試合時間と点数の解析
2. スコアシートからの選手情報と獲得点数の解析
3. 解析した情報を元にした得点・タイマー表示映像の自動生成
4. 動画編集ソフトでの編集作業

説明の都合上、まずは3.から説明していきます。

得点・タイマー表示映像の自動生成

得点・タイマーの表示ですが、ざっくり言うと試合内容をテキストでデータ化し、それを元に各フレーム時点での得点と残り時間を計算した上で、Pillow (PIL; Python Imaging Library) で表示画像を描画し、MoviePy で映像に合成するという処理を行います。

 

データ化は今回はこのような形式にしてみました。

00:00.00 - timer_set 6:00
00:30.01 - timer_start
00:35.14 - score_gain right 2p
01:05.44 - score_gain right 2p
01:17.11 - score_gain left 2p
01:27.38 - timer_stop
01:43.60 - timer_start

とりあえずこれを手入力でもよいので試合映像を都度確認しながら用意しておきます。

あとは各フレーム時点の score_gain や timer_start - timer_stop の情報を積み重ねてそのフレームで表示すべき値を計算して描画するという処理を繰り返すことで、得点・タイマー表示の映像が作成されます。

 

作成される動画はこのような感じです。グリーンバックにしておいて、あとで動画編集ソフトで試合映像の素材に重ね合わせてから編集することを想定しています。

グリーンバック動画

試合時間と点数の取得

ひとまず試合経過の情報さえ入力すれば、あとは得点・タイマー映像を自動で生成することが出来るようになりました。

これだけでも、動画編集ソフトでテキストを一つずつ挿入する作業に比べれば遥かに楽になりますが、それでもバスケットボールの試合でこれらを手動で入力するのは非常に面倒です。

 

例えばサッカーなら得点が入るのは数回程度で、タイマーも前後半それぞれ開始と停止は一回ずつですが、バスケットボールは得点は数十回も入るし、タイマーは試合中何度も停止・再開を繰り返す（例えばボールがコート外に出たら一旦停止する）ので、あとから試合映像を見ながらそれに合わせて手作業でその情報を入力していく作業はだいぶ時間がかかってしまいます。

 

これについては試合中、デジタイマ（デジタルで得点やタイマーを表示する機器）を定点撮影し、それを解析して自動入力するということを試してみたいと思います。

 

定点撮影した映像はこんな感じです。

プライバシーに配慮してぼかし

予備スマホを三脚で固定し、レンズは超広角にしてデジタイマを画角に入れつつ、ハーフコートすべてを撮影しています。これは編集時、メインの映像とは別のアングルからの映像として利用することも兼ねています。（あと、よく観戦に集中し過ぎてカメラを向け忘れてシュートシーンを撮り逃すことがあるので、そのバックアップとしても…。）

 

これだとデジタイマはかなり小さく映っていて、拡大するとだいぶぼやけて見えますが、読み取れなくはなさそうだという感触です。

デジタイマ部分の拡大写真

ここで例えば光学5倍ズームのレンズを選べば一応多少は画質が改善されるのですが、体育館の床に三脚を立てての撮影だと床からの振動でスマホ本体がブレる方が影響が大きく、最終的な精度はあまり変わらなそうでした。

 

7セグメントの数値の読み取りは、流行りの機械学習で…と言いたいところですが、いくつか試した既存のモデルだと今回の条件では高い精度を出せなかったことや、そもそも多数のフレームを処理するので出来るだけ軽いものが望ましいこともあり、各セグメントに応じた領域の明度を読み取るだけというシンプルな手法を選んでいます。

 

こういう判定処理は、大抵は閾値の選択に苦労するものですが、デジタイマは発光式のため明暗がはっきりしており、位置さえ正しく合わせていれば認識の精度は比較的安定していました。ただし、この位置合わせがかなり難しく、その話は後述します。

読み取り結果はこんな感じ

あとは連続して同じ内容を読み取れたフレームに限定するなどして誤認識を省いた上で、得点の増加やタイマーが変動した/しなくなったタイミングなどを検出することで、最終的には先に定義したような試合経過を表すテキストデータに変換することができます。

選手情報と獲得点数の解析

得点とタイマー表示があれば良い感じにはなりますが、どうせなら他の情報も追加してさらに「それっぽく」しようと思います。

とはいえ手作業でデータ入力する手間はできるだけ避けたいところです。他に何か参考にできるものはないかなというところで、登場するのがスコアシートです。

架空の試合内容を記載したスコアシート

詳細な説明は省きますが、試合経過をいろいろ記録していく用紙です。特にミニバスでは試合進行の運用ルール上、試合後には必ず記入されたスコアシートが出来上がるので、これを写真で撮影した上でいくつかの情報を拾いたいと思います。

 

今回利用したのは選手名とその背番号、そしてランニングスコアです。

ランニングスコアは一部のスポーツを経験してない限りは聞き慣れない言葉だと思いますが、縦に並ぶ数字が累計得点を表し、その数字の横にそれを得点した人の背番号を記入していくものです。

 

これを使って何が出来るかと言うと、デジタイマから解析している得点増加の情報を、それを決めた選手、さらにその選手名と対応させることで、得点が入ったタイミングでそのシュートを決めた選手の情報をテロップで表示する、という演出が追加できます。

 

実際の描画内容としてはこんな感じです。

グリーンバック動画

ついでにその試合での累計得点も表示してみました。自動化しているならついでに累計得点を計算して表示することも簡単で、手軽にそれっぽさを追加することが出来ます。

 

さて、これらのスコアシートの読み取りですが、手入力を避けるためには、OpenCV による直線検出や Tesseract による OCR を利用して領域を判断し、その記入内容を検出するというアプローチが考えられます。

ただ、特にランニングスコアは手書きなので、その検出は出来るだけロバストな手法を採用するなどの工夫が必要そうです。

 

…とか考えていると面倒なので、今回は ChatGPT に丸投げしてみました。

投げた

結果

 

スコアシート全体をそのまま投げるだけではランニングスコアの読み取りまではさすがに無理でしたが、ランニングスコアの説明を加えた上で、ランニングスコア欄だけをクロップしてから渡せば、しっかり読み取ることができていました。すごい。

 

…が、よく見たら、実は二か所ほど間違いがありました（Aの最後の41, 42点目を読めてない、Bの13点目に28番が入ってしまっている）。

そもそも手書きを認識するので多少の誤認識はやむを得なさそうで、とりあえずは結果を目視で確認して修正する運用がコスパが良さそうではありました。このあたりは AI とシステム的な補助を組み合わせることで、もう少し精度は上げることは出来そうには思います。

 

選手名と背番号の方は、もともと Tesseract でも認識可能だろうなと思うくらいだったので心配はしていませんでしたが、やはり完璧に読み取れていました。

結果

ついでにこんな画像も生成しておけば、最後の動画編集で、各Qの開始前にさらにそれっぽい演出を行うことが出来ます。

各Qごとの最初の出場選手の情報も、スコアシートから取得できる。

動画編集

これは単に市販のソフトで編集するだけなので、特筆することは何もないです。メインで撮った映像、定点撮影した別アングルの映像、そして一番上に生成した得点・タイマー表示映像を時刻が揃うように並べた上で、得点・タイマー表示映像にグリーンバックを透過するエフェクトを設定し、あとは良い感じに映像を切り貼りするだけで、冒頭の画像のような動画が出来上がります。

 

プログラミングとか何も関係ないただのノウハウなのですが、カメラは試合開始からハーフタイムなどで中断せずに回しっぱなしにしておくと、タイミングの同期を最初に合わせるだけで良いので楽です。

課題など

基本的には当初思い描いてた通りに実装することは出来たのですが、7セグメントの認識だけは結構てこずってしまいました。

特に、最初は既存のOSSや公開されてるモデルをそのまま使えば認識できるだろうと高を括っていて、それがうまくいかなかったのが予想外でした。

どのみちそれらのアプローチだと毎フレーム処理するのに時間がかかってしまったとは思うので、結果的には良かった点もあるのですが、しかしながら今回のようなセグメントごとの領域の明度から7セグメントの値を読み取る方式は、位置のズレには非常に弱いので、そのあたりはいろいろ調整が必要でした。

7セグメントの初期検出領域の指定

今回の手法では事前に検出領域を指定する必要があります。

こちらの自動検出は簡単には出来なさそうなので、今回は事前にセグメント位置がわかる画像を重ね合わせて領域を指定する簡易ツールを自作しました。

プライバシーに配慮して一部ぼかし

これだと完全に同じレイアウトのデジタイマしか対応できないことになりますが、今まで観戦した試合のほとんどが同型機種を使用していたので、あまり困ることはなさそうです。（界隈でのデファクトなのでしょうか？）

モルテン デジタイマ110X UX0110

もし自動化したければ、大まかな位置なら大量にデジタイマの写真を用意して学習させれば機械学習で検出できそうなので、そこから細かく探索して適切な領域を見つけるというアプローチになるでしょうか…？だいぶ難しそうな気はします。

7セグメントの検出領域のズレの補正

7セグメントの値を読み取る方式は、位置のズレにはめっぽう弱いのですが、最悪なことに体育館のフロアで定点撮影していると、選手が走ったりドリブルしたりすることによる床の振動でどんどんスマホ本体が動いてしまうので、そのズレまで考慮する必要があります。

わずか2分ほどでこれだけズレる

今回は、少しずつズレるだけで一度に大きく移動することがないこと、角度に大きな変化はないことを前提として、解析中に一定頻度で上下左右にズラした追加の解析も行い、そちらの方が明暗がはっきり検出されてそうならそちらに基準位置をズラすという処理を入れることで、最後まで検出することができました。

このあたりは撮影環境にも大きく依存するので、今回の素材ではたまたまうまくいったものの、都度調整が必要になりそうです。

おわりに

今回は以前から試してみたかった試合映像の表示編集の自動化にチャレンジしてみました。結果としては、まだまだ素材の映像に応じた微妙な調整の上で何とか動作している感じはあり、今回作った仕組みであとは試合映像が秒で作れる！ということにはならなそうですが、少なくともこれをベースにちょこちょこコードを調整しながら動かしていけば、普通にやるよりは格段に短時間で編集できるのではないかと思いました。

自転車で取手市を一周する話

取手市とは

取手市とは茨城県の県南地域に位置し、かつては東京都のベッドタウンとして栄えたものの、その後は都心回帰によって1995年をピークに人口が減少し、さらにはお隣の守谷市につくばエクスプレスが開通したことで中心駅である取手駅の周辺も急速に寂れてしまった、そんな市である。

とはいえ都心へのアクセスは今でも悪くはなく、寂れた代わりに住宅相場が他の東京近郊に比べてお安くなっているため、個人的には都内勤務者の郊外移住先としては穴場だと思っている。実際に自分もそのような理由で東京都内から取手市に引っ越して暮らしている。

sgymtic.hatenablog.com

（あとは最近イオンモールの計画が話題になってましたね。できるといいなぁ。）

そんな取手市の地理的な特徴として、北・東に小貝川、南に利根川と、3方向が川に囲まれているというものがある。

取手市一周コース

自転車乗りなら何となく察すると思うが、要は利根川、小貝川沿いを走りながら自転車で一周するという話である。ざっくりと地図上にコースを描いてみた。緑色の線は堤防上または河川敷の歩行者自転車専用道路を走る区間、黒色の線はそれ以外の区間になっている。全周40km弱で、アップダウンはほとんどない。

取手市一周コースの図

川のない西側は仕方ないとして、南の利根川沿いにも歩行者・自転車専用道路になってない区間があるのは少し残念なのだけれども、全体の8割程度を快適に走れるのはとても楽しい。

利根川沿い

小貝川沿い

コース詳細

取手駅からスタートして左回りに一周する場合のコースを紹介する。

取手駅東口からスタート。

線路沿いの道路を南へ。

突き当たりの県道11号線を左へ。

反対側の歩道に渡る。

ここを曲がる。

堤防に上がる。

この日は花火大会の数日前だったので提灯が並んでいる。

レンタサイクルの受付もここにあるので、自転車を借りて一周するのも良い。

利根川沿い

しばらく堤防上を走ってると行き止まりになるので河川敷に下りる。

下りた後はこんな感じ。

右側は歩行者専用なので案内通りに左側へ。

信号をよしなに渡って小貝川沿いへ。

田園風景

北浦川水門を渡る。

小貝川沿い

高須橋からの道路にぶつかる。
このように橋があるたびに道路の横断または回避が必要になる。
ここを100mほど左後ろに戻れば高架下を通れるけど、横断するのが早い。交通量は多くないけど自動車に注意。

常磐線の小貝川橋梁。
ここは階段を降りる必要があるので少し不便。
自転車に乗ったまま迂回するルートもあるけど、かなり遠回りになるので大人しく歩く。

文巻橋を通る道路にぶつかる。ここは信号で渡る。

少し道幅が広くなる。

再び橋にぶつかるがここは高架下を通って回避する。

高架を抜けるとすぐ堤防に戻る道があるが、近い距離に次の橋があるのでそのまま下を走り続けるのが良いと思う。

こんな感じに。

堤防上に戻った。

しばらく走ると藤代スポーツセンターがある。
近くには小貝川リバーサイドパークやポニー牧場など色々施設があるのだが、これ以外の写真を撮ってなかった。とりあえずここがトイレ休憩スポットです。

再び橋にぶつかるのでくぐって回避。

こういう場所って何かエモい。

しばらく走ってると岡堰が見える。

岡堰水神岬公園

ちょっと道幅が狭くなるので通行人とすれ違う時は徐行しましょう。

ここで小貝川と別れて左側へ降りる。
ちなみに小貝川自転車道は常総市まであと10kmほど続く。そちらを走るのも楽しい。

交差点を左折する。

田んぼの近くを通る。

ここからしばらく取手市の 敵 お隣さんである守谷市を走る。

守谷市の道路を走ってる時はこんな感じ。そんなに走りづらい道ではない。

関東鉄道常総線にぶつかる。
自転車通行止めの標識も見当たらないのでアンダーパスの車道を通っても良いのだろうが、自分はいつも歩道に回避してる。

歩道を進む場合は階段を登る。

再び取手市に戻る。
この高架橋が市境なのだけど、守谷市の案内標識はあるのに取手市の案内標識はない。

そのまま走ってると常総ふれあい道路との交差点があるがそのまま直進する。
ここを左折しても取手市を一周出来る。
約3kmの桜並木が続く道なので、特にお花見シーズンはそちらを走るのが良さそう。

新大利根橋を渡る。

途中で左に曲がる。

利根川沿い

車両通行禁止とあるが、看板を設置している利根川上流河川事務所に問い合わせたところ自転車は通行して大丈夫らしい。通行人に細心の注意を払いつつ、ありがたく走らせていただく。

利根川沿い

左にはアジア取手カントリー倶楽部というゴルフ場がある。
ちなみに取手市および近隣には東京からの利用客を期待してるのかゴルフ場が多いので、ゴルフ好きにもオススメである。ゴルフやらないからわからないけど。

左に江戸川学園取手中学校・高等学校の校舎が見えて来たら終了の合図。

ここで一旦舗装路が途切れてしまう。
ここから先はいくつかのルートがあるが、自分は常総ふれあい道路に合流して、残りは普通の道路を走ることにしている。出来るだけ川沿いを走りたい…！という場合には最低限だけ迂回して再び堤防上に戻るルートもあるのだけど、もう十分走ったし、早く帰っちゃおうという気持ち。

ここは少しだけ鋭角に引き返す感じになる。

常総ふれあい道路に合流する。

交通量は多いがそこまで走りづらくはない。
歩道に自転車レーンが用意されてるのでそっちをのんびり走っても良い。

交差点。
このまま直進しても駅に辿り着けるが、西口に行ってしまうので今回は右折する。

右奥にわずかに見える河川パトロール車が走ってるところは利根川堤防上の道。
そちらに合流することも出来るけど、今回はこのままゴールを目指す。

常磐線が見える。

壁画

常磐線の下を通ったらすぐ左折する。

出発地点の取手駅東口に戻って来た。

おわりに

ぐるっと一周するコースは単に往復するより飽きが来なくて楽しいし、距離も40kmくらいでサッと走ってくるのに向いてるので、結構良いコースだと思う。

一周する以外に紹介中でも触れた小貝川自転車道を常総市まで走るコースもあるし、利根川沿いをそのまま河口まで走って犬吠埼を目指すコース（片道90kmくらい）もある。都心へのアクセスが良いこと以外になかなかアピール出来る点がない取手市ではあるが、サイクリングコースには恵まれてるとは思う。

まあ、走りやすさだけなら普通に荒川サイクリングロードの方が上だし、同じ茨城県南部にはつくば霞ヶ浦りんりんロードという全国でも屈指のコースを持つ土浦市などもあるため、市外の人に取手市をアピールするにはちょっと弱いあたりが「ほどよく絶妙*1」な取手市らしいというか何というか…。

ちなみに、今回平日昼前＆気温35℃の猛暑という状況だったから人のいない写真になってるけど、時間帯によっては散歩している人などもいるコースなので、通行人の安全には最大限配慮しながら走りましょう。見ての通り道幅はそこまで広くないので、ロードバイクのトレーニングとして高速巡航したい場合にはちょっと向いてないコースかもしれません。

*1:取手市のブランドメッセージ https://zetsumyo.city.toride.ibaraki.jp/

7帖の室内で球速を測ってみる話

こちらは ドワンゴ Advent Calendar 2021 4日目の記事です。

はじめに

新型コロナウイルス対策の一環としてテレワークが急速に普及し、今はご自宅でお仕事をされている方も多いのではないでしょうか。

私が働く会社でも、感染対策として昨年2月という比較的早い時期から原則在宅勤務が導入され、昨年7月にその制度が恒久化されました。

さて突然ですが、みなさんの仕事部屋に防球ネットは置いてありますか？

 

私はあります。（マウント）

 

仕事部屋です

防球ネットが仕事部屋にあると非常に便利です。仕事で溜まったストレスをいつでも軟式M号球に込めて防球ネットにぶつけて発散することが出来ます。

ただ、仕事部屋の広さは約7帖で、日本の一般的な住宅の1室としては普通の広さかなと思いますが、軟式球を投げるにはあまりに狭過ぎます。

それでも防球ネットは安定して私の投げたボールを受け止めてくれるので素晴らしいのですが、逆に常に同じ手応えしかなく、今投げた球がどの程度の勢いだったのかも知ることが出来ないので、いまいち楽しさに欠けるなと思っていました。

 

ということで今回作ったものがこちらです。

ストレス発散の様子

この記事ではこれを作った過程について書いていきます。

方針

最初に思い浮かぶのは、一般的なスピードガンで用いられる、ドップラー効果による反射波の周波数変化を観測する方式です。

ドップラーセンサーというものがあるらしく、こいつを使えば良いのかなと思うのですが、私は信号処理に詳しくないので手に余りそうなのと、そもそも狭い室内だと乱反射して正しく計測出来ないのではないかという懸念（素人考えなので正しいかはわかりません）があったので、今回は採用しませんでした。

代案として思い付くのはカメラで撮影した映像を解析する方式です。

既にプロ野球での球速計測にもこちらの方式が採用されているらしく*1、簡単な画像処理程度なら扱ったことがあるので、今回はこちらを採用してみました。

カメラ

とりあえずカメラを用意します。fps は高ければ高いほど良いだろうということでこいつを買いました。260 fps らしいです。

ELP 高速高フレームレート MJPEG 1080P 60fps/720P 120fps/360P 260fps ウェブカメラ UVC OmniVision OV4689 CMOS USB カメラモジュール

試しにボールを投げた様子を撮影するとこんな感じ。

こんな感じ

260fps を指定した場合には画像サイズは 640x480 固定になる上、映像もかなり暗くなります。ボールもかなりブレて写ってしまうのですが、お遊び程度の精度を目指すなら十分使えそうだなと思いました。

画像中の対象物検出

カメラから得られるコマ送りの画像それぞれから、ボールを検出していきます。

今回は最もシンプルに、色による検出を採用します。

先ほど撮影した画像だと比較的くっきりとボールが写っていたので輝度だけのフィルタでも何とかなるかと期待していたのですが、さすがに白色のボールを白色の壁の部屋で検出するのは難しいようです。代わりに、ちょうど蛍光色の軟式M号球が売ってたのでそれを買いました。夜間練習用らしいです。

(フィールドフォース) FIELDFORCE 軟式野球ボール M号 練習球 ナイトボールM号 FNB-722MY （株）フィールドフォース

記事冒頭の写真もそうですが、自室に置いてある物は赤・白・黒で統一されているので、黄緑色を検出すればちょうどボールだけが検出される状態になっています。最初に買ったいくつかの器具の配色が偶然同じだったことから生まれた謎のこだわりでしたが、まさかここで役に立つとは思いませんでした。

あとは以下のような流れでボールの中心座標を取得します。それぞれOpenCVにそのまま関数が用意されているようなお決まりの手法なので、何をしているのかを知りたい人はググって下さい。

原画像	レンズ歪み補正*2	ＨＳＶ色空間変換
色範囲による二値化*3	メディアンフィルタ(ノイズ除去)	重心計算

画像内の座標からの空間座標計算

さて、画像1枚のどこにボールがあるかわかったとしても、以下の図のようにボールが存在する可能性のある直線がわかるだけで、ボールの位置を確定させることは出来ません。

直線上のどこかに対象物がある

ここにもう1枚、別の角度から撮影した画像があれば、そこから得られる2直線の交点にボールがあることが確定するわけですね。

２直線の交点に対象物がある

ということでカメラをさらにもう1つ購入し、自室の2箇所に設置しました。

この両側から撮影するスタイルが最良なのかは不明

まず必要なのは1台のカメラから1つの「ボールが存在する可能性のある直線」を得ることです。

その方法については様々なアプローチがあると思いますが、今回は室内に「ちょうどカメラにぴったり収まるように写る4:3の長方形」を考えることにします。（4:3は今回買ったカメラから得られる画像の縦横比です。）

ひとまずボールがその長方形上にあると仮定した場合、その位置は前述の「4:3の長方形」に求めた二値画像の重心座標を対応させてやると簡単に決まるので、あとはカメラとその点を結ぶ直線が「ボールが存在する可能性のある直線」になるわけです。

4:3の長方形に先ほど重心座標を求めた画像を対応させたイメージ図

カメラの空間座標は、部屋のどこかを原点に座標系を定義すればそこからメジャーで計測するだけですし、この「4:3の長方形」の四隅の空間座標も、実際に4:3の板を用意してカメラにすっぽり収まるように配置すれば計測出来るので、それらの値を使えば例の直線を計算することが出来そうです。*4

そしてもう一方のカメラでも同じ直線を求めて、さらにそれら2直線の交点を求めれば、それがボールの空間座標です。実際には測定誤差もあって綺麗に交差するわけではないので、代わりに「2直線を最短で結ぶ線分の中点」を求めることにします。

あとはこれらの計算をプログラムにするだけです。あまり3D座標系に関する処理は扱ったことはなかったのですが、これまでの考え方は高校数学の「空間座標とベクトル」で習った内容がそのまま活用出来るので、当時の記憶を引っ張り出すだけで想定よりは簡単に書くことができました。

出来上がったものはこちらです。

3Dグラフ上に「4:3の長方形」を元にした計算過程を表示したもの

実際に対象物の位置を測った値と比較しても、そこそこ正確な値になっているようでした。

画像の取得タイミングのズレの考慮

前述のように2台のカメラからの画像があれば対象の位置を求めることは出来るはずなのですが、実際には2台が完全に同じタイミングで撮影した画像を取得出来るわけではないため、対象物が高速で動くような状況では正しく計測出来ません。

一応それについての対策を入れてあります。あまり手法として洗練させたわけでないので詳細は省略しますが、ざっくり言うと一方のカメラは時間差で求めた2直線からなる平面で考えることにして、この平面と他方のカメラから求めた直線との交点をボールの位置としています。

緑色の点が平面と直線との交点

速度の計算

ボールの空間座標は取得出来たので、速度を求めるには2つの空間座標の距離を求め、それを経過時間で割るだけです。

経過時間を計算するためにはボールがそれらの空間座標に存在した時刻が必要になるので、今回はカメラの画像が取得できた時のPC側の時刻を使っています。

伝送や処理の遅延等を考えると必ずしも正しいとは言えず、実際に後述するようにここらへんが怪しいことが原因で誤差が生じている可能性があるのですが、他に使える時刻情報もないので一旦そのままやってみます。

動作確認

実際に投げて測ってみた結果は冒頭の動画の通りです。

測定の過程を出力した画像はこちらです。

（測定には10フレーム使えていたので、そのうちの4フレームの抜粋です。）

メインカメラ

メインカメラ（重心座標検出）

サブカメラ前

サブカメラ前（重心座標検出）

サブカメラ後

サブカメラ後（重心座標検出）

3Dグラフ上に計算過程を表示したもの

ぱっと見た限りでは、ちゃんと動いてそう？？

たまたま直径40mmほどのウレタン球を一定速度で連続発射する謎のマシンを持ってたので計測してみましたが、毎回大体同じ球速が表示されています。まあ、結局この商品のカタログに球速の記載はないのでこの値が正しいのかはわからないのですが、少なくとも低速で移動する対象においては安定した計測結果が出せていそうです。

部屋の配色上、青色もバッチリ検出可能

[フィールドフォース] インドア バッティングマシン ACアダプター対応 FPM-103

ただ、今回の測定方法だと、球速が上がった場合にはボールの像がブレて位置の誤差が大きくなる上、計測に使えるフレーム数も減るので経過時間の誤差も大きくなるという、悪いことしかない状態になります。今回は私が野球経験も運動センスもなかったため球速も大したことなく、ギリギリ信頼出来そうな精度で計測が出来ていたのですが、これ以上球速が上がると厳しい気がします…。

課題など

ここまで書いた流れは概ね画像処理で球速測定しようと思い付いた時点で予想してた通りなのですが、実際にはいくつか想定外の問題もありました。いちいち書くと脱線だらけになるのでここにまとめて書きます。

フレームの取得タイミングが安定しない

稀にあまり信頼できそうにない球速が表示されてしまうことがあるのですが、画像を取得出来る間隔にムラがあることが原因のようでした。撮影間隔にムラがあるのか、PCまで伝送する時に詰まるのか、はたまたPCで取得する際に遅延してるのかはわかりませんが、今回はPC側の時刻情報しか使えない以上、稀に発生する誤差は避けられなさそうです。

計算に利用出来るフレーム数が思ったより少ない

自室の間取りで投球するとリリースポイントから防球ネットまでの距離は 1m くらいしか確保出来なさそうでした。例えば 80km くらいのボールを投げたとしても

1(m) / ( 80(km/h) * 1000(km -> m) / 3600 (h -> s) ) * 260 (frames/s) = 11.7 (frames)

ということで、11枚くらい。前述の通りカメラからフレームを取得するタイミングにはムラがあるものの、フレーム数が多ければ誤差は僅かな範囲に収まるだろうと期待していたのですが、この枚数だとちょっと心許ないです。

天井照明の近くを通るとつらい

投球動作にはある程度スペースが必要だし、防球ネットの後ろにも余裕が必要なので、ボールを検出するのは部屋の中央辺りになってしまうのですが、部屋の中央には天井に照明が設置されています。

上投げだとボールは床から2mくらいの位置から放たれるため、そのままボールが照明の下を通過するとかなりの近距離で強い光にさらされることになり、どんなにHSVの閾値を調整してもボールの全てを正しく検出することは出来ませんでした。

実際にこのカメラのこのあたりのボール検出が一番怪しい

最後に

結局のところ本当に正確なのかという疑念が消えないので、球速が計測できるマシンが置いてあるバッティングセンターまで足を運びました。

コントロールが酷いのは気にしない

結果としては大体同じくらいの球速で表示されている気がします。

まあ、そもそもバッティングセンターの球速測定は正確なのかという話もありますが、「バッセンに置いてあるスピードガンと同程度の球速測定が仕事部屋でいつでも出来ている（気がする）」ということで、とりあえずは満足です。

 

最後の最後に、一応今回作成したコードを GitHub に上げておきます。

完全に自分の環境だけで動かすつもりで書いており、そのまま他の人が動かすことは厳しいと思いますが、今回説明を省略した部分で実際に何をしているのか気になる方がいらっしゃれば、覗いてみてください。

github.com

*1:https://japanese.engadget.com/jp-2019-09-07-jiko.html

*2:実際にはレンズ歪み補正はこのタイミングで行うのではなく、最後に得られた重心座標のみに対して行います。（そっちの方が余計な計算をせずに済むので。）

*3:実はこの画像はわかりやすさのために意図的にHSVの範囲を広げてノイズを出しています。実際には適切なHSV範囲を設定すれば稀にごく僅かなノイズが発生するだけでした。

*4:さすがに面倒なので、「4:3の長方形」の四隅については実物の板を用意するようなことはなく、画像の決まった位置に写る壁・床などの計測しやすい箇所を二つだけ計測すれば残りは計算で求まるようにしたのですが、詳細の説明は省略します

茨城に480万円で家を買って東京で働く話

概要

都内で働き、都内に住んでいたが、茨城県の中古一戸建てを購入して引っ越した。 家自体の値段は480万円、追加でリフォーム費用が200万円ほど。 郊外暮らしもそこまで不便ではないので選択肢の一つに入れても良いのではなかろうか。

背景

地方から上京し、妻と当時2歳の息子と同居していた。

8万円で2DKのマンションを両国に借りていた*1が、全9戸の小さなマンションなのにちょくちょく警察や救急車が来るなど住民に難があったほか、新耐震基準前の建築であったりエレベーターなしの4階であったり、家族で暮らすには向いてない住まいであった。

最終的には、子供が夜泣きしている時に警察や児童相談所に虐待の疑いで通報されてしまう事が何度かあり、それが純粋に善意だったのか嫌がらせ目的だったのかは不明だが妻には相当なストレスになったようで、引っ越しを検討することになった。

家探し

前述の理由で騒音トラブルに悩まされたので一戸建てが望ましく、それならばと賃貸ではなく持ち家にすることに。

妻も自分も貧乏性で最初から新築は眼中になく、最低限の条件を満たす範囲でとにかく安い中古一戸建てを探そうということになった。

その最低限の条件というのは以下。

• 通勤時間が片道1時間半以内
• 最寄り駅から徒歩15分以内
• 建築が1981年（新耐震基準施行）以降

特に通勤片道1時間半というのは、庭付き一戸建てが庶民の憧れだった一昔前ならまだしも現代では避けられる距離だと思う。ただ、自分の職場ではラッシュ時を避けた時差通勤が可能なので、何とかなるだろうと考えた。

茨城県取手市

前述の条件で色々と物件を探していると、取手市が安そうということに。

取手市は、都心から常磐線沿いに隅田川・荒川・江戸川を渡って千葉に入り、さらには利根川まで渡って茨城県に入ったすぐの場所にある。

goo.gl

取手市とはどういう街か。 Wikipediaの記事の冒頭を引用すると以下の通り。

1970年代から1980年代にかけて東京都心のベッドタウンとして開発され人口が増加。それ以降、いわゆる「茨城都民」と呼ばれる住民が多くなった。

1995年をピークとして以降、都心回帰現象の影響や、子供が成長して家を離れるケース（当初より核家族が目立った井野や戸頭では、団塊世代前後の夫婦のみが暮らし、子供は進学・就職・結婚等で取手を離れて他地域を生活拠点とするケース）も多く見受けられ、人口は減少傾向に推移している。

つまり、高度成長期に東京通勤圏として栄えたものの、現代になって衰退した街ということである。

特に取手駅周辺は、つくばエクスプレス（TX）開通の影響を大きく受けており、以前は守谷市・常総市・つくばみらい市といった茨城県南部の人々は取手駅でローカル線からJR常磐線に乗り換えて東京に出ていたのに、TX開通後は守谷駅から秋葉原駅まで行けるようになってしまった。

また、TX沿線は大型商業施設や大型マンションの建設も進んで綺麗で新しく子育て世代が住みやすい街として人気になっており、その中でも守谷市には「茨城でもいいや」と考える人の貴重な需要すら持っていかれてしまった。

そのような取手市の衰退ネタは、取手市を舞台にしたWeb漫画である「けんなん！」*2が面白いので、他の話も含めて読んでみてほしい。

blog.livedoor.jp

しかしながら、それにより取手市は、ギリギリ東京通勤圏でありながら住宅相場が安い穴場スポットになったのである。たぶん。

480万円の家

取手市に狙いを定め、いくつかの物件情報サイトで家を探した。

条件に合致する700〜900万円の物件をいくつか内見には行ったものの、取手駅からさらに乗り換えが必要などの問題があり、いまいち決めかねていた。

そんな中である日、住宅情報サイトに以下のような新着物件が追加されていた。

• 480万円
• 4LDK
• 取手駅から徒歩15分以内
• 築年数25年以下

条件だけ見ると非常に良い。ただ、内観写真もなく情報が少ない。

とりあえず不動産会社に連絡してみると、すごく汚れてますという返答。

「うーん？これはおとり物件か…？」とも疑ったが、内見したいなら案内しますよとの話だったのでお願いすることに。

その時に見た状況がこれ。

LDKの一部が激しく雨漏りし、そのまま数年放置されたことで天井がボロボロになっていた。さらにその影響か、LDKは全体的に壁も床も汚れている。

これはかなり酷い…のだが、逆にLDK以外はそこまで汚いわけではなく、何より破格な値段と好立地だったので、妻も自分も一発で気に入り「これ買いたいです！」と即答した。

とはいえ、建物の安全性は気になるので、本契約の前にホームインスペクション（住宅診断）なるものを自費で依頼し、建物に大きな瑕疵がないことは事前に確認した。費用は5万円程度だった。

リフォーム

古い家に住むことに抵抗がない自分と妻でも、さすがにそのまま住むことは出来なかったのでリフォームすることに。

ここでホームセンターで資材を揃えてDIYしました…とか言うとブログ記事としてはもっと面白くなるのかもしれないが、そんな技術も暇もなかったので素直に業者に頼んだ。

結局、LDKの雨漏りの補修や天井＆壁のクロス交換のほか、外壁塗装から和室の畳の張り替えまで色々追加してしまったので、最終的にリフォーム費用は200万円ちょっとになった。*3

リフォーム後の写真はこんな感じ

部屋の造りが少し古臭いのは否めないが、壁と天井のクロスを全て張り替えたので清潔感は出た。このLDKはカウンターキッチンで15.5帖の広さがあり、そこそこ気に入っている。

フローリングは全く張り替えなかったので、雨漏りが直撃した部分の床は色褪せたままになっている。ただ、当初は床全体にも傷みがあると思っていたのだが、ハウスクリーニングだけでそこそこ綺麗になったのは嬉しい誤算だった。

ちなみに、取手市には住宅リノベーション補助金という制度があり、中古で購入した住宅のリフォーム代についてその費用の10%、上限30万円まで補助してくれる制度がある。自分もそれで20万円ほど補助して貰えた。*4

同じような制度は多くの自治体で行われてるようなので、もし中古住宅の購入を検討している場合は調べてみると良いと思う。

住んでみた感想

進学・就職で実家を離れるまでは地方で生活していたので郊外暮らし自体は特に心配していなかったが、長距離の電車通勤はこれまで経験がないので実際やってみるとどうなのだろうという不安はあった。 結論から言うと通勤含めて概ね予想通りではあったのだが、いくつかの観点での感想を書いていく。

（良い話と悪い話を混ぜて書いたらわかりづらくなったので [Great], [Good], [Bad] を先頭に付けた。それぞれ「都内に比べても良い」「都内には劣るがそこまで悪くない」「悪い」くらいで考えていただけると。）

快適さ

都内で高級マンションに住む事に比べてどうなのかは知らない（まあ負けるだろう）が、少なくとも都内に安い家賃で無理して暮らしていた頃に比べると快適である。

[Great] 家が広い

4LDKは家族3人で住むのに十分な広さで、自分専用の部屋も持てた。都内でこの広さに住もうとするとある程度のお金が必要になるので、安く広い家に住めるのは郊外の一番良いところ。

[Good] 騒音に気を使わない

引っ越して数週間が経った頃、子供が広いリビングを楽しそうにドタドタと走り回っているのを見て、一戸建てにして良かったなぁと思った。

Great ではなく Good にしているのは、別に戸建てでなくてもお高めのマンションなら防音はしっかりしてるのと、古い家なので建物自体の防音性は良いものではなく、周辺が閑静なのもあって、深夜に子供が大声で泣いてしまうと外まで泣き声が漏れてしまうため。

[Bad] 虫が多い

特に自宅は虫が多く、蚊、クモ、蛾のような不快害虫はもちろん、トンボ、カマキリに加え、なぜかクワガタも室内に入って来てしまったことがある。取手市というよりも自宅の周辺環境の問題だと思うが、市内を歩いていても都心よりは虫が多いと感じる。自分は平気な方だが、苦手な人には結構つらいであろう。

[Bad] (2020/06/14追記) 冬場は室内が寒い

ブコメで指摘されてて思い出した。結構大きなデメリットなのだが実家も同じだったのと喉元過ぎてたので忘れてた。

古い木造住宅は断熱性が優れてないので、冬場は室内でも非常に寒い。そもそも取手が東京よりも寒い*5。特に先に写真をあげた15.5帖で広々として窓も大きく明るいお気に入りのLDKは、冬場になると無駄に広く窓からも冷気が伝わる暖めづらい部屋になってしまい、真冬にエアコンをぶん回してると月の電気代がゆうに2万円を超えてしまう。

娯楽

自分はインターネットされあれば楽しく生活出来るのだが、家族がいるとそうも行かない。週末に家族で何して過ごすかを考えた場合は、取手市だと苦労することは多い。

[Great] 利根川サイクリングロードに近い

自転車が好きでロードバイクに乗ってるのでこれは非常に嬉しい。ちょっと気が向いた時に30kmほど小回りしても良いし、銚子市の犬吠埼まで往復180kmを丸1日がっつり走っても良い。

[Bad] 近場の遊び場が少ない

一応近場に娯楽、商業施設はあるのだが、やはり東京に比べるとその数が少なく、数年住むと大体どこも行き尽くして飽きることになる。

よく田舎民はイオンで遊ぶと言われるが、そもそも取手市にはイオンすらない。昔はあったのだが取手の衰退により2015年に閉店してしまった。*6

[Bad] 水族館・動物園などが非常に遠い

水族館や動物園、遊園地のような子供と行きたい大型の娯楽施設は取手市の周辺にはなく、都内あるいは大洗・日立などの茨城県央まで出掛けることになる。子供を連れての移動となるとちょっとした旅行になってしまう。

利便性

当然ながら利便性では都内には敵わないが、意外とそこまで不便ではない。

[Good] 取手駅が始発で座れる

JR常磐線は取手駅始発の便が多く、その便を選べば確実に座れる。座れてしまえば今はスマホという便利なものがあるので、長距離通勤もそこまで苦痛ではない。

[Good] 終電が遅くまである

取手は一応東京通勤圏として発展しただけはあって、東京からの終電は意外と早くない。

JR常磐線の取手行き最終列車は上野駅00:23発で、山手線でちょうど反対にある恵比寿駅でも23:49発の電車に乗れば間に合う。都内在住者の終電とそんなに変わらないので、飲み会で一人だけ先に帰るようなケースはあまりない。*7

[Good] 付近の店舗がそこそこ充実している

東京通勤圏としてある程度の人数が集中して住んでるため、住宅地であれば付近にスーパーやコンビニはそこそこある。特に自宅からはコンビニもスーパーも徒歩3分以内に立地しており、日常生活の食料品や消耗品の買い物には困らない。

都内のように超大型の商業施設や多様な専門店はないが、そういう買い物は都内に住んでた頃から通販が中心だったし、どうしても実店舗で買いたい場合は都内まで足を運べば良いのが関東近郊の強み。

[Bad] 一部地域限定サービスが使えない

Uber Eats や Prime Now など、スマホアプリからリアルでのサービスを受けることが出来る流行りのサービスは、一部都市限定のものが多い。東京23区から神奈川、埼玉、千葉と対象が広がっても、茨城までは対象とならないことも多い。

平成のネットや通販の普及で、都市と田舎での利便性に差はなくなったと思っていたが、令和になってまた変わるのかもなぁとちょっと心配している。

新型コロナによる生活の変化

さて、去年までは前述のような感じでそこそこ不便ながらも概ね快適に暮らしていたのだが、今年になって生活スタイルもだいぶ変わってしまった。

新型コロナウイルス感染症の流行である。

自分の勤務する会社も在宅勤務が推奨となった上、緊急事態宣言後もそのまま恒常的に在宅勤務が導入されることになった。

往復2時間を超える通勤時間が不要になったことで平日でも時間の余裕は出来たし、急に在宅勤務が決まって作業環境に困る人も多い中で、自分は作業机のある自室も確保していたため大きな支障もなく、結果的には郊外に引っ越しておいてラッキーだったかなと思う。

通勤の利便性も重視した上で今の家を選んでいるので少し損した気持ちもあるのだが、在宅勤務が働き方の中心になったとしてもアフターコロナであれば一定の頻度で出社する機会はありそうなので、無駄に近くなく遠過ぎもしない今くらいの通勤距離がちょうど良いのかもしれない。

最後に

茨城県取手市に住む話とボロ家を買ってリフォームして住む話とが混ざって話の軸がブレてしまったが、今回は特に前者を伝えたくてこの記事を書いた。

正直なところ、自分は実家が貧乏で親の老後が心配だったり奨学金の返済も残ってたりと経済的にマイナスからのスタートになっており、それを自分の生活水準の低さと日常的な苦痛への耐性を利用して手っ取り早く帳尻を合わせたみたいなところがあるので、お金に余裕がある人は素直に東京に住むのが良いと思う。

ただ、都内の住宅相場が異常なほど高いのは事実だと思っているので、まだこれから社会がどう変化するかはわからないけど、もし近い将来に在宅勤務や時差通勤の普及によって必ずしも通勤の利便性を最優先に考えなくて良くなるのであれば、無理に都内にこだわらず郊外を引っ越し先の選択肢に入れても良いのではなかろうか。

（そして取手市にも人が増えて、あわよくば再興を……無理かな……。）

最後の最後に、自宅と取手市のお気に入りの写真を並べておく。

傷んだ床をカーペットで隠したリビング

勢いで機器を揃えてよくわからないことになった自室

リボンとりでビル（旧取手とうきゅう）を構える取手駅前*8

海から88.0km地点の利根川サイクリングロード

田植えシーズンで青空の映る取手市西部の田園風景

*1:都内に住んだ経験がないとわからないかもしれないが、結構安い。

*2:個人的なお気に入りは始発の話と高井さん登場の一連の話です。

*3:内訳としてはLDKの雨漏り関連の補修が30万、壊れてた給湯器やビルトインコンロの交換が20万、外壁塗装が100万、その他が50万という感じ。外壁塗装が一番高いのだが、10〜20年の間にはやっておかないとマズいものらしいので、最低限のリフォームだとしても150万円は掛かりそう。

*4:住宅の購入自体を補助する住宅取得補助金という制度もあるが、これは優良な（新しい、広い、緑が多い、など）住宅を購入した場合にのみ適用されるもので、当然ながら今回は対象外。

*5:昨冬の最低気温を 気象庁のページで調べたが、東京が-2℃に対し、取手（のお隣の龍ケ崎）は-6℃。

*6:そして守谷にイオンが出来た…。

*7:ただし、取手駅に着くのは1:05になる。

*8:取手とうきゅうについても「けんなん！」を読んで下さい。

第9羽 毛玉はタイポし無慈悲なslは放たれる

この記事は「ごちうさ Advent Calendar 2015」9日目の記事です。

はじめに

こんにちは、 @sgymtic です。

ギリギリで放映済みの羽数を追い抜かずにすみました。

明日以降の担当の方がタイトルフォーマットをどうするのか気になります。

 

さて、本当はしっかりとした記事を書きたかったのですが、

最近無駄に忙しくて記事を書く時間が取れませんでした。

とりあえずネタは用意したので、サクッと紹介だけさせてください。

 

pyonpyonコマンド

週末になって疲労が溜まり、特にごちうさ放映日の土曜が近づいてくると、作業中に ls と pyonpyon とのタイポが多発しますよね。

これはその対策として作ったコマンドです。チノちゃんがコーヒーを淹れてくれます。

sgymtic/sl at pyonpyon · GitHub

ちょっと原型を留めてなくてアレなのですが、元ネタ、というかフォーク元は皆さんご存知 sl コマンドです。

このコマンド、一晩徹夜して作り上げた自信作なのですが、実は別の場所で、しかも結構前に発表したことがあるネタです。ブログとかで一般向けに公開してはないので、これだけでも許されるかな、とも思いましたが、さすがに同じネタを使い回すのもということで、もう一個作りました。↓

 

ごちうさキャラミキサー

ごちうさキャラの服装・髪型・髪色・顔をミックスして名前と画像を表示します。

ごちうさキャラミキサー - sgymtic.com

 

各パーツのイラストは頑張って描きました。絵は得意ではないんですが、ペンタブとCLIP STUDIO PAINTを買ったのでなんとかなります。

すごいぜワコム。すごいぜセルシス。

これ、各パーツをCanvasとかで合成しているのではなく、事前に全パターンの画像を生成してます。5^4 = 625 通りです。

さすがに合成処理は1枚ずつやってられないので、Image Magickをループで呼び出すシェルスクリプトを適当に書きました。あと、同じループで twurl を使ってTwitterシェアまでしてしまって、その画像URLを記録するようにしています。

ごちうさキャラミキサー (@gochiusamixer) | Twitter

既にTwitterに投稿された画像のURLを本文に含めてツイートすると、そちらはちゃんと画像がタイムラインでプレビューされるという Twitter の仕様があります。だから、結果に対応する画像URLを本文中に含むようなTwitterボタンを配置するだけで、ちゃんと画像プレビューされるシェアボタンが実現出来ます。

 

ということで、みなさんツイートしていただけたら嬉しいです。

 

おわりに

記事が短くて恐縮ですが、以上が僕のごちうさアドベントカレンダーのネタでした。

明日の担当は neotaso_ さんです。