マウスのシステム構成の紹介

この記事は、「マイクロマウス Advent Calendar 2022 - Adventar」３日目の記事です。

---

こんにちは、なおフィスです。昨日は、ウメちゃんによる設計のノウハウ紹介でした。
タイヤに関し、運用含めノウハウが詰まった記事でしたね。単に、運動性能だけを語るのではなく、トレードオフを意識しつつ、運用も見据える。強者の目線ですね。

さて、今回は、昨年度から参戦をしているハーフサイズ競技における、システム構成について、大雑把ですが、語りたいと思います。

導入：利用しているマイコンの紹介

ESP32-S3という7x7mmサイズに、2コアが載ったマイコンを採用しています。 同シリーズを利用している人は非常に少ないですが、以下の魅力的な特徴があります。

• 開発環境の依存性が少ない。公式の開発環境ESP-IDFが提供されている。
• チップの単価が安い（300~400円程度）。昨年度の半導体不足の環境下で新作を量産。
• A/D変換を除くと、SPIなどの専用ポートなどの制約がないため、ピンアサインは対応するIC・部品に一番近いところを選べばよい。
• フラッシュ領域（最大8MB程度）はファイルシステムとして利用可能（ファイルの読み書きができ、迷路やパラメータを保存可能）
• メモリマネージャが利用可能（簡単に言うとヒープ領域に対し、動的なメモリ確保を「何度も」できる。STLのコンテナ（vectorなど）も使える）
• FeeRTOS対応

このように、様々な特徴を備えていますが、それを使いこなすには、良いソフトウェアシステムであることが求められると考えています。
それは「各機能の役割が明確」であり、「機能進化のための拡張性や互換性が保てる」ものであり、かつ、「実装しやすい」ものが理想と考えます。

今回、私が考案したシステム構成を紹介します。

システム紹介

以下、システム概要図

図は、Core0とCore1にタスクの配備状況、各タスクが担う役割と、データの流れの簡易的に表したものです。

以下、各タスクが有する機能の紹介です。

main_task

マウスの基本機能を実行するメインルーチンともいえるタスクです。
主には、足立法の実行や、必要なモーションを決め、動作が終わるまで待つといった、意思決定と要求を順序に沿って行います。

また、「調整値読込」では前述のファイルシステムの機能を用い、シリアル通信で送り付け保存したテキストファイル（jsonテキスト）を読むことで、タイヤ径などの値をソースコードではなく、フラッシュ内のファイル上の値を用いるようにしています。 これにより「再ビルドすることなく」調整したい値を反映・確認を可能にしており、調整作業の時短に繋げています。

読み込むパラメータはPIDのゲインなど様々な値があり、起動時に他のタスクが使うパラメータを更新するようにしているため、大会会場では原則再ビルドの必要はありません。

sensing_task

各センサーから値を取得します。このタスクはマウスがおかれている状況は把握してないため、扱うデータは基本生値（A/D変換の結果そのまま）としています。

• 壁センサー（IR_LED + IRセンサー）の値をA/D変換で取得。
• ジャイロセンサーの値をSPIで取得。
• バッテリー電圧をA/D変換で取得。

planning_task

main_taskからの動作要求に対し、置かれている状況を踏まえ、sensing_taskの結果を物理量に置き換えた値から、目標の状態を算出。 目標値偏差からFB制御（PID）や、FF制御（内部モデル制御（Internal Model Control））による制御量を算出し、モータに与える出力（Duty）として反映します。

logging_task

認識結果や制御、システムの状態をメモリに貯めこむタスクです。 走りながらファイルシステムにデータを保存することは性能上できませんが、300kByte超のRAMとSTLのコンテナによるお手軽な動的データ確保機能を活かし、複数のデータを記憶、csv形式で出力することで可視化ツールと連携し解析作業をしやすくしています。

まとめ

簡単ではありますが、システムの構成を紹介しました。 役割が不明確で、複雑でスパゲッティなシステムを作ると、何年もわたって進化させることが難しくなってしまうため、これから作る人・作り直したい人には是非、以下の観点を意識してみてください。

• タスクレベルで役割が明確であるか
  • 図より相互関係は明確といえる
• 拡張性・互換性があるか
  • タスク間を行き来するI/F(構造体)を拡張することで、容易に可能。
• 実装が容易であるか
  • main_taskではSTLのコンテナ(vector)などを活用。実装コストを下げることに成功

最後に

明日は後輩の半田ディザスターの人こと、しろめ君です。
10月に、個人的に学生大会を見据えた講習をしたのですが、無事優勝を勝ち取ってくれたので、やった甲斐があったかなと勝手に満足していますｗ
そんな彼が、直前に何をしていたのでしょうか（焦るようなツイートをしていた記憶がある）

2021年度マウス活動振り返り

はじめに

IREXでの全日本大会お疲れ様でした。 試走会からの参加はできず、IREXの展示もある程度絞りながらではありましたが、普段とは違う大会を味わえたなと思います。 難しい情勢のなか、運営、関係者各位本当にありがとうございました。

大会結果

セミファイナル３位

過去の大会の実績から、セミファイナル不適切との判断。受賞なし。

実質、セミファイナル出禁と受け取りましたｗ

感想

斜めなし、壁切れなし、ターンのパラメータはシミュレーター通りでオフセット距離の調整は一切しないという個人ルールで走り切れました。 色々不安定なところが有りますが、環境や言語などこれまでのソフトの資産が一切使えなかったので、今後時間を書けて育てていきたいところです。

１１月にハード設計初めて１２月中旬ぐらいに完成してからの最短まで感想なので、まぁ良いでしょう。

次年度について

新しいマシーンの設計、発注が完了しており、既に一部部品を組み立ててます。 マイナーチェンジ機なので大きな変更はありませんが、シーズンを通じて少しずつ改良する感じにしていこうと思ってます。

32×32対応も既に終わってまして、解を出すロジック面は何もせず、計算コスト面で工夫をしただけですが、来シーズンはコレで挑めるかなと。

いずれはプロファイルの修正だけで、クラシック・ハーフの両方を同じソフトで挑みたいですね。

1ヶ月でマウスを作ってみた

この記事はマイクロマウス Advent Calendar 2021 - Adventar11日目の記事です。

昨日は入院をしていたアライさんどうぞご自愛ください。
最近マウサー界隈、体調崩す方が多いので、自分も体調を気をつけたい。（といいつつ、無頓着なんだよなー）

---

さて、今回は、新作を１ヶ月で作成したので、その話をします。

きっかけは、この告知。

ビックサイト開催を知ったのは、11/6のことである。

さて、ここ１年の自分の行動を確認しよう。

• 昨年はBustersする相手がいないため、Bustersを休業。
• 今年も秋まで具合から、オンラインだろうと判断。
• 使ってみたい、ICの発売遅延と知り更にだらける。（watchだけはしてた）

このモラトリアムからの急転換であった。

国際ロボット展なので、何であれ、行くのは決定事項。行ったら捕まるので、自分から出向くしかないなと判断。 走らせるものがないと話にならないので、ハードウェアから用意を開始。マイクロマウスづくりRTAを実施。 今回はハーフサイズ。
ハーフに致命的な設計ミスがあったら、クラシックでExiaAlter出します。

スケジュール確認

２月に調整に集中したい。となると、１月末までに基本システムの構築、１２月中にはハードウェアをFIXさせなくてはならない。
ということは、11月から年末までの１ヶ月〜２ヶ月でハードウェア周りFIXさせなくてはならない。
（最近、仕事でもプライベートでもスケジュールに追わてる！）

コンセプト

とは言え、コンセプトを決めなくては形も定まらない。以下のように（後付）設定した。

1. 脱Renesas
2. C++を使う
3. ESP32-S3を使う
4. K峰さん撃墜を目指して基礎を固める。

1については、RX71Mや72Nの在庫があるが、RXシリーズやる気なさそうだし、開発環境もやる気なさそうだし、見限りました。
2については、ここ数年rosで戯れていたということも有り、夏休みにシミュレータを再構築した。
3については、ピンアサインの制約が小さく、十分なRAM、処理速度、そして開発環境はOS縛りからの脱却。
4については、クラシックでは宇宙人枠でカウントされてますが、ハーフは試作機止まりなので、地球人からやり直し。K峰さんの機体の重さなどを参考に目標値を設定。

設計

CPU

ESP32-S3は2021年12月時点でサンプル品がdigikeyにて手が入る、という流通レベル。チップ単体での販売は現時点では行われてないため、WROOMボードからヒートガンをつかって剥がすことにした。

ESP32-S3は内蔵フラッシュがあるタイプと、ないタイプがあり、WROOMボードは内蔵フラッシュなしだったため、仕方なく外付けフラッシュを搭載して設計。 MINIボードの方は8MBのフラッシュがある模様。

ピンアサイン

ESP32はADCのピン以外は特に機能の制約がないため、spreadsheetである程度雑にアサイン。

ICはdigikeyと手持ちの在庫を見ながら調整。

一気に仕上げた（この画像では外付けフラッシュなし版）

足回りの設計

磁気式エンコーダは手持ちのAS5147Pを選択。旧作マウスの足回りからESP32のパルスカウンタで値が取得できるかを確認。 ピニオンギアは2017年ごろに買った在庫に合わせて設計。(kkpmoで発注したが３週間経過したが発送されない。)

開発環境の確認

ESP32-S3とS2はピンコンパチではないがWROOMボードならコンパチなので、 届いたWROOMをESP32-s2-devkitcボードに無理やり移植し火入れ。一発成功しuartでデフォルトで設定されているアプリが吐き出す文字列を確認。

そして、ESP-IDFを使い開発環境を構築を実施。 ESP32の開発の場合、通常platformioを使い、GUIサポートなどを受けながらが楽なのだが、S3は最新のためplatformioが最新のESP-IDFに対応していない。 そのため、ESP-IDFを単独利用を敢行。複数のバージョンを試したが、v5-devに落ち着いた。

発注＆組み立て

足回り

DIDEL mk-06-4.5で仮組み。 実はタイヤをつけるとシャフトとタイヤが干渉。千石で売っているアルミプチカッターにて切断。

この時アルミプチカッターで切断後の表面処理用にリューターを購入。

mk-06を使うのでは、目標としているK峰さんマシーンに回転数では同等となる。更にスペックを狙う場合、より回転数が出せるモーターを選ぶことになるが、その場合、モーターの全長が長いものしか無く、収まりきらないという問題が生じる。

「収まらないなら削ればいいじゃないか。」 ということで、リューターで器用に後の金属部スレスレまでプラスチック部を削り落とした。だが、まだ足りない。 ダイヤモンドカッターを使って金属部をどれだけ削って良いのか限界を確認。 意外と行けるが、全体を削ると当然プラスチック部が落ちる。（性能は落ちている可能性はある）

最後に互い違いになるようにして、配置することでモーターは完成。 （まさかモーターのシャフト以外を加工するとは・・・）

はんだ付け

ステンシルとヒートガンを使ってLGAパッケージたちをはんだ付け、無事１度もショートすること無く完成。

完成

ExiaAlterから継承したセンサー５つ構成

重さはというと、 仮のバッテリーを使って17.1gなので、実際はもう少し軽くなると思いますが、少し改善できそう。 当初目標にしていたK峰さんのロング１９号機はセンサー４つで１６ｇなのでいい勝負なのでは無いだろうか。

作り終わって

短期決戦ということも有り、在庫を駆使しつつ、楽をしながら、作ってみました。 各方面に怒られそうなことをやってますが、自己責任です。 参考にするかは今年の大会結果が出てから判断してください。（12/7時点でここまでに執筆）

2021.12.10時点 での話

既にESP32S3の使用なのか、起動時や書き込み時にHighになるピンが複数存在し、 モーターが全力で回転するという嫌な事象に遭遇しています。ESP32の一部のモデルには起動時の値がHighになるという言及が有りますが、S3にはないので困ってます。場合によっては回避した基板を作成してしまおうか検討中。（ちゃんと調べて直す時間よりも、さっさと回避した基板を発注したほうが安上がり？）
工場出荷直後の状態でテスターを当ててもHighだったので、チップ側が原因（仕様）っぽいですね。

つまり・・・・

１ヶ月でマウス完成しませんでした！！！！（2021.12.10 23:45に確定）

モーターが分回るのが嫌なら、初期状態の状態リストを作って、影響が出るモーターやブザーを避けて再度基板作しかないですね

---

オチがついたところで、明日の担当はkerikun11です。/dev/nullとのことで、ログも何もかも握りつぶされるので、何が来るかわからないですね。

追記

某５年制大学の圧政によって、Miceが息していないため、MiceBustersは名乗る意味は少ない。
どうしようか？と考えているのですが、最近、ふと思うのです、毎年表彰台を荒らす某組織Dに対抗する組織が必要なのではないかと。
考えた組織名は、
対D抵抗組織「D_structions」(ディーストラクションズ)

１強は流石につまらない。抗いたいという人たち、とりあえず、名乗りませんか？ 構成員募集中！ご賛同いただける方、サブ組織でも良いので、是非、名乗っていただきたいです。

正式名称はD_structionsです。

○nikiBustersにしなかっただけ自重したとご理解ください

AtCorderに挑んでみた

この記事は書きかけの記事です。一通り終えたら、清書し直す予定です。

プロコンをやってみたきっかけ

• 特に無い。
• 思いつき。
• 自分がどれだけ書けるのは興味がある。

目的

やってみた後に考えてみた。

• C++にもっと慣れたい。（プログラマー歴に対し、C++歴がとても浅い）
• 数をこなしたい。

目標

• 水色（上位１０％）！

現状の実力（主観）

• プログラミング歴：９年（大学１年から）
• 言語
  • Java・・・３年：品質を意識して商用レベルが書ける
  • JavaScript・・・３年：品質を意識して商用レベルが書ける
  • Matlab・・・　２年：書けはするが、あまり好きじゃない。
  • C++・・・１年半：最初はCの延長で適当に書いてたため適当。
  • C・・・９年：ロボコン用の汚いコードを量産。（コンパイラの成約でC99止まり）

元Web屋さんという背景から、ミドルウェアやAPI、OSSなどを扱う機会が多く、実は、各言語に向き合ってちゃんと勉強したことは少ない。製品化する過程でコーディングもするし、品質も意識したり、周りの人のコードのレビューも行っていたことから、コーディング自体に不安はあまり無い。

自分にとってプロコンの意味あるのか？

仕事でやるようなWebや組み込みシステムを作りコード（品質を考えたコード）とプロコンのコードは異なることは理解している。「プロコンが強い人材≠仕事で書くソフトの品質も高い人材」も理解している。（相関はあるとは思う）

広義のソフトウェアエンジニアとしての力量はコーディング能力だけでは測れない。アーキテクチャやデザインパターン、運用など、ソフトウェアにおけるサプライチェーンまで含むすべてが対象になると考えている。

ただ、仕事で書くコードに「工夫の幅」を広げるために、プロコンで使われるようなスキルが役に立つのでは？という期待はある。

（初期戦略）進め方

AtCoder（主にAtCoder Beginner Contest（以降：ABC））の問題はA~Fまであり、後半になるにつれ難易度が上がる。初レート戦に挑む前に、試しに５回分ほど過去問を解き、以下に分類。

(1) 解ける（毎回安定する）
(2) 解ける（たまにミスる）
(3) 解けない（回答を見たら理解できる）
(4) 解けない（問題文が理解できない。回答を見ても理解できない）

当初。Aはほぼ安定（１）。Bはたまにミスる（２）。Cは回答できることもあるがほぼ（３）。D以降は解けない（４）という状況でした。

当面の進め方は、「過去問を解き(2)(3)の正答率を上げつつ、(4)については徐々(3)に近づけるよう勉強する。」とした。

(4)に該当しているのは、そもそもの手法を知らない、考え方がわからないため、手を付けられないものである。 これはレート戦でも最初は相手にせず、QIitaの解説記事を見ながら徐々に学習していくことを優先した。

環境準備

過去問を１，２回やる中で、競技プログラミングはタイムアタックの性質上、ローカルの実行環境を整える必要性があると判断。普段遣いのPC（Ubuntu 20.04）で作業しやすいようにワークスペースを作成。以下のコマンドなどを用意。

• テンプレートからcppファイルを出題数分（６個）生成するコマンド
• ビルドコマンドの省略化するためのコマンド
• IDE（clion）でビルドするために、CMakeLists.txtを整備
• 解いたコードを退避し保管するコマンド

特にワークスペース作成コマンドは問題に取り掛かる初動がとても早くなったことから有用である。（たぶん、誰でもやってることなのかな？）
ワークスペースはgithubで公開済み。
github.com

仕事でもココらへんは自主的にやってる（好きでやってる）

---

To Be Written....

Matlab/Simulinkでシミュレータ環境を作るコツ

はじめに

この記事はMicro Mouse Advent Calendar 2020の1日目の記事になります。

このAdventCalendar(ADC)について

今年はCovid-19により、例年ですと、ちょうど全日本が実施される頃合いですが、今年は特別対応、オンラインでの開催になりました。

12/4に公式ＨＰより「詳細告知・課題公開」の予定です。マイクロマウス2020 – All Japan Micromouse Contest 2020

さて、学生団体のように活動が規制されていない社会人たちはきっと、進化を続けていることでしょう！！！ということで、例年に漏れず、このＡＤＣを作りました。

というのは建前で、だいたいこれが理由です。

今年のadvent calendar
誰か作って誰か書いて
僕読みたいから

— らっち (@hiiragium1) 2020年11月28日

らっちくん。枠なら余裕があるよ。

本題

マイクロマウス大会のスポンサー「mathworks社」が大会出場者向けに無償提供しているソフトウェア「Matlab/Simulink」でシミュレーションを作る際のコツや使える関数などを紹介します。

Ｃのヘッダファイルからバスに読み込む(Simulink.importExternalCTypes)

Simulinkでバス（構造体のようなもの）を使用する際、自作バスを定義するのが面倒です。
そこで紹介するが、Simulink.importExternalCTypesです。この関数はC/C++のヘッダファイルに記載した構造体をバスとして読み込み、Simulinkで使用することができます。

以下のコードをシミュレーション前にinitファイルとして1度実行し、バス構成をワークスペースに登録しておきます。

Simulink.importExternalCTypes('../include/bus.h'); 

コード生成後は生成されたファイルと、上記のbus.hをC/C++のワークスペースにコピーしてビルドすればＯＫです。（インターフェースに構造体を使用したい場合など、この方法が個人的ベストプラクティスです）

enumを読み込むと、~~.mというファイルが自動生成されますが、enumの中身を変更した際は一度mファイル側を削除しないと、エラーが出たりしますが、overwriteのオプションを使用すればエラーを無視し、上書きします。

mファイルのパス情報を取得（mfilename、fileparts）

simulinkでビルドした際や、コード生成をした際は、matlabの現在のディレクトリに対し、ファイルを生成する仕様があります。（これどうにかしてほしい）

自動ビルドなどを行う際、ｍファイルなどに記載したコードを実行しようにも、mファイルの配置先からみた相対ファイル情報を得た方が、git管理をするときなど便利です。

mfilenameでは現在実行中のmファイルのパスを、以下のように、引数に'fullpath'と入れることで、取得できます。

script_file_full_path = mfilename('fullpath')

これだと、ファイル名まで取得できてしまうので、filepartsを使用します。 filepartsでは、引数に指定したファイルのパス、名前、拡張子を取得できます。

[filepath, name, ext] = fileparts(script_file_full_path );

コード生成コマンド（slbuild）

slbuildは引数に指定したSimulinkファイルをコンフィギュレーションファイルに沿ってビルド（コード生成）します。
ただし、先述のように、現在のディレクトリに対して、ファイルを生成します。（gitユーザには至極迷惑）
そのため、先に紹介したmfilenameやfilepartsを使用し、テンポラリーで作成したbuildフォルダに移動してから実行しましょう。.gitignoreでbuild/を追記しておけば、ビルドファイルによるgitのワークスペースの汚染は防げます。

初期値とunit_delayしたデータを切り替える

1ステップ目の初期状態と、シミュレーション結果を切り替えたい。そんな場合に、clockブロックを使用しています。
clock>0ならシミュレーション結果の座標を使用しています。

csv読み込み

私のマウスでは走行ログをCSV形式でprintfしてダンプしてます。
以前まではexcelでグラフを描画していましたが、simulinkのFrom Spradsheetを使用すると便利です。
1列目にtime_indexとして時系列情報を書き込む(行番号でＯＫ)必要があるのですが、それ以外は特に制約なく利用できます。

「適用」を推すとブロックから各出力が表示されますので、あとはscopeなどで描画して確認します。

まとめ

「Matlab/SimulinkでMBDをやるんだ！」といっても、それ以前にソフト作りのしやすくするために、スクリプトを整えなくては宝の持ち腐れです。（そういう系の共有がMatlab/Simulinkは商用ユーザばかりでなさすぎる気がする）

やってることが、shell芸につながるアレコレだったり、自動化系じゃないかって？（本職でjenkinsおじさんしているので仕方ない）

おわりに

明日の担当は「ジャッジー君」です。（あ。twitterフォローしてない。これではトスができない。）

STM32+Clionで開発（在宅勤務の話も）

在宅引きこもりでマウスの意欲をロストして、３ヶ月間一切何もしなかった。 ここまで何もしない期間ができたのは、マウスを初めて以来初である。

今日は久々にモチベがあったので、ブログまで書ききった

技術的なネタの前に、在宅７ヶ月目が終わりに近づいて、在宅勤務も感想をちょっとだけ。

• 通勤は害悪。1日2h近く移動に使っても、１円も認められないのは損でしかない。２時間睡眠を増やせばパフォーマンスは上がる。（平均５ｈ未満が８ｈになることのバフ効果はヤバイ）
• 在宅でコミュニケーションの問題が起きているのは言い訳。直接会えてても問題があったか、欠如していたかのどちらか。（私見）
• 通勤定期バグ（在宅で電車乗ってないのに、定期代が支払われるバグ）の修正が遅い。
• 仕事中の何気ない雑談は少なくなったが、ネット会議の枠を使ってやれば十分足りる。
• 場所に縛られない働き方によって、オフィスの価値が変わり、住む場所の選び方も変わった。仕事の選び方も変わるのだろうか？

---

さて、本題だ。 naophis.hatenablog.com

この記事の続きのつもり。

構成

• Ubuntu 20.03
• clion 2020.2
• stm32h743(nucleo743zi)　
• openocd(自力ビルド!!!!)

CubeMXの設定

Project Manager

• Project・・・toolchainでSTM32CubeIDEを選択
• Code Generator・・・Generate peripheral initialization as a pair of '.c/.h' files per peripheralにチェックを入れることを推奨。

HAL or LL?

LLを選択。HALは遅い。
HALを使うと格闘ゲームプレイヤーなら違和感が出るレベルで遅い。
ただし、基本動作の確認にHALを使うことは、ネットにサンプルコードがたくさんあることから推奨。テストコードはOK、本番コードはNGな印象。

printf

main.cに以下の関数を挿入しておく。

// LLでUSART3を使用。
void USART_TransmitByte(uint8_t ch){
    LL_USART_TransmitData8(USART3,ch);
    while(LL_USART_IsActiveFlag_TXE(USART3)==0);
}
void __io_putchar(uint8_t ch){
    USART_TransmitByte(ch);
}

OpenOCD

sudo apt install openocdで入るopenocdではnucleo-h7系がない。
githubの最新のcfgファイルを抜き出して入れても、参照先の解決ができない。

面倒くさいから自力でビルドする！！

以下を参考に前提になるパッケージを入れて、ビルドするだけ！！（他力本願）
hackaday.io

Clionで使えるようにする

clionの設定でOpenOCD SupportでOpenOCD Homeにインストール先（openocdコマンドがあるディレクトリ）を選択する。

Clionのデバッグ構成

board/st_nucleo_h743zi.cfgを指定。後は▶で書き込むだけ。

やり残したこと

C++でやりたい。自動生成されるmain.cをmain.cppに変更するだけでGPIOやTIMは動きはするが、printfが動かない。（LL_USART_TransmitData8を使って１文字ずつの送信はできるのに。printfはできない。タスケテ）

eagleでRS-274X形式のガーバーデータを出す方法

基板発注する際、毎回忘れてしまうため備忘録として残す。

使用するもの

• Eagle(バージョンは何度もよい）
• CAMプロセッサー(P板の2層用CAMプロセッサーを利用)
  • リンク
• eagle標準で入ってるexcellon.cam

発注先と出力形式

• JETPCB・・・ここ数年、基板はここに発注してる。残念な思いをしたことがない。
• RS-274X形式・・・eagleで出力したものをzip化し、発注画面でアップロードすればよい。

出力方法

1. eagleのトップメニューから、使用するCAMプロセッサーをダブルクリック
   • P板のCAMプロセッサーを使う場合は、gerb274x[2L].camを指定。
2. File>Open>Boardから出力したい基板の.brdファイルを選択。
3. Process Jobを実行

   このままだとドリルファイルがないため、以下を続けて実行。

4. eagleのトップメニューから、excellon.cam
5. File>Open>Boardから出力したい基板の.brdファイルを選択。
6. Process Jobを実行

以下の拡張子が付いたファイルが生成されればOK。

*.cmp
*.drd
*.dri
*.gpi
*.out
*.plc
*.sol
*.stc
*.sts

念のため、ガーバービューワーなどで、意図した出力がされているか確認しましょう。

CAMプロセッサーをカスタムして長穴を作りたい

悪い人は思うのです。余計なことをしたい（少し弄りたい）と。
今回、メッキ付きの長孔を作成したかったため、46. Millingを使い、長穴を作成。参考

ガーバデータに、46. Millingを出力に含めるため、CAMプロセッサーを改造。

gerb274[2L].camのOutlineにて、すでにある20. Dimensionに加え、46. Millingを追加してからProcess Jobを実行する。

これで行けるはず。（まだ物が届かない）