PiGRRL Switch: Controller Test Firmware

May 7, 2017 kelliott121 Projects Arduino, Bluetooth, emulator, Nintendo, PiGRRL, Switch

As a follow-up to my last post, I wanted to go over the Arduino firmware I used for my primary controller test. Essentially what it does is read the states of multiple buttons and print a sequence of 1’s or 0’s (1 for unpressed and 0 for pressed) to the Bluetooth module.

	enum DPad {RIGHT = 2, UP = 3, LEFT = 4, DOWN = 5};
	enum Buttons {A = 6, B = 7, X = 8, Y = 9};

	void setup() {
	// Set the DPad buttons to pullup inputs
	pinMode(RIGHT, INPUT_PULLUP);
	pinMode(UP, INPUT_PULLUP);
	pinMode(LEFT, INPUT_PULLUP);
	pinMode(DOWN, INPUT_PULLUP);

	// Set the action buttons to pullup inputs
	pinMode(A, INPUT_PULLUP);
	pinMode(B, INPUT_PULLUP);
	pinMode(X, INPUT_PULLUP);
	pinMode(Y, INPUT_PULLUP);

	Serial.begin(9600);

	delay(5000);
	}

	void loop() {
	// Print the Key packet
	// DPad
	Serial.print("K:");
	Serial.print(digitalRead(RIGHT));
	Serial.print(digitalRead(UP));
	Serial.print(digitalRead(LEFT));
	Serial.print(digitalRead(DOWN));

	// Action buttons
	Serial.print(digitalRead(A));
	Serial.print(digitalRead(B));
	Serial.print(digitalRead(X));
	Serial.println(digitalRead(Y));

	delay(10);
	}

view raw

BluetoothTest.ino

hosted with ❤ by GitHub

The whole program is embedded above and I’ll go through each section individually and explain what it does below.

	enum DPad {RIGHT = 2, UP = 3, LEFT = 4, DOWN = 5};
	enum Buttons {A = 6, B = 7, X = 8, Y = 9};

view raw

ControllerTestFirmware0.ino

hosted with ❤ by GitHub

These enums serve the purpose of defining human-readable names for the pins that are hooked up to the buttons. That way their usage in the code is immediately obvious upon reading.

This isn’t strictly necessary due to the simplicity of this program, but the general best practice is to not use integer literals in code.

	// Set the DPad buttons to pullup inputs
	pinMode(RIGHT, INPUT_PULLUP);
	pinMode(UP, INPUT_PULLUP);
	pinMode(LEFT, INPUT_PULLUP);
	pinMode(DOWN, INPUT_PULLUP);

	// Set the action buttons to pullup inputs
	pinMode(A, INPUT_PULLUP);
	pinMode(B, INPUT_PULLUP);
	pinMode(X, INPUT_PULLUP);
	pinMode(Y, INPUT_PULLUP);

view raw

ControllerTestFirmware1.ino

hosted with ❤ by GitHub

This is the pin mode setup in the Arduino setup() function. The buttons are hooked up directly to ground so that when the button is pressed, the pin sees 0V. When not pressed the pin is floating so here I’m enabling the Arduino’s pullup resistors so that when the button isn’t pressed the pin sees 5V.

	// Print the Key packet
	// DPad
	Serial.print("K:");
	Serial.print(digitalRead(RIGHT));
	Serial.print(digitalRead(UP));
	Serial.print(digitalRead(LEFT));
	Serial.print(digitalRead(DOWN));

	// Action buttons
	Serial.print(digitalRead(A));
	Serial.print(digitalRead(B));
	Serial.print(digitalRead(X));
	Serial.println(digitalRead(Y));

view raw

ControllerTestFirmware2.ino

hosted with ❤ by GitHub

Here the state of the buttons is read and printed to the Bluetooth module over UART. Because of the way pullups are handled, ‘1’ corresponds to unpressed and ‘0’ corresponds to pressed. The printing of the button states is preceded by a “K:” to act as a key-value pair. This means that when the controller driver on the Raspberry Pi sees a “K” it knows it’s about to get a list of digital buttons. I’m planning on using this in the future to enable more complex data than just a few buttons. For example, I could use the keys “JX” and “JY” to denote the two axis values of an analog joystick. The last serial print is a Serial.println() function call to print a newline character. This is an easy way to segment the data so the controller driver can differentiate between multiple packets.

delay(10);

view raw

ControllerTestFirmware3.ino

hosted with ❤ by GitHub

Lastly is the delay that sets the update rate of the program. With a delay of 10 milliseconds at the end of the loop, new button states will be sent to the driver at an update rate of roughly 100Hz. Right now this rate was arbitrarily decided, but in the future I’ll have to tweak it to balance several factors.

First off is the bandwidth of the Bluetooth connection. As far as I can tell, the HC-05 module uses Bluetooth 2.0 which has a data throughput of of 2.1 Mbit/s or 275251.2 bytes per second. Divide this by the update rate and you get the total amount of data that can be sent in one cycle of the program. This also assumes that the connection is perfect with no lost packets. Bluetooth’s serial port profile uses re-transmission to verify that packets sent are received. This means that wireless noise can cause the connection to slow down while the Bluetooth module is attempting to resend a bad packet. Additionally, if I go back to the BLE module and am able to get it working, BLE only has a throughput of 35389.44 bytes per second, or 13% of Bluetooth 2.0. So while I’d be saving power I’d be restricting the update rate and amount of data I can send from the controller.

Another thing to consider is the update rate of the controller driver running on the Raspberry Pi. Serial ports have buffers to store incoming data. This means that if the driver is updating slower than the controller, the driver won’t be able to process all of the data coming in and the buffer will overflow. This problem will exhibit itself as lag in the controls. The driver needs to be updating at the same rate, or faster, than the controller.

The last consideration is debouncing. This is a topic that has been extensively covered elsewhere, but suffice it to say that if the controller updates too fast it will accidentally send phantom bounces in the switch contacts to the driver and cause erroneous button presses.

Once everything has come together and is working to a degree I’m happy with, I’ll come back to these small issues and tweak everything until it works perfectly. Until then, my next step is writing the controller driver! As always, my code is available on my GitHub in the PiGRRL_Switch repository.

PiGRRL Switch: Creating the Controllers

April 27, 2017April 27, 2017 kelliott121 Projects Arduino, Bluetooth, Circuit Design, Gaming, Raspberry Pi

With the screen chosen and working, the next step for creating the PiGRRL Switch was prototyping the controllers. Initially, I wanted something cheap and easy like a breakout board that acted as a Bluetooth HID joystick. I was immediately drawn to Adafruit’s EZ-Key which acts as a Bluetooth keyboard. At the time I’m writing this, however, it’s out of stock and seems to have been for a while. Additionally, because it acts as a Bluetooth keyboard and not a joystick, it rules out any possibility of adding analog controls in the future.

Another alternative to a Bluetooth HID breakout would be taking apart a cheap Bluetooth joystick and putting it in a 3D printed casing. However, I decided this would greatly reduce the design flexibility of the controllers and might make it difficult to reconfigure the controllers on the fly (i.e. using two JoyCons as one controller vs. using them as two separate controllers).

So with those two options off the table I decided instead to use a Bluetooth serial bridge. The HM-10 BLE and HC-05 Bluetooth 2.0 modules are both cheap and plentiful and provide a good solution at the cost of some extra work. These modules can be hooked up to the UART of an Arduino and paired via Bluetooth. Once connected, it acts as a virtual serial port in Linux, allowing the serial data to be read just as if the Arduino was connected via USB or FTDI. The only exception to this is that it doesn’t support firmware loading wirelessly.

2017-03-13 22.18.32

The next step was setting up the initial design on a breadboard. Above is an Arduino Pro Mini, four pushbuttons wired to the digital pins, and the HM-10 BLE module. I decided to use the HM-10 because of the lower power requirements (BLE being an initialism for Bluetooth Low Energy). The code for the Arduino reads the values from the digital pins and prints out eight characters to signify which buttons are pressed (‘1’ for unpressed and ‘0’ for pressed). Right now I’m using a byte for each button which is wasteful, so I’ll go back at some point in the future and make the code more efficient so each button is represented by a bit.

2017-03-14 22.50.16

Once everything was wired up and running I had a lot of trouble finding an app that could connect to the HM-10 as a serial terminal. Apparently the BLE standard has a lot of bells and whistles that make configuration a bit more difficult. After trying several different apps I eventually found Serial Bluetooth Terminal which can connect to both BLE and regular Bluetooth devices via a serial terminal. Above is screenshot of my phone connected to the controller with the button status being transmitted.

2017-03-14 20.31.24

2017-03-14 20.31.37

With my proof of concept working, I soldered everything onto a proto-board, this time with eight buttons to serve as a D-pad and four action buttons.

With that complete the next step was connecting to the Raspberry Pi over a serial terminal. Unfortunately, this was much more difficult than I expected. I could pair and connect to the HM-10, but couldn’t find a way to mount it as a serial terminal.

2017-03-15 21.01.17

Rather than continue further down the rabbit hole, I decided to drop the BLE module for now and switch to the HC-05 modules I bought as a backup. Those have been around for years and have been used extensively with Arduino and Raspberry Pi. Once that module was paired and connected, mounting it as a serial terminal was as simple as using the following commands to connect and then print out the values read from the module:

sudo rfcomm bind /dev/rfcomm0 <MAC Address>
sudo cat /dev/rfcomm0

2017-03-17 19.20.25

2017-03-17 22.01.22

Lastly I connected the controller, screen, and Raspberry Pi to battery packs and verified everything still worked as suspected. Success! The next step is writing a program for Linux that reads the button data coming off the serial port and uses it to emulate a controller for the console.

PiGRRL Switch: Choosing the Screen

April 12, 2017April 12, 2017 kelliott121 Projects

The centerpiece of any tablet or in the Switch’s case tablet-thingie, is the screen. Therefore, that seems like the best place to start my PiGRRL Switch design. But first, a brief list of the Switch’s display specs:

Size: 6.2 inches
Resolution: 1280×720
Type: LCD

Now the Raspberry Pi has a wide array of compatible screens, but unfortunately I’ve been unable to find a 6 inch one to match the size of the Switch. However, there are an abundance of 5 inch and 7 inch screens. This effectively means that my console display will have to be either larger or smaller than the Switch.

The 5 inch display I was looking at was from Elecrow with a resolution of 800×480. However, after looking at the dimensions of the display, it looks like it’s only slightly larger than the Raspberry Pi. This would require me fitting the supporting electronics (e.g. HDMI splitter, battery, etc.) into a small space. After the space concerns I ran into on my Raspberry Pi Tablet, I have no doubt I won’t be able to do this. So with that it mind, I decided to go with the larger, 7 inch display.

The two 7 inch displays I considered were Elecrow’s 7 inch display with a resolution of 1024×600 and Chalk-Elec’s 7 inch HD display with a resolution of 1280×800. I’ve used Chalk-Elec’s 10 inch display before for my tablet/oscilloscope project and was completely satisfied with it, but at two times the cost of Elecrow’s display I decided to go with the lower resolution. The highest resolution console of the first five console generations was the N64 with a output capability of 480i (or 576i for PAL regions). This means the 1024×600 resolution is more than capability of properly displaying any games I might want to play.

Because the screen input requires a specific resolution, the Raspberry Pi’s configuration file needed to be modified. I used this site as a guide. I added the following lines to /boot/config.txt

max_usb_current=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0

These lines increase the current to the USB peripherals and configure the HDMI to output the exact resolution required by the display.

PiGRRL Switch

April 5, 2017April 5, 2017 kelliott121 Projects

So keeping in line with my general theme of “anything big companies do, I can do worse” I’m going to attempt to make a retro game console stylized after the Nintendo Switch. Building a retro console is something I’ve wanted to do for a while now, but I’ve never gotten farther than a bare Raspberry Pi running RetroPie. Making this project would give me a retro console like I’ve wanted with some of the features provided by the Nintendo Switch. Another reason I wanted to do this project is because it’s been so long since I’ve done any high level programming or Linux development. With OpenADR moving away from Linux, this project will be a refreshing change of pace, a chance to brush up on old skills, and an opportunity to learn more.

And luckily for me, there are a ton of great resources that I can utilize for my build. RetroPie already has a great emulation console and interface with tons of users. Additionally, what I’m doing will be heavily based on Adafruit‘s PiGRRL. A lot of the design, programming, and resources are already there, I just need to remix them for what I’m trying to do.

Primary Goals

The main goals of the project are as follows:

For the Console:

Portable
Docking station for playing on the TV
Compatibility with a wide array of games (1st gen through 5th gen)
Enough resolution to do compatible games justice
Speaker(s) for sound in portable mode
WiFi and Bluetooth connectivity
USB charging
>= 2 hours of battery
Up to four players
Touchscreen

For the Two Controllers:

Easy to connect and disconnect from console
Wireless
1x D-pad
4x action buttons
Usable as a single controller or two separate controllers
>= 2 hours of battery
USB charging

Secondary Goals

The less important goals of the project are as follows:

For the Console:

High quality stereo audio
>= 4 hours of battery

For the Two Controllers:

Analog sticks instead of a D-Pad
Chargeable via console
Controller mount with external battery
Controller mount with wireless audio
>= 4 hours of battery
Bluetooth Low Energy
Easy way to dynamically switch controller configurations

Tertiary Goals

Some “nice to haves”:

For the Console:

>= 6 hours of battery

For the Two Controllers:

Accelerometer support
>= 6 hours of battery

Alien Clock: Finally Finished!

March 27, 2017March 23, 2017 kelliott121 Contests, Projects 3D Printing, Props, robotics

And with everything assembled the project is finished! There was a small amount of coding involved, but it was pretty simply and mostly self explanatory. The Arduino sketch can be found here on my GitHub. It’s really just a combination of the Arduino ToneMelody example, Adafruit DS1307 example, and my custom L9110S llibrary that I wrote for OpenADR. And without further ado, the final video!

Alien Clock: Painting All the Things!

March 24, 2017March 22, 2017 kelliott121 Contests, Projects 3D Printing, DIY, Props

So rather than make individual posts for painting each of the pieces, I decided to lump everything together. The Xenomorph design has varied a lot between depictions, so really there were no specific requirements for coloring and design. I wanted something similar enough to the original designs to be recognizable, but I wasn’t that concerned about fine details.

Disclaimer: Since I don’t have an artistic bone in my body, my wife was kind enough to do most of the painting for me. She did a far better job than I ever could have and everything turned out wonderfully!

Prior to painting, I coated all the prints and the styrofoam head in liquid latex, which was an interesting experience. The bottle I purchased advertised that it was good for monster make up or making scars on faces, but it was difficult to work with to make a smooth surface. Luckily, the dried latex peeled off really easily, which was convenient in the case of mistakes but also sometimes peeled off too easily. After several tries, however, all the pieces had a nice matte finish and fleshy look to them.

Facehugger

Since Freddie the Facehugger is so large, we were a little concerned about keeping the color scheme constant if we went with the same messy approach used for Charlie. Instead, she mixed a ton of light yellowy greenish gray (again, technical terms!) as well as a darker, browner version and a deeper dark gray/brown for shadows. She coated the whole thing with the lightest shade and then contoured the edges and details with the darker colors. This approach was less detailed than mixing small amounts of each creepy bloody shade for Charlie, but it was the easiest way to keep this consistent from the tail all the way out to the arms. One extra challenge with Freddie was all the joints. We wanted to cover as much of the white PLA as possible while still allowing some flexibility. To solve this problem, we used a very watered down paint that was more translucent but soaked into the joints better and did a good job of covering all the visible white sections.

Chestburster

For Charlie the Chestburster, she painted a base coat of yellowish peachish brown (that is the technical term for it, I believe) with some gray mixed in for texture and then added darker gray to the shadows and details to help define them. For the blood, she mixed a bright red paint with black, brown, and green to get a deeper color and painted this on thick in splotches and also watered it down to stain other areas. This was a lot of just splashing paint around and hoping for the best, but the messy look really turned out well!

Mannequin

For the face itself, I just spray painted the styrofoam head model with two coats of “Skin colored” paint. The model had some stains and marks on it when I got it, but this really covered them up well. Plus, his face will be pretty much hidden anyway (poor guy).

Clock Hands

The clock hands were just black and gray paint mixed together. We had to do two coats to get in all of the grooves of the uncoated PLA. The benefit of this is that it lets some of the white plastic show through and gives the “tails” a more textured look.

3D Printed Sword: Build

March 11, 2017 kelliott121 Projects, Techniques 3D Printing, DIY

Printing

Material

The filament I decided to use was silver Hatchbox PLA. After printing the coloring of the plastic turned out more of a shiny gray than a silver. While I knew I was going to paint the sword anyway, I wanted a grayish base color so that the color of the filament wouldn’t show through. Plus, if the sword ever gets scratched, the dull gray scratch color will look more realistic.

Settings

My biggest concern for the printed parts used for the sword was the strength, specifically the strength between print layers. This was most critical on the blade of the sword, due to its length and weight providing a lever arm that could cause the prints to snap. Additionally, due to the way I decided to print out the blade, speed became an issue. I oriented the sword segments so that the blade was divided along the X-Y plane. This meant that the longest axis was in the Z direction. The Z-axis is also commonly the slowest on a 3D printer, mainly because a leadscrew is usually used. To compensate for all of these design concerns, I tried to find an optimal balance between weight, strength (particularly layer adhesion), and print time.

After reading numerous studies and suggestions, I decided on a layer height of 0.3mm and width of 0.4mm. I also ran the hotend a little on the hotter side at 210C. Because I planned on sanding and finishing, allowing for a little stringing (a common result of too-high hotend temperature) was well worth the added strength and layer adhesion it provided. I also kept the infill a little low at 10% so the blade wouldn’t be too heavy.

The 18 50mm segments of the blade are shown above. They turned out pretty good with minimal stringing. One noticeable feature on the outside of the blade segments are the vertical lines. These are caused by interaction between the internal hole perimeters and outside perimeters. There’s isn’t enough space for both sets of perimeters and so some external artifacts are present on the outside. Luckily these can be easily hidden by the finishing process.

The two halves of the pommel didn’t turn out as well as I’d hoped. Because I printed with the center of the pommel on the bed, there wasn’t enough support for the circular arch that would hold the grip. This can hopefully be fixed with some sanding and finishing. Also shown above is the hole that the blade will be glued into.

Lastly are the grip and pommel. The grip was printed in two halves and held together by a metal spine. Three 2mm holes were extended through the length of the grip so the pommel and blade could both be securely attached.

Assembly

The majority of the build time was spent assembling the blade, because it’s the most complex part. I used cyanoacrylate glue (super glue) due to it’s good adhesion to PLA. The brand I used was also labeled as “gap filling.” I figured this would be useful if the tops and bottoms of the blade segments were slightly warped or didn’t match up properly.

I also used a metal spine to prevent stress on the glue joints and provide additional strength to the blade. Due to the metal pieces only being 300mm long, I trimmed the rods so that, when transitioning from one rod to another, the joint is in the center of a blade segment.

I was able to fit three metal spines at the wider base of the blade.

I cut the metal rods so that a decent portion would protrude from the bottom. These extra length could then be used to mount the blade to the grip.

With the pieces all glued together, the next step was coating it!

Finishing

The process of finishing the blade was divided into three main parts, coating, sanding, and painting, with an additional step of leather wrapping the grip. These steps weren’t terribly difficult, but nevertheless the finishing took a long time, with each step requiring patience.

Epoxy Coating

This slideshow requires JavaScript.

The first step in finishing the sword involved coating the plastic in epoxy. The brand I used was XTC-3D. It works like most epoxy, involving mixing the two parts together to get a rapidly curing mixture. I then had about five minutes before the epoxy hardened to brush it on to the plastic. After this was a four hour wait for the epoxy to finish curing. Once completely hardened, the epoxy left a hard, clear coat over the plastic. This had the added benefit of adding more strength to the plastic by holding together the print layers and separate parts. Because I planned on sanding the pieces anyway, I used an excessive amount of epoxy when coating, as is evident by the visible epoxy drips.

Because I had to apply the coating two each side of the blade separately, I had to wait four hours between each half. I also wanted to apply three coats to the blade. What resulted from this was the week long process of coating the blade because I only effectively had time for one half of a coat once I had gotten home from work.

Sanding

This slideshow requires JavaScript.

The next step was sanding down the epoxy coating to a smooth, metal-like surface. This was by far the most tedious process. I initially bought plain sandpaper and started the process of sanding everything down by hand. As I soon realized, this was a profoundly terrible idea and would have taken forever. I shortly gave up and bought a random orbit sander. The benefit of the “random orbit” was that no directional sanding lines would show up on the finished piece, and so the sword would look uniformly smooth, just like actual steel.

New toy in tow, I forged (pun intended) on with the process of smoothing out the pieces of the sword. I started out by using 80 grit sandpaper to sand the flat surfaces of the blade entirely flat, and then slowly worked my way through 150, 220, 320, 400, and 600 grit sandpapers. These left me with an incredibly smooth surface that was ready for painting.

One downside of the sanding that I noticed was that the vibrations caused some of the superglued joints to come undone. Both the pommel and a piece of the blade had to be reglued. The blade one actually happened after painting and was difficult to repair.

Painting

This slideshow requires JavaScript.

The last step was painting everything. This was the simplest step, but was still time consuming due to having to wait for each coat to dry before flipping over the sword to paint the other side. I spray painted each of the pieces separately with silver spray paint, with several coats for each piece.

Leather Wrapping

This slideshow requires JavaScript.

As a bonus step, I decided to wrap the hilt in leather to add a nice touch to the finished product. I cut the leather roughly to size stretched it out a bit, then superglued one edge to the grip. I specifically left the grip unpainted so that the glue would have a stronger hold on the plastic part. I then tightly wrapped the leather around the octagonal grip, applying glue on each face.

Failings

While I’m fairly happy with how the finished product turned out, there are two things that didn’t turn out as I’d hoped. Mainly the stiffness of the blade was lacking and joints between blade segments couldn’t handle the stress of the finishing process.

Stiffness

While the PLA is stiff enough to prevent significant bending, the metal rods have a certain flexibility that allow some give at the inter-blade joints. As a result, the blade is more flexible than I’d like. I had to handle the sword very carefully for fear of the joint bending causing the blade to crack or break. If I attempt a repeat of this project, or something like it, I’ll have to consider a fix for this.

One option would be to use a different type of joint. The current, flat joint that I’m using allows for some space between the segments where the metal rods can bend. If I had used some type of overlapping joint it’s possible that the flexibility would have been reduced.

Another alternative would be to use a stiffer material for the blade spine. Something like carbon fiber rods would be much hopefully be much stiffer. The only concern with this would be the lack of flexibility putting more strain on the glue joints between segments.

Cracking

The biggest issue I had was with the blade segment joints not being strong enough to withstand the finishing process. Specifically the vibrations from the sander caused the joint adhesion to fail in one particular spot.

Near the top of the blade, where the cross section of the blade was small and only one spine held the segments together, the glue joint repeatedly failed.

At first I reapplied both the glue and the epoxy coating and sanded it down again. However this caused a second failure, at which point I gave up and just used a lot of super glue and some light sanding. Fortunately the poor finish isn’t too noticeable at a distance.

Another part of the blade partially cracked towards the bottom. Some of the epoxy came out between the blade segments leaving a slight crack. Because spray paint is so thin, it was unable to hide this defect.

I think the only solution to the strength problem would be to change the way I’m joining the segments since the superglue doesn’t seem to be strong enough. Two different methods I could use would be heat or friction welding when using PLA, or solvent welding when using ABS. These methods would hopefully make the whole blade into one cohesive unit.

Another possible option would be to use a different kind of paint. I used spray paint which is thin by necessity and has trouble hiding defects. Using a thicker, brush-on paint would have done a better job hiding the cracks that popped up.

Finished Product

Despite the issues I had I’m mostly happy with the finished product. Unfortunately not all projects can be resounding successes, but I learned some new techniques and have a nice decoration for my office now!

OpenADR: Mop Module v0.1

November 18, 2016November 19, 2016 kelliott121 Contests, Projects 3D Printing, OpenADR, robot, robotics

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.

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.

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

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.

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.

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

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.

A picture of the downwards facing shafts.

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.

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.

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.

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

OpenADR: Esp32 Initial Test

November 17, 2016November 17, 2016 kelliott121 Projects Arduino, ESP32, OpenADR

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

November 16, 2016November 16, 2016 kelliott121 Projects ESP32, OpenADR, robot, robotics

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!