マイクロマウスのソフト設計の話　その2

2020年6月7日

こんにちは。そらです。

マイクロマウスのソフト設計の話ということで、今回はマイクロマウスのソフトウェアの要求定義、要件定義をしていきたいと思います。ここを適当にして進めてしまうと後からこの機能が～となったときに訂正が大変になることが考えられるためです。ソフトウェア設計では一番大切な場所になるのでしょうか？本当に必要な機能は何なのだろうかというところをしっかりとピックアップしていきます。

前回の記事で紹介が忘れていましたが、ここから先はV字モデルの流れで進んでいくと思います。V字モデルについては調べていただければと思います。簡単流れを説明すると、要求定義→基本設計→実装→テストして最初の要求に即しているかどうかをチェックをしていく形になります。

ここから先の流れは色々な手法があると思うので、参考程度にしていただけると助かります。




マイクロマウスのソフトウェアにおける要求定義/要件定義

要求定義をしてみる

まずは、マイクロマウスでやりたいことを書いていきます。

  • マイクロマウスの大会のルールに基づいた迷路を自律制御をしながらゴールまでにたどり着くようにしたい。
  • 迷路の情報を集めたい。
  • 最短走行の経路を導出して、走行のパラメータの設定をしたい。
  • 最短走行では斜め走行をしたい。
  • 操作者から、走行前に命令を与えられるようにしたい。
  • 操作者にマシンがどの処理をするケースなのかを可視化してわかるようにしたい。
  • おかしくなったときに、マシンが判断して停止したい。
  • 電池の電圧がおかしいときは動いてはいけない。
  • 集めた迷路情報を可視化したい。
  • 宴会芸1がしたい。
  • 各種センサの値を可視化したい。
  • 上位陣と張り合えるようになりたい。

私が必要だと思ったことは以上のことです。マイクロマウスの設計の時点で決めておく必要があることもあると思われますが、今回はあくまでソフトウェアのところにだけ触れるようにしました。横線を引いたところは、ソフトも重要ですがハードウェアにも依存するためです。コンテストに参加する人は、目標として上位を目指す方が多いかなと思ってかきました。

要件定義をしてみる

要求定義ではできるだけソフトウェアの話を基本的にしていましたが、要件定義ではハードウェア情報も必要になります。今回の想定するハードウェアはマイクロマウス(旧ハーフサイズ)設計まとめ(2020年)で紹介したマシンとします。

上記の記事に書かれていないユーザーインターフェース(UI)については以下に書いた通りです。

  • タクトスイッチ1つ
  • LED　6個(前方に3つ、後方に3つ)

システムに対して求めるものを上げていきます。

  • RAMメモリの使用量はMCU(STM32F411CEU6)の128[Kbyte]の限界までは使用してはいけない。
  • 迷路探索のアルゴリズムはリアルタイムで計算できる必要がある。
  • 経路設計をして目標値の生成をする必要がある。
  • センサの情報やUIはMCUで取得、操作することができる。
  • リアルタイムで制御が行われる必要がある。
  • モーターの出力はMCUで制御できていること。回してはいけないときに回りださないようになっていること。
  • 電圧監視や異常動作をしていないかどうかを常に監視している。
  • マシンのモード遷移の中で無限ループ等でメインルーチンに戻ってこれないようなことにはなってはいけない。
  • 目標値に追従する必要がある。

こんなところでしょうか。書き出し忘れ等があるよという指摘があればTwitterやコメントでしていただけると助かります。

基本設計をしていく

要素抽出をする

要求・要件定義でした内容から大まかな要素を抽出していきます。細かい要素に関しては、大きい要素を抽出した後にそれぞれの要素の中で考えていくものとします。

要求定義、要件定義ででてきた内容で大まかにわけると、迷路アルゴリズム(探索、最短経路導出問題等)、制御(目標値設定、目標値追従等)関連、センサの取得、UIの操作(MCUの周辺機能)、ハードウェアの制御、処理の統括に分けてみます。センサの取得等の処理と、ハードウェアの制御、処理の統括に関しては近いものではありますが別のものであると考えました。センサの取得等は瞬間的に行うものですが、ハードウェアの制御、処理の統括は常に行う必要があるものであり違いがあると考えたためです。

これらの4つをパッケージとしてそれぞれの相関関係を図で表してみたいと思います。

 

ハードウェアの制御、処理の統括と3つの機能に関しては相関関係がありそうということがわかりました。他の機能はハードウェアの制御、処理の統括を経由することでそれぞれ独立にすることができそうだということがわかりました。

要求・要件定義とずれがないかチェックする

各自でやってみてください。足りないと思った場合は別途考え直す必要があります。ここをないがしろにすると後でしんどいことになります。

気がかりはハードウェアの制御、処理の統括が少し大きいパッケージになってしまっていることだと思います。ただ、パッケージはでかくても処理の内部を小さくまとめていけばいいと考えているためこのままいきます。

おわりに

今回は要求・要件定義をした後に基本設計をしました。基本設計に関してですが操作者一人がロボットのシステムにアクセス、ロボットはシステム内で基本的に完結しているためユースケース図は書いても意味がないかなと思い書きませんでした。

次回予告

詳細設計をやっていきたいと考えています。アクティビティ図とかを書いてマシンの処理の流れを確認する予定です。

  1. 速度0、角速度0としてPID制御をするもの。