Making an Electric Longboard

boosted-board image

Electric longboards have been taking off lately and gaining publicity through Kickstarter campaigns and tech sites like TechCrunch, Engadget, and Tested. The most popular commercial products come from Boosted, evolve, and Marbel. However the price for a consumer board is upwards of $1000!

Because of this price, there has also been a huge movement in DIY electric longboards and the most common designs take a regular longboard and RC Car electronics to create a custom electric longboard with swappable components. This was the route that I was interested in going since I already had a regular longboard and couldn’t justify spending over $1000 on a longboard that I could build myself for less than $600.

The first step in building your own electric longboard is of course research. I found a lot of great material on forums, instructables, custom sites and blogs, but the best resource was a forum dedicated to electric vehicles which had a specific section for electric skateboards and scooters known as Endless-Sphere. From here I was able to gain insight and chat with a bunch of similarly minded DIYers who had built or were building their own electric longboards. The most common designs were a single motor setup, dual rear setup, and dual diagonal setup.

What are the differences?

Single Motor

The cheapest option to build, it’s main use is for traveling on flat ground and it is lighter due to the one motor setup. It doesn’t have as great hill riding capabilities and could burn out with too many or too long of an incline ride.

Dual Rear

This costs more than the single motor setup, and creates a size restraint on the motors since you can’t use two 63mm motors with a traditional truck. However, it allows you to ride faster, tackle more hills with less stress on the motors, and have a back-up motor in case one fails.

Dual Diagonal

Some people prefer this build over the Dual Rear because it spreads out the motorized wheels in order to give better coverage over uneven ground. The cost and performance should be relatively the same as a dual rear, but you are able to use two bigger motors for this build since you don’t have the size constraint of mounting two motors on one truck.

What do you need to build your own electric longboard?

Longboard Components

  • $20 and up – Longboard deck (there are plenty of options here, whatever floats your boat)
  • $60 – Longboard wheels (preferrably with some sort of hub that you can interface a motor pulley with, common choices are ABEC 11 Flywheels and Orangatang Kegels)
  • $50 -Longboard trucks (your choice, but I prefer the Caliber trucks since they come with decent bushings and are great stable)

Mechanical Components

  • $50 to 100 – Motor mount (Can be bought for a couple types of trucks, or made yourself and welded onto your mount or clamped)
  • $10 – Motor pulley (Can be bought for 9mm or 15mm wide belt with varying teeth. Recommended teeth are 12T, 14T, and 15T)
  • $10 – Wheel pulley (This will depend on your wheel. You can make one yourself using a CNC machine and aluminum, or you can buy one for certain types of wheels. Recommended 36T)
  • $10 – HTD5 belt (after you figure out the spacing and mounting, you’ll want to measure and buy this to fit perfectly)

Electrical Components

  • $70 – Motors (The general rule of thumb is to use a Brushless DC Outrunner motor with over 1000W and below 300 KV)
  • $110 – ESC (Electronic speed controller which determines how fast the motor should spin. Check out the VESC that is being developed specifically for electric longboards)
  • $60 – Batteries (LiPo batteries are the most common, and these are commonly used)
  • $35 – Controller (Some people used a generic RC car controller, but I went the Wiiceiver route and a Wireless Wii Nunchuck)

Total: $565 with quality parts!



Starting Development with Amazon Echo

Here’s a simple guide on how to create a Node.js app hosted in Azure that will handle your Amazon Echo‘s API calls.

amazon-echo

  1. You will want to download and install Node.js if you haven’t already.
  2. Download the code from the repository here.
  3. Create an Azure account if you haven’t already and create a new web app.
  4. Using FTP, Git, or whichever method you would like, get the code into the location for your new azure web app.
  5. Join the Amazon Developer program for the Echo and create a new Echo app. (Note: In order to use this while in development on your Echo, the account needs to be the same one that the Echo is linked to)
  6. In your App information tab:
    1. Fill out your “App Name”. This will act as your official app name.
    2. Fill out your “Spoken Name”. You will want this to be short and simple to say in order to give it the easiest time to recognize.
    3. Give your “App Version” which will need to match the info you hand back through the API.
    4. Give your “App Endpoint” which will be your Azure webapp’s URL + the api endpoint. (Example: “https://echotest.azurewebsites.net/api/echo”)
  7. In your Interaction Model:
    1. Fill out your “Intent Schema”. The intent is the name of the function, slots are parameters, and the type when “literal” will give you back the speech-to-text recognized word. More info on this here.
    2. Fill out your “Spoken Utterances”. They should be tab separated between the intent and the sample phrases. Something interesting to note is that they suggest that you provide a sample for every number of literal device phrases from min to max. (In my case from 1-3 words, thus the repetitions.) It also does not like it when you have multiple of the same literals anywhere in the file.. More info on this here.
  8. After this, set your app to be ready for testing and you are on your way!
  9. Call Alexa with your Spoken Name by saying “Alexa, open {YourSpokenAppNameHere}”
  10. Now you can say the commands that you’ve designated in both your Nodejs web app and your Amazon app declarations for your response!

If you want to make it your own, you will need to modify the Node.js back-end to respond according to the requests that you allow while also altering your intent schema and spoken utterances.

 



Amazon Echo: Should I buy?

amazon_echoThe Amazon Echo is a home automation maker’s dream. It provides an easy way to use voice recognition to interact with your devices, but there are a couple things you should know about developing for it before you buy one and start.

  1. Despite it being called an Echo “App”, your development will take place in a web-service hosted in the cloud that can answer it’s calls. What the Echo will do is translate what it hears into text and then hand it off to your service by calling your API with a package that contains the information.
  2. Creating an “app” with Amazon for the Echo requires you to fill out an “Interaction Model” which consists of an “intent schema” and “sample utterances” as well as program your web-service.
    • The “intent schema” is pretty straightforward and you basically create a JSON array of “intent” which contain a name and “slots” which are used like parameters and you must define the type.
    • The “sample utterances” are a list of the “intent name” and potential sample phrases.

Making it talk to a web service hosted in Azure using Node.js turned out to be fairly trivial and I was able to get a basic implementation hooked into the OpenSmartHub that I have been developing in less than a couple hours. I even created a sample in a github repository for those who want simple instructions and an easy place to start.

It really is amazing to see it come together and interact with your voice commands in a custom scenario that you have developed, but still has a long way to go in order to improve it’s voice recognition. It works really well with the pre-programmed functions, but there aren’t that many that I find particularly useful in an every day scenario and it doesn’t do well with brands or non-dictionary words. For example, it recognizes “Pandora” because it’s a vital part of their pre-programmed functionality, but it doesn’t recognize “Yamaha” or “Wemo” well.

Another thing that I’ve noticed is that it can sometimes mix up the singular and plural versions of words when converting text-to-speech. (For example, mine would sometimes hear “lights” when I say “light”)

Overall, I think it’s going to only improve from here and I think it’s worthwhile to invest into in order to integrate voice-recognition and voice commands into your homemade projects!



Make It Dead Simple: Documentation

Lately I’ve been writing a lot of documentation, instructions, and guides for work, Hackster.io, and my side-project (Open Smart Hub). Most of the time the instructions needed to be compiled from multiple sources but kept simple and digestible. As a long time consumer of documentation, I’ve come to a couple realizations about instructions and guides. The most important is:

Make it dead simple. It should be fool-proof and easy to follow.

Don’t make assumptions about a reader’s skill level, the more knowledgable readers will skim over the instructions they already know, but newcomers will treasure those details.

How?

  1. Draw up a storyboard of the steps. Just like primary school, where they would tell you to brainstorm on a sheet of paper before writing an essay. This will help you figure out if there are any missing parts before you get into the nitty gritty details, whether or not the ordering makes sense, and if you need more research as well.
  2. Start with a schematic of the parts (if it’s a hardware related or multiple component documentation)
  3. Add pictures (these always help clarify for the unsure)
  4. Be concise. Make sure that each word added to your documentation adds value.
  5. Don’t overwhelm your reader. (Avoid using acronyms unless you have elaborated on them earlier in the documentation)

Making this kind of robust yet straightforward documentation takes time, but it will also reduce the amount of support and questions you might receive about it in the future.



Buy vs. Build a 3D Printer

I have been spending part of my spare time working slowly to get my Prusa i3 built and I am just now finishing the build. I’ve run into multiple problems throughout the experience and thought I would let you in on some of the frustrations. Here are some of those issues to keep in mind:

  • Sourcing all of the metric vs. inches components. Make sure that if you pick one, you stick with it for all the parts or be prepared to figure out which parts will require updates to the .scad files since they will need to be altered to fit your custom components. (Hint: metric is easier for following instructions but harder to source in the US)
  • While your dimensions may be right in the scad file, once printed, they may not match exactly to your specifications and may need to be reprinted.
  • There are many different models for each 3D printed part based on individual scenarios. If you are following instructions for a build, try to use their parts/print designs.
  • There are plenty of options for every component from the the hot-end to the extruder, bolts, rails, etc. and this makes sourcing the right 3D printed parts with the right bolts, nuts, etc. a lot more cumbersome than I initially expected.

Final Thoughts:

If you want to get the experience of building a 3D printer on your own or getting a cheaper 3D printer, the best solution is to buy a kit and then build it. You can alter most designs later to suit your desires. Since most kits for a Prusa i3 use the same Arduino Mega and RAMPS board setup, the software to control add-ons is pretty simple to change.

Now that I have gone through the process of sourcing and building my own, I wish I had just bought a kit and assembled all of those parts myself in order to save myself time, money, and frustration.

Node-OpenZWave on Raspberry Pi 2

As a continuation of my Open Smart Hub project I have been interested in adding Z-Wave and Zigbee devices to my supported devices and recently decided to swing for Z-Wave devices first. I bought a Z-Wave Z-Stick Series 2 USB Dongle from Aeon Labs and a simple Z-Wave Door Sensor in order to create the basic mesh network with just two devices.
z-wave-usb-stick

Since the Open Smart Hub is based in NodeJS, it only made sense to search for a Node port of the OpenZwave library. I stumbled upon Jonathan Perkin’s port of it to NodeJS (https://github.com/jperkin/node-openzwave)

Unfortunately, it does not work on Windows, and it seems to be having issues with the latest version of NodeJS… But luckily (or coincidentally) the Open Smart Hub runs on a Raspberry Pi 2 running Raspbian and NodeJS v0.10.28.

After the initial setup of my RPi2 with NodeJS, I got to work getting the node-openzwave module on my RPi2. I was seeing build errors when it was trying to install the module, but found a couple of blogs with information that in order to get it to work I might have to install a couple more tools.

sudo apt-get install build-essential make subversion
sudo apt-get install subversion libudev-dev make build-essential git-core python2.7 pkg-config libssl-dev

After that, it worked and I could call “npm install openzwave” and have it install properly.

Note: If you are interested in using it on Mac OSX, you will need to install the drivers for it. Read more about that process in a previous blog post.

Aeon Labs Z-Stick Series 2 on Mac OSX

z-wave-usb-stick

Aeon Labs, the makers of the Z-Stick, a USB dongle for implementing a Z-Wave controller, don’t seem to provide information on how to get it setup on various operating systems and using it for the OpenZWave library on Mac means that you’ll need to be able to access it through the /dev/ directory. In order to do this on Mavericks, you need to install the latest drivers for the USB stick: http://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx

After finishing the install, it should now be visible as /dev/tty.SLAB_USBtoUART if you open a console on OSX and type ls /dev/

From here you can begin to use the Z-Stick by calling on the /dev/tty.SLAB_USBtoUART endpoint.