Skip to content

Design Overview

dcyoung edited this page May 11, 2017 · 12 revisions

Concept

The RaspberryPi creates a local access point and hosts a small webserver. Users can connect to the app from any device (phone or computer) without internet access.

  • User connects to the RaspberryPi's access point
  • User navigates to the hosted webpage using a browser
  • User interacts with scanner via webpage GUI
    • Specify scan parameters
    • Submit scan requests
    • View list of recorded scan files
    • Download a specific file
    • Delete a specific file
    • Trigger small troubleshooting scripts that test various components. To be used during device assembly or on error states.
    • Shutdown RaspberryPi

Design Philosophy

  • Simple dependencies or platform requirements
  • Simple messaging (ie: printing stringied JSON)
  • Simple languages (Javascript + python)
  • Familiar/standard environments (Node + express)

Application Structure

  • node webserver (app)
    • express routing
    • jade templating for frontend
    • standard view + route directory structure
  • simple client side javascript for user interaction
  • app uses node's child_process module to spawn child processes that execute simple compartmentalized python scripts which interact with the sweep device (ie: perform scan)
  • stdin of the main process (node) and the stdout of the child process (python) are piped together, such that print - statements in python code are essentially messages received as JS events
  • python code provides updates about the scan progress using a simple message format encoded as stringified JSON, which the backend JS can easily decode and feed right off to the client side JS at the client’s request

Directory structure

  • dummy_scanner/: contains dummy versions of the scripts from the scanner/ directory
  • output_scans/: where .csv output scan files are stored
  • public/: contains static files (express will look here)
    • javascript/: client-side javascript (includes sub-directory for every page)
    • lib/: libraries like jquery
    • stylesheets/: style related stuff
  • routes/: contains scripts (1 per page) which handle routing + backend logic
  • scanner/: contains python scripts for the actual scanner
  • views/: contains jade templates (1 per page) which handle the front end view
  • app.js: the main entry point to the app

Main Dependencies

The idea is to let other libraries do all the heavy lifting (ie: libsweep + sweeppy should handle all the low level communication with the device).


Alternative Directions

The main design philosophy for the main scanner application is to keep things simple. But there are a lot of interesting directions to take the application in the future.

Other branches provide some experimentation with more powerful and expandable solutions. See the outdated zmq-ipc branch for a WIP using distributed zeromq patterns with a message schema like protobuff. This could extend the capabilities beyond IPC, to messaging multiple external applications for real time viewing of data etc.

The sweeppy python bindings don't seem as robust as a well organized c++ application that uses libsweep directly. The scanner code could likely be cleaned up and re-written in c++ without too much effort.