[Architecture] Separating "web app" functionality from hardware integration

[tejashah88]

As it stands, the Raspberry Pi is hosting the server while managing the hardware integration. This was originally with the intent that the robot should be self-contained and not require the use of the internet. However, the current setup takes a toll on the raspi's resources and can make the robot unstable as a result.

The idea is to split the web app code from the hardware integrations, preferably the latter into a new repository, and have the web app hosted online (Heroku is a good start) so that it can also see if the robot's online or not. It also lets anyone interact with the web app to either change some non-critical settings or allow easier testing of the web app (this is kind of related to DVC-Viking-Robotics/webapp#44).

Here's a diagram of how the interaction between the user, web app, and robot would look like with the new change:

[2bndy5]

Been thinking about this... I think that, for the sake of preservation, we should rename the current webapp repo as "standalone-robot" and the separated repos as "networked-robot" and "robot-server" or something like that. Because the software we have will likely be more applicable for individuals' projects (people who want to make their own robot with our software), should they want to use it without running a separate server to control their robot. Don't misunderstand me: I'm all for separating the hardware interfacing from the webserver controls, but this is a fundamental change that may not fit for prospecting DIY-ers.

[tejashah88]

@2bndy5 I like this idea but it'll be easier to make a "standalone-robot" repo after separating the components, since we can do a similar method to how we use your CircuitPython library modifications in the requirements.txt. For now, if DIY-ers want to work with the robot, we can add instructions for them being able to host their server locally as well, such as either on their PCs or their Raspberry Pis, which shouldn't be too different from hosting the server in the cloud.

[2bndy5]

Have we been doing this web socket thing all wrong? I think the webapp's server has been playing both client and server using callback events to emit sensor data to the user (primary remote client). I think there should be 2 servers and 1 client for each namespaced I/O hardware:

• 1 server on the robot that coordinates the sensor data (clients) with the drivetrain (another client).
• Another server to host the GUI (webapp repo) that exists remotely (not on the robot). This server should handle the user input (like setting GPS points A, B, C, etc) and dump the calculated path to the server on the robot.

We should be able to use the server on the robot as middleware between IO hardware (clients) and user interface (abstracted server). That way would rhyme with the MQTT paradigm (much like ROS) as a drop-in replacement for the web socket server on the robot. Have I missed something?

Currently, the Robot-Senses repo is set up to be an self-sufficient web socket server that would be graced with the privilege (not actually implemented yet) of connecting to the webapp server.

This is the client-side executable code in my head:

# drive.py
import socketio
from drivetrain import Tank, PhasedMotor

d_train = Tank([PhasedMotor(pin1, pin2), PhasedMotor(pin3, pin4)], max_speed=85)
sio = socketio.Client()

@sio.event('remoteOut', namespace='/drivetrain')
def remoteOut(args):
    d_train.go(args)

if __name__ == '__main__':
    sio.connect('robot_server_IP_address:port', namespace='/drivetrain')

[2bndy5]

I think using a class-based namespace would be most comprehensive.

EDIT

Nevermind. The class-based namespace suggestion seems to only be beneficial if a client assumes multiple namespaces. I've been reading more on the socketio docs, and I think it might be a better idea to use "session ID" as it is unique for each client's connection if/when multiple drivetrains use the same namespace, /drivetrain. We might consider using the room parameter instead of session ID, but that seems to be only beneficial when communicating to multiple clients assigned to a "room" (eg. more than one robot coordinating with the webapp server).