HAL 9000: Wiring

BOM

Wiring

This slideshow requires JavaScript.

With the Raspberry Pi as the centerpiece, I went about connecting everything together.  The first step was wiring up the sound.  I took a stereo audio cable plugged into the Raspberry Pi’s audio port and wired each of the left and right channels into its own amplifier.  The power and ground of both amplifiers was sourced from the Raspberry Pi’s 5V and GND pins on the GPIO header.  I then wired the outputs of one of the amplifiers to the speaker.  The outputs of the other amplifier were wired to the LED in the button.  By doing this, the light inside of HAL’s eye would flash in sync with the audio being played.  Aside from that, all that was left to do was plug in the USB microphone and I was done.  One optional addition I might make in the future is wiring up the inputs of the button.  This would provide the possibility to activate Alexa via means other than the wake word.

HAL 9000: Alexa Install

I originally thought this blog post was going to be a lengthy explanation of how to install the Alexa software (found here) on the Raspberry Pi 3 with all of the caveats, tweaking, and reconfiguration necessary to get the software to install.  Any Linux user who frequently installs software from source knows that the time it takes to get some software to compile and install is exponentially proportional to the complexity of the code and the compile time.  This is not the case here.

It did take roughly an hour to run the automated install script provided in the Alexa repository, but once that had completed everything ran almost perfectly right out of the box.  I’m utterly floored by this, and am incredibly impressed with the Alexa development team on the quality of their software project.  So really, if this is something you’re interested in doing, use their guide to set up everything.  All you really need is a Raspberry Pi 3, a microphone (I used this one), and a speaker (I used one from Adafruit which I’ll discuss in detail in my post on wiring).  The only thing I had to tweak was forcing the audio to be output on the 3.5mm jack using raspi-config and selecting the jack in Advanced Options->Audio.

And without further ado, my working example.

HAL 9000: Overview

A HAL 9000 replica has been on my “to make” list since Adafruit started stocking their massive, red arcade button.  They even created a tutorial for building a HAL replica!  When the Alexa developers added support for a wake word last month, I knew I had to build it.  Rather than simply playing sound effects with the Pi, I wanted to include Amazon’s new Alexa sample that allows to run the Amazon Echo software on the Raspberry Pi 3.  Always a fan I tempting fate, I thought the HAL replica would be the perfect container for a voice assistant that has access to all of my smart home appliances.  What could go wrong?

OpenADR: Data Visualization

As the navigational algorithms used by the robot have gotten more complex, I’ve noticed several occasions where I don’t understand the logical paths the robot is taking.  Since the design is only going to get more complex from here on out, I decided to implement real time data visualization to allow me to see what the robot “sees” and view what actions it’s taking in response.  With the Raspberry Pi now on board, it’s incredibly simple to implement a web page that hosts this information in an easy to use format.  The code required to enable data visualization is broken up into four parts; the firmware part to send the data, the serial server to read the data from the Arduino, the web server to host the data visualization web page, and the actual web page that displays the data.

Firmware

The firmware level was the simplest part.  I only added print statements to the code when the robot changes speed or reads the ultrasonic sensors.  It prints out key value pairs over the USB serial port to the Raspberry Pi.

Serial Server

The Raspberry Pi then runs a serial server which processes these key value pairs and converts them into a dictionary representing the robot’s left motor and right motor speeds and the obstacles viewed by each ultrasonic sensor.  This dictionary is then converted into the JSON format and written out to a file.

This is an example of what the resulting JSON data looks like.

Web Server

Using a Python HTTP server example, the Raspberry Pi runs a web server which hosts the generated JSON file and the web page that’s used for viewing the data.

Web Page

 

The visualization web page uses an HTML canvas and JavaScript to display the data presented in the JSON file.  The velocity and direction of the robot is shown by a curved vector, the length representing the speed of the robot and the curvature representing the radius of the robot’s turn.  The obstacles seen by the five ultrasonic sensors are represented on the canvas by five points.

DataImage

The picture above is the resulting web page without any JSON data.

Here’s a video of the robot running alongside a video of the data that’s displayed.  As you can see, the data visualization isn’t exactly real time.  Due to the communication delays over the network some of the robot’s decisions and sensor readings get lost.

Further Steps

Having the main structure of the data visualization set up provides a powerful interface to the robot that can be used to easily add more functionality in the future.  I’d like to add more data items as I add more sensors to the robot such as the floor color sensor, an accelerometer, a compass, etc.  At some point I also plan on creating a way to pass data to the robot from the web page, providing an interface to control the robot remotely.

I’d also like to improve the existing data visualization interface to minimize the amount of data lost due to network and processing delays.  One way I could do this would be by getting rid of the JSON file and streaming the data directly to the web page, getting rid of unnecessary file IO delays.  The Arduino also prints out the ultrasonic sensor data one sensor at a time, requiring the serial server to read five lines from the serial port to get the reading of all the sensors.  Compressing all sensor data to a single line would also help improve the speed.

Another useful feature would be to record the sensor data rather than just having it be visible from the web page.  The ability to store all of the written JSON files and replay the run from the robot’s perspective would make reviewing the data multiple times possible.

OpenADR: Connecting to Raspberry Pi

2016-06-11 23.25.45

The most frustrating part of developing the wall following algorithm from my last post was the constant moving back and forth between my office, to tweak and load firmware, and test area (kitchen hallway).  To solve this problem, and to overall streamline development, I decided to add a Raspberry Pi to the robot.  Specifically, I’m using a Raspberry Pi 2 that I had lying around, but expect to switch to a Pi Zero once I get code the code and design in a more final state.  By installing the Arduino IDE and enabling SSH, I’m now able to access and edit code wirelessly.

Having a full-blown Linux computer on the robot also adds plenty of opportunity for new features.  Currently I’m planning on adding camera support via the official camera module and a web server to serve a web page for manual control, settings configuration, and data visualization.

While I expected hooking up the Raspberry Pi as easy as connecting to the Arduino over USB, this turned out to not be the case.  Having a barebones SBC revealed a few problems with my wiring and code.

The first issue I noticed was the Arduino resetting when the motors were running, but this was easily attributable to the current limit on the Raspberry Pi USB ports.  A USB 2.0 port, like those on the Pi, can only supply up to 500mA of current.  Motors similar to the ones I’m using are specced at 250mA each, so having both motors accelerating suddenly to full speed caused a massive voltage drop which reset the Arduino.  This was easily fixed by connecting the motor supply of the motor controller to the 5V output on the Raspberry Pi GPIO header.  Additionally, setting the max_usb_current flag in /boot/config.txt allows up to 2A on the 5V line, minus what the Pi uses.  2A should be more than sufficient once the motors, Arduino, and other sensors are hooked up.

The next issue I encountered was much more nefarious.  With the motors hooked up directly to the 5V on the Pi, changing from full-speed forward to full-speed backward caused everything to reset!  I don’t have an oscilloscope to confirm this, but my suspicion was that there was so much noise placed on the power supply by the motors that both boards were resetting.  This is where one of the differences between the Raspberry Pi and a full computer is most evident.  On a regular PC there’s plenty of space to add robust power circuitry and filters to prevent noise on the 5V USB lines, but because space on the Pi is at a premium the minimal filtering on the 5V bus wasn’t sufficient to remove the noise caused by the motors.  When I originally wrote the motor controller library I didn’t have motor noise in mind and instead just set the speed of the motor instantly.  In the case of both motors switching from full-speed forward to full-speed backward, the sudden reversal causes a huge spike in the power supply, as explained in this app note.  I was able to eventually fix this by rewriting the library to include some acceleration and deceleration.  By limiting the acceleration on the motors, the noise was reduced enough that the boards no longer reset.

While setting up the Raspberry Pi took longer than I’d hoped due to power supply problems, I’m glad I got a chance to learn the limits on my design and will keep bypass capacitors in mind when I design a permanent board.  I’m also excited for the possibilities having a Raspberry Pi on board provides and look forward to adding more advanced features to OpenADR!

Maker’s Tablet

For the past year or so I’ve had a project on my project list called the PiPad+.  The details on the project page are pretty generic, describing it as a DIY tablet.  I’m hoping to remedy this by fleshing out the project details and motivating myself to finish it in the coming weeks.

Like most of the Maker community, I was amazed when the PiPad came out.  When Chalk-Elec got their 10″ displays back in stock I quickly bought one so I could create my own version of the PiPad.  Of course, being myself, I couldn’t just copy what had already been done.  I had to do something new and exciting.  Right off the bat I decided I would get rid of Raspbian’s default GUI and do something new that was optimized for touch controls and my personal tastes.  I got as far as implementing a basic window manager and a grid-style homescreen before I “took a break” because GUI design is hard!  For the past year the code lived in my GitHub, gathering digital dust, until very recently when I decided to delete it.

During the long “break”, the project was also subjected to a good deal of feature creep and component scouting.  Many things have also changed in that time; I bought a 3D printer, the Raspberry Pi 2 was released, etc.  Rather than continue to let this project stagnate in its project drawer I’ve decided to try to finish up the project in the near future so I’m no longer plagued by the inexorable desire to shove in as many features as possible.  The semi-final state of the project will be as follows.

Processor:

I chose to build my tablet around the Raspberry Pi due to the large amount of community support behind the SBC.  The huge number of people tinkering with the Pi’s OS ensured that I’d be getting the maximum performance available for the hardware.  I’m currently using a Raspberry Pi 2, though I will probably upgrade to the Raspberry Pi 3 once it becomes available.  The built in WiFi and BLE will help save space inside of the tablet.  The only downside with using the Pi is the size.  Due to the dimensions of the USB port the thickness of the tablet will have to be around 2.5cm.  Rather than attempting to slim down a Pi, I opted to utilize the thickness to cram the tablet full of features as detailed below.

Screen:

Due to the amount of stuff I wanted to cram in this tablet I decided to get Chalk-Elec’s 10″ Touchscreen to use as the tablet display.  If things get too cramped I might consider upgrading to one of their bigger displays.

Battery:

For the battery I decided on an EasyAcc 10Ah Battery, commonly used as a portable phone charger.  I chose this battery because it was the largest one I could find that would fit in the tablet chassis.  It also has pass-through charging, a feature which allows the battery to power the tablet while it’s being charged.  Surprisingly, this is a rather uncommon feature in portable battery packs.

Extra Features:

Rather than building a basic tablet that won’t get much use, I decided to add extra features that would enable my version of the PiPad to be the ultimate Maker’s tablet.  The extra added features are detailed below.

Multimeter

The most important tool in a Electrical Engineer’s toolbox is his multimeter, so this one was a must have.  However, I had trouble finding a small and cheap USB multimeter, so instead I opted to make my own.  I borrowed heavily from this Instructable when designing my custom board.

Oscilloscope

An important tool for working with analog circuits is an oscilloscope.  A few months prior to starting this project I bought an Xprotolab Plain, which is a nifty little USB oscilloscope that’s surprisingly cheap.  Due to its small size I decided to add this into the tablet.  I also created an adapter to go from the Xprotolab’s header to a standard BNC connector.

Logic Analyzer

The Xprotolab Plain also had a Logic Analyzer built in so this one was a freebie.  The logic level is only 3.3V, however, so I’m toying with the idea of making an adapter to add 5V tolerance.

Bus Pirate

The Bus Pirate seems to be a commonly used tool by many makers and hackers.  I don’t have any experience with it, but decided to include it in the tablet since it didn’t take up much space.  I decided to go with version 3.6 of the hardware as that seems to be the most widely supported.

GPIO Header

Lastly, because I wasn’t using them for anything I decided to add a breakout for the Raspberry Pi’s GPIO to the tablet.  This would add some additional IO to fiddle with and was simple to add.

Plans

The components that will hopefully make the tablet are currently sitting on my workbench in a rough semblance of how they will be organized inside of the tablet.  The steps that I still need to take in order to get everything working are listed below:

  1. Populate, solder, and test the multimeter
  2. Determine how to organize the power subsystem
  3. Decide on a semi-final organization of all the parts’ locations inside of the tablet
  4. Finalize the 3D printed bezel with connector cutouts
  5. Glue the mechanics together
  6. Secure the components inside of the tablet with double sided and Kapton tape
  7. Connect everything together
  8. Design and attach a removable back plate
  9. Decide on whether to use Raspbian’s default window manager or design my own

Over the next few weeks I’ll start going through each step, trying to finish up the tablet hardware so I can move on to other projects.  For the components that I’ve custom built, I’ll post source files and separate blog posts to explain how I’ve designed these parts, and how they work.

Home Maker Server

Being a generally disorganized person who works as a professional engineer, I’ve noticed that the tools I use at work have really helped me stay organized and focused.  After noticing this, I’ve decided to utilize some similar tools for my personal projects to keep me organized and motivated, and also to apply a professional touch to my hobbies.  The most useful tools I’ve used at work are part databases, a version control system, and an issue tracker.  Since the specific tools I use at work are targeted towards large companies and therefore have expensive licenses, I’ll be using open source or free alternatives.  In addition to the tools I mentioned, I’m also going to install a 3D printing server so my Printrbot is no longer tethered to my main PC and prints can be uploaded and controlled from anywhere.  I’ve bought a Raspberry Pi 2 Model B specifically to handle this software and become my official home maker server.  The software that I’ll be installing as well as links to installation instructions are as follows:

PartKeepr

PartKeepr – A part database.  I’m constantly losing, buying multiples, and rediscovering parts so this will help give me a clear snapshot of all of my components, allowing me to better plan out projects and determine part requirements.  I used this blog post for installation instructions, but here are a few quirks I noticed when installing:

  • I had to copy the partkeepr folder to /var/www/html rather than /var/www since that was the default root directory for my apache server
  • I had to be logged in as the super user (sudo su) for the pear part of the installation or it wouldn’t work

GitHub

Github – I don’t anticipate developing closed source code in the foreseeable future so I’ll just be using Github for version control.

Trello

Trello – A simple issue tracker with a convenient web interface.  There’s not a lot of advanced functionality but it should be sufficient for what I want to do.  Originally I was going to use a more sophisticated issue tracker called Trac because it has integration with version control and a built-in wiki, but decided against it.  It would be another service to install and host on my Raspberry Pi and the additional complexity might deter my productivity.  In addition, not having a private wiki could serve as encouragement to keep my projects better documented on this blog.

Octoprint

Octoprint – A 3D printing management server.  It provides network access and a web GUI for uploading prints and viewing printer status.  The installation instructions I used are from their GitHub page.