Progress Evaluation - Milestone 2

_______________________________

Model Based IoT

Florida Institute of Technology Senior Project

Sponsor & Client:

Dr. Siddhartha Bhattacharyya

Associate Professor of Computer Engineering & Sciences

Prepared by:

Sung-Jun(Tony) Baek,

Caelan Shoop,

Cameron Wright

Last Modified:

Oct 29, 2021

Version:

1.0.0

Project Title: Model Based IoT

Team Members:

▪ Sung-Jun Baek (CSE): sbaek2015@my.fit.edu

▪ Caelan Shoop (CSE): cshoop2018@my.fit.edu

▪ Cameron Wright (CSE): cameron2018@my.fit.edu

Faculty Sponsor & Client:

▪ Dr. Siddhartha Bhattacharyya: sbhattacharyya@fit.edu

○ Associate Professor of Computer Engineering and Sciences at Florida Institute of Technology

Progress Matrix for Milestone 2:

Discussion of each accomplished task and obstacles for Milestone 2

• Task 1:

This task involved manually producing the desired mock output from our translator given an UPPAAL model, and this output was in the form of a python script. It was created based on an UPPAAL model that controlled mock Roomba states, which consisted of five nodes, six transitions, no loops, and only guard and assignment statements on the transitions. This mock output needed to mirror the structure of the model, meaning all possible paths had to be represented.

The obstacles in this task included finding a consistent and logical method of representing the control flow as a valid Python script given an UPPAAL model and using all of its elements. This method's logic must feasibly be able to be implemented into our Translator. Furthermore, how each different possible element in the model would be represented in the Python code, i.e. node, guard transition, assignment transition, etc.

• Task 2:

There were lots of UPPAAL components to be implemented. Which requires intensive logical discussion within the team. The final software design is selected as below:

1. Parse XML by tags and required components
2. Transform basic components into objects(nodes, transition, model) filling up the object content with the related attributes
3. Make connections and construct a graph-like heap data structure similar to the UPPAAL model, allow traverse by transition
4. Translate into python code based on the graph elements and its attributes
5. Generated python code must be usable by the API on the Pi

• Task 3: 

Required UPPAAL features were implemented into the translator as following:

• Node regards the name as a function name and contains a list of outward transitions. This object structure makes the translation process much easier in identifying neighbour nodes.

• The idea of converting an entire model’s transitional operation into a python script automatically has the potential threat of bug occurrence. However, by handling each of the operations separately, the program was able to append the script into a desired output. “name” is implemented to label a function name, “guard” to label conditional statements, and “assign” to set a new value to a desired variable in python script. The function call will be appended after the operation script. Sync will be implemented in Milestone 3.

                Example of name:

                        Given: “Explore”

Output: async def Explore(self):

Example of guard:

Given: “mode == 4 || battery < 10”  

Output: if self.mode == 4 or self.battery < 10 :

Example of assign:

        Given: “mode := 4”

        Output: self.mode = 4

Full format:

async def Explore(self):

           if self.mode == 4 or self.battery < 10 :

                self.mode = 4

                await self.Dock()

• The invalid model input was put into consideration. Therefore, the abstraction of graph structure is used to do DFS traverse via unvisited nodes which will prevent going into a loop, but catching the invalidation of the model by identifying unconnected transitions or meaningless transitions. However, this feature is discarded since the UPPAAL program already checks the validation.

Also, a well organized script is implemented for better user readability. With the graph abstraction from above, the translator does the BFS traverse to stack the visited node that contains the part of the script(script chunk of function) into the queue, and dequeue from the queue to append the script chunk at the end of the full script so that the script order going from the bottom to the top.

Example: if node ‘A’ is calling node ‘B’ and ‘C’, node ‘B’ and ‘C’ have to be defined before ‘A’.

async def B(self):

  pass

async def C(self):

  pass

async def A(self):

  await self.B()

  await self.C()

• The given variable declaration was formed in C language. Therefore, we have built a parser to percolate declaration tags and attributes into python-acceptable script. It has features of handling variable declaration in the smart way.

                Example input:

<declaration>// Global declarations.

int status1, charge1 = 0;

int status2

</declaration>

                Output script:

def __init__(self, ):

             print('Running constructor')

             self.status1 = 0

             self.charge1 = 0

             self.status2 = 0

• Task 4:

This task involved the creation of multiple simple, or restricted, UPPAAL models related to potential Roomba states which could immediately be used to test our Translator. These restricted models could only use guard and assignment on transitions, only used the boolean, integer, and double data types, and did not have any backward transitions or loops, were a single template, and had no more than nine nodes in total. The purpose of these restrictions was to create models that could be run successfully using our initial Translator implementation. In total, there were four different simple UPPAAL models created.

The obstacles in this task included becoming comfortable enough with the UPPAAL software to freely implement multiple valid models. Another is to understand the level of complexity necessary and components necessary in each model, such that it could potentially be similar to our end Roomba state model. Lastly, a solid understanding of how the Translator was to be made and what features were to be implemented first was needed to define what a simple model is and what restrictions are necessary to potentially run through the initial Translator.

• Task 5:

This task involved the creation of mock expected output for all four of the simple UPPAAL models. These would both serve to validate the methods implemented in the Translator, manually going through the logic and more practically as a means of comparison for the actual Translator output. It was essential to have a valid expected mock output to compare to for validation because there is no way of running the UPPAAL model before translating.

The obstacles in this task included understanding the underlying logic used in the current Translator implementation, e.g., what Python statement is produced for guard transition and what order will node functions be declared. Furthermore, understanding UPPAAL models and specifically each of the four simple models is also required both in the visual model and the XML file, e.g., what its control flow should look like and where variable declarations are located.

• Task 6:

The translator could crash with incorrect input and generate totally inaccurate python scripts. Therefore the translator breaks when an invalid input or model is given. The program terminates the job and shows the error rather than producing unusable scripts.

• Task 7:

Final python scripts have to be accepted by the python compiler to run on the Raspberry Pi. The compiler accepted the code, but the runtime error occurs because none of the functions are predefined in the Pi. This problem will be resolved by the next milestone.

• Task 8:

Raspberry Pi integration with the Roomba E5 was found to be unnecessary after being provided with an API that effectively tricks the Roomba into thinking the Pi is the mobile app from iRobot. This also fits better with the idea behind IoT. A massive obstacle to hardwiring a Pi to the Roomba is the Roomba’s circuit board layout. It is not easy to interpret and it would take a long time to figure out how to interface the Pi physically.

The solution to this obstacle is to utilize the Roomba’s integrated Wifi capabilities that connect to the iRobot app, and simulate the application with an API. The dorita980 API used for the demonstration is in javascript and not perfect for utilizing translated scripts, and while a Python adaptation of this API exists (Roomba980-Python), it was decided to make a new API that does only what is necessary and can utilize translated scripts quickly and easily. This API can be run on any device that is on the same network as the Roomba, rendering the Pi technically unnecessary, but storing the API and scripts on the Pi and using SSH helps keep any personal device uncluttered, as well as allowing team members access to them at all times for testing purposes.

• Task 9:

An API written in Javascript called dorita980 was provided. The Roomba E5 was set up with the wifi using the iRobot Home app. After setting up a Raspberry Pi, controlling it with SSH through a personal laptop, and installing nodeJS + ndm, the API was installed on the Pi and tested. By modifying the scripts and running them, it is possible to control the Roomba and have it clean the room or return to its dock. This API will be recreated with Python to work more fluently with the team goals. Teammates can use the existing Python API to create translated scripts and the new API will be made to be compatible with them.

Discussion of contribution of each team member to Milestone 2:

• Sung-Jun(Tony) Baek:

Had intensive discussions with the advisor assistant and the advisor on how the translator system should work accordingly with UPPAAL features. Handled the programming in python. Mostly maintained the consistency of the clean code style and preventive spaghetti code structure was taken care of. Aimed for best readability rather than coding skill performance. Confirmed the final output from the program to generate the python scripts in the python compiler.

• Caelan Shoop:

Disassembled one of the Roomba E5s to see how difficult interfacing a Raspberry Pi would be. It was collectively decided to avoid that if possible after seeing the motherboard layout of the Roomba. After being provided with the dorita980 API that would mimic the iRobot app, the other Roomba was set up using the iRobot app on the network. NodeJS and ndm were installed on the Raspberry Pi through an SSH from a personal laptop after getting the Pi setup. The API was then installed through ndm and a script was created for testing. The Roomba’s local IP was obtained through the information tab in the app, and the Roomba’s Blid and password were retrieved through the included features of the API. The script could then be duplicated and the main internal command for the Roomba changed. This allowed for the creation of a 0clean.js script and a 0dock.js script. By running these scripts with “node 0clean.js,” the Roomba would be connected to and instructed to run its internal “Clean” function.

• Cameron Wright:

Worked with and studied the UPPAAL software to guide translator design, create mock translator output, and create UPPAAL models to test specific Translator functionalities. Worked closely with Sung-Jun(Tony), providing specific information about the structure of UPPAAL models and their XML and general information about the requirements of the Translator. For example, do we need to check for valid transitions and how specific instances should be handled, and what should be the structure of the output. Created the initial mock expected Translator output and the mock outputs for all four models created in this milestone. By manually checking each node, defining each as a function based on its name, then filling in the logic according to their outgoing transitions, and once all nodes are defined, the mock output is complete. Was responsible for creating all four different UPPAAL models by first designing a general concept of Roomba states, creating the required nodes for each state, coming up with logical connections between states, implementing required parameters and appropriate transitions between the nodes, then declaring necessary instances of the template and variables and, finally ensuring valid syntax.

Task Matrix for Milestone 3:

Discussion of each planned task for Milestone 3:

• Task 1:

This task will be continuing the development of your Translator by implementing the ability for our Translator to translate models that contain scalar, array, structure data types. Currently (the start of milestone 3), our Translator can only handle models that contain variables with the boolean, integer, and double data types. By implementing these additional data types, our Translator will be able to handle models containing all possible data types available in UPPAAL except for clock data type. However, the clock data type isn’t a traditional data type and is intuitively handled internally within a UPPAAL model as it is a timed automaton. However, implementation into Python would likely require the usage of additional systems such as threads. Furthermore, we currently do not need clock, and due to the scaffolding required to implement it, we have chosen to make it an optional implementation later on. We will test that all data types apart from clock have been implemented by creating models that utilize all these types then running them on your Translator.

• Task 2:

More complex version compared to milestone2 tasks. The current translator can only handle a single template which produces a single class structure. In addition to that, on this task, the translator must be able to accept multiple templates(models) and make them work together, finally producing a multi-class structure of python scripts.

• Task 3:

Implement “Sync” function on transition object. Which generally commands the syncing process to other templates. For example if such transitions from different templates are triggered, the sync transition with the same name will be processed at the same time, and that process can be a function call. Therefore, we are currently thinking of using a hash mapping, a key-value pair, by searching the class’ transition set to identify the required node information.

• Task 4:

This task will be the development of a practical UPPAAL model, meaning one that will eventually be Translated and executed. Moreover, this model will differ from our previous models in its ambiguity, it will not contain specific Roomba states, but instead will contain general states that could be used to implement a divide and conquer strategy applicable to the collection of any such smart devices. Once the model is created, its functionality will be validated through queries within UPPAAL to ensure desired functionality.

• Task 5:

This task will be the continuation of Translator development by implementing the ability to handle inline code within the UPPAAL model. Currently (the start of milestone 3), only a shell of a program that maps the control flow with function definitions is output during translation. However, there can be inline code within the UPPAAL model that needs to be inserted into a corresponding function. This will be accomplished by mapping each inline function to its corresponding node via their identifiers. They will have the same name. Once mapped, the contents of the inline function will be inserted into the beginning of the corresponding model function definition. This will ensure that its corresponding inline code will be executed before continuing once a node is reached.

• Task 6:

Creating necessary predefined functions on Pi. This will be the creation of sample scripts that can be run to control the Roomba. These scripts will be simple tasks, such as executing the Clean command and after a certain delay executing the Dock command.

• Task 7:

Manually controlling the Roomba with scripts on Pi. To do this, Roomba980-Python will need to be installed on the Pi and analyzed to determine how to best utilize scripting for remote control of the Roomba. This determination will influence how the translator outputs code because that code will be the scripts that are run on the Pi and directly control the Roomba.

• Task 8:

Manually insert translator output onto the Pi and use it to control the Roomba. This will be done using sftp (secure file transfer protocol) to move the translator output, which are the scripts, from the translating device to the Pi. By running these scripts, the Roomba will be directly controlled by the translator output. This will involve making adjustments to the model in UPPAAL and validating the translator output before and during testing.

• Task 9:

Creating a new Roomba interfacing API. If permission cannot be obtained to use and modify the existing Roomba980-Python API, a new API will have to be created. This new API would be highly specialized for conveniently running scripts while still being heavily based on the existing APIs.

Dates of meetings with Client & Faculty Advisor during Milestone 2:

• Oct 26, 2021 11:00 - 11:30 : Discussed final results for milestone 2 and planned milestone 3.
• Oct 28, 2021 11:00 - 11:30 : Review on developed production. Evaluation.

Faculty Advisor & Client feedback on each task for Milestone 2:

• Task 1:

• Task 2:

• Task 3:

• Task 4:

• Task 5:

• Task 6:

• Task 7:

• Task 8:

• Task 9:

Faculty Advisor Signature: _______________________________ Date: ________

Due Nov 1,  2021.

Faculty Advisor: detach and return this page to Dr. Chan (HC 214) or email the scores to pkc@cs.fit.edu

Score (0-10) for each member: circle a score (or circle two adjacent scores for .25 or write down a real number between 0 and 10)

Faculty Advisor Signature: _______________________________ Date: __________