KM NRC

Request for Proposal: Nano Robotics Challenge(NRC)

This project reflects real life scenarios; the robot must be able to handle minor imperfections in the course.

Introduction and Overview

Nano-robotics is a quickly growing field; robots the size of a nanometer (1*10^-9 m) could very well be the next important breakthrough in medical technology. Currently the interest in nanorobots revolves around their potential application in the medical field to act inside the human body as a cure for various ailments.

The Center of Disease Control (CDC) has recently had an influx of very sick volunteers willing to try out this novel technology. In response the CDC has reached out to engineers and programmers to develop an autonomous nano-robot that can travel through the bloodstream, diagnose health issues, and cure diseases.

Each research group has been provided with a patient. Your group's patient is Jesse. Jesse decided to go for a swim in the Gowanus Canal. We can't be sure what possessed them to do that, but here we are. Provided with information on illnesses that Jesse could have, your group will need to program an autonomous nano-robot to detect, find, and cure all the illnesses present in the body.

Specifications

Jesse is represented by a light-up skeleton located in the EG Modelshop. Jesse contains a program that represents a set of diseases and viruses. Each group of "doctors" working to cure Jesse will be given a set of three, two diseases and one virus, that will need to be diagnosed and cured. Although the "doctors" will be able to see the location of the disease/ virus and how its moving through the body the nanorobot will need to diagnose the Jesse separately, and will therefor need to be soft coded.

The following viruses could be present:

Virus Steve - This virus moves through the human body on a set course with easy to follow motions, it will follow a preset path, but stop randomly to take a small break from wreaking havoc on Jesse.

Virus Jenny - This virus doesn't move randomly but will take different paths through the body, though it doesn't stop moving.

The following diseases could be present:

Heart Attack - The heart pumps blood through the body. A heart attack occurs when there is a blockage of blood flow into the heart. Oxygen is cut off and the heart begins to die.

Kidney Disease - Kidneys filter excess water and waste properly through the body. Kidney disease occurs when the kidneys begin to loose functionality that can result in a variety of health problems.

Stroke - When blood supply to the brain is interrupted, the brain cells that lack oxygen and glucose will begin to die.

The nanorobot in Jesse's body can be interacted with via an HTTP API as described in Appendix A. Most programming languages have some way to send HTTP requests. For the purposes of this project, Python with the Requests module is recommended. However, for students completely unfamiliar with programming, an instance of Snap!, a graphical programming language maintained by UC Berkeley, is provided.

To interact with Jesse, connect to the WiFi network EG_NRC-8913 in the EG Modelshop. Snap! is available at 10.42.0.1:5000/. Information on the API Specification and using Snap! is available in the Appendices below.

Microsoft Project

A project schedule must be created in Microsoft Project. Learn to use Microsoft Project by accessing the Microsoft Project Student Guide. This schedule must include all tasks related to the project from the start of the project to Early or Final submission. Click here to access the guide on how to transfer a file. The Microsoft Project schedule should include:

• Minimum of 20 tasks, excluding Milestones
• Milestones should be clearly indicated on the project plan (duration of zero days)
• Each task must include the person responsible for completing the task (resource names)
• Use the "Copy Picture" function to include the schedule in the presentations. Do not take a screenshot
• Gantt chart must be displayed alongside the tasks list (fit onto one slide)
• Gantt chart must show a progress line
• Clearly state during the presentations whether the project is on-time, behind schedule, or ahead of schedule

For help planning the project, review the manual page Planning Project Scheduling & Costs.

Milestones, Benchmarks, and Deliverables

As work is done on the project, three Milestone presentations will report on the project's progress. All of the items assigned in each phase of the project are called Benchmark deliverables. These deliverables often consist of a combination of written submissions, presentations, and demonstrations. Benchmark assessments evaluate the progress of the project.

Preliminary Design Investigation

The Preliminary Design Investigation (PDI) is extremely important, as it lays the groundwork for the project. It outlines the project idea, inspiration, and goals.

The PDI must include:

• Cover Page
• Project Overview
• Goals & Objectives
• Design & Approach
• Cost Estimate
• Project Schedule
• Relevant Pictures

An example PDI template can be found here. The PDI is due by Benchmark A. Do not forget to include the items listed above. Use this link to access the VEX PDI Rubric.

Milestone 1

Prepare a preliminary assessment of the track system using digital logic (truth table, Karnaugh maps, and Boolean equations), a cost estimate, and an MS Project plan.

Look Ahead: What tasks are planned between now and Milestone 2?

See How To Give a Milestone Presentation for the format of a Milestone presentation.

Milestone 1 Deliverables:

• Presentation:
  • Project description
  • Design approach
  • Mission statement
  • Cost estimate
  • MS Project schedule
  • Progress update: current state of the project

Presentation notes:

• Be sure to include any special features and benefits of your design.

Benchmark Assessment A

The purpose of Benchmark A is to demonstrate familiarity with interacting with the API and the ability to do it repeatably through code. For benchmark A, students must:

• Demonstrate an understanding of the API by building a set of functions (or SNAP! blocks) that allow them to use the API conveniently
• Demonstrate the ability to login
• Demonstrate the ability to tick the game
• Demonstrate the ability to start holding and stop holding
• Demonstrate the ability to change the direction of the nanobot
• Demonstrate the ability to reset the game

Milestone 2

Look Ahead: What tasks are planned between now and Milestone 3?

See How To Give a Milestone Presentation for the format of a Milestone presentation.

Milestone 2 Deliverables:

• Presentation:
  • Project description
  • Design approach
  • Design changes since Milestone 1
  • Mission statement

Benchmark Assessment B

Students must twice:

• Defeat the weaker virus
• Reset the game

WITHOUT manually interacting with their program.

Milestone 3

Look ahead: What tasks are planned between now and the completion of the project?

See How To Give a Milestone Presentation for the format of a Milestone presentation.

Milestone 3 Deliverables:

• Presentation:
  • Project description
  • Design approach
  • Design changes since Milestone 2
  • Mission statement
  • Cost estimate (previous and current). What changes were made?
  • MS Project schedule (previous and current). What changes were made?
  • Progress update: current state of the project (time, budget, etc.)

Commissioning

In order to commission students must twice:

• Defeat the stronger virus
• Return to their start node
• Reset the game

WITHOUT manually interacting with their program.

Final Presentation

The Final Presentation will be a technical briefing, similar to the Milestones, but also serves as a sales presentation explaining why your company should be selected instead of the competition.

Your Final Presentation must include:

• Company profile
  • Company name
  • Employee profile, role(s), and qualifications
  • Mission statement
• Problem statement
  • Why is the project happening?
  • What does the audience need to know?
• Project objective
  • What is the purpose of your project?
  • Who does your project help?
  • What problem does your project solve?
• Project description
  • Specify LEED certification
    • Examples of LEED implementations in Revit
  • Revit drawings
    • All floor plan drawings
    • Dimensions
    • 1:240 scale
  • Views of exterior of building: front elevation, side elevation, isometric elevation
    • Dimensions
• Market and product viability
  • Does your company have competitors?
  • What makes your project unique?
  • How does your design compare to competitors - cost, quality, features?
  • Is the project versatile?
  • What is the price of your project?
• Conclusion
  • Reiterating project purpose
  • Highlight project features
  • Future goals of the company
  • Why should your company be awarded this contract?
• Video pitch
  • Price of project
  • Walkthrough animation of building in Revit
  • Embedded into Final Presentation
• Problem statement
• Solution overview
• Company description and qualifications
• Source code of program
• Cost estimate
• Microsoft Project schedule
• Video demonstration
• Why should the company be awarded this contract?

Submission

All SLDPs must be submitted online. Please visit this page for the link to the Project Submission form and each project’s individualized login information. To submit, login to the EG1004 website using this special login information. Submitting with an NYU account or any other account will generate an error. Components may be resubmitted at any time before the deadline. Please note that submission times are based on the most recent submission.

Please note the deliverables for this project are as follows. If any of the following items are omitted, there will be a penalty. Be sure to click "Submit" at the bottom of the form and allow sufficient time for uploading. The following list includes deliverable items that are required:

• Submission deliverables:
  • Final presentation
  • Final program
  • Final MS Project Schedule
  • Final cost estimate
  • Resume(s) (No fictitious resumes will be accepted.)

Late Submission

Late submission is not allowed. If a project does not Commission or receive Partial Commission by the deadline set forth in the syllabus, the project will not be allowed to submit and will receive a 0 for the project grade. To receive Partial Commissioning, two TAs must evaluate the project and determine its degree of completion according to the Commissioning requirements and the project will be given a grade accordingly. Please refer to the EG1004 Grading Policy for more information.

Appendix: Programming NRC

NRC can be interacted with via an HTTP API. Most programming languages have some way of making HTTP Requests. For NRC, we recommend using Python with the Requests module. There are a number of resources on-line that can help you learn about these tools.

For students with absolutely no programming experience, we also provide a graphical programming interface, Snap!. Snap! is based on the Scratch project and provides a drag and drop environment to put together code. The instance of Snap! used to interact with NRC is available at 10.42.0.1:5000/. The reference manual for Snap!, that includes information about the basic use of Snap! and any advanced operations you may need is available here as a PDF. Note: In order to interact with NRC via Snap! you will need to go to the file menu (on the upper left), to Libraries, and then select the "Web services access (https)" option.

The API Specification for NRC is as follows:

All URLs for NRC follow the following format:
    http://10.42.0.1:5000/<command-family>/<username>/<secret>/<action>/<index>

    http://10.42.0.1:5000/
        The base URL is the IP address of the Raspberry Pi running the webserver

    <command-family>
        There are two command families currently in use, login and game.
        login -> handles logging in
        game -> handles game interaction

    <username>/<secret>
        These fields are used to "authenticate" your game.
        username -> your netid
        secret -> a string set during login.  This CAN be different between games, it is set by
            the user, not the game itself

    <action>
        These fields are the actual interaction with the game.  Unless otherwise
        specified, they are POST requests that return a json object with a returned status.

    <index>
        Some actions require you to specify WHICH thing to take.  This is done by providing a numerical index.

Logging in:
    Make a POST request to http://10.42.0.1:5000/login/<username>/<secret>
    Where username is your NetID and secret is a secret of your choosing.


<action> list: 
    /tick
        POST request.
        Progresses the game forward by one unit of time, here called a tick.
        Returns a one item json object with the status of the tick

    /start_holding
        POST request.
        Causes the player character to "Hold." The player will temporarily stop moving through the graph.
            Holding has a limited length of time it can be applied.

    /stop_holding
        POST request.
        Causes the player character to release a possible "Hold".  The player character will begin moving again.

    /select_direction/<index>
        POST request.
        The next time the player character can choose their next path they will go down the path in the list with
            the specified index.  Indices begin at 0.  If the selected index is greater than the length of the list
            the player character will go down the last path in the list.  This is NOT automatically cleared and will
            remain until manually reset.
        Returns a one item json object confirming the direction selected.

    /reset
        POST request.
        Resets the game so that other users can log in.  MUST be done after EVERY run.

    /get_status
        GET request.
        Returns all of the available status for the player character in a json object.  The schema is specified below.

status json object schema:
    "player_postition"-> the name of the node the player character is currently in
    "options"-> the list of nodes the player character can go to next
    "number_of_options"-> the length of the options list
    "score"-> the current score
    "round_number"-> the round number/number of ticks that have occurred
    "rounds_remaining"-> the number of ticks left in the game
    "holding"-> True if the player is holding, otherwise False
    "holding_time_remaining"-> The number of rounds the player could hold
    "bot_visible"-> True if the bot character is within sight of the player character, False otherwise
    "bot_location"-> The name of the bot's current location if it is visible