Software Rearchitecture

(return to Under Development)

Status: OPEN
[open, in-progress, needs-analysis, conclusion] I've added my comments in blue below - Dominik Fretz --Codewithpassion (talk) 08:21, 9 March 2013 (PST)

Description
The software is currently difficult to read and modify, even for the developers familiar with it. Also, there's a tension between whether software and intelligence should live in the Arduino code and which in the Javascript code on the BeagleBone.

Constraints
The issue with updating the Arduino code ist manly because the way Arduino reset cirquit is layed out. To update the Arduino code, you need to reset the arduino and then init the upload process. With a normal Arduino board and the Arduino IDE, it uses the serial port RST wire but this doesn't work with out setup. The best way to fix this, is by extending the ino-tool to enable an external reset event (in our case, toggeling the GPIO port). --Codewithpassion (talk) 08:19, 9 March 2013 (PST) The mian decision point should be on which layer (Arduino or JavaScript) is best suited to do a task. This probably boils down on how close to the hardware something happens. --Codewithpassion (talk) 08:19, 9 March 2013 (PST)
 * It's currently difficult/impossible to update the Arduino code without taking the ROV apart and taking out the chip. This is annoying and effectively shuts out the Arduino coders.
 * There's a disagreement about where to put code and logic
 * Tinkerers/hardware/mechanical/Maker people (e.g. Eric Stackpole, Walt Holm]]) are more familiar with Arduino, and these are the people active in developing the hardware, sensors, etc.  Turning Arduino into a dumb sensor pipeline controlled by the Linux server would alienate these people from contributing software
 * Software developers/non-mechanical people (e.g. Bran Sorem,  Peter Christensen) are much more comfortable with Javascript, and Javascript has a wealth of libraries for data manipulation, web connection, etc.  As the ROV becomes more intelligent and collects more sensor data, sharing that data will require more software contribution, so the Javascript developers can't be excluded either.
 * Code should be easy to read, understand, and contribute to

Discussions

 * Arduino vs Cockpit Customizations
 * 2013-03-05 Development Call Notes

Description
Code should be packaged into discrete sets that can be combined to create the desired functionality.

A package
 * should contain some mix of Javascript, Arduino, and other(?) code
 * should declare any hardware services it needs
 * should declare any OpenROV services it needs
 * may declare optional OpenROV services it can consume
 * may provide a list of services it provides

The main OpenROV server will be a registry of services and handlers, and route requests to the installed packages that can handle them.

Example of Packages
The basic functionality could be in these packages:


 * Movement-JS
 * Javascript code: Control Arduino motors code to produce the desired movement
 * Arduino code: Control individual motors by setting speed to a % of the acceptable ranges
 * Hardware Services: [XMovement, ZMovement, YawRotation]
 * Service Dependencies: []
 * Services Provided: [MoveForward, MoveBackwards, TurnLeft, TurnRight, MoveUp, MoveDown]

Arduino has nothing to do with the camera (except driving the tilt servo, but that's not really concerning the camera) nor will it ever be IMHO. On NodeJs, we probably need some level of control code, depending on the way we are going to stream the video feed. For example we might want to control brightnes and contrast from the UI and that would need some code on the server too.
 * VideoCamera
 * Javascript code: Provide a url endpoint to serve the video stream from
 * Arduino code: Connect and configure camera
 * Hardware Services: [StreamingCamera]
 * Service Dependencies: []
 * Services Provided: [StreamingVideo]


 * Cockpit Server
 * Javascript code: Web pages, server, and UI for viewing the video and controlling the ROV's movement
 * Arduino code: None
 * Hardware Services: []
 * Service Dependencies: [StreamingVideo, MoveForward, MoveBackwards, TurnLeft, TurnRight, MoveUp, MoveDown]
 * Services Provided: []

The two packages Movement-JS and VideoCamera meet all the dependencies for CockpitServer, so this is a functional set of packages.

Swapping in Compatible Packages
If someone wanted tinker with the motion controls in Arduino, they could use this package instead:


 * Movement-Arduino
 * Javascript code: Interface to pass the services interface to the Arduino code
 * Arduino code: Logic to control motors to implement the given moves
 * Hardware Services: [VerticalMotor, 2x ForwardMotor]
 * Service Dependencies: []
 * Services Provided: [MoveForward, MoveBackwards, TurnLeft, TurnRight, MoveUp, MoveDown]

It provides the same services as Movement-JS so it can be swapped out without changing the Cockpit Server, and now they can work on the movement logic in Arduino.

If someone added a new sensor (say a depth sensor), they could make a package like this:


 * Depth-ES-Experimental
 * Javascript code: Interface to provide the depth value to the service interface
 * Arduino code: Component settings, readings, and calculations to return the depth value in a specified unit
 * Hardware Services: [EricsDIYDepthSensor]
 * Service Dependencies: []
 * Services Provided: [Sensor.Depth]

The Sensor.Depth value would be available to the main OpenROV server for logging, etc, but if someone wanted to add it to the cockpit display, they could modify the Cockpit Server code to display depth if available and add this to the Cockpit Server package:


 * Cockpit Server
 * Optional Services: [Sensor.Depth]

Then anyone else who got a EricsDIYDepthSensor could install that package on the ROV and upgrade it, similar to using apt-get or homebrew to install new software.

Deployment
We would have a repo of packages (code sources would probably be in individual code repos, like Homebrew) and a web interface for adding assembling packages. This will provide dependency resolution (and prioritization if two packages provide the same services) and produce an assembled version of the code they can download to their ROV. It would probably start as a copy and paste or a script they can download and run, but could later include a desktop daemon that could reboot the Arduino, etc.

This could be the first big step in taking individual ROVs and turning them into a community of ROVs.

Open Questions
I don't have a good understanding of what an Arduino-heavy version of the ROV would look like so I might not be representing the Arduino side correctly.

Finding the right namespacing of core and custom services is crucial but can't be done beforehand.

Participants

 * Peter Christensen
 * Dominik Fretz

Conclusions
None yet

Conclusions
None yet

Overall Conclusions
{summary of lessons learned across all experiments}