キャリアの絵文字を抹消したい

こんにちは、まんぼーです。

Galaxy S23 Ultraを購入しました。

いつも端末はdocomoで買ってましたが、MNP値引きが魅力だったのとdocomoマークを抹消したくて購入先をauにしたのですが、、

絵文字がダサい見慣れていないため拒絶反応を起こしました。

なんか、、、ホラー味ありますよね、、、

ということで今度は絵文字を抹消したいと思います。

なにをやるか

Googlefontsのnoto-emojiをgit cloneしてきて、副作用が起きる原因のスクリプトを修正してbuildし直す。build後の生成物をスマホに移して適用する。

なぜこうしたか

誰かがアプリ作ってくれていたらいいな〜という安易な気持ちでググっていたら、zFont3というアプリで変えられることがわかりました。

試してみたところ、リンクとして認識された文字の下線が文字から離れてしまう副作用を発症しました。これはキツイ…

もう少し調べるとGooglefontsが出しているnoto-emojiのコードを変えてmakeしてあげれば良さそう、となったので試してみます。

[参考サイト]

Galaxyスマホの絵文字が気に食わないのでGoogleの絵文字に差し替える | media.growth-and.com 

> 基本的にはこれなのですが、記事が古いためいくつか変更点があります)

PC環境

• Ubuntu22.04 LTS ※windowsの方はwsl環境を構築してください

環境構築

googlefontsのnoto-emojiをgit cloneしてくる 

 git clone https://github.com/googlefonts/noto-emoji.git

noto-emojiディレクトリに移動

cd noto-emoji

不要な記号を削除する

rm png/128/emoji_u002a* png/128/emoji_u0023* png/128/emoji_u003*

 

• ここでは0~9, *, #を消しています

設定ファイルのバックアップ

mv NotoColorEmoji.tmpl.ttx.tmpl NotoColorEmoji.tmpl.ttx.tmpl.bak

設定ファイルの書き換え

sed -e 's/".notdef" width="2550"/".notdef" width="680"/g' \ -e 's/"nonmarkingreturn" width="2550"/"nonmarkingreturn" width="680"/g' \ -e 's/"space" width="2550"/"space" width="680"/g' \ -e 's/".notdef" height="2500"/".notdef" height="680"/g' \ -e 's/"nonmarkingreturn" height="2500"/"nonmarkingreturn" height="680"/g' \ -e 's/"space" height="2500"/"space" height="680"/g' \ -e 's/underlinePosition value="-1244"/underlinePosition value="-300"/g' \ NotoColorEmoji.tmpl.ttx.tmpl.bak > NotoColorEmoji.tmpl.ttx.tmpl

• 未定義文字、マークのない改行文字、半角スペースを修正しています

スクリプトの修正

vi check_emoji_sequences.py

以下の箇所を探してコメントアウトする

if not coverage_pass:
  exit("Please fix the problems mentioned above or run: make BYPASS_SEQUENCE_CHECK='True'")

buildt instructionに従ってbuildする

※失敗する場合は大抵パッケージが足りてないので、pip3 install XX(足りていないと言われたパッケージ)をインストールする

成功すると生成物としてNotoColorEmoji.ttfが作られます。

これをスマホに持ってきて、z-font3にインポートしてきます。

インポートしたらアプリの手順に従って適用します。

英語で手順がわからない人のために下記のサイトでまとめてくれています。

https://smhn.info/202209-docomo-emoji-z-font3

結果

入力した絵文字の表示は変わるようになりました。

ただ絵文字の候補が変わってないのがちょっと(結構)気になります。気が向いたら直せないか調べてみます。

冬休み中に読みたいAdvent Calendar

こちらはの25日目の記事です．

adventar.org

昨日の記事はまだ投稿されていなかったので，投稿されたら感想書きます．

みなさんこんにちは．まんぼーです．

ついこの間までピカピカの大学1年生だった気がするのですが、気づいたら6年経ち就職してました.ﾊﾔｽｷﾞﾃｺﾜｲ

サークルも完全に代替わりし、Twitterで見たことあるかな…？というような方だらけになってしまいましたが、ギリギリ知ってる人がいるうちに顔出したいですね。来年ラストチャンスですかね...

今年の題材何が良いかな～とか思いつつ過去のブログに目を通してみたら，

ものづくりのチーム開発を攻略しよう① リーダーが気をつけるべきこと - まんぼーの技術記

Nucleoに学ぶプリント基板設計①-配線編- - まんぼーの技術記

Part1だけ作って後を公開していないものがしばしば...ブログ向いていない人の典型的な例ですね．続き気になっていた人いたらすみません．毎回②のDraftは作って書き始めはするんですがなんかパッとしなくて途中で書くのをやめてしまっています．よくないですね．

今趣味で作っているロボットのお話しようかなとか思ったのですが,全然完成していないのでお披露目は別の機会として，今回はTwitterで流れてきた共有したい記事・興味深い記事と，冬休み中に読もうと思っているAdvent Calendarを共有したいと思います．手抜きですみません！

1.DCモータをなんとなくPID制御している人向け 

移動ロボットにおけるブラシ付きDCモータのPID制御 - Qiita

DCモータのPID制御用PWM駆動回路について - Qiita

マイコンでDCモータのPID制御をなんとなく実装して調整したことはあるけど，最初に学んだ理論以外よくわかってないな...という人は全員読むべきだと思います．

2. 面白かった記事

ROSのOSSで4脚ロボットを制御できるchampでM5stack×レゴの4脚ロボットを動かしてみた記事です．Lego StudioってURDF化できるんですね... お手軽にロボットを作れそうです．

M5Stack+ROSで4脚ロボットを作る - Qiita

冬休み中に読みたいAdvent Calendar

・全国の強ツヨ学ロボエンジニアたちが書いている記事です．チラ見しましたが，ロボコンやっているからこそ出てくる検討や考え方など，興味深いものが多々転がってました．読み物として読み進めます．

・基盤モデルについてのカレンダーです．ロボットの基盤モデル活用はまだ研究レベルだと思いますが，ここ数年でできることが格段と広がってますよね．この分野は疎いですが，最近やたら耳に入ってくるので，ちゃんと動向を追っていきたいです．

・ROS1のEOLに従って様々なプロジェクトがROS2に移行していっています．

今年ROS2開発をしましたが，やっぱりちゃんと開発して困った！みたいな情報は貴重ですよね．まだROS2で開発したことがない/開発しようとしていないとナニコレ状態かもですが，ロボット開発者を続けていく人はいつか役立つと思います．

まとめの割に少ないですが，以上となります！

この機会にAdvent Calendar色々漁ってみましたが，ロボティクス・IoT以外にもいろいろ面白いものが潜んでました．冬休み暇だな・・という方，是非暇潰しに漁って，興味あるものを読んでみると良いと思います！

Advent calendarのリンク↓

ではでは，よいお年を～！

ものづくりのチーム開発を攻略しよう① リーダーが気をつけるべきこと

この記事はWMMC Advent Cakendar 2021 25日目の記事です．

adventar.org

今までの記事も是非↑をクリックして読んでください！

今日の記事の目次と概要↓　適宜飛んでください！

はじめに

あらすじ

こんばんは，まんぼーです．

1年ぶり(昨年のAdvent Calendarぶり)の更新です．

私を知らないWMMCメンバーも多くなってきたかと思います．学内でしか伝わらなそうな表現で自己紹介しておくと，S0UK1のM2で，所属はT研です．

コロナが流行してからサークルに顔を出す手続きが面倒になり，サークル活動が緩和されてからは中々行く時間がとれなくなってしまいました．卒業までに顔を出さねば…

昨日の記事はalminum君による「CADをクラウド管理してみた」でした(まだ公開されてないみたい。記事みたら再度編集します)．

最近は様々なものがクラウド化していて，便利ですよね．

たまにネットワーク障害で機能しなくなることもあるので，クラウドに頼りすぎると痛い目を見ることがあります．臨機応変に対応したいところです．

さて，今年のカレンダーは書く余裕ないなぁとか思って放置してましたが，J●君とs●phia君に沢山脅迫されたので，書くことにしました．

脅迫1

脅迫2

技術のことを書こうかと思ったのですが，簡単なものは先人のすごい人たちのおかげで山ほど転がっていますし，話したい分野は大体研究絡みで機密性が高くて、ブログに出すためにはモデルを作り直さなければならないしそこまでの時間はない...　マウスは先人の方々の尽力のおかげでオープンになってきているので，技術を学びたい人には良い材料だなぁ，とつくづく実感しています．

そんな中何を書こうか迷っていたのですが，私は今年結構大きめの研究プロジェクトをリーダーとして回してきました．多分ドクターがやるべきことなのですが，残念ながら自分の研究班には研究を主導してくれるドクターがいなかったため，チーム開発について悩んだり気をつけなければいけないことが多い1年でした．また，学部の頃にやっていたロボコンでもチーム開発について考えさせられることが多くありました．

そこで，チームでものづくりをする時にリーダーやメンバーが気を付けるべきことや，重要だと感じたことについて書き連ねたいと思います．長くなってしまったので，分割して公開したいと思います(書くのが間に合っていないなんてそんなことないよ！！！汗)．

この記事では，リーダーとして自分が常に注意していることや，失敗から得た知見を少しでも共有できればと思います．

読むとためになる人

• チームをリーダーとして率いる必要がある人
• チームリーダーをやって失敗したことがある人
• チームで仕事を奪いがちな人
• チームでの開発経験がない人
• これから研究をするB1~B3の人

　　　(そのうち公開する「メンバーが気を付けるべきこと」を読むと良いです)

• 未来の自分

そもそもチーム開発をするメリットとは？

マイクロマウスをやっている人はチーム開発の経験がない人もいると思います．また，チーム開発をしていても１人のほうが進むと感じている人も多いと思います．自分が優秀すぎる人は，足を引っ張られた経験からチーム開発を嫌う傾向にあるような印象があります．

では，なぜわざわざそんなチーム開発をするのでしょうか．

答えは，以下に尽きると思います．

Twitterの拾い画

引用元: わかめ on Twitter: "世界のことわざの中で群を抜いて好き。… "

1人では必ず限界があります．その限界を突破するためにはチームでやらなければなりません．

もちろん，小さなプロジェクトなら1人で回せるかもしれませんが，大きなプロジェクトの開発，マウスより大きなロボットの開発では，分担をした上で各々がその分担におけるスペシャリストになることによって，1人での開発では到底届かないレベルにもっていくことができるのではないか，と思います．もちろん，大きなロボットの設計から制御まで全部1人でやってしまう化物級の逸材もいますが...　そんな人でも，やっぱりチームを組んで開発していることが多いですよね．

それは，チームを作り技術を繋いでいくことにより，開発を始めた最初にはできなかったことができるようになっていくからだと思います．

リーダーが気をつけるべきこと

リーダーが常に考えるべきことは「チーム全体を見て目標に対してうまくいっているか」を意識することです．私が挙げることが全てではないと思いますが，これを実現するために重要なことをいくつか挙げ，細分化して見てみたいと思います．

1. チーム内全員に目標・方針を誤解なく共有する

　大事なことは全員に共通の目標を誤解なく持たせることです．後輩の指導をしたことがある人はわかると思いますが，誤解なく，というのが非常に難しいものです．メンバーが少しでもリーダーの思っている理想の方針と違う解釈をすると，誤解に気づくまで少し違う目標に向かって進み始めます．これは大幅なタイムロスです．

例えば，後輩を指導していて「自分が言ったことと違うことをやってきたな…」と思ったことありませんか？私も指導をする側になった頃にしばしば感じたことがあり，「ちゃんと言ったのにな…」と思うことがありました．

これによるタイムロスは基本的にリーダーの責任だと思っています．

いや，指導を受ける側がちゃんと理解しないのが悪いでしょ！と感じる人はまずはじめに自分の指導の仕方を見返すべきです．

タイムロスが起きる理由は主に2つあります．

1つめの要因は「自分の思っていることを正確に伝えられていない」ことです．

これにもいくつか種類があると思いますが，「言葉足らずで大事な部分が抜けている」か，「話がまとまっていないため要点が掴めない」のどちらかが多いのではないでしょうか．

その人が誰に対しても当たり前だと勘違いして一部の内容を省いているか，頭の中にふわっと浮かんでいる主張を言語化しきれていないことが原因であると思います．

日頃から言語化する練習を行い，数日後の自分が見返して理解できる文章を作る訓練をしましょう．私も口下手な方なので，まず言語化できるまで考え抜き，PCやスマホなどで文章化して伝わりやすい文章かどうかを考えるようにしています．

言語化がうまくできるようになるまでは，本当に自分の言ったことを理解しているか，意図が伝わっているかを確認しながら，何か違うと思ったらその時点で考えが合致するまで説明を丁寧に行う他ないと思います．

自分は丁寧に教えてるけど…と思うなら，2つめの要因として挙げられることは，「リーダーの思考と自分の解釈が同じかどうかを常に考えさせ，気になったら必ず相談するように初期の頃に指導していないこと」です．この指導を初めのうちにやっておかないと，相談せずにとりあえず進めることに慣れてしまうため，修正が利きにくくなり，いつまで経っても同じことが起き続けます．もちろん指導しなくても自ら相談しに来てくれる人もいますが，相談することにすら抵抗を感じる人もいます(自分は割とそうです)．個々の性格をうまく汲み取り，相談しにくい人が相談してくれるような環境づくりを最初に行うことが大事です．

2.方針・方向性の是正

チームを組み始めて間もない頃は方針を定めるために頻繁にミーティングをすると思います．しかし，方向性が固まってくるとミーティングの頻度が少なくなり，気づいたら自分の思っていた理想と離れた方向になっていることがあります．

また，時間が経つにつれて方針や方向性を変更しなければいけないことが出てくることもしばしばあります．

これらの変化にいち早く気づき，必要に応じて是正を行うこともリーダーの役目です．

3. 進捗管理とタスクの分担量の調整

複数人で開発するからには，進みの速い人もいれば遅い人もいます．また，そのスピードはタスクの重さによっても変わります．各人の進み度合いや性格などを見ながら仕事の振る量を見極め，タスクをうまく分担することが重要です．進度が早い人に，仕事を分散させることにより，効率的に進めるべきです．リーダーがある程度手伝ってあげることも選択肢の一つです(ただし，項目6・7に気をつけましょう)．

また，進捗管理をする際，タスクには必ず優先度をつけるようにしましょう．同時にやることが多いと，どうしても簡単なものから取り組んでしまいがちです．必ずプロジェクトにおいて最も効果的に効いてくるタスクから取り組ませましょう．

4.  メンバーの人数が適切かを考える

これはメンバーを取る前の話になりますが，プロジェクトに応じて適切な人数を取るべきです．多い方が分担できて楽でしょ！と思うかもしれませんが，ものづくりにおいてはそうとは限りません．

例えばボールを投げる1m立法くらいのロボット1台を作って動かしたいとしましょう．あなたがチームリーダーをするとして，何人ほしいですか？

開発期間とチームメンバーのやる気度合い・熟練度合いによって変わるとは思いますが，開発期間は1年，やる気は全員あるものとします(もしくは卒修論や給料が出るためやらざるを得ない状況だとします)．大体メカで2~3人，ソフトウェアに3~4人，回路で2人くらいではないでしょうか．もちろんあくまで参考人数です．メンバーの熟練度合いによってはこれより少なくてもいいと思います．

メカは足回りに1人，アームに1人，統合やなんやかんやする人でもう1人(要らない？)．

ソフトウェアは足回りのモータ制御に１人，動作計画に1~2人(動作計画の程度による)，アームの制御に1人．

回路はソフトウェアの人数を多く取る場合にはその中の1人にもやってもらい，合計で2人．

メンバー過多のチームではタスクが被る人が出てきて，うまく分担できない・タスクの取り合いが発生する状況に陥ります．

漠然と「うーん，なんとなく4人ほしい！」みたいに考えるのではなく，どのように分担させるかを考えた上でメンバー数を決定しましょう．

5. 必要に応じて決定権を行使する

これはポスドクに言われて学んだことです．今年は何回もこれに助けられました．

方針決めや何等かの取捨選択をする際，中々決まらずグダグダになることがあります．普通物事の取捨選択をする際には，いくつかの物事に対して比較項目を並べ，根拠を探したり試作をいくつかした上で感覚に頼らずに比較する，ということを行うことが大事です．これは研究を始めたばかりに言われることだと思います．

根拠を探すことなら比較的短期間で終わらせられますが，ものづくりにおいてはただ根拠を探すだけでは取捨選択できず，試作をしなければいけないことも多いです．特にプロジェクトの開発期間等が短い場合，「試作をしないとわからない」という時間は非常にもったいなく，最終的に間に合わなずうまくいかなかった，といった結果になる可能性が出てきます．

これを防ぐためには，重大な場面においてリーダーが決定権を行使することが重要です．自らの経験を踏まえ，「これならうまくいく可能性が高い」という選択を行い，「これは多分無理だ」という選択肢を捨てることが必要となります．1つに絞ることは無理だとしても，比較項目を経験からいくつかに絞ることにより，時間のコストを削減することができます．ある意味博打です．博打が原因でうまくいかなかったら反省するしかないですが，そうならないように経験を踏まえた判断ができるよう，普段から判断力と即決力を鍛えましょう．すぐに身につくものでもないので，リーダーになる前から取捨選択を正しく行う習慣をつけるべきです．

決定権を行使しすぎると他人の考えた案を潰す場合があります．絶対無理だろうという案を潰すのは良いと思うのですが，良い案を潰さないように気をつけましょう．潰すときは，必ず論理的な理由をつけ相手を理解させるよう心掛けましょう．そうでないとただの理不尽になります．

6. メンバーをフォローする

7. メンバーを信頼する

6,7についてまとめて説明します．

チームでリーダーになる人はソフトウェア開発からハードウェア設計，回路設計まで，色々な事が出来る人が多いと思います．なんでもできるからと言って分担したはずの作業を取ったりしてしまうと，メンバーが成長していきません．作業を取るのではなく，成長を手助けすることがリーダーの役割だと思います．メンバーを信頼し，物事を主体的に取り組まることにより次第に自分が手助けをする頻度が減り，開発効率が上がっていきます．

8. 消えない

色々書きましたが，これが最も大事だと思います．今までチームをまとめていた人が突如いなくなると，チームは大混乱です．大規模かつ忙しいプロジェクトではありがちだと思いますが，消えないようにしましょう．

メンタル面で消える可能性がある人は，いつ消えても仮のリーダーを立てられるよう，日頃からチーム全体に関する相談をしたり，自分の考え方を共有できるメンバーを作っておきたいところです．リーダーを務められる人が何人かいる場合は，メンタルの強い人にリーダーを任せた方が良いと思います．

ボスではなくリーダーになろう

これまで，ものづくりにおいてリーダーが気をつけるべきことを書いてきましたが，リーダーになる人には必ず知っておいてほしい言葉があります．それは「ボスになるな」という言葉です．イギリスの起業家であるハリー・ゴットン・セルフリッジの言葉が有名です．

以下，セルフリッジが表現した「リーダーとボス」の違いです．

・ボスは部下を追い立てる　　　

↔リーダーは人を導く

・ボスは権威に頼る　　　

↔リーダーは志、善意に頼る

・ボスは恐怖を吹き込む　　　

↔リーダーは熱意を吹き込む

・ボスは私という　　　　　　　

↔リーダーはわれわれという

・ボスは時間通りに来いと言う

↔リーダーは時間前にやってくる

・ボスは失敗の責任を追わせる

↔リーダーは黙って失敗を処理する

・ボスはやり方を胸に秘める　　

↔リーダーはやり方を具体的に教える

・ボスは仕事を苦役に変える　

↔リーダーは仕事をゲームに変える

・ボスはやれと言う　　　　　　

↔リーダーはやろうと言う

引用元 Harry Gordon Selfridge - Wikipedia

皆さんはボスとリーダーのどちらのほうが良いと思いますか？価値観によって変わると思いますが，私はリーダーの方が有用だと思いますし，このようなリーダーになりたいと思っています．

詳しく気になる人は，私が説明するよりも下の記事を読むと良いと思います．トヨタの経営の話ですが，根本はものづくりのチーム開発においても同じだと思っています．

おわりに

いかがでしたでしょうか．この記事を書きながらも，自分がまだうまくできていないな，と感じるものがたくさんありました．全部できる人になりたいですね...

少しでもチーム開発の参考になると幸いです．

また，ここに書いていない内容で，自分はこういうことに気をつけてるよ，ということがある人は是非コメントなどで教えてください．

修論が落ち着いたら，

・メンバーが気をつけるべきこと

・数年計画の開発で気をつけるべきこと

についても書いて公開したいと思います．

WMMCのAdvent Calendar2021はこの記事で終了です．

卒業された先輩方の記事を見れるこの企画は結構良いですよね．後輩の誰か，来年も是非企画してやってください！

それでは良いクリスマス・良いお年を！

ROSとNucleoで通信してみる ~rosserial_stm32の導入~

みなさんこんにちは．まんぼーです． 

この記事はWMMC Advent Calendar 2020の25日目の記事です．

昨日はJackie君の今年の振り返りとAnalog Discovery2についてのお話でした。

ROSとNucleoで通信してみる ~rosserial_stm32の導入~
jackie39.hatenablog.com

Jackie君は僕の同期ですが、M1になってから１回も会ってない気がします。コロナめ…

AD2、秋月で売ってるのは見たことがありますが高くて手が出せません。

でも、お家でオシロやロジアナ・ファンクションジェネレータが欲しくなったらこれ１つ買っておけばよさそうですよね。

さて、今日はクリスマスですが、皆さんはどうお過ごしでしょうか？？

WMMCのクリスマスに出てくる記事やばそう、とか思った皆さん。

僕がクリスマス枠をとってしまいごめんなさい！！！

代わりに今までのクリスマスで面白かった記事でも貼っておくのでユルシテ

judge.hatenadiary.com

titech-ssr.blog.jp

言うのも悲しくなってきますが、今日(というかもう昨日)の夕方はバイトに行き、この記事が書き終わったらロボットのプログラムと睨めっこしたいと思います。つまり、この記事が投下された瞬間から

製　の　6　時　間　開　幕  

です。はぁ。

さて、今回はROSのシリアル通信機能であるrosserialを使ってSTM32と通信してみる、というのをやってみます。目次はこちら。

Advent Calendarから来た人はROSを知らない人もいると思うので軽く説明すると、ROSとはロボットのソフトウェアプラットフォームです。ロボットを開発する際に必要なツールやライブラリが豊富に存在し、ロボットの開発が容易にできるようになっています。

rosserialとは、シリアル通信を用いてROSとマイコン間の通信を実現するためのパッケージで、強い人がそれをSTM32マイコンに拡張してくれたrosserial_stm32というパッケージを使います。（やっている人はちらほらいるのですが、初見だと詰まる箇所があったのでまとめておこうと思いました）

動作確認済の環境

・Nucleo STM32F401RE/STM32F446RE

・Ubuntu16.04(kinetic) / Ubuntu18.04(melodic)

・STM32CubeIDE(ver1.4.0)

CubeIDEのインストール・プロジェクト作成

まず、UbuntuにSTM32CubeIDEをインストールします。

https://www.st.com/ja/development-tools/stm32cubeide.html

このサイトの

STM32CubeIDE-DEB

STM32CubeIDE Debian Linux Installer

を入手します。インストーラーのあるディレクトリまで移動し、↓のコマンドでインストールします。

sh st-stm32cubeide_1.4.0_7511_20200720_0928_amd64.deb_bundle.sh 

※バージョンによって違います。 

terminal上で利用規約を読まされますが、ctrl+Cで飛ばせます。

Enterをずっと押しているとNo/Yesを選択するときにNoが選択され、このコマンドを知らなかったときはひたすら良い感じのタイミングでEnterを離す…みたいなことをやってました。アホ。

規約読みながらEnterを適切なタイミングで離さないといけないクソゲーやってる pic.twitter.com/xWnCwPLgDE

— まんぼー (@was3to4) 2020年11月3日

ちなみに投稿時点で最新バージョンは1.5.0ですが、私のPCではバージョン1.5.0だとうまく動作してくれませんでした。プロジェクトをインポートしようとするとクラッシュするみたいな。解決方法探すのもだるかったので1.4.0を入れました。

インストールが終わったらSTM32CubeIDEを起動し、ボードを選択します。

そしてプロジェクトを作成します。

Targeted LanguageはC++でないといけないので注意。

ピン設定ファイル(.ioc)を以下のように設定します。

いじる箇所はUSART2,TIM2です。

①USART2の設定

・Parameter SettingsでBaudRateを57600に設定(最後に記述するコマンドでBaudRateが統一されていればOK)

・NVIC SettingsのUSART Global Interruptをチェック

・DMA SettingsにてUSART2_RXをDMA1 Stream 5に紐付け、 DMA Request Settings のModeを Circularにする

・USART2_TXをDMA1 Stream 6に紐付け

②TIM2の設定

Clock SourceをInternal Clockに設定

設定が終わったらコードを生成して一旦閉じます。

rosserial、rosserial_stm32の準備準備

次にrosserialのパッケージをインストールします。

sudo apt-get install ros-kinetic-rosserial

 続いてワークスペースを作り、src内に移動します。

mkdir ~/catkin_ws/src
cd ~/catkin_ws/src

 開発者様のgitからクローンしてきて、ビルドします。

git clone https://github.com/yoneken/rosserial_stm32.git
catkin build
cd ~/catkin_ws
source devel/setup.bash

続いてterminalで生成したSTM32コードのディレクトリに移動します。

ワークスペースの場所によってコマンドが変わると思います。

Srcがあるディレクトリまで移動してください。

cd  ~/ STM32CubeIDE/workspace_1.4.0/rosserial_test/Core

Srcがあるディレクトリまで移動してください。

 rosrun rosserial_stm32 make_libraries.py .

を実行します。するとtopic通信に必要なメッセージライブラリたちがインポートされます。

次に、mainpp.cppとmainpp.hを追加します。

・catkin_ws/src/rosserial_stm32/src/roslib/chatter/Srcの中のmainpp.cppをIDEプロジェクト内のCore/Srcに

・catkin_ws/src/rosserial_stm32/src/roslib/chatter/Incの中のmainpp.hをIDEプロジェクトのCore/Incに

コピペします。

これらのコピーが終わったらCubeIDEを開き、再度STM32のプロジェクトをインポートし直します。

・main.cを書き加えます。

main.cのwhileの手前でsetup();と記述

main.cのwhile内でloop();と記述

・STM32F4xxを使用する場合、STM32Harware.h内の

#define STM32F3xxをSTM32F4xxに書き換えます。

ここまでできたらプログラムをコンパイル・書き込み、Nucleo側は準備完了です。

terminalを開き、１つめのターミナル上で

roscore 

2つめのターミナル上で 

sudo chmod o+wr /dev/ttyACM0
rosrun rosserial_python serial_node.py _port:=/dev/ttyACM0 _baud:=57600

3つめのターミナル上で 

rostopic echo /chatter 

 うまくいけば↓の右のターミナルのようにtopicが表示されます。

無事、Hello World!が表示されました！

terminalの番号は左上、左下、右の順に1,2,3

最後に、mainpp.cppとやらに書かれているコードを記載しておきます(自分が書いたやつじゃないけど)。基本的にはココにrosのコードが書かれているみたいですね。私はもう色々いじっちゃいましたけど

#include <mainpp.h>
#include <ros.h>
#include <std_msgs/String.h>

ros::NodeHandle nh;

std_msgs::String str_msg;
ros::Publisher chatter("chatter", &str_msg);
char hello[] = "Hello world!";

void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart){
nh.getHardware()->flush();
}

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart){
nh.getHardware()->reset_rbuf();
}

void setup(void)
{
nh.initNode();
nh.advertise(chatter);
}

void loop(void)
{
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_3);

str_msg.data = hello;
chatter.publish(&str_msg);
nh.spinOnce();

HAL_Delay(1000);
}

コードを見るとわかる(わかる人には)と思いますが、 ほぼROSでのコーディングと同じ勝手で記述されています。とても便利ですね。

おわりに

いかがでしたでしょうか。書ききってから思ったのですが、これ…マウスのカレンダー向きじゃないな。まぁいっか。

今日でWMMC Advent Calendar 2020は終了となります。

私も一通り記事に目を通してきましたが、記事の更新で生存を確認できた人がいたり、まだ見たことのない１年生も参加してくれていました。コロナで新歓が潰れ、今年は誰も入らないんじゃないかってみんなで騒いでましたが、無事１年生が入ってくれたようで安心しました。今後の彼らの活躍に期待です。

私はAdvent Calendarに2回投稿しましたが、1回めの記事を投稿した5日目から20日、あっという間すぎてビビってます。本当はもっとロボットっぽいことを記事にしたかったのですが、もう少し時間と心に余裕があるとき(あれば)に改めて書きたいと思います。

企画してくれたJG君、参加してくれたサークルメンバー、読んでくださった皆さん、ありがとうございました。よいクリスマス・よいお年を！

2020年に勉強した本の紹介

こんにちは．こんばんは．まんぼーです．

この記事は WMMC Advent Calendar 2020 5日目の記事です．

adventar.org

昨日は1個上のズャさんの留学の話についての記事でした．

zoo-kazu.hatenablog.com

留学は…そうですね．いつの日か時空が歪んだため選択肢から外れました． でも，留学って憧れますよね．

ズャさんとオフラインで最後にいつ会ったっけ...というレベルで会っていないのですが，無事海外から戻って来れて安心でした．卒業するまでに会いたいです．

この記事の目次です．ドーン．

 はじめに

 2020年，学びを得るのに使ってきた本を紹介したいと思います．

本なんて自分で探せるよ！と言われると返す言葉もないのですが，「○○についてオススメの本ない？」とは案外よく聞いたり，聞かれたりする話題の一種だと思います．

特に初学者にはどの本が良いかわからないと思いますし，研究室に入っている人と入っていない人の情報は結構異なったりすると思います．そこで，これから同じ道を歩もうと考えている人のためにこの記事を書くことにしました．

色々な本を比較したわけでもないので，ここが良かった，ここが足りてない，みたいなものはないのですが，同じ分野で生きようとしている人の手助けになればいいかなと思います．ではLet's Go．

1.『現代制御工学－基礎から応用へ－』  江上正・土谷武士 共著

弊学科は学部時代に簡単な古典制御しか学ばなかったので，学部4年の時に物足りなく感じて購入した本です．ちゃんと読んだのは今年に入って制御の授業を取ってからですが，安定性の話オブザーバ，最適レギュレータ系の話，デジタルサーボ系の話まで，現代制御について多くの例題を交えながら説明が書かれており，わかりやすい参考書でした．

私の所属する研究班のボス(某Iさん)がオススメしていた本なので，間違いないと思います．読むだけでは定着しないと思うので，手を動かして式を追ったり，MATLABで実際に制御系を組んでみると良いと思います．

☞こんな人にオススメ

・古典制御を知り尽くして物足りない人

・将来制御関連で生きていきたい人

honto.jp

※学部1~2年で初めて制御工学を学ぼうとしている！という人は足立修一先生執筆の「制御工学の基礎」を勧めます．完全に理解した人は↑の本で学ぶと良いと思います．

※ちなみに足立先生は慶応義塾大学の教授で，制御やフィルタ等について様々な本を出しています．YouTubeでも講義動画が公開されているので，そちらも初学者にはかなりおススメです．(URLは⇩)

www.youtube.com

2.『C++で学ぶオブジェクト指向プログラミング』　柴田望洋

修士課程に入り，修論やROSのプログラミングでC++の勉強必須だなぁとか思っていたのですが，GW前に色々あり，C++のクラスの勉強を急ピッチで進めなければいけなくなった頃に使用した本です．正直紹介するまでもないですが，C/C++，Pythonなど様々なプログラミング言語の教本を作っているBohYohさんの参考書です．C++の基礎的な部分は省かれ，クラスを始めとしたオブジェクト指向プログラミングについてひたすら書かれています．

解読難易度はまあまあ高めで，元々そこまでプログラミングが得意ではない私は，GW前後は1日7時間くらいこの本と格闘していました．2回くらい読んだりコード書いたりしましたが，うーんわからん！って感じです．今も結構な頻度で参考にしています．

C++を軽く触れて軽く使えるようになればいい！という人には「やさしいC++ 第5版」くらいがちょうどいいと思います(Amazonレビューに書いてある通りミスが多いが)．

ちなみにですが，この本を読んで練習プログラムを書いただけでは，使いこなせるようになるのは難しいと思います(C++に限らないですが)．ある程度まで読んだら，実際に実装目標を立ててプログラムを書いてみると一番上達が早いと思います．

☞こんな人にオススメ！

・ロボットを仕事にして生きていきたい人

・プログラミングが好きな人 

 ・残念なことにC++が必要になってしまった人

www.sbcr.jp

まだC++を学んだことがない人はこの本ではなく， C++ 入門編を買うべきです．

⇧の本の姉妹本で，初学者向きです．

www.sbcr.jp

 3.『リーダブルコード 』 ―より良いコードを書くためのシンプルで実践的なテクニック

他人にコードを読んでもらってワケわからん！って言われたことないですか？もしくは，他人のコードを読んでワケわからん！っと思ったことはないですか？

私は両方あります．そんな時にはこの本がオススメ．宣言する変数名の決め方やプログラムの書き方など，プログラミングの授業ではほとんど教えてもらえないことが書いてあります．チーム開発をする前・就職する前に読んでおいた方が良いと思う．マジで．

 私はTwitterで流れてきて，周りにもこの本を勧める人がいたので研究費で購入しました．マウスを始めて「標準プログラム(※1)」なるものを手に入れてから，コードをできるだけわかりやすく書くように心掛けてきましたが(何回も使う変数にaとかiとかsとか使わない．まとめるべきものはまとめる．など)，他にも色々気を付けるべきことはあるんだな，と改めて思わせられた1冊でした．とにかく一回触れるべき．

※1)弊サークル内でオープンソース(※「内で」とか書いてる時点でオープンソースではない)になっているマウスのプログラムのこと

どんな事が書いてあるか気になる人は⇩の記事を参考に．

qiita.com

qiita.com

☞こんな人にオススメ！

・チームでソフトウェア開発をしている人

・他人にコードを理解してもらえない人

・自分で書いたコードを2週間後に読めなくなっている人

www.oreilly.co.jp

4.『ヒューマノイドロボット 改訂2版』(梶田秀司 編著)

某研究室で結構な人が愛用していると言われている神書，『ヒューマノイドロボット』の改訂版です．

ヒューマノイドロボットの制御方法を学ぶことが目的の本で，基本となる運動学の話からZMP，動力学，パターン生成などについて詳しく書かれています．

この本の第一版は絶版になっていて，メ〇カリでたまーに出品されて即売り切れのループが続いてました．大きめの図書館で借りるくらいしか読む手段がなかったのですが，今年10月に改訂版が出たみたいです．

出たので買おうかなと思いつつ，つい先週ようやく買いました．

え？勉強に使った本の紹介なのに先週買ったの？

ええ，只いま絶賛使っている最中です．でも研究室の皆が使ってますし，評判通りわかりやすく書かれているのでオススメです．

［こんな人にオススメ！]

・ヒューマノイドロボットの制御理論を学びたい人

・運動学の勉強をしたい人(はこれよりもっと良い本があると思います．読んだことないですが↓に貼った本とか良いのではないでしょうか．)

www.ohmsha.co.jp

www.ohmsha.co.jp

おわりに

いかがでしたか？

他にも色々な参考書を読みましたが，多すぎても読む気が失せると思ったのでこのくらいにしておきます．

 新しいことについて勉強をしたいなと思った時にこの記事を思い出してくださると幸いです．

明日はRivière君の「rand関数で迷路をランダム生成させてみた」という記事です．

Rivière君もコロナ禍に入ってから1回も会っていない後輩です．期待のB2の初記事(だよね？)，とっても楽しみです！！ではまた．

Nucleoに学ぶプリント基板設計①-配線編-

こんにちは．まんぼーです．

皆さんStay Homeしていますか？

個人的にですが，研究室に行けなくなり，やろうとしていた実験を当面しなくて良くなったので できなくなったので，色々な面で(※金以外)余裕ができました．

コロナのせいで収入が激減した反面，コロナ禍がなかったら触れていなかったであろうこと(長年放置してきたギターやC++の勉強など)に手が出せるようになりました．なんやかんやで時間が経つのは早いので，有意義に過ごしたいです．

はじめに

さて，この記事を読んでいる皆さん．Nucleoは持っていますか？持っている方，「こっちが本体！！！」とか言ってデバッガだけ切り取って，下側を捨てたりしていませんか？

プリント基板の回路設計をしながら色々勉強していくと，「これ…どうすればいいんだ？」みたいなことが良く出てくると思います．そんな時にNucleoがあると学べることがあるはずです(その前にググれというツッコミは全面的に受け付けます)．

超大手の会社が作るプリント基板ですから，私みたいな回路初心者よりも，それなりの技術が詰まっているはずです(と信じたい)．Nucleoを見て回路設計について学べることを学んでいきましょう！(※完全に入門編です．所詮は開発ボードなので，あまり深くは学べないです)

Nucleoについての細かな説明は割愛しますので，他のブログ等をあたってください．

Nucleoで学ぶプリント基板設計

今回はよく配られている秋月で売られているNucleo F401REをじっくり見ていきます．

(私の持っているNucleo F411RE, L476RGはすべてパターンが同じでした(多分)．もしかしたら変わっているかもしれないですがご了承ください．)

Nucleoはレジストが白なので目立たないです．図もとても見にくいですが，ご了承ください．

1．信号ラインは直角配線を避ける

まず，パターンの曲がり角を見てみましょう．

パターンの曲がり角

どのパターンも45°に折れていることがわかります．

プリント基板の設計では，基本的に直角配線は嫌われます．

これは，曲がり角で特性インピーダンスが変化し，ノイズが発生しやすくなるためです．インピーダンスが変化するのは，直角にしてしまうと直角部分だけ他の部分よりも極端にパターン幅が大きくなるからです．

この特性インピーダンスの変化をできるだけ抑えるため，45°に2回曲げることによって配線の方向を90°変えることが多いです．

また，本当にノイズを発生させたくない場合は，弧を描くように配線すると良いです．

2.基板外周にGNDビアを打ち，GNDベタで囲う

続いてNucleoの外周をよく見てみましょう．等間隔に点が打ってありませんか？

外周のGNDビア

これは「ビア」といい，基板の表と裏を電気的に繋いでいます．これは何のためにあるのでしょうか．

理論上の回路ではノイズは回路内でしか発生しないはずですが，プリント基板は外部からのノイズも受けます．同様に，外部にノイズを放出することもあります．これらを防ぐために，基板の外周をGNDで囲う必要があります．

Nucleoにも打ってあるように，外周に等間隔でGNDビアを打ち，ベタにしてあげるとノイズ源となることを防げます．

等間隔！ってどのくらいだよ！と思った皆さん．Nucleoの出番ですよ．

Nucleoの外周ビアの間隔を測ってみると，5[mm]間隔で打ってあります．回路の規模にもよりそうですが... マイクロマウスを作るときの参考にしています(これが言いたいがためにこの記事を作ったまである)．

ベタGNDって何？という人はこちらの記事がわかりやすいです．

http://www.noise-counterplan.com/article/15136099.html

両面基板のベタGNDについてはこちら

https://www.noise-counterplan.com/article/15165055.html

3.細長いGNDベタにはビアを打つ/カットする

表面のR32の左側やデバッガの下側を見ると，下図のようにベタが細長くなっている箇所があります．そして，この細長いベタの先端や真ん中にはビアが入っています．

細いGNDベタとビア①

細いGNDベタとビア②

GNDベタは大きいほどいいという訳ではなく，細長いベタはノイズ源にもなり得ます．

そのため，細長いベタにビアを入れてあげるか，表に配線があったり細長すぎてビアを入れられない場合は，細長い箇所をカットしてあげましょう．

図の①ではかなり細いベタが入っていますが，これほど細くしてでも入れているのは，2番で説明した「外周はGNDベタにする」を強く意識しているのではないかなと思います．

※ちなみによくみると裏面にこんな箇所もありますね…大して重要じゃない箇所なのかな…ここら辺はよくわかんないです．

細いGNDベタと…ビアが...ないだと…？

4.GNDビアは適切な量にする

ベタGNDを増やそうとすると，GND線が通っていないスペースにビアを打っていくことになります．このビアは多ければ多いほど良いわけではなく，多すぎると電気特性が劣化していきます．Nucleoは多層基板だと思うので限りなく少ないですが，信号線を挟むようにしてGNDビアを入れているように見えます．これはパターンから他のパターンに信号が漏れないようにするためです(漏れることをクロストークと言います)．

※GNDビアはノイズ対策の色々な目的で使用するため，必ずしも少なければ良いとは限りません．詳しくはこちら．

https://www.atmarkele.com/articles/89

※電源配線で表裏の行き来をさせたい場合は，こちらを参照にしてください．

1A流れる想定では，Φ0.5のビアを3個空ければ良いそうです．(ちなみに電源線の太さは0.1Aあたり0.1[mm]です．)

https://www.noise-counterplan.com/article/14969107.html

5.水晶発振子の下にはパターンを通さない

Nucleoには水晶発振子が2つあり(x1,x2)，下側の方にも1つ後付け(x3)ができるようになっています．この部分をよく見てみると，水晶発振子の足から生えているパターン以外，パターンが1本も通っていないですよね． 

水晶発振子周りの拡大図

このように，水晶発振子の下にはパターンを通さないようにするのが定石です．

水晶発振子の下にパターンを通すと，パターンと水晶発振子の間にクロストークが発生します．

まとめ

Nucleoを舐めまわすように見てきましたが，いかがでしたでしょうか．実際のプリント基板では様々な場所でノイズが発生します．何も考えずに設計をしても上手くいくこともありますが，回路は絶対に合っているのに挙動がおかしい…(マイコンの動作が不安定だったり)，という場合はノイズが原因であることも多いです．

オシロスコープを使用すればノイズの発生源は大体特定できますが，家にオシロスコープがある人もあまり多くないでしょう．ノイズに苦しみたくないなら，最初からノイズ対策を施したプリント基板設計をすべきです．

 次回はIC周辺について触れたいと思います．

ロボット製作のスケジューリング

0.はじめに 

この記事はMicro Mouse Advent Calendar 11日目の記事です． 

目録

※つらつら書いてたらめっちゃ長くなりました．暇なときに見てください…

昨日はぱわぷろ君の今年得た教訓の話 - ぱわぷろ活動日誌という記事でした．この人マウスから身を引くマ？？とか思いながら読みましたが，どうせ彼のことだから来年には何かに取り憑かれたようにマウスもやってるんだろうなぁ．兎にも角にも，道標の開発，お疲れ様でした．卒論ともに頑張ろう．

はじめまして，WMMCの老害B4，まんぼーと申します．

最近はマイクロマウスに一切触れられずに卒論に呑まれていますが，平時は⇩のようなクラシックマウスを作っています．

Mola Tact(2019~)

この子には完走歴はないのでまだマウスではありません．早くマウスにしてあげたい．

ロボットの詳しい紹介についてはまた後日(卒論終わったら)書きたいと思います．

1.スケジューリングが重要ってはなし

今回は完走できてない人がマウスについて語るのもあれなので，大学に入ってから4年間ロボット製作に携わって学んだことのうち，一番大事なことだと思うロボット製作のスケジューリングについて語りたいと思います．

この記事を見ている人の多くはロボットを作ったことがあると思います．

では，ロボットを作るとき，最初に何をしますか？

頭でふわっとしている構想を紙にまとめてみよう！と思ってノートにラフ絵をかいてみる？

作りたいものが思いつかないからインターネットで作りたいロボットを見つける？

それともとりあえず秋葉原に行ってみる？

いや俺はマウスを作るんだから機構を設計をするよ！回路を先に設計するよ！

ロボコンをやる人はルールが発表された瞬間にチームで話し合ったり．

などなど．人や状況によって様々な答えが返ってくると思います．

では，ロボット製作を経験したことのある人は⇩のようなことを経験したことありませんか？

• 途中でやる気が起きなくなり，適当に遊んでいるうちに授業が忙しくなり気づいたら他のことをやっている
• ずっと一人で設計してたアイツが消えたぞ！？
• 気づいたら大会1週間前だ…海外で頼んだ部品まだ届かない…
• ロボット作るの遅すぎて調整不足だ！

ない人は凄いですが，多くの人はこれに似たようなことを経験した(もしくは知人が経験していた)ことがあると思います．

こうならないように，ロボット開発をするときは何よりも始めに「適切な」スケジュールを立てることが重要になります．

2.「適切な」スケジュールとは

当たり前ですが，わざわざ「適切な」という言葉を強調しているのは，無理なスケジュールを立てても実現不可能だからです．

例えば，大会1か月前にこのロボットは機能不足だ！マイコンのピン全部使っちゃったし使っているマイコンを変えよう！と思って大会に間に合うでしょうか？

正直強い人はギリギリできるかもしれません．ですが，ロボット製作歴が浅い人には到底無理だと思います．なぜ無理なのか？

マイコンを変えようとしたときにやるタスクはおおざっぱに以下の通りです．

マイコンを変えたいときのフロー

マイコンに関する知識を多少持った人目線に立って書いてみましたが，日数はかなりテキトーです．これもっとかかるやろとかいうのたくさんありますが目を伏せてください．もちろん，一概にマイコンを変えると言って，Renesas製からSTMicro製に変えるのと，STMから違うSTMに変えるのではかかる時間が桁違いに変わりますし，マイコンプログラミングをどの程度やったことがあるかによっても時間はかなり変わります．

言いたいのは，マイコンを変えるという一見簡単そうなことをするだけでこんなにも時間がかかるということです．大会1か月前にこれをやる！と言い出したら上級生は全力で止めにかかります．

このように，大会等といった期日のあるロボット開発中に，これをいつまでにやりたい！となった時，いつまでにできるだろうという憶測を立てないと破綻します(ロボットに限りませんが)．逆に言えば，期日から逆算する能力があればいつから始めれば物事が間に合うかどうかがわかるわけです．

というわけで，私は

　　　スケジューリング能力＝逆算能力

かなぁと思ってます．

適切な逆算能力を持つためには，ロボットを1から作るときの流れを知ることが大事です．次の章で見ていきましょう．

3.ロボット開発のフロー

早稲田大学理工学術院創造理工学部総合機械工学科(長い)ではデザインエンジニアリングという授業で機械設計に関するフローを学びますが，それのロボット製作版です．

ロボットを開発する際にしなければいけないことは大きく分けて

• マシン設計

• 回路設計

• プログラム(ソフト)

 の3つです．

設計の流れとかかる時間に焦点を当てながら説明したいと思います． 

3.1 マシン設計フロー

マウスなどの目的が明確なロボットの設計ではここまで面倒な段階を踏むことはないですが，自分でロボットを作ったり研究したりするときはそうはいきません．知っておきましょう．

※ロボットのサイズと複雑さによってマシン設計に必要な時間はめちゃくちゃ変わるので，時間は最低でもこんなにかかるんだくらいに思ってください．

マシン設計フロー

1.要求仕様の決定

ロボットを作るときには要求仕様(マイクロマウスなら迷路1区間以内に収まること)を決定することがマストです．これをなくしていきなり詳細設計に入ろうとすると，どんなサイズで作ればいいのかわからなくなり，いざ加工しようとしたときに思ったサイズとちがう！とかが起きます．さすがにサイズを決めずに加工し始めようとする人はいないと思いますが，サイズを決め直してCADをいじり直すという2度手間は避けたいですよね．

3.モータ選定

ロボットの性能のほとんどを決めるのがモータ選定です．

モータ選定を詳細設計より前に行う(※今回は3DCADでの設計のことを詳細設計と言ってますが，厳密にはモータ選定も詳細設計に含まれる)のはモータの納期が長いからです．特に性能が良いことで有名なMaxonモータはスイスから取り寄せをするため，在庫があっても3週間，なければ1～2カ月かかります．クラシックマウスで多くの人が使っているFAULHABER製モータは新光電子で買うと1か月近くの納期を必要とします．

モータの発注が遅くなると納期に間に合わない！現象に陥るため，なんとしても早く発注しなければなりません．

4.詳細設計

マシン製作では詳細設計が一番時間かかります．

とはいってもマウスは他のロボコン等と比べてここのウエイトはかなり軽いです．マウスはマシン面では足回り＋筐体＋吸引ファンの設計くらいしかないので(他にあったらごめんなさい)，設計に関して何も知らない状態でも，他人のブログを見ながら設計すれば1か月あれば終わると思います．

設計ミスがあったら，改良を加えて＋1か月くらいでしょうか．

※マウスでは当たり前の話ですが，回路基板をロボットの内部に入れる場合は，基板を置くスペース考慮して設計を行いましょう．作った後に基板どこ置く？なんて考え始めるのは愚かです．同様に，回路素子と筐体が干渉したぁとかいうのも愚かです(ブーメラン2回目)．

雑談：

私は普段3DCADにSolidworksを使用していますが，基板が筐体になっているマイクロマウスでは， Fusion360をEagleと連携させることで部品の干渉等をチェックできる上，学生は3年間(中途半端…)無料なのでこちらがおすすめです(詳しくは⇩のブログ)．

kt33.hatenablog.com

3.2 回路設計フロー 

続いては回路設計の流れです．

回路設計フロー

なんかこう見るとめっちゃ簡単そうに見えますが，つまずく箇所はたくさんあります．

データシートの読み方，Eagleの使い方，ノイズ対策…全部学びながら設計するとなんやかんや1カ月は使いそうです．ミスの粗探しをしてもミスは見つかる物なので，周りに頼れる人がいたら見てもらうことをお勧めします．初めて作る基板を早く欲しいばかりにミス探しを疎かにすると，最悪何もできない基板が届き虚無になるだけです．

基板発注してから届くまでの時間は発注先によって様々です．Elecrowだと通常2～3週間，PCBGOGOだと最短1週間くらいで届くみたいです．どこがいいかについては他のブログを漁って考えてみてください．

ミスがあったとして，2回くらい発注したら2か月弱過ぎ去ります．

3.3 ソフト開発フロー

最後にソフト開発の流れを見てみましょう．

ソフト開発フロー

こちらはマイクロマウスに特化して書きましたが，マイクロマウスではソフト開発にかかる時間が一番長いと思います．そもそもプログラミングを書けない人は学ぶ時間も発生するので，とにかくめちゃくちゃ時間がかかります．全くの初心者が1から書くとなると，1年以上はかかると思います．1回完成すれば流用できるんですが(クソプログラムを生み出してしまった場合はもう一回書き直せるドン)．

3.4 フローまとめ

おおまかにそれぞれの開発の流れをみてきました．

開発するロボット，知識量によってはどこかで無限ループがあったりします．僕の卒論はハード開発の無限ループを起こしています．

これらを1人で行うのははっきり言って神の為す業です．全部ひとりでやれる人はすごい．

マイクロマウスサイズですらかなり大変なので，少しでも大きくなると一人でやるのは無理があります．そのため，大型の機体を作るロボコンチームは大体がハード屋さんとソフト屋さんに分かれてやります．

3.5 それぞれのフローの進め方

話を戻しますが，3つのフローを順番に消化したらとてつもない時間が必要になります．

では，それぞれのフローをどのように進めていくか．

仮にロボット開発を4月にスタートして，9月にある大会に間に合わせたいとします．

マイクロマウスに絞って考えていくと，こんな感じかなぁと思います． (※人によって進め方は多少違うと思いますが，一例です)

4月から開発を始めた場合の開発フロー

どうでしょうか？できそうですか？

超強い人は「余裕」とか言いそうですが．

もしくは，回路図・ソフトはもらったからあるという人(WMMCの新人教育を受けた人)ならこの期間でもどうにかなります．

しかし，マシン設計・回路設計に関しての知識が少なくて，１からプログラムを書かなければならない人が1人でやると，当然どこかでうまくいかなくなり間に合いません． 経験者でも設計にミスが生じたら，間に合ってもギリギリ・調整不足になると思います．

ではいつからやれば間に合うか．

正直知識と経験の量・聞ける先輩がいるかどうかによってかなり差が出てくると思います．

参考までに私がMola Tactを開発したときに立てた開発フローを載せておきます．

＜進め方に関する補足＞

• 最初はマシン設計で寸法を決めた後回路設計を行った．基板上に部品を配置する前に穴の位置を決定するのが好ましい
• 発注の合間を縫って他の事をやるというイメージ．動作確認などすぐにできるものは隙間時間に済ませる

 ＜ついでに1年間を振り返ってみる＞

卒論というおもりがあることを考慮してオフシーズンになった瞬間に始めましたが，これでも間に合うかどうかわからないスケジューリングでした．

これを見るとずっとわりとマウスやってるように見えますが，3月末から卒論がスタートしてるので，土日とマウスをやりたい気分の日だけ開発するといった感じです．

WMMCのプログラム(標準プログラムと呼ばれている)を捨てて(※探索法を除く)1から書き直したおかげでかなり時間を吸われましたが，シーズンオフになってわりとすぐ始めたおかげで東日本大会で走る状態になりました(※なお完走はしていない模様)．

研究室配属前はもっと時間を割けるはずなので，同様のスケジュールでもうまくいくかもしれないです(※十分な知識を持った先輩にある程度頼ることは必須)．

あとは自分が持っている知識量・実装能力を考慮して，自分なりのスケジュールを立ててみましょう．

(プログラムを大して書いたことがないけど1からプログラムを書きたい！という場合は倍以上の時間がかかると思います)

 4.スケジューリングで特に注意すべきこと

4.1 試行錯誤が必要な場合

マシン設計には試行錯誤が必要な場合があります．

試行錯誤が必要な例→

• 物を掴んだり投げたりするための機構が重要になるロボット
• 一部の研究(ソフトロボットなど)

こういったロボットを設計する場合，複数回の試行錯誤をして初めてうまくいくケースがあります．複数人で設計する場合は分担して設計→評価することができますが(そうすると選ばれず失職する者が現れる闇があったりする)，1人 or 少人数で開発を行う場合，試行錯誤に必要なサイクルを把握する必要があります．

設計サイクルは設計するサイズと人(やる気と充てられる時間)に大きく依存しますが，1つの機構を設計して実験まで済ませるのにかかる時間は2~3カ月くらいと見積もっています．

これを始めにすることで納期までに何回試行錯誤ができるかがイメージでき，開発スパンの目安になります．

試行錯誤をする際に最も気を付けなければいけないのは，

「切り捨てられる機構を見極める」

ことです．いくら試行錯誤が重要な開発をやっていたとしても，最初から悪い結果が想定できるロボットを開発していては時間の無駄です．

4.2 開発における外乱

外乱？スケジューリングについて話してるのにいきなりどうした？と思うかもしれませんが，

　ロボット開発における外乱 ＝ 開発の妨げになる要因

です．

この外乱を2種類に分けると，

• 予測できる外乱　　　

　　↪予め日程の決まっているレポート(実験や製図など)・中間発表・期末考査・ゲーム発売日

• 予測できない外乱

　　↪いきなりやってこいと言われた大量のレポート・入院

に分けられます．後者はどうしようもないので余裕を持って開発しましょうとしか言えないのですが，前者はスケジュール上で必ず考慮しなければいけません．

特に期末考査は，正常な人間なら1～3週間勉強に時間が取られるので，この期間は空白としてスケジュールを組みましょう．

5.スケジューリングを実行するために

スケジューリングを立てたとして，そのスケジュール通りにやるにはどうするの？
 

答えは根性です．

は？って思うかもしれないですが，人間は弱い生き物なので，根気がないと辛くなった瞬間に逃げ出します．なので，スケジューリングを立てた後は根性でやり遂げるしかないです．

 ※補足：他人に自分の根性を押し付けるのはダメです

ただし，モチベーションを保てば継続できると思います．

モチベーションの保ち方は以下の通りです．

• マウスの大会やプチ大会で行われる懇親会に参加する

• 目標となる人を見つける

• サークル内or他校のライバルと競い合う

→私は同時期にDCマウスの開発をしていた東京理科大学MiceのMakotoさんやふくだくんを勝手にライバルにしてました．向こうの方がどうみても強いんだけど，強い人をライバルとすることで得られることは腐るほどあります．進捗勝負も負けましたが，いつか同じスピードで戦いたいです．

• 選ばれし者しか出れない大会(＝全日本大会)に出るという目標を立てる

→大会があるロボットを作るならこれが一番のモチベーションになると思います．

• リーダー・教授に急かされる

→チームで開発する際はこれが一番効きますが，圧が強いと逃げ出す可能性もあります．

自分がリーダーの場合は優しくいたぶろうね☆

6.まとめ

ロボット製作のスケジューリングについて，たらたらと書いてきましたが，まとめです．

1. スケジューリング能力＝逆算能力
2. 自分の知識量・実装能力を考慮しよう
3. 外乱を考慮したスケジューリングをしよう
4. スケジューリングを立てた後は根性でこなそう

長くなりましたが，少しでもロボット製作の参考になれば幸いです．

「俺は大丈夫」って思ったそこの1・2年生，本当ですか？(煽)  ロボット製作を何回かやったことがあっても，スケジュール管理(とメンタル・モチベーション維持)ができなくなった瞬間に破綻します．卒論やってても結構そういう人がいる印象を受けます．

最後に，今年は行けなかったですが，全日本大会に参加した皆さんお疲れ様でした．

来年は参戦したいです．

＜以下WMMCの後輩向け＞

今年うまくいって来年DCマウスを作りたい人は，今からでも新機体を作りましょう．

※その前にちゃんとスケジュールを立てましょう．

間違ってもB4(特に「ぐでたまうす」の飼い主)の開発スピードは参考にしちゃいけないです．積み重なった知識があるからこそ成せる業です．