狠狠撸

狠狠撸Share a Scribd company logo

厂测蝉惭尝実习20220822厂颁冲骋础.辫诲蹿

?
?
O
openrtm

RTミドルウエア SUMMER CAMP 2022 SysML実習

1 of 10
Download to read offline
RTミドルウェア SUMMER CAMP 2022 SysML実習 日時：2022年8月22日(月) 14:30～ 株式会社 グローバルアシスト 坂本 武志
2022.8.22 Copyright (C) GLOBAL ASSIST Co., Ltd., All Rights Reserved. 2 本実習の目的 ? サマーキャンプを通して開発を行う対象システムの明確化 ? 設計を行うのであれば，その場限りの独自記法で検討を行うのではなく，標 準となっている記法で検討を行って欲しい ? 開発したRTコンポーネント公開時に，設計情報も併せて公開して欲しい ? 後からRTコンポーネントを利用する人のため ? サマーキャンプでモデリングを行っている理由 ? 開発内容の説明 ? どのようなシステムを開発するのか？何が特徴なのか？など ? チーム内での意思統一，進捗管理 ? 何を開発するのか？どう実装するのか？など ? どこまで開発できているのか？
2022.8.22 3 要求図 ? 性能なども含めたシステムが満たすべき項目を表現 req [model] 移動ロボッ ト [移動ロボ ット(自律 移動)] <<requirement>> 自律移 動 id = text = "ユーザが指定した 目的地まで，安全に移動で きること" <<requirement>> 障害 物回避 id = text = "ロボット周辺の障害 物を回避できること" <<requirement>> 経路生 成 id = text = "目的地までの移動 経路を自動で生成できるこ と" <<requirement>> 移動 id = text = "移動指令に従って 移動すること" <<requirement>> 自己位置 推定 id = text = "ロボット自身の現在 位置を推定できること" <<requirement>> 環境地 図 id = text = "周辺環境の地図を 持つこと" <<requirement>> 環 境地図マッ チング id = text = "周辺環境の地図と 外界計測センサの計測結 果からマッチングを行うこと" <<requirement>> デッド レコニング id = text = "内界センサの計測 値を基に，自分の位置を推 定できること" <<requirement>> 内 界センサ id = text = "ロボットの相対的な 移動量を計測できること" <<requirement>> 周 辺環境情報 の計測 id = text = "ロボット周辺の環境情 報を計測できること" <<requirement>> 移動時 間 id = text = "なるべく短い時間で 目的地まで到達できること" <<requirement>> 連続 移動可能 距離 id = text = "なるべく長距離を移 動可能であること" <<requirement>> 低 消費電力 化 id = text = "消費電力をなるべ く下げること" <<requirement>> 環境地図 自動生成 id = text = "周辺環境の地図を自 動的に生成できること" <<requirement>> ユーザビリ ティの向上 id = text = "使用時のユーザの負 担をなるべく軽減すること" <<requirement>> 地図精度の 向上 id = text = "なるべく高精度な地 図を生成できること" <<requirement>> パター ン移動 id = text = "指定されたパターン に従って移動できること" <<requirement>> 効率的な 自律移動 id = text = "ユーザが指定した目的地ま で，なるべく短時間で安全に移動で きるとともに，ユーザの手間をなるべく 軽減しつつ，長距離を移動可能であ ること" <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>>
2022.8.22 4 要求図 ? 目的 ? 開発対象システムの説明 ? どのような機能，特徴を持ったシステムを構築するのか？ ? 開発時の進捗管理 ? どこまで実現できているのか？を確認 ? 開発時の代替案の検討 ? 作成手順 ? ?何を?実現するシステムなのか？を検討 ? それぞれの要求を実現するためには，?何を?行わないといけないのか？を検討 ※要求図では，具体的な実現手段は記述しないため，?どのように?実現するかの詳細は 初期段階では気にしない
2022.8.22 5 内部ブロック図 ? システム構成要素間の接続関係を明確にする ? 構成要素間でやりとりする内容を明確にする ? システムを構成する要素間でやり取りする内容を表現 ib d [Pack ag e] 移動ロボッ ト [移動ロボッ トシス テ ム(SW)] : ~レンジデータ : ~深度画像 : 周 辺環境 計測 : ~レンジデータ : ~深度画像 : ~レンジデータ : 測 域センサ制御 [0..1] : ~レンジデータ : ~深度画像 : 距離 画像 センサ制 御[0..1] : ~深度画像 : レンジデータ : 深度画像 目標位置: 位置 移動指令: ~速度 : 障害 物回避 : レンジデータ : 深度画像 目標位置: 位置 移動指令: ~速度 : レンジデータ : 深度画像 現在位置: 位置 移動指令: ~速度 : 地図 生成 : レンジデータ : 深度画像 現在位置: 位置 移動指令: ~速度 : レンジデータ : 深度画像 現在位置: ~位置 : 移動量 : 自 己位置 推定 : レンジデータ : 深度画像 現在位置: ~位置 : 移動量 現在位置: 位置 目標位置: ~位置 : 経 路生 成 現在位置: 位置 目標位置: ~位置 移動指令: 速度 : ~移動量 : 移 動制 御 移動指令: 速度 : ~移動量 目的地を設定する
2022.8.22 6 内部ブロック図 ? RTSystemEditorで構築したシステム情報とほぼ同じ内容を表現 RTC データポート(Out) データポート(In) サービスポート ：ブロックR name : BlockType : Type プロパティ ポート ポート インターフェース プロパティ OpenRTM-aist SysML RTコンポーネント プロパティ(ブロック) データポート ポート(連続型) サービスポート ポート(離散型) サービスインターフェース インターフェース
2022.8.22 7 内部ブロック図 ? 作成手順 ? 使用するハードウェアの検討 ? どの機材を利用するのか？不足している機材は何なのか？ ? 必要な機能の検討 ? どのようなRTCで構成するか？ ? RTCを新規開発するのか？既存のRTCを再利用するのか？ ? RTC間のインタラクションの検討 ? RTC間でやり取りするデータ，コマンドの検討 ? 各データ型，インターフェースの明確化 ? 検討事項 ? 必須機能の判断 ? 最低限どの機能が必要なのか？ ? 優先順位の決定 ? どのRTCから開発を行うのか？ ? 開発工数の見積もり ? 各機能を開発するのに必要な工数はどの程度か？ ? 作業分担の検討 ? 誰がどのRTCを開発するのか？
2022.8.22 8 設計時の注意点 ? 使用する用語の意味を統一 同じ概念を表現する用語は１つに統一する １つの用語で表現する概念は１つに統一する 一般的な用語ほど，誤解を発生しやすい ? 代替案の検討 ? 必須機能とオプション機能の検討 ?初期段階では，どうしても多機能，複雑なシステム構成としがちなため ?各RTCの粒度(機能)をあまり大きくしすぎない ? 再利用RTCの検討 ? 開発工数を下げるため，既存のRTCで使えるものがないか検討 ?再利用可能かどうかを検証するのにも時間が掛かってしまう場合がある ?使用する環境，インターフェース(データ型，操作の詳細)が合致している か確認
2022.8.22 9 設計時の注意点 ? 作業工数の見積もり ? 担当者を決める前に，全員で各RTC，各機能の開発時間の見積もりを行う ? 今回は期間が１週間と短いため，時間単位での見積もりを行う ? 全員で各RTC，各機能について，作業時間の見積もりを行う ?(以下は見積もり方法の参考) ?最初は必須機能のみを対象にして見積もりを行う ?1,2,5,10の数字のみ用いて，各人が考える作業工数を出し，単純にそれらの 数の平均値を見積もり工数とする ?この段階で，細かい検討を行ってもあまり意味がないので，各人の見積 もりは大ざっぱな数値を使用 ?この際，なるべく見積もり工数がなるべく小さくなる単位まで機能を分解する ?見積もり工数が大きい項目が出た場合，作業を更に細分化できないか 検討する ?実際に開発にかかった時間を計測しておき，見積もり値との差異を記録する ?この差異を元に，何度か再見積を行う ?工数の見積もりは，個人によって傾向が異なる．自分自身の傾向を把握 し，見積もりの精度を向上させることが重要
2022.8.22 10 設計時の注意点 ? 作業スケジュールの検討 ? 各機能の担当者の決定 ? 上記で作成した見積もり工数を参考に，期間内に作業が終わるか？を確認 ? サマーキャンプ期間中に開発可能な時間数： ?8/22(月) 2h,23(火) 4h(+4h),24(水) 6.5h(+5h),25(木) 6.5h(+5h),26(金) 6h ?計：25h (39h)/人 ? もしも工数的に終わらないのであれば，そもそものスケジュールに無理がある ? 各機能の開発順番の決定 ? マイルストーンの検討 ? 複数RTCを用いた結合試験のタイミングなど ? 検討結果を基に，２日目15:00から，今回開発するシステムを発表し て頂きます

More Related Content

厂测蝉惭尝実习20220822厂颁冲骋础.辫诲蹿

  • 1. RTミドルウェア SUMMER CAMP 2022 SysML実習 日時：2022年8月22日(月) 14:30～ 株式会社 グローバルアシスト 坂本 武志
  • 2. 2022.8.22 Copyright (C) GLOBAL ASSIST Co., Ltd., All Rights Reserved. 2 本実習の目的 ? サマーキャンプを通して開発を行う対象システムの明確化 ? 設計を行うのであれば，その場限りの独自記法で検討を行うのではなく，標 準となっている記法で検討を行って欲しい ? 開発したRTコンポーネント公開時に，設計情報も併せて公開して欲しい ? 後からRTコンポーネントを利用する人のため ? サマーキャンプでモデリングを行っている理由 ? 開発内容の説明 ? どのようなシステムを開発するのか？何が特徴なのか？など ? チーム内での意思統一，進捗管理 ? 何を開発するのか？どう実装するのか？など ? どこまで開発できているのか？
  • 3. 2022.8.22 3 要求図 ? 性能なども含めたシステムが満たすべき項目を表現 req [model] 移動ロボッ ト [移動ロボ ット(自律 移動)] <<requirement>> 自律移 動 id = text = "ユーザが指定した 目的地まで，安全に移動で きること" <<requirement>> 障害 物回避 id = text = "ロボット周辺の障害 物を回避できること" <<requirement>> 経路生 成 id = text = "目的地までの移動 経路を自動で生成できるこ と" <<requirement>> 移動 id = text = "移動指令に従って 移動すること" <<requirement>> 自己位置 推定 id = text = "ロボット自身の現在 位置を推定できること" <<requirement>> 環境地 図 id = text = "周辺環境の地図を 持つこと" <<requirement>> 環 境地図マッ チング id = text = "周辺環境の地図と 外界計測センサの計測結 果からマッチングを行うこと" <<requirement>> デッド レコニング id = text = "内界センサの計測 値を基に，自分の位置を推 定できること" <<requirement>> 内 界センサ id = text = "ロボットの相対的な 移動量を計測できること" <<requirement>> 周 辺環境情報 の計測 id = text = "ロボット周辺の環境情 報を計測できること" <<requirement>> 移動時 間 id = text = "なるべく短い時間で 目的地まで到達できること" <<requirement>> 連続 移動可能 距離 id = text = "なるべく長距離を移 動可能であること" <<requirement>> 低 消費電力 化 id = text = "消費電力をなるべ く下げること" <<requirement>> 環境地図 自動生成 id = text = "周辺環境の地図を自 動的に生成できること" <<requirement>> ユーザビリ ティの向上 id = text = "使用時のユーザの負 担をなるべく軽減すること" <<requirement>> 地図精度の 向上 id = text = "なるべく高精度な地 図を生成できること" <<requirement>> パター ン移動 id = text = "指定されたパターン に従って移動できること" <<requirement>> 効率的な 自律移動 id = text = "ユーザが指定した目的地ま で，なるべく短時間で安全に移動で きるとともに，ユーザの手間をなるべく 軽減しつつ，長距離を移動可能であ ること" <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>> <<deriveReqt>>
  • 4. 2022.8.22 4 要求図 ? 目的 ? 開発対象システムの説明 ? どのような機能，特徴を持ったシステムを構築するのか？ ? 開発時の進捗管理 ? どこまで実現できているのか？を確認 ? 開発時の代替案の検討 ? 作成手順 ? ?何を?実現するシステムなのか？を検討 ? それぞれの要求を実現するためには，?何を?行わないといけないのか？を検討 ※要求図では，具体的な実現手段は記述しないため，?どのように?実現するかの詳細は 初期段階では気にしない
  • 5. 2022.8.22 5 内部ブロック図 ? システム構成要素間の接続関係を明確にする ? 構成要素間でやりとりする内容を明確にする ? システムを構成する要素間でやり取りする内容を表現 ib d [Pack ag e] 移動ロボッ ト [移動ロボッ トシス テ ム(SW)] : ~レンジデータ : ~深度画像 : 周 辺環境 計測 : ~レンジデータ : ~深度画像 : ~レンジデータ : 測 域センサ制御 [0..1] : ~レンジデータ : ~深度画像 : 距離 画像 センサ制 御[0..1] : ~深度画像 : レンジデータ : 深度画像 目標位置: 位置 移動指令: ~速度 : 障害 物回避 : レンジデータ : 深度画像 目標位置: 位置 移動指令: ~速度 : レンジデータ : 深度画像 現在位置: 位置 移動指令: ~速度 : 地図 生成 : レンジデータ : 深度画像 現在位置: 位置 移動指令: ~速度 : レンジデータ : 深度画像 現在位置: ~位置 : 移動量 : 自 己位置 推定 : レンジデータ : 深度画像 現在位置: ~位置 : 移動量 現在位置: 位置 目標位置: ~位置 : 経 路生 成 現在位置: 位置 目標位置: ~位置 移動指令: 速度 : ~移動量 : 移 動制 御 移動指令: 速度 : ~移動量 目的地を設定する
  • 6. 2022.8.22 6 内部ブロック図 ? RTSystemEditorで構築したシステム情報とほぼ同じ内容を表現 RTC データポート(Out) データポート(In) サービスポート ：ブロックR name : BlockType : Type プロパティ ポート ポート インターフェース プロパティ OpenRTM-aist SysML RTコンポーネント プロパティ(ブロック) データポート ポート(連続型) サービスポート ポート(離散型) サービスインターフェース インターフェース
  • 7. 2022.8.22 7 内部ブロック図 ? 作成手順 ? 使用するハードウェアの検討 ? どの機材を利用するのか？不足している機材は何なのか？ ? 必要な機能の検討 ? どのようなRTCで構成するか？ ? RTCを新規開発するのか？既存のRTCを再利用するのか？ ? RTC間のインタラクションの検討 ? RTC間でやり取りするデータ，コマンドの検討 ? 各データ型，インターフェースの明確化 ? 検討事項 ? 必須機能の判断 ? 最低限どの機能が必要なのか？ ? 優先順位の決定 ? どのRTCから開発を行うのか？ ? 開発工数の見積もり ? 各機能を開発するのに必要な工数はどの程度か？ ? 作業分担の検討 ? 誰がどのRTCを開発するのか？
  • 8. 2022.8.22 8 設計時の注意点 ? 使用する用語の意味を統一 同じ概念を表現する用語は１つに統一する １つの用語で表現する概念は１つに統一する 一般的な用語ほど，誤解を発生しやすい ? 代替案の検討 ? 必須機能とオプション機能の検討 ?初期段階では，どうしても多機能，複雑なシステム構成としがちなため ?各RTCの粒度(機能)をあまり大きくしすぎない ? 再利用RTCの検討 ? 開発工数を下げるため，既存のRTCで使えるものがないか検討 ?再利用可能かどうかを検証するのにも時間が掛かってしまう場合がある ?使用する環境，インターフェース(データ型，操作の詳細)が合致している か確認
  • 9. 2022.8.22 9 設計時の注意点 ? 作業工数の見積もり ? 担当者を決める前に，全員で各RTC，各機能の開発時間の見積もりを行う ? 今回は期間が１週間と短いため，時間単位での見積もりを行う ? 全員で各RTC，各機能について，作業時間の見積もりを行う ?(以下は見積もり方法の参考) ?最初は必須機能のみを対象にして見積もりを行う ?1,2,5,10の数字のみ用いて，各人が考える作業工数を出し，単純にそれらの 数の平均値を見積もり工数とする ?この段階で，細かい検討を行ってもあまり意味がないので，各人の見積 もりは大ざっぱな数値を使用 ?この際，なるべく見積もり工数がなるべく小さくなる単位まで機能を分解する ?見積もり工数が大きい項目が出た場合，作業を更に細分化できないか 検討する ?実際に開発にかかった時間を計測しておき，見積もり値との差異を記録する ?この差異を元に，何度か再見積を行う ?工数の見積もりは，個人によって傾向が異なる．自分自身の傾向を把握 し，見積もりの精度を向上させることが重要
  • 10. 2022.8.22 10 設計時の注意点 ? 作業スケジュールの検討 ? 各機能の担当者の決定 ? 上記で作成した見積もり工数を参考に，期間内に作業が終わるか？を確認 ? サマーキャンプ期間中に開発可能な時間数： ?8/22(月) 2h,23(火) 4h(+4h),24(水) 6.5h(+5h),25(木) 6.5h(+5h),26(金) 6h ?計：25h (39h)/人 ? もしも工数的に終わらないのであれば，そもそものスケジュールに無理がある ? 各機能の開発順番の決定 ? マイルストーンの検討 ? 複数RTCを用いた結合試験のタイミングなど ? 検討結果を基に，２日目15:00から，今回開発するシステムを発表し て頂きます