Close
0%
0%

Build Logger

A companion cube for makers, collecting pictures, audio, and text during a build, and serving up a build log web page to those nearby.

Similar projects worth following

A voice activated, web enabled active project repository that reduces the friction of documenting a build. It is a device that is left in or near your project as you build. You use voice commands to interact, taking audio notes or taking pictures with a phone app that sends to the Build Logger's embedded web server. Build Logger verbally reminds you to take pictures, make audio notes, even do a few short text blurbs. It arranges all of this information into a timeline, creating a web site that it serves to those nearby. Its SD card can be used to upload the generated static HTML5 pages to any web host for easy publishing.

The overall system design is:

Speech is the primary I/O between the Build Logger (BL) and Maker. Voice commands provide hands-free functionality. Text-to-speech gives eyes-free feedback. For instance the combination allows you to check a FET pinout without taking your eyes off the circuit board, as if asking an assistant. Another set of commands can run timers, letting me move onto soldering or machining while caulk sets. More elaborate commands and data can be done by letting Wolfram Alpha do the thinking.

Pictures take a little more doing. There's no point in recreating the camera system on a smart phone or tablet, so let's leverage it. A simple app will take pictures and send them to a nearby BL using the BL's embedded web server.

Text notes can also be captured via an app, though realistically it adds overhead to collect much information on a phone keypad.

The BL can record sound as well. Voice Commands trigger a short recording, allowing the Maker to call out part numbers or make short notes such as "Use number 10 wood screws but do NOT countersink the hole, we're going to use the resulting edge later." Again, like asking an assistant to take down a note. I think these audio notes can be spliced over photos to make a build movie in a future version. In the near term, they can be played by the Maker as fodder for properly typed posts.

All activity during build sessions is logged, including all text-to-speech, voice commands, and notes about when pictures were taken. I often need access to small notes during build sessions. For instance, I remote control a data collection system that sits inside a vacuum chamber. It records data at a high rate and stores it to a SD card for later retrieval, all out of reach within the vacuum chamber. It prints the file name (just a number) (via Bluetooth serial) and leaves it to me to remember what the overall test conditions were. Being able to verbally note that "file 1234 is test 8" keeps my eyes on safety critical gauges.

Non-Makers see the Build Logger as a web server hosting a timeline of the project's pictures, audio notes, and text. Anyone within range sees the BL's short range WiFi access point and can leave comments on the log. This makes the BL part of the project's full life cycle - from inception through display and use.

People not nearby could still see the log because the BL actually creates static HTML5 web pages on its SD card. This reduces computation burden serving files and makes it incredibly simple to publish the log to the world through copy-n-paste of a whole directory to any web server.

To me, it's really the connection between the Build Logger and Non-Makers that makes this project so exciting. I love the idea of a project that becomes self-logging and self-advertising.

  • Prototyping sources

    wes.faler08/20/2014 at 03:30 0 comments

    The final goal is a something with a custom circuit board. In the meantime, Build Logger has to be prototyped from existing parts. Here's what I'm thinking so far:

    For now, I'm not going to worry too much about a battery. From prior experience, I know the Digix will run forever on a small solar panel and battery pack, so the extra peripherals can't be all that much load.

  • Voice commands

    wes.faler08/20/2014 at 03:18 0 comments

    "Voice command" does not equal "Speech recognition". That is, Build Logger supports a very limited set of sounds ("words") that it recognizes as command tokens. When the right set of tokens has been provided, an action is performed.

    It is important to know when to interpret the stream of tokens. People get.. ooo a bird... interrupted all the time. Some even exclaim loudly when a solder blob misbehaves mid-command. As such, instructions need prefix and suffix markers. Tokens/words can be ignored until a prefix is found, such as "Command". Then the words accumulate until a suffix is found. Naturally, the accumulator is cleared if too much time passes or too many words are spoken.

    A resulting command structure could be:

    Command session - begin a build session with associated reminders to collect data

    Command stop session - end the build session. Can also happen due to inactivity.

    Command record - begin audio recording for use during audio tours and later note-taking.

    Command timer - start a count-up timer without a limit.

    Command stop - stop the current recording or timer. If a timer is stopped, its timer's final minute duration is spoke.

    Command status - speak the timer's current minute duration (and any other short status information)

    Command [numbers] timer - start a count-down timer for the given minutes duration.

  • What about XYZ?

    wes.faler08/20/2014 at 03:01 0 comments

    Build Logger (BL) has a lot of features that sure feel familiar: text to speech, voice commands, storage, web server, etc. It's no wonder people ask "What about just using your phone? It has a microphone and Internet access."

    Yes, yes it does. It is not a web server though. Anything the phone posts to the Internet can only be found while.on.the.Internet. This really is where the inspiration for a new bridging technology comes from. The phone has GPS but it can't know anything unless it checks some central registry of cool GPS locations and someone registers the exacting GPS location of their project. It just doesn't work for ad-hoc things like Maker Faires or even Open Make nights at the local hackerspace.

    For that, you need the project being shown to advertise itself. It needs to be fully self contained so no Internet connection is required to serve information to someone standing right next to it. (Besides, have you seen the Internet connection request forms at a Maker Faire?) Its self contained nature gives it its greatest strengths.

    Strength: It must serve a complete web site about the project, highlighting the entire build timeline. This is a web site of static HTML5 files and images that can be copy-n-pasted to web host for larger sharing.

    Strength: To collect the required information, it must connect to easy sources of data. Namely camera phones and keyboards made for Twitter-length thoughts. That is, to be self contained for the end viewer, it must be fully connected for the builder.

  • Use case for the observer

    wes.faler08/20/2014 at 02:48 0 comments

    A typical use case for an observer of the logged project.

    I've been wandering Maker Faire all day, especially interested in someone that's used those strange small bearings. You know the ones, right? Hey, my Build Logger app just buzzed my phone. There's a project nearby that actually uses them! Tap. Ah, I see the pictures. It looks so easy. There must be more.

    "Hi there! I see you used the mark 7 bearings. How'd you mount them so level?"

    "I'm glad you asked. Command record."

  • Use case for the Maker

    wes.faler08/20/2014 at 02:42 1 comment

    An example use case from the builder's perspective.

    I turn on lights in the workshop. BL (Build Logger) speaks "Welcome" and I respond by speaking "Command start session". BL fully awakens, making Internet connections, opening its local web server, powering up all peripherals, and checking its SD card for consistency.

    BL speaks "Remember Pictures". I grab my phone, tap the BL app, and snap a few shots of the bench, the pile of wood screws I just got from the store, and half opened Amazon box of goodies.

    First things first, I caulk some cracks. That'll need time to dry. "Command one five start" and a 15 minute timer starts with an obliging "Beep" (the spoken word not the noise, because it's cooler).

    Setting that aside, its time to solder. Holding a part in hand, "Command ef eee tee tee oh two two zero pinout". "Ground one drain two source three" comes back and that pesky FET's fate is sealed.

    "Feed me". Ok, "Command record". "Hi again. Today, we're building the power supply for the next generation build logger. It's tricky because..." (spoiler removed) "... Command stop." Good, that'll really help with writing the next blog post.

    "Command end session."

View all 5 project logs

Enjoy this project?

Share

Discussions

PointyOintment wrote 08/20/2014 at 19:55 point
I like the idea but I'm not sure about your choice of hardware. Maybe a Raspberry Pi would be more effective. If you have a spare Mac, use that; they have a built-in extensible voice command system.

  Are you sure? yes | no

wes.faler wrote 08/20/2014 at 19:59 point
Did not know that about the Mac. Still too pricey, as I want to leave one Build Logger with each project, as if it were a component. Thanks for the Raspberry Pi encouragement - I admit I don't know much [yet] about their features. Their size and price is right though.

  Are you sure? yes | no

Don Smith wrote 08/20/2014 at 11:22 point
Hackaday.io should be open as well as our projects. If Hackaday.io has an API you could post project logs directly from the Buildlogger.

  Are you sure? yes | no

wes.faler wrote 08/20/2014 at 18:50 point
Love it!

  Are you sure? yes | no

Does this project spark your interest?

Become a member to follow this project and never miss any updates