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

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

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

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

本題

マイクロマウス大会のスポンサー「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として時系列情報を書き込む(行番号でＯＫ)必要があるのですが、それ以外は特に制約なく利用できます。

f:id:nao1288stusj:20201130212640p:plain

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

まとめ

「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形式のガーバーデータを出す方法

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

使用するもの

発注先と出力形式

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

出力方法

  1. eagleのトップメニューから、使用する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を実行する。

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

Clion+CubeMXでSTM32マイコンの開発環境紹介(CMake)

当記事は後で書き直します。画像の用意が面倒。

開発環境の紹介

  • Clion 2019.3
  • CubeMX(デフォルトでClionに内包)
  • CMake

なぜこの構成

  • ビルド環境をＯＳ依存にさせたくない。（プラットフォーム対応しているIDEなどを使う）
  • マイコンのドライバソフトに力を入れない。（CubeMXによる、HAL or LL出力）
  • Gitを経由して複数のＯＳ、環境にて再度開発環境を再構築したい。

最新のClionではCubeMX、OpenOCDが標準に組み込まれており、Windows, Mac, その他Linux環境での構築が可能である。

exlipseベースの他のIDEでは、C++の環境を標準で作成してくれない上、 いちいちオプションを見たりと、C++プロジェクトにするのに手間がかかる。そこでCMakeを率先して使いたい。

他に組み込みたいこと

内部にMatlabなどのシミュレーション環境も内包させ、Matlab/Simulink coderを使用し、シミュレーション、コード生成といった流れを作りたい。

C++でGUIアプリを作ろうとすると、環境依存が大きいので、やめることにした。（Win環境しかできないとか、まるで求めてない。）

今年のアップデート点

このブログはMice Advent Calendar 2019の 14日目の記事です。

強調に意味などありません。14日目の記事です。良いですね？

さて。タイトルの通り、今年試したネタ（ボツネタ含む）を紹介していこう

ExiaAlter(黒)

APEC大会向けに定格無視していた部分をすべて直したつもりの機体。

使用したICが悪かったせいか、不安定の極み。シーズン後半ではExiaAlter(白)を使う羽目に。

ExiaAlter(白)　修正版

昨年の有償機体

  • エンコーダからの出力（5V)を直にマイコン(3.3V定格ピン)に流していたが、分圧していれるように修正。
  • 足回りはアクリルからMJFに変更し、強度を向上
  • 吸引ファンはダクトを渦巻きポンプを意識し作ることで、圧損を軽減、低騒音と効率上昇を実現

Exia-Jr.

新作ハーフの予定だったもの。ExiaAlterのフォルムをそのまま小さくした機体。強そうな印象がないためお蔵入り。

  • ギアの噛み合いが何故か悪かった
  • 重い
  • RX71Mを思ったより余裕で載せられたので、つまらなくなった。

これまでも、お蔵入りの機体＞リリースされた機体　なので、仕方がない。

一回限りの根気で作れるものなんてたかが知れてます。１度良いものを作れるわけないのは仕事でも同様。（これを知らず、すぐに心折れる人を何人も見てきた）

調整システム

全データアップデート機能を実装。これでパラメータが合計１３００個だったことを知る。 使ってないデータはいくらかあるのだが。これは酷い。

バッテリー

いつものHyperionを3個直列。半年程度で膨れ始めるからいい加減やめたい

ソースコード

テストプログラムを修正しただけ、実はここ３年ほどほとんどアルゴリズムの開発を行ってない。 パラメータチューニングだけで済ませている。来年は大型アップデートするので、作り直しかな

次回作の構想

この記事はMicro Mouse Advent Calendar 2019の７日目の記事です。

なお、2019/12/06 23:47から書き始めています。RTAです。

まずは

２０１９年全日本大会お疲れ様でした。

昨年優勝したものの、あっさり３位に陥落しました。 これで、勝ち逃げと言われず、ハーフに行けるというものです。

次回作の構想

ハードウェア周り

今回のマイクロマウスにて、W特別賞の彼が利用しているマイコン「ESP32」をメインにした構成にしようと構想中

電波法の改正があったので、無線回りも工夫したいですね。

ソフトウェア周り

従来のヘンテコC言語による実装をほぼすべて廃棄したい。

せっかくある高級MATLABを使ったモデルベース開発を主軸にしていこうかなと

起動生成について

今までの軟化子を使ったターンを廃止。 基準軌道をベースに追従軌道と数msec後先まで計算するモデル予測制御を採用したい。

最後に３つほど

上記どれもが完成するまで大会に出ませんとかそういうのは多分しません。 所詮構想です。完成して動いたら勝ちです。出れないのが最悪の敗北です。

それと、大会結果はあの場にいれば知ってるので、もっと未来の話とか、裏話とか聞きたいな！！！

明日はアライさんの「社会人マウサーを続けるコツ？みたいなもの」です。 注文した品は来ないが、今シーズン台風を呼び寄せ続けた方がきっとためになる話をしてくれます！！