App and Server Subsystem

App and Server Subsystem

The main function of the server is to act as a repository and relay data between Mell-E and the user, and vice versa. The architecture of the data flow is shown in figure below. app-structure

The dataflows between the app and server subsystems

The app, written for the Android mobile platform, is used to:

  • Display diagnostic information about Mell-E
  • Show the areas which Mell-E has covered
  • Provide location boundaries which Mell-E is allowed to cover
  • Start/stop Mell-E

Among all the host-providers, we decided to use Heroku as our API host provider, as it has tools that make it simple to diagnosis issues with the application and remotely restart the server.  With regards to the server-side technology, we used Ruby on Rails as our backend platform as our team-members had the most familiarity with the technology.  Furthermore, Ruby on Rails provides tools which simplify the process of managing the database.  For the database technology, we chose to use PostgreSQL because it is scalable while still being simple to manage. Mell-E retrieves the boundary data and start/stop commands from the server.  We currently haven’t implemented either or these functions on Mell-E; i.e., for the Fall semester, we pre-programmed a set of waypoints that Mell-E should go within 10 feet of.  Furthermore, rather than allowing the user to remotely start/stop Mell-E, we start/stop Mell-E directly from the mobile base.  Nevertheless, both the UI for starting/stopping Mell-E and setting Mell-E’s boundaries have been built on the app. Our backend exposes the following JSON API endpoints:

HTTP Method Endpoint Parameters
POST /api/boundary robotID, startLat, startLng, endLat, endLng
GET /api/boundary robotID
POST /api/running robotID, isRunning
GET /api/running robotID
POST /api/heartbeat robotID, lat, lng, batteryLevel, signalStrength, binFullness
GET /api/heartbeat robotID, withPath

The heartbeat contains all the important diagnostic data about Mell-E.  Mell-E’s location is retrieved from an Android phone that runs aboard the robot.  As detailed in the navigation subsystem description, our team decided the external GPS sensor was too noisy for our purpose; as a result, we wrote a simple app that retrieves the location and heading of the robot.  In addition, the mobile phone on-board Mell-E transmits a WiFi hotspot that allows Mell-E to connect to the Internet.  The battery level is calculated based on a voltage sensor attached to the batteries.  We use an IR sensor to measure how full Mell-E’s bin is.  Finally, the signal strength is calculated based on the cellular signal strength of the mobile phone onboard Mell-E.

Representation of how data is displayed to the user through the Android app UI is shown below.  In the state represented by the UI, Mell-E is stopped and does not have any boundaries set.  Therefore, the UI asks the user to enter a boundary area.

app

 

Main components of the UI are shown in the figure on the left. The figure beside displays the main components of the user-interface.  As previously explained, the UI displays relevant diagnostic data about Mell-E.  Additionally, the app is used to start/stop Mell-E and set the boundaries that Mell-E must cover. For Fall semester, our group:

  • Implemented all the functions of the user interface
  • Wrote the backend API services
  • Pushed the application to a production server
  • Setup a Postgres database
  • Retrieved sensor data from Mell-E and transmitted it to the server

For Spring semester, we had added the remote start and stop capabilities to the app. This was separated into two parts: build app content and be able to update data on server through touching buttons; pull the updated data from server and activate or kill the navigation node on Mell-E. The following four pictures show the start/stop buttons in app and their effects of updating isRunning data’s states on the server.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Once the server get updated, we created a Heartbeat ROS node that will grasp the data from the server and publish a topic /running to navigation ROS node, which will activate/kill the navigation process. The logic is shown as follows: