Progress Evaluation - Milestone 4

_______________________________

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:

Feb 9th, 2022

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

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

• Feb 11th, 2022 - Milestone 4 progress report

Progress Matrix for Milestone 4:

Discussion of each accomplished task and obstacles for Milestone 4:

• Task 1. The front-end of our website is accessible and functional for users (developers). Implemented user interfaces with HTML, CSS, JS. Can add predefined files up to 10 files. The main obstacle for the front-end website was making it function inside the Java Spring Boot framework. Understanding the web application concept in Java Spring took time since web sources need to be handled with REST for the page redirection, and every web source component to be associated with Java entities.
• Task 2. Implementation of the user request and file transfer handlers are made with Java Spring - Boot, Controller, Rest. However, the backend web server needs more improvements on designs and explanations. For minor implementations, instead of having a server crash, a web server shows the error message to the user when errors are encountered or if the translation cannot be done successfully. Moreover, the main decision was to have a reactive web application without any database or token authentication. Then we have to consider that there might be multiple users asking for submission and view requests and keeping them on track without acquiring any user inputs. The file generator on the backend appends the submitted filename to the output file after mapping the user IP. So, in that way, users never get any result collision even by submitting the same-named files.
• Task 3. Developed python objects and classes in translator for predefined code translation. Potential threats of accepting extended features and accepting unsupported action identified. However, the need to create more various python examples is required for the device execution tests.
• Task 4. Conducted further research into what type of model would be the best fit for the final task division model of the Roombas. Realized that a general divide and conquer model wouldn’t be effective, and a dynamic search algorithm such as D* should be implemented as a model instead.
• Task 5. Configured Raspberry Pis with Roombas and learned how to utilize the pycreate2 Python library to control the Roombas fully. Modified pycreate2 library to suit our needs for the demo, as the current version of pycreate2 did not have the dock functionality implemented. Synchronization has not yet been implemented.
• Task 6. We completed basic features on combining XML objects and predefined objects into a single auto-generated py script file, which were tested successfully on demo files used in the practical demonstration run on the Roombas. However, error handlers are not implemented on unsupported input syntax. The reconstruction of the packages was the main obstacle of this task before completion.

Discussion of contribution of each team member to Milestone 4:

• Sung-Jun(Tony) Baek: Created a responsive and functional website that can run a script generator and show result codes on the website interactively. Implemented a feature that creates and combines XML objects and predefined objects on script generation.
• Caelan Shoop: Set up and configured Raspberry Pis on Roombas. Wrote scripts for Pis to run to test the movement of Roombas. Modified pycreate2 library on each Pi to reimplement the seek_dock() function. Designed a 3D print object to mount LiDARs and Pis securely onto Roombas.
• Cameron Wright: I created basic predefined functions for moving Roomba using the pycreate2 library and created a UPPAAL model that utilized predefined functions & defined logic flow. Manually integrated predefined functions with output from translator and inserted the resulting python file into each Roomba Pi using SFTP for the video demonstration. I did initial research into LiDAR, finding that ROS drivers and PyLidar3 would be necessary, while the SDK specific to our LiDAR wasn’t necessary. I created a flow diagram for the translator that depicts how users (developers) utilize the translator.

Task Matrix for Milestone 5:

Discussion of each planned task for Milestone 5:

• Task 1: Tested models have been limited in operations used. As a result, the translator hasn’t been exposed to all potential minute operations possible in UPPAAL models; this helps ensure the translator works on all possible UPPAAL model configurations; dozens of new models are to be created or sourced and run on the translator. Based on the output of these models, the translator will be updated accordingly if necessary.
• Task 2: Possible solutions for syncing the Pis on the Roombas include having the Pis connect to each other or having the Pis send a signal to the main control device that will handle them accordingly. Further research needs to be done to establish the best method of synchronization. However, your client has indicated that utilizing the main control device, such as a smart home device, an Amazon Echo, or Alexa, is the end goal.
• Task 3: Decide on the final search algorithm to be used in dividing work between Roombas. The Roombas should be able to divide the work of cleaning a room evenly; thus, a dynamic search algorithm where a reference point is chosen is expected to be used. Create a predefined implementation of the search algorithm chosen to be implemented. Create a UPPAAL model for the chosen search algorithm verifying the functionality of the implemented model with queries within the model.
• Task 4: The basic functionality of the LiDARs has been tested; both spin when power is supplied. However, the LiDARs can not interface with the Raspberry Pis out of the box. In order to allow them to interface, the ROS driver package must be set up in Raspbian on both of the Raspberry Pis. Though the ROS driver will allow Raspberry Pis to interface with the LiDARs, in order to work with them in python, the PyLidar3 python library will be installed on both of the Raspberry Pis. Furthermore due to the resource
• Task 5: This task can only occur after the sensors are configured, which has been a challenge due to the outdated documentation on our specific LiDAR, the YDLIDAR X4. However, as we do not need the brand-specific SDK, we can instead follow the up-to-date documentation on the generic ROS driver. Once the Pis have the ROS driver and are able to interface with the LiDAR, the PyLidar3 library will be utilized to work with the LiDAR output and create the needed predefined functions.
• Task 6: The 3D printed parts will be assembled using pre-drilled holes and small screws. They will span across the width of the Roomba, secured to the green removable top on the Roombas, and act as a mounting platform for the Pis and LiDARs. The Pis will be mounted with standoffs that Cameron bought. While the LiDARs are secured in the center of the Roomba with their included screw