upsilon’s blog

備忘録なので内容は限りなく薄いです。

DevSumi 2019 聴講録

DevSumi 2019

2019/02/14-15 於 雅叙園

TL;DR

例年雅叙園で行われるオープン・Web系技術カンファレンス
今回は2日目の午後のみ参加 

聞いた講演

これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ -
Elixirを実際に使い込んだ人ならではの本当の楽しさ、辛さが滲み出ていた。自分もElixir使ってみようかな
プロダクトをGrowthさせるデータ駆動戦略の基礎知識~DMM.comにおけるユーザーレビュー基盤のKPIツリー公開~
プロダクトオーナー の立場で データドリブンなグロースハックをする話。KPIを設定する際の選定基準について詳しく話していて参考になった
セキュアな環境でDevOpsを実現する厳選ツール
セガゲームスにおける github Enterprise の導入事例。 git自体は今更感があるが、新しい技術を会社組織に導入した事例としては、大いに参考になった
エンジニア人生と定年退職、人生100年時代のエンジニアの生き方
講演者のエンジニアとしてのリタイアするまでの約40年のキャリアを、コンピューターの歴史と共に振り返る講演
 

これも聞いてみたかった

ゲームQAを支える技術~前処理・後処理は大変だが役に立つ~(太田 健一郎[スクウェア・エニックス])
中国・深センのテクノロジー最新事情(ちゃんとく[dotstudio]/寺尾 英作[SBクラウド])
システムエンジニアは空を飛ぶ夢を見れるのか~普通のSEがドローン系SEになるまで~(佐藤 明)
Webアプリのチューニングバトル「(社内)ISUCON」の魅力と楽しさ(櫛井 優介[LINE]/古川 陽介[リクルートテクノロジーズ]/南 直[Wantedly]
Site Reliability Engineering at Google(中井 悦司[グーグル・クラウド・ジャパン])
 

これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ -

 

発表者

幾田 雅仁
gumi Inc. CTO

Erlangとのつきあい

2007年 Erlangと出会う
2011年 Erlangでクレジット決済サービスを構築
2013年 Erlangでゲーム認証/課金サービスを構築
2014年 Elixirと出会う

私が愛するElixir/Erlangの楽しさ

Web開発者の悩み

  • 複雑化するコード
  • 肥大化するサーバー構成
  • 増え続けるクライアント
  • 素早くリリースしたい
  • 複雑化するサーバー構成

Web開発の辛さを改善し、以下の3つを実現するのが Elixir/Erlang

  • 並行性
  • 耐障害性
  • メンテナンス性

gumiでの利用実例

  • マイクロサービス群
    • 認証サーバー
    • 課金サーバー
  • ゲームサーバー群

流行ってない

Elixir/ErlangはWeb開発のための優秀なツールが完備されているのに…
  • サーバー構成をシンプルに保てるのに
  • コードをシンプルに保てるのに
  • 夜寝れるのに
  • 流行ってない
  • 転職サイトの求人数でみるとRubyの100分の一

なぜ流行らない?

  • 学習コストが高い(と思われている)× 実際のWeb開発では納期が短い
  • =Elixir採用されない
学習コストが高い(とも思われている)要素
  • 並行処理
  • 関数型
  • マクロ
  • Erlang

実は、Webシステムの開発に限定すれば、学習コストは高くも低くもない

  • Elixirは学習コストの割には恩恵が大きい
学ぶことと学ばないことを取捨選択して学習コストする
  • 学習コストを割くこと
    • リストの扱い方
  • しばらく学習コストを割かないこと
Phoenix(Elixirで作られたWebフレームワーク)でWebサービスを開発するなら
  • 逐次処理を書くだけで軽量プロセスの恩恵を享受できる
  • よって、しばらく、並行処理は忘れてよい
  • 学習コストを払うのも後回しでよい

並行処理

独立したCPUを持つ
  • ErlangVM(EVM)上で動くPhoenixの動作
    • PhoenixではEVM上にCowboyプロセスが常駐
    • Cowboyプロセスがhttpリクエストを受けたら、個別のリクエスト毎に軽量プロセスを生成して軽量プロセスがリクエストに対する処理を行う
    • この動きは、OS上でApacheが動く仕組みと似ている
      • EVM = OS
      • Cowboy = Web Server(Apache)
      • 軽量プロセス = CGI
      • iex = Shell
    • コンテキストスイッチはEVMに任せ、軽量プロセス上で動く処理は逐次処理として書くだけでよい
    • 一つの逐次処理の負荷が他の処理に影響しにくい
ネットワーク上の一意なアドレスを持つ
  • EVMは軽量プロセスに一意なアドレスを割り当てる
  • アドレスを使って軽量プロセス間で通信できる
  • 軽量プロセス同士をlinkすることができて、片方で異常が起きたらもう一方へと知らせてくれる
    • 不要なプロセスが残り続けるということがない
EVM(Erlang VirtualMachine)=OSと似たプロセスの仕組みを持つ
  • 軽量プロセスは耐障害性を向上する
  • 速さは…中程度
  • 結果として、並行処理の学習コスト不要で、ほどほどに遅くない、とても楽で安全

関数型

巷で噂されている良い話
    • 副作用が少ない
    • データ処理に集中できる
    • gotoは処理フローの迷子
    • OOは状態の迷子
そのような話は前提条件が誤り
  • Elixirは純粋な関数型ではないから…
    • 関数型由来の仕組みが少ない
    • OO由来の仕組みが少ない
    • 複雑さが排除されていて、理解するための文脈が少ない
そもそも、純粋な関数型言語の条件
  • 参照等価な関数で表現できることが多い
  • e.g. 演算子、例外、IOなどが関数で表現されている
 
Elixirはあまり純粋ではない
 
Elixirらしいコードの読み書きを学ぶおすすめの学習方法
 
初歩 - プログラミングElixirを読む前に…
  • リスト
    • 活用のカギは構造と再帰
    • リストを再帰でどう使うか解説
  • Enum
    • filter, map, sort  等
    • 関数がたくさんあるが、よく使うものから覚える
    • まずは、プログラミングElixirやElixirSchoolで紹介されている関数を覚えるとよい
    • _by, _while, _every サフィックスを覚える
  • パイプライン
    • パイプラインの存在意義は、関数定義に一貫性が生じること
    • パイプラインが使えるように関数を定義する癖をつけよう
      • 第一引数=操作前データ、戻り値=操作後データ
    • パイプラインはJavaScriptにも入るかも
      • Elixirで先行体験してライバルに差をつけよう
  • do
    • do内にはスコープがあるのでif文が読みやすくなる
 

私が愛するElixir/Erlangの辛さ

EVMについて

EVMは高機能
機能があると使いたくなる…が、Webシステム開発ではほぼ必要ない
  • そもそも私のモチベーション=楽をしたい
Elixirの用途を割り切るため断捨離

関数型とOOについて - 混線する関数型とOO

OOにどっぷり漬かっている人はモジュールをクラス定義のように使ってしまう
  • モジュール単位で抽象化するのはやめよう>やるなら関数単位で
プロトコルとビヘイビアを混同する
と覚える

マクロは高機能

まとめ

  • EVMは高機能だが断捨離しよう
  • モジュールで設計(抽象化)するな、関数中心で考えよう
 

プロダクトをGrowthさせるデータ駆動戦略の基礎知識~DMM.comにおけるユーザーレビュー基盤のKPIツリー公開~

 

講演者

  • Masato Ishigaki
    • Product Owner at DMM

プロダクトをGrowthさせる

  • プロダクトのグロースはS字カーブをたどる
  • 複数回の改善で連続したS字カーブをたどるのが理想
  • プロダクトグロース = 改善の繰り返し = データドリブン
 

データ駆動戦略とは何か?

  1. データドリブンに戦略を組み立てていく
  2. 不確実性に強い組織へ

Why

なぜデータドリブン?
  • 直観に頼る仮説は量産されがち > 開発者を圧迫する
  • リリース後にデータがないと学習できない、次の仮説が立てづらい

What

データ駆動戦略で何ができるのか
  1. プロダクトの状態を可視化できる
  2. 仮説/施策を作り、売り上げに貢献できる
  3. 意思決定を最速化できる
  4. 意思決定を定量的に共有できる
  5. 未来を予測して戦略が作れる

How to

データ駆動戦略における3種の神器 を駆使して行う
  1. データ分析基盤
  2. 優れた指標 - 指標に基づくKPI
  3. 開発プロセス - リーン・アジャイルアジャイルマーケティング

DMM.comにおけるデータ駆動戦略

DMMには40以上のサービスがある
事業ドメインごとに自己組織(スクラムチーム)化している
自己組織化したチームにおいて、Product Owner の強い味方が  データアナリスト である
データアナリストはプロダクトオーナーとデータを見ながら日々会話する

DMM.comのデータ基盤

購買ログ、レコメンド履歴、行動ログなどのBigDataに蓄積
データアナリストがデータ分析を行って仮説立案する
データアナリスト×プロダクトオーナー が、データドリブンで仮説立案→意思決定する

ユーザーレビュー基盤プロダクトについて

コンテンツに対するユーザーレビューは購入決定の強力な動機
70%以上のユーザーが、レビューを見て購入の決定をしているという統計結果もある
 
DMMでは、サービスで利用されるユーザーレビューの仕組みは一つのプロダクトチームが専門で開発、運用している
データを一元管理することにより、データドリブンな開発が可能になる
 
どんな行動ログをトラッキングしているか
  • 星の数・コメント・平均評価
  • 参考になった数・いいね押下ユーザー
  • レビューのどこまでスクロールしたか
  • レビューを見た後の行動(購入・カード追加・離脱)

データ分析基盤について

データ駆動戦略は組織として進行しないとビジネス価値が集まらず、効果は薄い
データ駆動がもたらすメリットを定量的にデータを使って提示しなければいけない
データアナリストが分析しやすいデータ分析基盤を構築しなければならない
  • データ基盤の規模
    • テーブル数:数千テーブル
    • 総レコード数:数億レコード(感想:DMMの規模で数億は少なくない?)
    • BIツール:Redash
 

優れた指標でないとデータは「駆動」しない

 
再掲:三種の神器 - 2. 優れた指標
  • データが駆動する とは?
    • データを見ることで 次の行動 につながること
    • Action → Result → Next Action
 
優れた指標の3つの土台と4つの指標
 
3つの土台
  1. 優れた指標は 比較 ができる
  2. 優れた指標は わかりやすい
  3. 優れた指標は 比率割合 である
 
4つの指標
  1. 定量的指標 vs 定量的指標
    • 定性的 = 主観的で感覚的な指標 インタビュー・調査・クレームなど
    • 定量的 = 科学的数値な指標 - 会員登録数・売上金額など
      • ユーザーレビューにあてはめて考えると
        • 書く人の定量的指標は
          • レビュー増加率(CV)
          • レビュアー増加率(CV)
          • レビュアー種別増加率
        • 見る人の定量的指標は
          • レビュー経由購入率(CVR)
  2. 虚栄の指標 vs 本物の指標
    • 虚栄の指標 = 次の行動につながらない指標
      • ex. 会員登録数 - 時間とともに上がるだけ
    • 本物の指標 = 次の行動につながる指標
      • ex. 会員登録数+離脱率+アクティブユーザー率
        • 会員登録数だけ見ると虚栄だが、他の指標と合わせてみると次の行動につながる
    • ユーザーレビューに当てはめて考えると
      • 虚栄の指標
        • レビュー増加率
        • レビュアー増加率
      • 本物の指標
        • 新規レビュアー率
        • アクティブレビュアー率
  3. 先行指標 vs 遅行指標
    • 先行指標 = 未来を予測した指標
    • 遅行指標 = 変動後の数値を示す指標
  4. 相関指標 vs 因果指標
    • 相関指標 = AとBが関係していること
      • これから起こることが予測できる
    • 因果指標 = AtoBであること
      • 未来を変えることができる
    • ex. 「交番の量」が多いほど「犯罪件数」が多い → 鋼板を減らしても犯罪は減らない。相関関係であっても因果関係ではない
 
未来を変えたい指標があって、その指標と因果関係になっている指標を見つけたい!
  • 因果関係を探すために、相関関係がありそうな数値をグラフ化してモニタリングし続ける
 
ユーザーレビューで使っているKPIツリーを公開!(ここが本講演の目玉)
  • レビュー増加率
    • レビュー投稿増加率(星のみ)
    • レビュー投稿増加率(コメントあり)
    • レビュー掲載コンテンツ率
    • レビュー投稿→承認タイムラグ日数
  • レビュアー増加率
    • 購入者レビュー数/率
      • 新規レビュアー増加率
      • アクティブレビュアー増加率
    • 未購入者レビュー数/率
      • 新規レビュアー増加率
      • アクティブレビュアー増加率
  • レビュー閲覧率
    • レビュー先頭閲覧率
    • レビュー末端閲覧率
    • レビュー「次へ」閲覧率
    • レビュー経由購入率
 

データ駆動を実現する開発プロセスとは

 
 
リーンスタートアップとして有名なBMLループを使う
  • LEARN → IDEA
    • 仮説に妥当性を持たせる検証 (ex. A/Bテスト等)
    • 仮説立案
    • 事前に検証をすることで、開発しなくていい機能を減らす
  • BUILD → PRODUCT
    • アジャイルでリードタイムを短くMVPを開発 → リリース
  • MEASURE → DATA
    • データサイエンスをもとにデータを計測 → KPIに落とし込む
 

アジャイルマーケティングを用いたキャンペーン手法

アジャイルマーケティングとは、従来のマーケティングアジャイルやリーンを適用したマーケティング手法であり、アジャイル・リーン開発との親和性が高い
  1. キャンペーン中に「ニアタイム」でデータを取得。小さく初めて、小さく改善をデータ駆動で高速で繰り返す
  2. 過去のキャンペーンのデータを必ず蓄積して計測する。そこから計測→学習して次のキャンペーンにつなげる
アジャイルマーケティングで可視化するべき指標
事例:購入した商品にレビューするだけで、1レビュー10ポイントをプレゼント
  1. 想定される効果
    • レビューが増えると購入意欲が上がるので売り上げが伸びると予想される
    • レビュー数0→ 1、 1→2、 2→3でコンテンツ当たりの売り上げ増加見込みは違う
    • それぞれのパターン×コンテンツ当たり売上増加見込み×コンテンツ数で増加額を予測する
  2. キャンペーンを終了させる基準
    • 予算に対して費用がペイしているかを毎月確認していく
    • ROI や ROAS を指標とする
  3. 大きく成功した際、どこにリソースを再配分するか
 
 

セキュアな環境でDevOpsを実現する厳選ツール

講演1

GitHub Enterprise 導入から定着までにやってきたこと

講演者

上田 展生[セガゲームス]
 

はじめに

  • 3年前(2016/1)は…
    • 全員がSVNを利用(Gitも使ってない)
  • 今現在は…
    • 全員がGitHubEnterpriseを利用
    • アカウント数 450
    • Organization数 35
    • リポジトリ数 630
    • CircleCIなどとも連携
 

本日伝えたいこと

  • 何をして導入を進め定着させたか
  • 人員・サポート方法・会社への説明・現場の声・活用方法
導入から定着させるまでの参考になれば
 

試験導入

2016/2 導入委員会立ち上げ
  • 3名で片手間
  • 小さいチームへの導入サポート
  • VMサーバー整備
  • 自分たちもGitHubの勉強をしながら
 
2016/5 新規プロジェクトで導入開始
  • 新プロジェクト立ち上げ時に導入
  • 50ライセンス購入
  • 利用者向けの説明会などサポート開始
 
2016/9 導入規模の拡大
  • 利用プロジェクトの規模拡大に合わせて100ライセンスに増量
  • 委員会3人中、1人はGitHub専任に
  • 物理サーバー整備
 
採用プロジェクトを増やすよりも、同プロジェクトの人数が増える方が導入がスムーズ
プロジェクトメンバー同士で教えあってくれるので。
 
2016/10 正式な物理サーバーを導入
  • CPU 8コア
  • メモリ 128GB
  • ディスク 4TB SSD
  • トラブルなし
 

会社に対し正式導入を提案

2016/12 正式な導入へ向けて
  • もうすでにSVNへは後戻りできないプロジェクトができ始めている
  • 利用しているプロジェクトからのポジティブな意見
  • サポート人数も増やす必要がある
ネガティブ意見への対応
  • SVNではダメなのか
    • 検索キーワードのトレンドグラフでSVNGitHubの推移比較を見せた
    • すでに2013年にはGitHubの方が上回っている と説得した
  • レビューの価値がよくわからない
    • ゲームアプリのビルドは数時間かかるので、ビルド前にレビューすることによって手戻りの時間コストを減らせる と、具体的なコスト見積もり数字を出して説得した
  • 無料のGitHubクローンではだめなのか
    • デファクトスタンダードで一番情報が得られやすい
    • 他のツールと連携しやすい(BTS/CI)
    • 代理店からサポートを受けられる
    • 無料のクローンがいいのであれば、OpenOfficeを皆使っているはずだが、使ってないでしょ? と説得
説明の結果、本格導入決定となった
 

正式導入

2017/1 新規プロジェクトはすべてGitHub
  • 改めてサポートを強化した
    • 使い方ドキュメントとの拡充
    • 社内ハンズオンの実施
      • 新しく使い始める人全員に実施
      • 1時間程度
      • 概要、プルリク、ツールの使い方
      • 教わる人は理解しやすくなるし、サポート側はその後のサポートコストが減る
    • トラブル対応
      • Gitのトラブル
      • 巻き戻り、コミットできない、プルできない
      • 呼ばれたらすぐに飛んで行って解決
 

アンケートからの振り返りと対策

2018/1 アンケート実施
  • Gitの理解度 - ほぼ全員が普段の操作は支障なく行えるようになった
  • 作業フロー - プルリクを作成する人が全体の85%
  • まあまあ使えている
 
エンジニア以外のGitHub利用について
  • ゲーム開発ではすべてのファイル(ゲームパラメータの設定ファイル、画像ファイル、コード)がリポジトリに入っているので、プランナーやデザイナーもGitHubを利用せざるを得ない
 
アンケートではエンジニア以外のメンバーからはネガティブなコメントも
  • 概念が難しい
  • 操作が大変
  • 衝突時やマージ時の解決が大変
  • 良く巻き戻りが発生して大変
  • ローカルの変更ファイルでプルできない
  • SVNに戻してほしい
 
非エンジニア向けに独自のGitHubクライアント(Pengit)を作成して対応した
  • Gitの学習コストの大幅な削減
  • 行える操作をある程度絞って簡略化
  • プルリク発行までの簡潔な作業フロー
  • 分かりやすい競合解決
  • 親しみやすいエクスプローラー風画面
  • 日本語によるUIやエラーメッセージ
 

定着へ

2018/10 ひととおりGitHubが浸透した状況
  • 社内ハンズオン依頼が減少
  • エンジニア以外からのトラブル対応依頼も減少
  • 終了PJの振り返りで効果が認められ始める
 
CircleCI Enterpriseの導入
  • Enterprise版(社内サーバー)
  • ローカルのDockerレジストリ
  • ローカルでセキュアな環境
  • GHEとの最高の組み合わせ
 
GHEとPengitの持つデータの活用
  • 作業内容の可視化
    • プルリク数、Issue数、コメント数
  • プロジェクトごとの特性などを分析
    • うまく進んでいるPJとの比較など
  • データは蓄積しつつある状態
    • 何が改善につながるのか分析中
 

まとめ

  • 規模が拡大しそうな小さいPJへの導入がおすすめ
  • ネガティブ意見への丁寧な説明の準備
  • 利用し始める人へのハンズオンの実施
  • アンケート、振り返りの実施
  • (理解が深まらないなら)サポートツールで対応
  • CircleCIなど他のシステムとの連携
  • GHEの持つデータの活用
 

講演2

根本 竜也[マクニカネットワークス]
 
代理店の講演
内容は、ソフトウェアリリースプラットフォーム JFrog の宣伝
 
JFrogはソフトウェアリリースのための複数のツールの集合である
 

エンジニア人生と定年退職、人生100年時代のエンジニアの生き方

 

講演者

よしおかひろたか[東京大学大学院]
DEC, Oracleに勤務後、MiracleLinux創業メンバーとなる
未踏クリエータ
楽天 技術理事
60歳で定年退職後は大学院に入りひたすら論文を読み、問題を発見する訓練を続ける
 
散漫とした講演だったが、70’以降のコンピュータ歴史年表は感慨深いものがあったのでまとめておく
できごと
 
1971
マイクロプロセッサ Intel 4004
世界初の1チップマイクロプロセッサ
パーソナルコンピューター発展の基礎
1975
Microsoft BASIC
使いやすいインタプリタ言語
1977
初期のパーソナルコンピューター
1977
信用できないネットワーク上でもセキュアな通信ができるように
1980
LAN
1981
豊富なソフトウェアでエコシステムを形成、企業向けコンピューター製造販売最大手がPC市場に殴り込み
個人向けのグラフィカルなユーザーインターフェースのコンピュータ
1988
Unicode 提案
ソフトウェア国際化の嚆矢
1989
HTML, HTTP, UML 提案
Webの起源
1991
Web site が作られるように
 
1993
NCSA Mosaic
グラフィカルなブラウザ
1994
1995
 
1998
大事なソースコードOSSにしちゃってどうやって儲けるの?講演者は当時は理解できなかった
2000
ITバブル
 
2004
 
2007
講演者は出た当時、影響力を過小評価してしまった
2009
 
2012
深層学習
画像認識の分野で画期的な精度を実現したことで一気にブームに

DeNA TechCon 2019 にいってきた

 

TL;DR 

毎年開催されているDeNA単独の技術カンファレンス。今年は機械学習の応用とクラウド化とQAの話が多かった。
以下、各講演についてひとことコメント
 
車載カメラの画像を使用した3次元点群復元と物体認識技術における深層学習の活用
LIDAR等の高価な機器を使わず、車載カメラから撮った映像から3次元マップを作成する試み。SfMを用いると画像だけで3D構造を推定できるのが興味深かった。自分でもSfM試してみたいと思った。
キーワード SfM, Faster R-CNN, LaneNet
 
 『モビリティ・インテリジェンス』の社会実装〜タクシー運行最適化を実現する機械学習システム〜
タクシーの最適な流しルートをナビゲーションで指示するシステムを作る試み。タクシーを流すのは初心者と経験者で売り上げに2倍以上の差があるそうで、このナビに従うことで初心者でも平均的な売り上げをあげられる。モデルづくりの話とシステム構成(ほぼ全部GoogleCloud)の話の二本立て。個人的には フロントエンド~DWH~API までをすべてGoogleCloudで構成しているのが興味深かった。
キーワード マルコフ決定過程, DQN
 
DeNAの品質を支えるQAの取り組み 〜標準化から実践まで〜
満席のため諦めた。代わりに↓の講演を見た
 
運用中のゲームにAIを導入するには〜プロジェクト推進・ユースケース・運用〜
既存事業に対してAI施策をどう導入して回していくか、MLOps的な話だった。こういう話は少しずつ地道に進めるのが重要。
キーワード CloudMLEngine, Experiment as Code
 
パネルディスカッション:データサイエンスの競技者、Kagglerたちが活躍する職場とは
データサイエンティストが社内でどのように活躍しているかの話。日本に40人ほどいるKaggle Masterのうち10人がDeNAにいるそう。最近入社した人ばかり。これからもデータサイエンティストを積極採用していく意欲を感じた。事業付きエンジニアやデータエンジニアでは限界を感じていた問題も彼らデータサイエンティストが解決して行っている。餅は餅屋だと思った。
 
DeNAGoogle Cloud Platform
GoogleのカスタマーエンジニアとDeNAの開発責任者との対談。DeNAは未だに大規模なオンプレミス基盤を自前で運用していて、それを2020年までにすべてクラウド化する予定。システム運用者の観点からの話。クラウドを導入する際の説得方法、DockerとCloudFunctionの使い分けをどうするかなど。 StackDriver(ログ監視コンソール)が便利という話をしていた。機会があれば使ってみたい。
 
【対談:DeNAAWSクラウドジャーニーのこれまでとこれから
(前の講演と連続して)次はAmazon技術統括本部本部長とDeNAインフラ部門責任者の対談。GCPだけでなくAWSも大規模に使っていくらしい。お得意様のための特別なサービスの話が興味深かった。AWS本部長の押しが強い。声が大きくてうるさかった。
 
Lightning Talks (A-STAGE)
 
 

車載カメラの画像を使用した3次元点群復元と物体認識技術における深層学習の活用

 

講演者

    • Kosuke Kuzuoka
      • 元 建設 × IT Venture 勤務
      • 上記Ventureでは建設業界で使われる設計図をコンピュータビジョンで読み取る研究を行っていた

DeNAでの現在のミッション

    • 高精度地図を低コストで作成する
    • カメラ等の安いデバイスだけで作る Lidarとかは使わない

高精度地図とは?

    • ここでいう高精度地図とは車や機械のためのもの
    • 自動運転で自己位置推定によく使われる
    • 地図と現地がずれていると事故の元
    • 精度は数センチ〜数十センチが求められる
    • 経路探索にも用いられる
  • 今回使った重要技術
    • 深層学習とSfM(Structure from Motion)

深層学習

    • 深層学習についておさらい
      • 昔(1950年代)からある
      • 昔はパーセプトロンと呼ばれていた
      • 線形分離不可能な課題>層を深くすることで解決
    • 深層学習がなぜ今盛り上がっているのか
      • 膨大なデータセット(ImageNet)の蓄積
      • 高度な計算資源を得られるようになった

SfM (Structure from Motion)

    • 画像から3次元形状を復元する技術
    • Web上の画像(15万枚)だけでローマのコロッセオを3D再現する(21時間で)という有名な研究がある
    • どのように復元するのか?
      • 対象を様々なアングルから撮影した画像を用意
      • 特徴抽出
      • 特徴点を関連付け
      • さらに多数の点で関連付けすることで誤差を少なくする

SfMを使ってみなとみらいエリアの3次元点群を復元

    • 走行エリアの画像を収集
    • SfMで3D点を復元
    • 標識や車線レーン、レーンの矢印まで詳細まで復元できてる
    • カメラで見えない部分は復元できない
 

3次元点群から物体を認識する

    • 道路標識、レーン、路面標示 を認識したい

道路標識の検出

    • Faster R-CNN(2016) を使用
    • 畳み込みネットワーク
    • 精度は高いが実時間で使うには遅い→今回はリアルタイムで動作する必要はない
    • 検証の結果、ほとんどの標識、信号は検出できたが、見えにくいものは検出できないこともあった

レーンの検出

路面標示の認識

    • 路面標示とは、路面にペイントで描かれた矢印や停止線、横断歩道などのこと
    • なかなか研究がない分野
    • 下記のような新しいアルゴリズムを作成
      • 画像を上から見た画像に変換
      • 変換画像をFaster R-CNNを用いて検出
      • 検出結果を元の画像の座標に戻す
    • 実際の画像や動画に適用した結果
      • 路面標示(レーン矢印、停止線、横断歩道)が認識できている

これまでの情報を3次元情報にマッピングする

    • 特徴点=認識点 になっていないと 3Dにマッピングできない
    • 特徴点から認識できたところだけをフィルタする
    • みなとみらいの2交差点間でテスト
      • レーン、矢印、標識のみを抽出した高精度地図を作成できた

今回の技術を今後どのように応用するか

    • オートモーティブ事業向け高精度地図の自動作成
    • カーナビ情報、地図のアップデートの効率化
      • 地図データと最新情報との差分を自動的に生成するなど
 
 
 

『モビリティ・インテリジェンス』の社会実装〜タクシー運行最適化を実現する機械学習システム〜

 

DeNAのオートモーティブ事業がやっていること

 

今回の講演テーマ - タクシー交通システムの最適化

 

講演の前半:運行最適化アルゴリズムを作る

講演者:織田 拓磨
タクシー運行を最適化するとは?
    • 日本ではアプリ配車アプリの利用率が海外に比べて著しく低い
    • そのため最適化には配車アプリ以外の部分(つまり流しの部分)で工夫する必要がある
    • タクシーの流し(探客スキル)は乗務員に大きく依存する
      • 初心者と熟練者で2倍の成績差がある
    • タクシーが空車になったときに、現在位置を与えるとそこからの最適な探客経路を与えてくれるAPIがあればよい
探客経路APIをつくるには
    • ダイクストラ法では解けない
      • 目的地がない
      • コストを最小化するという問題で定義できない
APIを作る上で4つのチャレンジ
    • チャレンジ1:道路レベルの需要供給予測
    • チャレンジ2:リクエストに応じてすぐに経路を返すため 探索を効率化したい
    • チャレンジ3:複数の車両で利用した場合に全体最適になる
    • チャレンジ4:乗務員にとって走りやすい経路を提示する
 
チャレンジ1:道路レベルの需要供給予測 を行う
  • 待ち客の位置を直接観測することはできない→既存のデータから推測するしかない
  • 既存のタクシー乗降情報を利用する
  • 流し需要の分析
    • 乗降データの座標を道路に紐づけて分析
  • 道路、時間帯ごとの需要予測モデルを作成した
 
チャレンジ2:リクエストに応じてすぐに経路を返すため 探索を効率化したい
  • 最適な行動系列を探索する一般的な方法>木探索
  • MCTS(モンテカルロ木探索) 
    • 木探索をそのまま使ってオンデマンドで 適切なコストで 探索を行うのは難しい
  • アルファ碁などで使われた方策の概念を導入する
  • 方策 > MDP(マルコフ決定過程)でモデル化する
    • 環境(状態)の中でエージェント が利用可能な行動を取る
    • 環境はランダムに遷移して、エージェントは環境に応じた報酬を受け取る
    • MDPの問題設定:累計報酬を最大化する方策=行動選択の確率分布を 求めること
  • 探客問題をMDPでモデル化する
    • 状態:現在位置
    • 行動:移動方向
    • 報酬:売上
    • 方策=ある場所から報酬の確率分布を最大化する移動方向を算出する関数
  • MDPを解く
  • 実際のAPIでは方策を使って答えを返すので高速
 
チャレンジ3:複数の車両で利用した場合に全体最適になる
  • リアルタイムの需給予測結果を方策に反映している
    • 需要が高い場所でも、供給が多ければ他のタクシーはそちらには行かないようになる
 
チャレンジ4:乗務員にとって走りやすい経路を提示する
  • 最適な経路とは何か?
    • 頻繁に右左折しないなど、乗務員にとって走りやすい経路
    • 安全な経路であることも重要
  • MDPの報酬関数は自明ではない
    • 報酬が正しいか検証するのも難しい
  • 報酬関数をどのように定義したら良いのか? → データから推定する手法がある
    • IRL(逆強化学習)による報酬関数の推定を行う
    • エキスパートの軌跡(デモンストレーション)から報酬関数を推定する
    • つまり模範データから報酬関数を推定する
  • タクシーでは、売上の高い乗務員の軌跡をIRLに入力して報酬関数を推定する
 
実証実験の結果
  • 対象エリアの乗務員全体と同程度の成績
    • つまり、経験の浅い乗務員には有効
  • このアプリはプロダクト化に向けて実証実験中
 
 

講演の後半:タクシー配車サービス MOV の機械学習基盤

講演者:益子 遼介
    • 12年新卒 MLエンジニア
基盤の構成
    • サービスの基盤は GCP で作っている
    • Data Service, ML Service, API Service の3つのサービスで構成
データサービス
    • 車両から送信されてくるデータや各種APIログをPubSubに集約
    • Dataflow StreamingでPubSubから集約したデータをBigQueryにインサート
    • データ処理の一例
      • ノイズの多い生のGPSデータを地図上の道路にマッチ(補正)させる
DWHのはなし
    • BigQuery
    • 選定の基準
      • 列志向(分析向き)
      • 低コストのストレージ
      • 分散処理性能が高い
      • 運用レス
    • 普通の使い方とちょっと違う
      • リアルタイムのパイプラインに組み込む
    • BigQueryGIS(地理統計関数)
      • ある場所で起きたログを集約したりすることができる
    • パーティショニング
      • データが膨大すぎるので、予めパーティショニングしている
      • パーティション単位:時刻と地域で分割している
      • パーティション軸は重要なので、分析者とよく話し合うことが重要
    • セキュリティー
      • プロダクト側とは独立したGCPプロジェクトにしている
      • プロダクト側からは書き込みのみ許可
      • データを暗号化
      • etc
機械学習サービス
    • MLモデル開発フロー
      • データサイエンティストがJupyterNotebookが入ったDockerImage上で開発する
      • DockerImageにデータ処理が全部入っている
      • DockerImageを実際の推論パイプラインにデプロイすることでモデルを適用する
    • ML推論パイプライン
      • CloudComposer(Managed Airflow)を利用している
        • ジョブの成功・失敗が一目で分かる
        • ガントチャートを見てネックとなるタスクを見つけることができる
プロダクトの運用
    • ありがちなこと1
      • どうやってモデルを学習したのか当時の担当者しか知らない(再現性の喪失)
      • データサイエンティストから渡されたコードが実行できない(コミュニケーションギャップ)
    • 解決1
      • Dockerに処理を全部乗せてやり取りする
    • ありがちなこと2
      • モデル精度が経年劣化しているのに気づかない(モデルの経年劣化)
    • 解決2
      • モデル推論の精度を自動監視
    • MLの精度に依存しないサービス設計をするのも重要
      • 精度が悪い場合は自動でフォールバックするなど
 
 
 

運用中のゲームにAIを導入するには〜プロジェクト推進・ユースケース・運用〜

 
 

今回のテーマ

  • AIプロジェクトのライフサイクル
    • 前半の講演:機械学習の概念検証(Proof of Concept)
    • 後半の講演:本格的な仕様検討、実装、運用
    • 最後のまとめ:AI施策を運用に乗せるためのMLOps
 

前半の講演

  • 講演者:奥村 純
    • 理学博士(宇宙物理学)
    • データアナリスト
    • 強化学習チームリーダー
 

AI施策をどのように作ってきたか

課題の背景
    • 逆転オセロニア
      • 戦略対戦ゲーム
    • 解決したい課題
      • ネガティブ体験を無くしたい
      • 初心者がデッキ編成を覚えるのが大変
      • デッキの編成や戦い方の学習をサポートしてくれる機能がほしい
解決
    • デッキのおすすめ編成機能を作った
    • 大量のデッキ編成ログを使用して、キャラクター同士の関係性を評価する
      • 関係性評価のためにアソシエーション分析を行った
        • 支持度・信頼度・リフトの3つの指標
    • 初心者の勝率が上がった
    • 上級者は自分でデッキ編成した方が勝率が高い
戦略の学習をサポートする機能
    • 気軽に対戦の練習相手が欲しいというニーズに応える
    • 対戦相手AIを作った(未リリース)
    • 対戦AIの作り方
      • DNN(深層学習)を採用した
      • 盤面、手駒情報を数値化 5000程度の特徴量を使う
      • AIのモデルに入力して、どこに打つべきかを算出する
      • 上位プレーヤーの行動に一致するようににモデルを作っていった
 

後半の講演

AI施策を実現するための技術

  • 講演者:岡田 健
    • 理学修士(数論)
    • DeNAエンジニア
    • 逆転オセロニアでAI導入担当
 
 
機械学習のPoC(コンセプト検証)が終わると、サービスにどう組み込んでいくかのフェーズになる
  • ML Codeは機械学習を利用するシステム全体から見ると小さい
 
システム設計 - 企画をどうシステムに落とし込むか
    • オススメ編成
      • 学習サイド
        • BigQuery内のデッキ編成ログ → アソシエーション分析 → アソシエーションルール算出、GCSに保存
      • サービスサイド
        • ユーザーがレコメンドAPIを叩く → デッキ編成を返す
    • 対戦AI
      • 学習サイド
      • サービスサイド 
        • 打ち手の棋譜の特徴量抽出 → AIモデルによる推論
高付加に耐えられる仕組み - Cloud ML Engineをどう利用しているのか
    • スケーラビリティーについて
      • 社内に知見がなかったのでスケールアウトの検証をした
      • 負荷要件:サービスでイベントが開始された瞬間から10分間程度、高負荷が続く
      • 検証結果
        • スケールはすばやくしてくれる
        • レイテンシは3秒以下
        • ただし、一定割合でタイムアウトする(インスタンス数が増加するタイミングで起きる)
      • ここで、推論APIに求められる仕様を確認
        • 推論APIは10秒程度で帰ってこれば良い
        • →バックアップを用意し、5秒待って帰ってこなければバックアップサーバーが処理
      • バックアップを利用するとエラーはほぼなくなった
運用を楽にする仕組み - 特に、モデルや特徴量抽出器をどう管理しているのか
    • MLモデルの依存要素
      • 学習データ
      • 隠れ層のユニット数、活性化関数、学習率、バッチサイズ 等
      • 表現ベクトル
    • 以前は依存要素をエクセルで管理していた
      • 依存要素が一致していないと使えない → ごちゃごちゃになる
    • 解決策:Experiment as code を徹底
      • 依存要素を設定ファイル化した
      • 学習やデプロイの手順が明確になり、再実験・共有が容易に
 

まとめの講演

講演者:奥村 純
 
プロジェクトの振り返りと今後
以下の記事にもまとまってます。
スモールスタート
  • 課題は不確実性
  • 小さな検証を積み上げていく
期待値を合意
  • 不確実性があること(一喜一憂しない)、不確実性の度合い について認識形成する
  • 3つの見通しを用意する 最低ライン 現実ライン 理想ライン
    • 一番すり合わせが重要なのは最低ライン
役割を分散
全部できるスーパーマンはいない
想像以上にプロジェクトの生態系は複雑
大きく4つの役割
  • ケースの設計
  • データ設計・収集
  • モデル構築・評価
  • 実装・運用
目的を見失わない
  • AIのためのAI開発をしない
  • 目的はゲームを面白くすること。AIが黒子に徹するくらいがちょうどいい
 
最後に社外とのつながり
  • AIが複雑化して、単独の会社だけでは話が進まない
  • GameAIについて会社の垣根を超えたコミュニティ活動をすすめてゆきたい
 
 

パネルディスカッション:データサイエンスの競技者、Kagglerたちが活躍する職場とは

 

Kagglerについて

  • Kaggle : 機械学習モデルを構築するコンペティションのプラットフォーム
  • Kaggler : Kaggleコンペに精力的に取り組む人のこと
  • Kaggle Master : Kaggle のコンペで上位入賞実績がある人に与えられる称号
 

DeNAとKaggler

  • 日本に40人ほどいる Kaggle Master のうち、10名(アルバイト含む)が DeNA に在籍
  • 社内Kaggle制度がある
    • Kaggle上位者は入社してからも業務のN%をKaggleに当てて良い
    • Nの値はKaggleの実績に応じたクラス分けによって決まる
    • 最高ランクのSSだと、業務時間の100%をKaggleに使って良い
  • 先日Kaggleコンペで準優勝したチームにDeNAの2名が含まれている
    • 小野寺和樹
    • 加納龍一
  • Kagglerが関わった案件の例
  • Kagglerがいる場所
    • DeNAには全社横断のシステム本部があり、その中にAIシステム部がある
      • KagglerはデータサイエンティストとしてAIシステム部で働く
      • AIシステム部には他に、MLエンジニアやAI研究開発エンジニアも働いている
    • その他にも、事業部付きのデータサイエンティストもいる。
  • データサイエンティストに求められるスキルセット
 
 
 

パネリストについて

  • 原田慧
    • 司会
    • アナリスト
    • Kagglerのマネージャー的な人
  • 小野寺和樹
  • 加納龍一
    • データサイエンティスト
    • バリバリKaggler
  • 鈴木翔太
    • MLエンジニア
  • 山川要一
    • 事業部付きのデータサイエンティスト
    • Kaggler
 

グラフィックレコーディング

パネルディスカッションのステージ上では、わなみん氏によるディスカッション内容のリアルタイムでのグラフィックレコーティングが披露された
 

パネルディスカッション

  • 事業の中でどのように働いているか
    • 山川さん
      • データアナリスト的なことをしている
      • ビジネス課題をデータサイエンス モデル化する
      • きれいな課題ではない時にどうするか?
        • 主体性をもってみんなで問題設定 KPI目標設定がないと評価できない しっかりと打ち合わせする
    • 小野寺さん
      • Kaggleのほうが面白いw
    • (社内の課題は0.1%の改善を競っているKagglerにとってはあまり面白くないらしい)
    • (Kaggleの問題っぽく社内の課題を解ける社内基盤「DeNAggle」がある)
    • 鈴木さん
      • MLエンジニア
      • Automobile系のプロジェクトでKagglerと協業
      • モデルづくり以外の全部を行う
      • Kagglerはエンジニアではない
        • Kagglerはgitとか使えないので教えた
    • 加納さん
      • MLエンジニアと協業
      • エンジニアにプルリクとか教えてもらった
    • 小野寺さん
      • 一人で完結する仕事が多い
  • ここ1年くらいKagglerが来て会社がどう変わったか?
    • 山川さん
      • データはあるがどう活用すれば良いか分からなかった
      • いままでできなかったことができる
      • ユーザー残存率予測 これまでできなかったことができた
    • 鈴木さん
      • 実はDeNA出戻り
      • 昔はデータサイエンスできる人少なかったが今は変わった
      • 関西電力との協業 昔ならできるとは考えられなかった
    • 加納さん
      • バックグラウンドが違う色々な人が協業している
      • 色々な強みを吸収できる
    • (皆背景はバラバラだが、Kaggleが好きという軸があるので部署としてはぶれてない)
    • 小野寺さん
      • 勤務時間がゆるい。ヤフーにいたときは10時しゅっsy…(司会からストップがかかる)
      • DeNAは割と出社自由なのが良い 10時半がデフォ
    • 原田さん
      • 出勤時間は管理したくないので各自のプロ意識に任せている
      • DeNAがすでに持っている多様性が魅力
  • これから先どうなっていきたいか
    • 加納さん
      • Kaggleで実績を残し続ける
      • 社内で発生する様々な技術要求にフレキシブルに貢献する
    • 小野寺さん
      • コンペで優勝(世界大会に3度準優勝してるので)
    • 鈴木さん
      • Kagglerが社内でデータサイエンスについて啓発してほしい
      • Kagglerが活躍できるようMLOpsをしっかり整備していきたい
      • クラウド活用のレシピ(SageMakerとか)を提供できるようにしていきたい
    • 山川さん
      • 事業責任者とデータサイエンティストの間をつなぐことができるようになりたい
 
 
 

cncで製作した基板の作例

cncの記事へのアクセスが多いので、基板の作例をいくつかご紹介します。

 

13石 パワー・アンプ用基板

f:id:upsilon2:20161118012043j:plain

 

最小クリアランス0.5mmで設計、0.5mmのエンドミルで加工しました。

基板サイズは100mm x 70mm、部品穴の径は0.8mmです。

 

 

 

 

 定電圧定電流電源用基板

f:id:upsilon2:20161118012236j:plain

最小クリアランス0.25mmで設計、0.1mmのエンドミルで加工しました。

基板サイズは60mm x 40mm、部品穴の径は0.6mmです。

 

切削に使用しているエンドミル

f:id:upsilon2:20161118012528j:plain

左から1.0mm 0.5mm 0.1mm のエンドミルです。

 

 

 

電流帰還型パワー・アンプ

f:id:upsilon2:20161118011954j:plain

f:id:upsilon2:20161118011915j:plain

組み立て後の写真です。

基板サイズは100mm x 70mm です。

 

オーディオ用パワー・アンプの製作1

ふとしたきっかけで、半年くらい前から電子工作趣味を復活させています。アナログ回路の基本は増幅、ということでアンプの製作を思い立ちました。オペアンプはtransistor回路技術の結晶だと思ってます。トランジスタでまともなアンプを作ってみたいなーとは前から考えてました。この半年間で4種類ほどのアンプを作成したので、振り返ってみます。

 

オペアンプトランジスタバッファーを付けたアンプ

最初に制作したアンプです。オペアンプの後ろにトランジスタバッファーを付けた、よくあるやつです。万能基盤で作成しました。

f:id:upsilon2:20161104211438j:plain

 

セオリー通りに作ったのに音が歪む

このアンプは最初音がめちゃくちゃ歪みまくりました。

色々トランジスタが悪いのかとか思って色々試したのですが、結局オペアンプとして使っていたlm358のクロスオーバー歪が原因でした。オペアンプを4558に替えた所、歪まなくなりました。lm358はオーディオ用途には使えないと学習しました。

 

 

トラ技のヘッドフォンアンプ回路で作ったスピーカーアンプ

次に目をつけたのは、トラ技に掲載されていたフルディスクリート・ヘッドフォンアンプです。電池2本の正負電源で動作するものです。

続く

 

 

 

 

実験用電源の製作

最近よく電子工作をするので、手軽に持ち歩ける実験用電源を作りたくなりました。

作りたい電源の仕様は、出力電圧が0V~30V(できなければ0V~15V程度)、電流出力2A程度、定電流制御ができることです。

出力電圧が0Vからとなると、スイッチングレギュレータでは難しくてシリーズ電源ということになるのですが、トランスを使うと全体が大きく重くなるので、電力供給にスイッチングレギュレーターを使います。

ただし、一つスマートでない部分があります。出力電圧を下げたときに、シリーズに入れたトランジスタでかなりの電力が消費されてトランジスタがアツアツになってしまいます。

そこで考えました。出力電圧とスイッチングレギュレーターの出力電圧をトラッキングできないか?と。

普通にディスクリートで作ったシリーズ電源は、3V程度の電圧降下を必要とします。なので、スイッチングレギュレータの出力電圧が、シリーズレギュレータの出力電圧+4~5V程度になるように制御できれば、シリーズレギュレータの出力電圧を下げたときに極端にトランジスタが熱くなるのを避けられるはずです。

シリーズレギュレータの出力電圧と、ツェナーダイオードなどで降圧したスイッチングレギュレータの出力電圧をコンパレータで比較して、スイッチング出力の方が高ければスイッチングレギュレータにフィードバック信号を送ります。

 

定電圧定電流電源の回路は、

http://www.geocities.jp/mkttid/i_ctrlr/i_controller.html(リンク切れ)

を参考にしました。

スイッチングレギュレーター部分の回路は

トラ技2005年3月号と、TOP227Yのアプリケーションノートを参考にしました。

 

f:id:upsilon2:20161019173925p:plain

f:id:upsilon2:20161019173934p:plain

f:id:upsilon2:20161019173947p:plain

f:id:upsilon2:20161019174002p:plain

 

 

 

 

 

 

3Dプリンター 比較検討する際のポイントについて

 

形成・固化方式

光硬化方式

光を当てることで硬くなる樹脂にレーザーなどで固めたい所にだけ光を当てて固めます。中でもプロジェクタの技術を応用して断面を一気に生成するタイプは形成を高速に行うことができます。

FDM(熱積層方式)

溶かした樹脂をエクストルーダー(射出口)から吐き出して断面を形成、積み重ねて行きます。基本的にオーバーハングが苦手です。

 

以降は基本的にFDM型についての説明です。

軸方式

直交軸型

フライス盤のように直交するXYZ軸の動きで射出口の動き制御します。

デルタ型

垂直に立てた3本のレール上で台車を動かします。射出口はアームで各台車に連結されていて、3つの台車の動きで射出口の動きをコントロールします。

 

フィラメント

FDMでは、一定のペースで射出口に樹脂を供給するために、樹脂材料を細長い紐状に加工し、ドラムに巻きつけた物を使用します。これをフィラメントと呼んでいます。

樹脂素材

PLA

ポリ乳酸という樹脂です。3Dプリンターでは最も良く使われる樹脂です。摂氏200℃前後で融解する、熱による膨張/収縮が少ないなど、FDMに適した性質を持っています。一方でわずか摂氏60℃程度で軟化し始める、他の樹脂に比べて強度が弱いなどの欠点を持っています。

ABS

強度の強いプラスチックですが、熱変化による膨張/収縮の度合いが大きく、FDM型の3dプリンタでは印刷中に歪んだりステージから剥がれたりしやすく、印刷難易度の高い素材です。また、融解するときに有毒な気体を発生させるため、換気の必要があります。

TPU

熱可塑性ポリウレタン樹脂です。ゴムのような弾力性をもつ樹脂で一部のスマートフォンケースなどにも使用されています。

 

閉鎖式のFDM型プリンタ

温度による変形が大きいABSの形成では、プリンタ内部を外気から隔離することで形成物の精度を上げる事ができるので、一部のプリンタでは、プリンタ全面をパネルで仕切って、印刷中に外気が入ってこないようにしているものがあります。

 

フィラメントの直径

2.75mm(3mm) と 1.75mmがあります。最近は1.75mmがメジャーで、2.75mm(3mm)は入手性が悪くなってきているようです。これから3mmタイプのフィラメントを使用するプリンタの購入を検討する方は注意した方が良さそうです。

 

サポート

FDM方式のプリンターは基本的にオーバーハングがある立体物の印刷が苦手ですが、その対策として一部のプリンターでは、隙間部分にサポート材を充填するものがあります。サポート材は後から水や風圧などの方法で取り除きます。

 

 

中華CNC1610について 続き

前回基板が壊れてしまったcnc1610キットですが、実は組み立て中にどこか壊すんじゃないかと思ってもう1台注文してまして、それが届いたので基板だけ抜き出して交換しました。無事動作しました。ランダムに感想などを書いてみます。

何をしたら装置を意図通り動かせるのか分からない

キット付属のDVD-Rにgrbl-controllerが入っていたのでそれをそのまま動作させてみました。手動でXYZ軸を動かしたりスピンドルモーターを動かしたりできるのですが、それ以上何をすれば良いのか分かりません。

どうやら、このプログラムはncファイルというのを入力するようだと分かりました。web上で色々と検索すると、Machとcnc3040などを使う少し古い記事は見つかるのですがgrblの記事はなかなか無いので難儀しました。

少しずつ調べて分かってきたのが、ステージの動きを記述する命令がG-Codeだということです。例えば、ステージを座標(10mm, 0mm)に移動する、とか、スピンドルを(5mm)まで下ろすというような感じです。

Machの場合はMachがG-Codeをステッピングパルスに変換してパラレルポートに出力→パラレルポートに繋いだモータードライバがステッピングパルスでモーターをドライブするようだということです。

それに対して、grblの場合は、usb接続したarduinoの中にgrblプログラムが入っていて、そのプログラムがG-Codeを解釈してステッピングパルスに変換、arduinoから出力されたステッピングパルスがa4988等のマイクロステップドライバICに送られて、ドライバICがモーターをコントロールするということです。PCとarduinoの間は仮想シリアルポートで接続されていて、コンソールで対話的にgrblフォーマットの命令を送り込みます。

grblフォーマットの命令は、G-Codeをそのまま送るための命令と、grbl独自の制御を行うための命令で出来ています。grbl独自の命令とは、各XYZ軸の進行方向を逆にするとか、座標位置をリセットするとかそういう類の命令です。

で、G-Codeの送り方は分かったわけですが、今は基板の切削がしたいわけで、基板の設計データをいかにG-Codeに変換したら良いのか分かりません。で、またこちら

CNC - Linux工作室

に頼るわけですが、ここで紹介されているpyGerber2Gcodeを使うとガーバーデータをG-Codeにできるようだと、段々分かってきました。

pythonと依存ライブラリのインストールで若干つまづきましたが、pyGerber2Gcodeを動かせるようになり、普段使っているKiCadからガーバーデータを出力する方法も把握して、何とか切削に漕ぎつけました。

 

ステージが結構傾いてる

早速基板の切削をしてみたのですが、基板の端と端ではZ軸の高さが結構違っていて、基板の一部だけ溝が掘れませんでした。それでどうするのかというと、ステージの上に捨て板を貼って、エンドミルで一面同じ高さで削るわけです。そうすると、ドリルから見て、捨て板の高さが一定になります。この作業を機械加工では面出しと言うそうです。面出し用のgcodeを生成してくれるwebサイトがあって、ここ

tetterablog.hatenablog.com

のgcodeを使わせて頂きました。

基板切削用エンドミルは太すぎても細すぎてもダメ

太すぎるとランドまで削ってしまうので当然ダメなのですが、細すぎると、溝と溝の間に削り残しが発生します。