NRC Digital Programming

From EG1003 Lab Manual
Jump to: navigation, search

Snap! Digital Programming

Snap! is a drag and drop form of digital programming, it has the basic capabilities of more complex programming languages and is enough to work with the NRC SLDP. The Snap! website is linked here https://snap.berkeley.edu/snapsource/snap.html

A TA does not need to be well versed in SNAP! to answer your coding questions, SNAP! contains many many similar functions to other coding languages, if any function or operation explained bellow seems confusing reach out to a TA for help.

Figure 1: Snap Overview

Snap Basics

On the top left different types of coding blocks can be accessed. Although others may be used looks, control, operations, and variables will be used the most.

Figure 2: Operations Overview
  • The "Looks" section are operations that will allow different types of displays. So "Looks" will effect how the output is displayed on the white screen on the far right.
  • The "Control" section are operations that allow for different types of logic to occur. The following are common logic statements, although these are not the only "Control" operations available.
    • The "When" blocks will wait for a certain input before starting the code that can be attached bellow the block. The hexagon empty spaces featured in these blocks reference a seperate logic statement that can be placed there, this is explained more in detail later on.
Figure 3: Control Functions
    • The forever and repeat options act as loops, they will either loop a code forever, or until a certain set of feedback conditions are met, and those conditions can be set by the programmer.
Figure 4: Loop Functions
    • An "if" function will run through a set of code if a set of conditions is met. For example "if" a light switch is flipped then the light will turn on, its a conditional statement. An "if else" on the other hand provides a separate command if the first condition is not met.
Figure 5: If functions
  • "Operators" offers different types of logic and controlling variables that can be placed throughout the code or to control certain conditions. These operators include simple mathematical functions, some string functions (which are functions that include words), and some Boolean functions.
    • Boolean functions include "and", "or", and "not" functions. For an "and" function to occur both statements listed must be true, for an "or" function to occur at least one statement must be true, for a "not" statement to occur the input listed must be false.
Figure 6: Operators Operations
  • The "Variables" function allows for variables to be set, changed, and altered in various ways throughout the code. The variables of a code is usually whats being controlled.
Figure 7: Variables that Vary

Remember these are not the only functions that you are allowed to use, others in Snap! may be useful or necessary to complete the tasks.

NRC API Specifications

Simple coding and commands for NRC are as follows. Examples of how this works in Snap is shown after the following information. Coding is completed in this format so that the code for the nanorobot can properly interact with the main code, the code that holds the diseases and viruses, the main code will be refereed to as "Jesse".

There are two types of request commands that are used here:

  • "GET" requests are used to pull data from the server.
  • "POST" requests can also pull data BUT something is changed on the server side (that's you!), so after putting an input into the server feedback is received from the server based on that input.

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

Logging into Jesse

The following Snap! code follows the format described in the API specifications above using the format needed to log into Jesse. As action and index are not included for logging in they were left blank, although they can just be omitted from the code.

Figure 8: Login Code

Directions Sample Code

The following Snap! code follows the format described in the API specifications above using the format needed to give a simple direction to your nanorobot.

Figure 9: Directions Sample Code