PiGRRL Switch: Creating the Controllers

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.

Advertisements

Alien Clock: Description

Note: This is a mirror of my "Alien Cuckoo Clock project" submitted to the 2017 Hackaday SciFi contest. For more information, visit the project link.

The Alien Cuckoo Clock consists of several discrete pieces that will be combined to form the clock. The different pieces are:

  • Facehugger
  • Chestburster
  • Clock mechanism
  • Cuckoo mechanism
  • Mannequin
  • Electronics

Thingiverse is a great repository for premade 3D printed files and many of the designers there are far more skilled in 3D modelling than I will ever be, so I’ll be reusing open source designs from there for the Facehugger and Chestburster. I will, however, be painting them myself.

Rather than reinventing the wheel (errr… clock) I decided to buy a clock mechanism to use as the clock internals and hands. The upside of this is not having to handle clock controls or complicated gearing, but the downside is that the cuckoo mechanism will have to be synced with the clock somehow so it can be properly triggered at the top of the hour.

I’ll be designing the cuckoo mechanism myself, probably using gears or other basic components from Thingiverse. I have quite a few spare, generic, yellow motors from OpenADR, so I anticipate designing a mechanism to convert that rotary motion into the linear motion required by the Chestburster cuckoo.

The mannequin will serve as the body of the Facehugger/Chestburster victim (chestburstee?). I anticipate finding a spare full-body mannequin, if possible, and cutting off the lower portion and arms. However, if I can’t find one I can create the torso using duct tape casting and find a lifelike mannequin head on Amazon.

I’m hoping to keep the electronics for this project as simple as possible. I have plenty of Arduino’s laying around so I’ll be using one for the controller in addition to a few end-stop switches for the cuckoo mechanism and maybe a hall effect sensor to detect the top of the hour.

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: 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!

OpenADR: Wall Following

After several different attempts at wall following algorithms and a lot of tweaking, I’ve finally settled on a basic algorithm that mostly works and allows the OpenADR navigation unit to roughly follow a wall.  The test run is below:

Test Run

 

Algorithm

I used a very basic subsumption architecture as the basis for my wall following algorithm.  This just means that the robot has a list of behaviors that in performs.  Each behavior is triggered by a condition with the conditions being prioritized.  Using my own algorithm as an example, the triggers and behaviors of the robot are listed below:

  • A wall closer than 10cm in front triggers the robot to turn left until the wall is on the right.
  • If the front-right sensor is closer to the wall than the right sensor, the robot is angled towards the wall and so turns left.
  • If the robot is closer than the desired distance from the wall, it turns left slightly to move further away.
  • If the robot is further than the desired distance from the wall, it turns right slightly to move closer.
  • Otherwise it just travels straight.

The robot goes through each of these conditions sequentially, and if a certain condition is met the robot performs the triggered action and then skips the rest and doesn’t bother checking the rest of the conditions.  As displayed in the test run video this method mostly works but certainly has room for improvement.

Source

Conclusion

There are still plenty of problems that I need to tackle for the robot to be able to successfully navigate my apartment.  I tested it in a very controlled environment and the algorithm I’m currently using isn’t robust enough to handle oddly shaped rooms or obstacles.  It also still tends to get stuck butting against the wall and completely ignores exterior corners.

Some of the obstacle and navigation problems will hopefully be remedied by adding bump sensors to the robot.  The sonar coverage of the area around the robot is sparser than I originally thought and the 2cm blindspot around the robot is causing some problems.  The more advanced navigation will also be helped by improving my algorithm to build a map of the room in the robot’s memory in addition to adding encoders for more precise position tracking.

OpenADR: Test Platform

The second round of the Hackaday Prize ends tomorrow so I’ve spent the weekend hard at work on the OpenADR test platform.  I’ve been doing quite a bit of soldering and software testing to streamline development and to determine what the next steps I need to take are.  This blog post will outline the hardware changes and software testing that I’ve done for the test platform.

Test Hardware

While my second motion test used an Arduino Leonardo for control, I realized I needed more GPIO if I wanted to hook up all the necessary sensors and peripherals.  I ended up buying a knockoff Arduino Mega 2560 and have started using that.

2016-05-28 19.00.22

2016-05-28 19.00.07I also bought a proto shield to make the peripheral connections pseudo-permanent.

2016-05-29 11.47.13Hardwiring the L9110 motor module and the five HC-SR04 sensors allows for easy hookup to the test platform.

HC-SR04 Library

The embedded code below comprises the HC-SR04 Library for the ultrasonic distance sensors.  The trigger and echo pins are passed into the constructor and the getDistance() function triggers the ultrasonic pulse and then measures the time it takes to receive the echo pulse.  This measurement is then converted to centimeters or inches and the resulting value is returned.

L9110 Library

This library controls the L9110 dual h-bridge module.  The four controlling pins are passed in.  These pins also need to be PWM compatible as the library uses the analogWrite() function to control the speed of the motors.  The control of the motors is broken out into forward(), backward(), turnLeft(), and turnRight() functions whose operation should be obvious.  These four simple motion types will work fine for now but I will need to add finer control once I get into more advanced motion types and control loops.

Test Code

Lastly is the test code used to check the functionality of the libraries.  It simple tests all the sensors, prints the output, and runs through the four types of motion to verify that everything is working.

As always, all the code I’m using is open source and available on the OpenADR GitHub repository.  I’ll be using these libraries and the electronics I assembled to start testing some motion algorithms!

Big Seven Segment Display

Recently at work my team was throwing around the idea of real-time feedback by adding a big counter to the workspace to keep track of things like time left in the development cycle, number of static analysis warnings, etc.  For that reason I decided to build a large Seven Segment Display to provide that continuous visual feedback.  I designed the display completely from scratch to serve as a simple project that utilized a wide variety of skills.  Below I go through each step of the process and how each part works.

Mechanics

2015-07-24 17.30.41

For the actual segment part of the display I used transparent PLA from Hatchbox.  I didn’t have any trouble with how these turned out and am happy with the filament.  I had to do some experimentation with infill percentage in order to get the right amount of light passing through.  I believe in the end I settled on 20%.

2015-07-24 17.30.51

Here’s a close up of the semi-transparent digits.  Two 5mm LEDs fit snugly into the holes int he back.

2015-07-25 22.18.20

 

The individual segments are designing to press fit into black PLA frames.  I “welded” the four separate frames together using a 3Doodler to extrude plastic into the gaps.  For aesthetics I only welded the backs of the frames together, so while they’ll stay connected the seams won’t hold up to much abuse.

Electronics

Segment_Schem    Segment_Board.png

To keep board size small and reduce complexity I designed individual boards for each segment.  They only consist of two 5mm through hole LEDs, a current limiting resistor, and a 0.1″ header to connect to the main board.

2016-04-03 17.59.20

Here’s a pic of the boards soldered up and hot glued into the display.

Controller_Schem

Controller_Board.png

The control board is just a breakout for the TPIC6B595 which is a high current shift register that can power LEDs and be daisy chained together using SPI.

SparkFun ESP8266 Thing - Dev Board

I’m using the Sparkfun ESP8266 Thing Dev Board as the brains of the project.  This nifty little WiFi controller is Arduino-compatible and allows me to communicate with the display without needing to connect it to a USB port.

Firmware

Like I mentioned above, I’m using the SPI bus to communicate to each individual LED controller and daisy chaining them all together.  All that’s required is to write out four separate 8-bit numbers to set the appropriate LEDs.

The server side of things is the most complicated part of the project.  I borrowed heavily from the Web Server example in Sparkfun’s hookup guide.  The Thing board hosts a web server which accepts GET requests with the number to set the display two.  It then parses the string version of the number and converts it to the correct 8-bit sequence to set the seven segment display.

Software

The client side of things involved writing a Python script to submit the GET requests based on what data is being measured.  The current example is going through a directory and counting the occurrences of “if” in the code.

Source

As always, the source code and 3D files will be up on my Github.  I’m travelling this weekend, but will upload all the files Monday night.

Improvements

2016-04-08 12.43.14

While the LED display was plenty bright in my dim home office, I found out that they weren’t nearly strong enough to overcome the bright fluorescent lights at my office.  It’s difficult to see in the picture above, but it’s hard to read the numbers from more than a few feet away.  When I originally designed the display I erred on the side of caution and ran the cheap eBay LEDs at ~3mA.  Unfortunately, this was not nearly enough.  While it would be relatively easy to swap out the resistors to increase the current to the LEDs, I’m also unhappy with how much the plastic segments diffuse the light and think just making the LEDs brighter would only exacerbate the problem.

For version two I think I’ll experiment with two different ways to fix the problems above.  One option would be to use “straw hat” LEDs instead of the generic 5mm kind.  These LEDs have improved light diffusion.  I could also use hemispherical holes in the plastic digits, rather than cylindrical ones, so that the light is directed in a wider pattern.

Another option would be using WS2812B.  In conjunction with an improved plastic digit to help with light diffusion, this LED would greatly simplify the electronics of the display.  These LED modules have built in resistors and control logic, allowing them to be daisy chained and controlled via a serial interface without any need for the shift register control board that I used for version one.  WS2812Bs are also RGB LEDs, so another benefit is that the color would be controllable.

Hopefully I’ll get a chance to start on version two soon!