マイクロマウスのテストモードの紹介

この記事は「マイクロマウスアドベントカレンダー2023」 1日目の記事です。


はじめに

こんにちは、なおフィスです。

2020年度ぶりにマイクロマウスアドベントカレンダーの旗振りをさせていただきました。 今年はなんと開催前に全枠埋まるという好スタートです。この勢いで、Miceアドベントカレンダーの復活も期待しています。

昨年度、私はESP32-S3の機能を活かした、マイクロマウスのシステム構成について紹介をしていましたが、今回は中級者向けに、マイクロマウスにおけるテストについて紹介して行こうと思います。

導入:テストの重要性

ちょっと堅い話ですが、まず、ソフトウェアの開発プロセス、各開発工程について話をします。

開発プロセスには 「ウォーターフォール型」、「アジャイル型」、「プロトタイプ型」などありますが、いずれの手法においても、以下の作業工程が必要になります。

  1. 要件定義: ユーザの要求から、求められる条件・要件を明らかにする。
  2. 設計:要求を満たす手段を構想し、具体的な機能に分解する。
  3. 開発:機能を実装する。
  4. 機能テスト:作成した機能が設計通りか確認する。
  5. 統合・統合テスト:個別の機能を1つのシステムに結合し、全体として要求された条件を満たすか確認する。
  6. 品質確認:最終的なシステムがすべての要求を満たすことを、総合的に確認する。

特徴として、

  • 1の成果物の正しさを6で確認
  • 2の成果物の妥当性を5で確認
  • 3の成果物の動作を4で確認

という成果物の確認構造になります(V字フローで画像検索すると、差異はあれどイメージが付きやすいと思います)

ソフトウェア開発において、4~6は品質を確認・改める機会を得るための重要な工程であり、企業活動においては、この品質担保の仕方が製品の良し悪しに響くと言っても過言ではありません。

このことは、ソフトウェアのウェイトが高いロボットであるマイクロマウスにおいても言えることです。 そして、「性能をちゃんと引き出せる」というのは、中級者以上には必須とも言えますが、本番でそれを再現するには、テストモードを作成し確認・調整していくことも重要です。

テストモードの紹介

この記事では、私のマイクロマウスでのテストモードについて紹介していきます。
私の場合、以下の画像のように、競技モードとテストモードで大別し、テストモードを計11個を作ってあります。

ソフト開発経験者からすると、単体テストをすっ飛ばして、いきなり複合機能で確認しているじゃないか!!というツッコミはあるかもですが、ROS 2による迷路シミュレータ、MATLAB/Simulinkを使ったPlannerなど個別にテスト、確認する環境があります。

内訳について

駆動系とその他で分けて紹介します。

駆動系

制御に関わる大半を6種で確認しています。使用頻度も高く、順次動作を確認しながらオフセット量などを確認していきます。

調整する順序も重要ですが、できる限り単体の機能を確認してから、複合する機能を確認しています。 判断には、迷路に補助線を引くことで視覚的に判断していますが、大会会場では補助線がないため、定規を使って最後の微調整をしています。

以下、それぞれのモードに対し、モーションの補足です。

  • 最短時ターン:(「」はモーションパターン)
    • 「直進→壁切れ→ターン→直進→停止」:最短走行時のターン時の1モーションの流れを再現し確認
      • (派生)「直進→壁切れ→ターン(斜め45/135)→直進(斜めの制御)→停止」:斜め走行時の壁制御を確認
    • 「直進→壁切れ→ターン(斜めに)→壁切れ(斜め)→ターン→停止」:斜め走行状態からのモーションの確認
  • 直進:
    • 「その環境での最長距離を低速で直進」: タイヤ系の調整
    • 「その環境での最長距離を最高速で直進」: 速度の追従具合から各FF項、FB項を調整し、遅れなく追従できるように確認。(限界性能を確認)
  • 超信地:
    • 180度確認(左右): FF/FB項の確認
    • 360 x 10確認(左右): FF/FB項の確認、ジャイロのゲイン確認 
    • 360 x 10回確認(左右): (あまり使わないのでパス)
  • 壁切れ:
    • 「直進→壁切れ→直進→停止」: 壁切れの閾値をログから、壁切れ後のオフセット量を目で見て調整
  • 前壁補正:
    • 「停止→前壁制御(壁を手で動かして追従を確認)」: 壁との向き、距離を調整
  • 探索時ターン:
    • 「直進→ターン(横壁あり)→直進→停止」: (前提)スラロームの際、センサーで見た横壁との距離からスラローム直後の直進の距離を調整しています。(基準となる理想のセンサー値を方を調整してます)
    • 「直進→ターン(前壁あり)→直進→停止」: (前提)スラロームの際、センサーで見た前壁との距離からスラローム直前の直進の距離を調整しています。(基準となる理想のセンサー値を方を調整してます)

いずれも、探索、最短時に使う関数・パラメータをそのまま利用するように作っています(重要)

その他

こちらの5種は主に、機体完成後やメンテ後に使用します。

  • 吸引: 秤を使って何g吸えるかを確認。吸引力の調整は電源装置を使うことで、使用する電流量も確認しています。
  • その場停止: (「宴会芸」とも言われる、目標速度0、距離0、目標角速度0、角度0に追従する制御)
    • 並進方向のみFB制御: 機体を前後方向に移動させ、初期位置に戻ろうとする確認
    • 回転方向のみFB制御: 紙の上に置き、紙を動かし向きが変わらないことを確認
    • 並進+回転のFB制御: 制御の発振が無いこと確認
  • I/O確認: デバイス単体テストです。(初めて使うものほどよく確認しましょう。)
  • センサー確認: 一覧出力し、値の変化やノイズはなさそうかを確認
  • センサーキャリブレーション: 壁センサーの値をcsvデータをシリアル通信で出力(距離に変換するためのデータセットとして利用)

調整は何をどこまで詰めているか?

一部を参考として紹介。(一部、私が学生の頃、Miceで採用していた調整基準です)

  • タイヤ径:16区画直進で目視で1mm以上のズレがないこと
  • ジャイロゲイン:20回転で目視で基準線とのズレがないこと
  • オフセット値調整:目視でズレがないこと
  • FF/FB項調整:感覚。(どの速度・角速度でも追従してるっぽいな〜。破綻してないな〜という感じ)

各テストモードが終わってから、探索や最短走行を試験走行。失敗した場合はログから原因となる動きを特定しテストモードを再走します。

調整するパラメータ数について

上記に紹介したテストから、パラメータを網羅的に調整しようとすると、パラメータが多いため大変です。 性能向上に伴い、ターンのパラメータを増やすと、調整項目が増えていき、「モード切り替え→パラメータの調整」する際、都度「ビルド&書き込み」を繰り返すと膨大な時間がかかります。 他にも、直進時の「速度・加速度・距離」、超信地の「角速度、角加速度、角度、向き」など、状況によって細かく変えたくなることがあります。

私の場合、迷路情報の保存と同じ要領で、不揮発性メモリ領域にキャリブレーションデータを読み書きする機能を作ることで、ビルド〜書き込み時間をなくし、調整時間の短縮しています。

具体的にはyamlファイルに記載したパラメータをシリアル通信でマイコンに送信し、マイコン側はパラメータを保存しています。(私が使用しているマイコン(ESP32)ではUSBメモリのようなファイルシステムを持っており、パラメータのリストをテキストデータごとに保存し、起動時に読み込むようにしています)

これによりソースコード上に散在する値を変更するのではなく、調整用ファイル内の変更だけで調整を進めることができるので、ファイルの管理も用意になります。

まとめと補足

ざっくりではありますが、テストモードの紹介をしました。 駆動系とその他と雑に分けましたが、確認したいとき、確認するための方法を揃えておくというのが重要です。

1つ1つの動きを確認・調整していくことで長時間走る土台が固まるので、まだ決まったテストモードを持っていない方は参考にしてみてください。

補足をしますと、今回紹介したテストモードには、言語化できてないことや、下支えするツールありきな部分もかなりあります。 例えば、私の場合、ESP32-S3のPSRAM 2MBを使った豊富なログ情報と調整システムに駆使することで、大量のパラメータ調整を詰めていくという戦法を取っています。(逆にいうと、このスタイルを組みたいので、ESP32を選んでいます) このようなツールは何年も継続して活動する上で必須になるので、是非時間をかけて作ってみてください。

私自身、不揮発性メモリを使った調整の時短化は2017年ごろから行っており、調整速度の早さが私の戦績に大きく寄与しているので、中級者の方々には「マウスに役立つツールを作ってみる」ところから始めるのもどうでしょうか

明日の話。

PIDream.netさんの「クラッシュ時の止め方」です。フェールセーフは大事ですね。 『3・2・1 ゴー シュート!!!』

マイクロマウスアドベントカレンダー2023について

この記事は「マイクロマウスアドベントカレンダー2023」 マイナス10日目の記事です。


はじめに

今年は数年ぶりに全地区大会が一度の延期もなく、予定通り実施されましたね。 大会運営に関わってる方々には、以前と変わりない運営をしていただきまして、ありがとうございました。

軽く地区大会の振り返りをば。

私は例年、金沢、東日本、北信越、中部に絞ってスケジュールを組んでいましたが、今年は大学卒業以来初となる東北地区にも行きました。

実は、4度目の東北地区大会出場にして、初のタスパークホテルに宿泊でした。 というのも、大学の頃は基本ゼロ泊4日という強行軍で、「大会会場がホテルなのにホテルに泊まるという概念がなかったサークル」でした。 「あの部屋」の復活待ってます!

他にも、中部地区では「特別賞(勇者)」をいただきました。

勇者というと「葬送のフリーレン」が連想しますが、 私に関して言うと、決して、時事ネタだから、目新しいから印象的、という訳ではなく、 今シーズンの大会のデータシートには「そろそろ勇者パーティーがいてもいいのでは?」ということをずっと書き続けていましたので、「乗ってくれた!(ということにしてる)」という思いです。

是非とも魔王軍を滅ぼしたい人は残り2か月半頑張りましょう!!(もちろん来シーズンも)

転生者、チート持ちをお待ちしております。

地区大会の振り返りは主題ではないので、そろそろ主題に。

このAdventCalendarについて

過去には学生さん同士の煽りあいにより成立していましたが、今年はそういう訳にはいかなさそうなので、エントリーに際し、何点かお伝えしたいなと。

何を書けばいいか?

何でもありです。というのは困ってしまいますよね。

先にNGをあげます。

「ちゃんとしたものを書かなくては」という思い込み

「なんでもいい」の緩さを伝えるため、せっかくなので例をあげます。

ね?何でもありでしょう?

以下に、過去のアドベントカレンダーのリンクを張っておきます。参考にしてください。

「知識/実力不足だから」と書かない、エントリーしない

ここで伝えたいことは

  • 執筆中に考えが整理されていくことが多くある
  • 困っていることは発信することで誰かの助けになることがある。

あとは 「発表した奴が一番偉い」というのもあります。

書く内容がない

大会に出ている人、完璧にしてからエントリーして、いい成績が出せたことはありますか?

ないですよね?ということで、エントリーしてから考えてください。

こんな記事があるといいな

昨年度の全日本大会にて実行委員会の先生から「参加者が初級者と上級者に二極化している」という話がありました。

このことから、

  • もっと成績を良くしたいのに、~に困っている。
  • ~ができたら途端によくなった。 などノウハウが溜まるとうれしいです。

是非とも登録をお願いします。

枠がいっぱいになったら2枚目作ります。

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

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


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

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

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

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月に、個人的に学生大会を見据えた講習をしたのですが、無事優勝を勝ち取ってくれたので、やった甲斐があったかなと勝手に満足していますw
そんな彼が、直前に何をしていたのでしょうか(焦るようなツイートをしていた記憶がある)

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

はじめに

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

大会結果

セミファイナル3位

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

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

感想

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

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

次年度について

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

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

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

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

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

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


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

きっかけは、この告知。 f:id:nao1288stusj:20211206231548p:plain

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

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

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

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

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

スケジュール確認

2月に調整に集中したい。となると、1月末までに基本システムの構築、12月中にはハードウェアをFIXさせなくてはならない。
ということは、11月から年末までの1ヶ月〜2ヶ月でハードウェア周り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ボードからヒートガンをつかって剥がすことにした。 f:id:nao1288stusj:20211207000511j:plain

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

ピンアサイ

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

f:id:nao1288stusj:20211206235730p:plain ICはdigikeyと手持ちの在庫を見ながら調整。

f:id:nao1288stusj:20211206235824p:plain 一気に仕上げた(この画像では外付けフラッシュなし版)

足回りの設計

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

f:id:nao1288stusj:20211206235933j:plain

開発環境の確認

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で仮組み。 f:id:nao1288stusj:20211207001627j:plain 実はタイヤをつけるとシャフトとタイヤが干渉。千石で売っているアルミプチカッターにて切断。 f:id:nao1288stusj:20211207001730p:plain

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

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

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

最後に互い違いになるようにして、配置することでモーターは完成。 f:id:nao1288stusj:20211207002632j:plain (まさかモーターのシャフト以外を加工するとは・・・)

はんだ付け

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

完成

f:id:nao1288stusj:20211207003057j:plain ExiaAlterから継承したセンサー5つ構成

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

作り終わって

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

2021.12.10時点 での話

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

つまり・・・・

1ヶ月でマウス完成しませんでした!!!!(2021.12.10 23:45に確定)

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


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

f:id:nao1288stusj:20211210225147p:plain

追記

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

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

正式名称はD_structionsです。

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

AtCorderに挑んでみた

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

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

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

目的

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

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

目標

  • 水色(上位10%)!

現状の実力(主観)

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

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

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

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

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

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

(初期戦略)進め方

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

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

当初。Aはほぼ安定(1)。Bはたまにミスる(2)。Cは回答できることもあるがほぼ(3)。D以降は解けない(4)という状況でした。

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

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

環境準備

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

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

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

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


To Be Written....

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

はじめに

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

このAdventCalendar(ADC)について

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

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

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

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

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

本題

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

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

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

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

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

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

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

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

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

自動ビルドなどを行う際、mファイルなどに記載したコードを実行しようにも、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でグラフを描画していましたが、simulinkFrom Spradsheetを使用すると便利です。
1列目にtime_indexとして時系列情報を書き込む(行番号でOK)必要があるのですが、それ以外は特に制約なく利用できます。

f:id:nao1288stusj:20201130212640p:plain

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

まとめ

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

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

おわりに

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