2 September 2016
I haven't posted anything in a while and thought would do a quick post about what I have been up to and what I will be posting about in the coming days and weeks.
I have been working on replacing the Arduino based controller board on my RedBot with a Raspberry Pi. Yeah, I know, RPi based robots are nothing new and maybe even boring at this point in time, but my focus has always been on software, and a RedBot with a Linux powered brain gives me the perfect platform for me to try out my software musings.
Whatever happened to Wire Wrapping? #bringBackWireWrap
Back in the late 1970's, when I did a lot of hardware prototyping, a prototyping technique that was all the rage was wire wrapping. It seems to have disappeared off the face of the earth and I have no idea why. For those not familiar with this technique, it predated wireless breadboards and allowed one to connect components together without soldering. You simply placed a wire wrap terminal or socket on a perf board, and then using a special tool, wrapped a lead around the terminal. The connection was easy to make, easy to remove, and gave great conductivity. Here is a picture:
There is a great article on makezine.com about the technique.
Now don't get me wrong, for quick a proof of concept, a wireless breadboard can't be beat, but when it comes to actually building a board that is not a printed circuit board, transferring the prototype to working design can be a challenge.
For the RedBot Raspberry Pi brain transplant, I decided to use a solder-able breadboard. Sounds like a great idea in theory, and I am using it, but for my needs it is far from perfect. First, you need to solder. The solder holes are getting smaller and my eyes are getting weaker - not a great combination. When I first started prototyping back in the vacuum tube days - 100 watt irons, massive connectors with equally massive connection points, which were all the rage, soldering was really simple. Not so today.
Also, using a wireless breadboard layout is not ideal. There is a lot of wasted real estate on the board to accommodate the connection redundancy. Again great when testing out a design or creating a temporary one, but horrible for a real world permanent solution.
In addition, I am a software guy. When I screw up the software, I rewrite a few lines and fix the problem. When I solder something incorrectly or decide there is a better way to do things, I need to find my solder sucker and pray I don't destroy the board or components.
Wire wrapping alleviated all these problems. It was simple and quick to do and just as easy to remove an errant connection. Sparkfun, Adafruit I am calling on you to #bringBackWireWrap.
RedBot Brain Surgery
Here is a picture of my creation taken about a week ago. I have since added an LED and push button switch.
It supports a 5V Up/Down voltage regulator, 4 channel A/D converter, ADXL345 accelerometer, and a motor controller.
I will be connecting to the RPi using a Pi EZ-Connect.
Why a Pi?The Raspberry Pi 3 is a cost effective platform for me to play with. First it offers a mainstream Linux OS (Debian). It has integrated WiFi and bluetooth, a fairly hefty 4 core processor, and plenty of room for additional software on the SD card.
The stability of the Pi, and its community support in my opinion, is unsurpassed.
Using a Pi allows me to write everything in Python 3, my language of preference.
I have selected the pigpio library to be the basis of low level GPIO control. This may be controversial, but I think pigpio is the best RPi GPIO control library available for Python. It supports Python 3 (as well as 2), is actively supported by its author (joan - your the best!), and its API is concise and simple to understand (even for a simpleton like me.)
RedBot Supported Features and Hardware Improvements
I will be maintaining the features of the Arduino based RedBot. I decided not to reuse the RedBot accelerometer board since that device requires a fairly complicated i2c solution. Instead, I am using the ADXL345, which allows for much simpler software.
By creating my own interface board, I also added some hardware "improvements". For example, I have added current limiting for both the push button switch and bumpers.
ZeroMQ Pub/Sub Based software Modules
The software will revolve around a ZeroMQ Pub/Sub communication pattern. This effort will not be using Python asyncio, but instead a simpler multi-process approach that uses custom protocols implemented in MessagePack- stay tuned and all will be revealed.
A Kivy GUI
Eventually, when all else is working I will be implementing a Kivy based GUI. Kivy is a Python based GUI library that I found compelling both visually and from a programming standpoint.
Currently, I have Kivy working with ZeroMQ for the PC.
Kivy comes with a sophisticated tool called Buildozer, that ports the GUI to an Android .apk file.
Unfortunately, I have not been able to get ZeroMQ and Buildozer to play nice together. Hopefully that will be solved in the near future.