Monday, April 27, 2015


Slowly documenting things! I'm aiming for minimal documentation that communicates as much as possible. This is proving to be difficult : ) This also meant burying another scanner : )

I currently plan on breaking documentation into three sections:
1. Setting up the Raspberry Pi to automate scans
 - Process documented, needs testing and significant clean up before starting rough draft

2. Preparing a scanner for burial
 - Photos taken and rough draft done, needs review

3. Burying the scanner
 - Photos taken and rough draft done, needs review

The last two sections are pretty straightforward. The first section needs a couple dedicated afternoons cleaning up the existing documentation, testing from scratch, and finding a balance of what+how much to communicate. I would love to see if the entire project could be done by a group of young students, and that brings up a number of questions.

What and how much to communicate really depends on the goal of whoever's perusing it. It's somewhat amusing that the easiest way to document is to document everything in excruciating detail. Which is probably a buzz kill for most...  Trying to take into account things like:
 - Would it help to include automated publishing of images + videos.
 - - Do we cover rsync, backing up, ssh, etc.? Or discuss GoogleCL?
 - Is local access to images and videos preferred, and then they can decide what to do with it?
 - - Do we discuss methods on Windows & Apple to process images and video?
 - What's a good price point to assume? Minimal: ~$100. Ideal: ~$150.
 - - This changes how much data can be recorded and methods of storage.
 - Do we keep it to the command line environment?
 - - Aside from viewing videos it's all been SSH. This can be a huge barrier for some.
 - Do we discuss open source software, hardware?
 - - This whole project would likely not have happened without it.

Mmmmm, food for thought! Sounds like I need to spend some time communicating with people who might want to use it, and what their goals and desires might be.