Feedback 2017-11-06 Comments for Task 10 (PDR)

Dear Team I: Moon Wreckers,

Below are grades and comments for Task 10 (PDR)

Team I:

Score: 18.61/20

Comments:

Deductions:
2. Use case/System graphical representation 0.01
3. System-level requirements 0.11
4. Functional architecture 0.06
5. Cyberphysical architecture 0.03
6. Subsystem descriptions 0.63
7. Current system status 0.21
8a. Project management: Work Breakdown Structure 0.02
8b. Project management: Schedule 0.01
8c. Project management: High-level test plan 0.23
8e. Project management: Risk management 0.05
9b. Intelligibility, flow, demeanor, audience connection 0.03
Total deductions: 1.39

J. Dolan comments:
Proj descr: Distributed mapping element was a surprise – is this really crucial for your team?
Use case: Nice video.
Subsys descr: Where is overall system depiction? VIVE video is good. Path Planning slide has too-small fonts to see well. Generally good use of figures to illustrate concepts/progress.
Budget: Is your budget $10K because Red is giving you $5K?
Dan: Don’t cross your arms when presenting (-0.2).

Y. Nadaraajan comments:
Are you doing the mapping system as well? Do you really need a RTK GPS? Good risk list but did you consider hardware risks?

A. Sidhu comments:
Have you done some investigation on how rovers ( or AGVs) get stuck? In what configuration or failure mode is your method of rescue best? In what failure mode is it not optimal and how can that be improved via additional software, sensing capability, hardware capabilitiy?

D. Apostolopoulos comments:
(A fair number of comments are similar or the same to those provided for Assignment #2 of 16-650)
Page 4 – Be specific about mapping; mapping of the area around an entrapped rover or broad mapping?
Page 10 – Non-functional requirement #1 and #2 should be functional
Page 10 – Non-functional #3 is not a requirement; it sets an objective that would help define a performance target for functional #2
Page 11 – Performance requirements should be an one-to-one match to functional requirements. For example based on the specifics about rover alignment in performance requirement #2 you should have a functional requirement of the form:
“Rover 1 shall align with Rover 2”
Page 11 – Performance requirement #3 – “Mark” as in physically mark or digitally mark?
Page 11 – Non-functional – see comments above
Page 13 – Revised FA – What do the 2 inputs connect to? For example, is the initial low-res map used in localization and mapping?
Page 13 – Revised FA – Are the same sensors used both for state estimation and mapping? Ok the cyberphysical architecture details
Page 15 – Revised CyPA – The big block on Sensor Fusion actually does 2 things; pose estimation and sensing for mapping
Page 15 – Revised CyPA – A localization block is missing (mapping+pose estimation+sensing) Which sensor(s) do you use for localization?
Page 15 – Revised CyPA – Picture capturing is missing?
Page 22 – Path Planning – Connectivity and flow of computations/algorithms within the big blocks would be useful; and essential to plan and track specific tasks
Pages 25-27 – What value does the simulation effort add to the project?
Page 31 – It is unclear how a state space model of the rover addressed the low-level control. Is the team developing its own low-level controller and implementing on some dedicated h/w?
Page 33 – WBS – This seems to be a mixed bag of subsystems and functional work (analysis), some clean-up is needed
Pages 33 and 36 – WBS – The autonomous navigation and picture capturing/comms subsystems are missing; the auto nav subsystem represents a pretty significant amount of work!
Pages 42-43 – Make sure you specify the exact requirements teh team will validate at the FVE
Pages 46-47 – Further analyze the risks. Be more detailed about action to be taken; come up with realistic mitigation actions and act as soon as possible or as needed

L. Wan comments:
Great animation, visuals. Better requirements than before– focusing on system functionality. Good demo of vive sensor. Definitely want to start adding more system functionality as opposed to testing sensors, since your paltforms are already built. Discussion on mapping seems really new– was not aware of this functionality. What does “robustness” mean in the PR goals? You will be asked to show this. I would imagine that the grasp success rate would be much higher if the absolute pose of the object is already known via mocap. How are you defining your goals? Are they derived from any studies or are you guessing an easier lower bar to meet because it’s unknown?

The MRSD Instructors