OpenADR: Mop Module v0.1

For the sake of design simplicity and ease of assembly, the mop module is broken up in to two main parts based on the module base design.  The front of the module (the 150mm^2 square) is devoted almost entirely to the water storage tank and the rear is where all of the electronics and mechanics are.

IMG_0636

The picture above is a failed print of the front part of the mop module.  Rather than just tossing this piece, I ended up using it to test out the waterproofing capability of the XTC-3D print sealant.  It ended up working perfectly.

Despite the failed nature of the above print, it still demonstrates the main sections of the front of the mop module.  The main water tank is bounded by two walls, the left in the picture being the back wall of the water tank and the right wall being the front.  The small gap between two walls on the right side of the picture is the location of some holes in the base of the module that will allow for the water to be evenly dripped onto the floor.

IMG_0638

This bottom view of the part gives  a better view of the holes

IMG_0639

Two holes in the back of the water tank provide an input to the pumps.  Because combining electronics and water is a big no no, I added some holes in the bottom of the module so that any leaks around these holes would drip onto the floor rather than flooding the electronics section.

IMG_0640

This is the back of the mop module where all of the magic happens.  The holes in the bottom provide mounting points for the two motors that will drive the pumps.

IMG_0641

The two pillars in the very back provide a point to mount the base of the pump.

IMG_0644

The two, dual-shaft motors have one output shaft extending out of bottom that will be connected to the scrubber and one extending upwards that will be driving the pump.

IMG_0645

A picture of the downwards facing shafts.

IMG_0646

The above picture shows the back of the module with all of the hardware mounted.  Unfortunately, I didn’t give enough space for bolt heads that hold the motor in place.  The pumps can’t pushed down as far as I intended and so they don’t line up with the holes I left in the mounting pillars.  Luckily the mounts are sturdy enough to mostly hold the pumps in place and so I don’t need to mount them for testing purposes.

IMG_0648

These are the two halves the the scrubber that will hold the microfiber cloth that will be used to scrub the floor and soak up excess water.  The two halves are made to be pressed together with the cloth sandwiched in between them.

IMG_0649

This picture shows the cloth and scrubber assembled.  I underestimated the thickness of the cloth, so two won’t currently fit side by side.  I’ll need to either make the cloth smaller or move the scrubbers farther apart.

IMG_0650

Above is an overall picture with all of the pieces put together.

 

OpenADR: Esp32 Initial Test

As I mentioned in a previous post, I’m attempting to test the ESP32 as a cheap replacement for my current Raspberry Pi and Arduino Mega setup.  I’m hoping that doing this will save me some complexity and money in the long run.

Unfortunately, with the ESP32 being a new processor, there’s not a lot of Arduino support implemented yet.  Neither the ultrasonic sensor or the motor driver libraries compile yet due to unimplemented core functions in the chip library.

Luckily a new version of the ESP-IDF (IoT Development Framework) is set to be released November 30,with the Arduino core most likely being updated a few days later.  This release will implement a lot of the features I need and so I’ll be able to continue testing out the board.  In the mean time I plan on adding more sensors to the Navigation Chassis v0.3 in preparation, as well as working on some other projects.

OpenADR: New Controller Options

One of the reasons for my hiatus from OpenADR is due to some uncertainty when it comes to the main processor for the robot.  My current implementation uses a Raspberry Pi for general control and data logging with an Arduino Mega handling the real-time code.  However, these two boards result in a combined price of $80 ($35 for the Raspberry Pi and $45 for the Arduino).  Requiring these parts would make the total cost of the navigation chassis much higher than I’d like.  These parts might also make it more difficult to manufacture OpenADR if I ever decide to turn it into a product.  While I could always create a custom board based on the Arduino Mega, the Raspberry Pi isn’t exactly manufacturing-friendly.

These reasons are why I’m exploring alternative options for the main controller for OpenADR and through my research I’ve discovered two options that I’m pretty excited about.  Both the C.H.I.P. Pro and ESP32 are powerful processors that could potentially be used for OpenADR, with the former being similar to the Raspberry Pi and the latter being closer to an Arduino.  Below is a comparison of specs and a description of how they could be used.

C.H.I.P. Pro

The C.H.I.P. Pro is an embedded Linux module produced by Next Thing Co. and is advertised as a solution for products requiring embedded Linux.  It has onboard WiFi and Bluetooth, and has an ARM Cortex-A8 processor with 256MB or 512MB of RAM running at 1GHz.  An added benefit is the Gadget ecosystem that Next Thing Co. announced.  They haven’t released too many details, but the impression I got is that it’s a Linux package that allows for easy and secure updating of products running on the C.H.I.P. Pro system.  My expertise starts to fuzz when it comes to product software management, and I know very little about security, so having an ecosystem that would make this easier would help me a lot.

One possible downside is that embedded Linux isn’t always good enough for real time applications.  While the board might have enough GPIO to connect to the robot’s peripherals, they might not be able to update outputs and read data fast enough for what I need the robot to do.  For example, any timing delays in the reading of the ultrasonic sensors could lead to incorrect distance data that would inhibit the robot’s ability to understand and map its environment.  This is something I can experiment with when I receive my development kit.

ESP32

The ESP32 is the other side of the embedded systems coin.  It doesn’t run Linux, but instead uses a Tensilica LX9 microprocessor with 520KB of RAM running at 240MHz.  It also has WiFi and Bluetooth built-in.  The plus side of a bare metal system is that there’s less concern about delays and real time control with the robot’s peripherals.  The downside is that this makes it much harder to write software for the robot.  A lower level language would need to be used and without Linux or the features of a more powerful processor, certain features, such as real time data logging, may be harder to manage and implement.

While different processor architectures aren’t always directly comparable, the ESP32 does run a 15x the speed of the Arduino Mega I’ve been using so far.  So while it might not be able to compete with a Raspberry Pi or C.H.I.P. Pro in terms of data processing, it’s way more powerful the Arduino and it will probably still be possible to implement the more complex features.  I currently have SparkFun’s ESP32 Thing development board on my desk and look forward to testing it out with OpenADR!

 

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?

HAL 9000: Replica Design

For my design of the HAL 9000 enclosure, I mainly used Adafruit’s HAL 9000 replica guide as a baseline.  However, I decided to 3D print most of the pieces since I don’t have access to a laser cutter or any power tools.

This slideshow requires JavaScript.

The only piece that I ended up buying was the button, so I followed that section of the tutorial closely, but mainly used the linked references for the design of the case.

img_0770

Because of the 250x150mm limitation of the print bed, I broke up the case into parts.  The two outside sets of pieces are the vertical walls of HAL, the two pieces with center holes are horizontal walls that will have wiring run through them.  The top piece on the center-left side is the top of HAL.  The piece with a grid of holes is the speaker grill.  Lastly are the two black pieces, which form the main plate with a hole for the red “eye.”  Also notice the black rectangle at the top; this will be the space to put the HAL 9000 label.  I left this to save myself time measuring when applying the label.

img_0779

The next step was gluing all of the pieces together, and HAL starts to take shape!

img_0784

Because the plate is black, even if I don’t cut the label to the exact size, it won’t be noticeable.

img_0788

The last step is popping in the painted button, and HAL 9000 is complete!

One additional step I’d like to use in the future is applying the same coating, sanding, and painting steps I used for the sword on HAL, to make the replica look more metallic and accurate.  This would not only help cover up the seams between parts but would also help me replicate the brushed aluminum look on the original HAL’s black face plate.