C4 Labs Review

Zebra Black Ice Case For The Raspberry Pi

My latest open source efforts have been almost exclusively devoted to the Raspberry Pi. Over the years I have developed a strong affinity for this little powerhouse of a computer, but was never particularly pleased with the choices for housing the unit. 

I have gone from no housing at all, just letting it sit on my lab bench, to trying several of the inexpensive ABS cases available on the market.  I was never pleased with any of these choices. The "naked bench top" approach always left the computer exposed to mayhem, and the ABS cases never fit quite correctly, making installing and removing the SD cards difficult, not to mention removing the board from the cases, an exercise in frustration.

So I went on a quest for a quality case and found the C4 Labs family of products. I purchased a Zebra Black Ice case and was immediately impressed with both the physical design and the design aesthetics. You do have to assemble the case, which takes about 10 minutes, but it is well worth the effort. The case not only provides substantial protection for the RPi, but is truly a thing of beauty. Its rounded corners, and color accent make me smile each time I see or pick up the case. That is not something I had ever gotten from working with the RPi before.

The case comes with a set of heat sinks, as well as a set of soft feet. It allows access to GPIO pins, the DSI display connector and CSI camera connector. It provides for air flow on both the top and bottom, and has holes for screw mounting the case if desired.

If that wasn't enough, C4 Labs provides wonderful, personal,  customer service. I had some questions and not only were they answered and resolved quickly, but C4 Labs went over and beyond to make sure that I was satisfied. This is a rare thing these days.

I highly recommend this case for its protection, design integrity, quality construction, and aesthetics. If you too want to smile when you use your RPi, check out C4 Labs cases.

NOTE: I am not an employee of C4 Labs, nor have they solicited for this review, I am just one happy customer.

The Documentation For s2-pi has been updated and can be found here:

https://mryslab.github.io/s2-pi/

To install the demo code either type:

sudo pip3 install s2-pi

Or

Download From Github.

2 October 2016

Writing The Software To Control The Raspberry RedBot 

Part 2

I have completed the bulk of the coding for razmq and the results are in!

I wanted to share this information now. The code will be published in a short while, after some cleanup and additional testing.

The following screen shots were taken on a Raspberry Pi 3 running the latest Raspbian image, Raspbian Jessie with Pixel. 

The first is "quiescent" mode. The pigpio daemon, pigpiod,  the xrdp  daemon and htop  are running.

CPU utilization is at 4.2% and Memory utilization is 129 of 925 MB. CPU utilization varies and can go as high as 6.1% for this scenario.

Starting all the processes that monitor and control the Raspberry RedBot we see the following:

CPU utilization rises to 6.4% and Memory utilization is 294 of 925 MB. CPU utilization varies from about 4.5 to 6.5%.

The Accelerometer (ADXL345) and the  3 Line Followers (PCF8591) are continuously streaming data via i2c in this scenario.

Finally, we run the motors at full speed. This causes the encoders to add their streaming information into the mix. The motors at full speed run at 140 RPM. Each encoder sensor generates 192 "ticks" with each wheel revolution. Since this level of resolution was not necessary for the purposes of this project, the number of ticks was throttled  by a factor of 6. So now each wheel revolution is limted to generating 32 "tick" notifications per wheel (but 192 are still being generated). This yields a 1/8 inch or 3.175 mm distance resolution that is reported on the GUI screen. Here are the results when the motors are running full speed and all other sensors and actuators are active:

CPU utilization varies from about 16% to 26% and there is no additional memory utilization while the motors are running.

Here is a screen shot of the Kivy based GUI running on my Ubuntu based desktop PC.

Let's summarize what is running when the "motor run" numbers were captured:

1. Data is continuously being streamed by the accelerometer, 3 line followers and 2 wheel encoders.
2. All other actuators (LED, Buzzer) and sensors (Push Button Switch, two mechanical bumpers) are ready to be activated or provide reports in a non-blocking fashion.
3. There are currently 12 separate processes running to monitor and control the Raspberry RedBot.

Some Important Facts About The Framework Used to Create razmq

1. Everything is written using Python 3.4.2, the version that comes with the Raspberry Pi image.
2. All processes are activated using the lunch process launcher - simplifies the start up process.
3. Processes may be started, stopped, added and removed at will, with no system crashes. Effectively providing a software backplane with hot swapping capabilities.
4. Most of the processes were built using a base class that encapsulates and hides the complexities (and there really are very little) of ZeroMQ and MessagePack.
5. For the purposes of this article, all processes, with the exception of the GUI, were run on a single Raspberyy Pi 3. However, during development some processes were run on a Pycharm IDE in Ubuntu on my desktop.  The pigpio dependent processes were remotely debugged using the same PyCharm session. 
6. Without any coding changes, any process may be run on any computer residing on  a single LAN.
7. Module interfaces are defined as language independent protocol messages. The messages are asynchronously published to the network and may be subscribed to by any other process. This is done by transporting the MessageQueue messages using ZeroMQ.  The result of using this mechanism is a simplified, non-blocking IPC (inter process communication) scheme with no data needed to be protected or locked. A lot more about this will also follow in a future article.
8. The system is totally non-blocking without the need of mechanisms like the Python asyncio or threading or multiprocessing modules.
9. Testing new modules is easy to do. Their published protocol messages may be observed in real-time using a simple monitor process. Building drivers for these modules is also quick and easy as a result of using the encapsulation base class (more on this will follow in future articles as well).
10. All modules use a consistent and common coding pattern.

So What Does This All Mean?

The razmq project was built for a specific set of hardware actuators and sensors. However, the framework is easily adaptable to be used for other projects. New features can easily be added to existing projects and enabled on an already executing system. New projects can be created using a simple and consistent coding pattern.

The next several articles will explain in detail how razmq works and how you can use its framework in your own projects. 

Stay tuned!

Writing The Software To Control The Raspberry RedBot

18 September 2016


Now that the hardware has been completed and is in place, it is time to start writing the software. When working on a new project I like to take a "Mise en place" approach - that is getting everything organized and in place and ready to go. First I create a Github page for the project and update the Wiki pages as the project progresses. For this project, I created a Github repository called razmq. 

Next, I identify any additional software packages I might need and install them. The additional software requirements for razmq are identified here. 

After that, I  write a set of routines to exercise the hardware.- a hardware baseline so to speak. In this way, I am able to verify hardware functionality at any time.

An Experimental Software Architectural Approach

As I have done in several of my previous projects, Python 3 will be used. I believe it is better to look towards the future of the language rather than have to worry about maintaining the legacy of Python 2. 

I will still maintain an asynchronous event driven design approach, however, I would like to simplify things and provide concurrency without the use of either the Python asyncio module or the threading module. To do this, I will be dividing support for a given hardware functionality into 2 separate processes. The first process will present a "user" view of the hardware. For example, for motor control, this process will describe motor motion in abstractions such as direction and speed. These abstractions will be translated into MessagePack messages and then "published" using the ZeroMQ publisher/subscriber pattern. Another process will be created and it will be a subscriber for these messages. It will translate the abstractions into pigpio calls to directly control a motor controller device. In this way, I can maintain an abstract view of the world and swap in specific hardware at any time to implement that abstraction.

To simplify the networking connections between all of these processes, a ZeroMQ forwarder will be used. The forwarder uses a "well-known" IP address/port for all publishers to publish their messages, and another "well-known" IP address/port for subscribers to subscribe to receive messages. There are no configuration files to maintain and each process uses a consistent methodology to both publish and subscribe to messages. To make the coding easier, a base class will be provided to encapsulate many of the ZeroMQ and MessagePack details. This base class can be inherited by the classes that provide either the user or hardware view of the system. 

The experimental part of this exercise is to determine if the memory and CPU utilization is viable while having multiple concurrent processes running.

If this all seems a little abstract, in my next posting I will be describing the details of supporting a simple hardware device, the LED, using these methods. Hopefully that will demystify the described approach. It really is simpler than it sounds and provides a very flexible development environment.

Until next time ....

9 September 2016

It's Alive!

Brain Transplant A Success.

I've successfully replaced the original Arduino based processor board that comes with the RedBot with a Raspberry Pi 3.

It looks like a chaotic mess of wires, but is actually quite organized, and no GPIO pins were harmed in the process. A Pi Ez-Connect was used so that I can easily remove the Pi and use it in another project at any time. All solder connections were made on a solderable breadboard, so the Ez-Connect can be reused as well.

All of the original RedBot connectors were maintained so that the Arduino board can be restored if need be. The new brain supports all of the original features:

• Dual Motor Drive
• Encoders for each motor
• Left and right mechanical bumpers.
• On board LED.
• On board push button switch
• Piezo buzzer
• Line followers
• Accelerometer

In addition a 5 volt regulator was added to keep the Raspberry Pi 3 happy for as long as possible when running on battery power.

Current limiting resistors were also added to the bumper and push button switches. This helps protect the Pi's GPIO pins.

All in all, I am quite pleased with the outcome. 

Next up, the software!

2 September 2016

I'm Back!

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.

GPIO Support

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. 

More To Come Later ...

Xideco 0.2.0 Published

Update Contains Full Support For

 Raspberry Pi

Information about the new Raspberry Pi Bridge may be found here.

All Scratch blocks are supported including SONAR, Servo Control, and Analog Read (using an A/D converter).

Raspberry Pi Diaries

Jan 26, 2016

Part 7

Servo is now functioning and changes uploaded to Github.

Next is sonar (hc-sr04).

Evening Update

Sonar using an  HC-SR04 is functional - I can turn reports on and off and have Scratch display the report values (distance in centimeters).

Next is support for the PCF8591 YL-40. This is an i2c device that supports A/D conversion.

Once this is complete, I will be merging the Raspberry Pi Bridge into the Github Master Branch and and start to look at the BeagleBone Black Bridge. 

Another great day!

Raspberry Pi Diaries

Jan 24, 2016

Part 6

Last night, my Raspberry Pi Model B Rev 2 started acting erratically and then it decided to not even boot. I decided to rebuild the SD card and reinstall everything.

After flashing the SD card with the Raspian Jessie release, the PI booted up. I then proceeded to install everything I needed for the Raspberry PI bridge using my own instructions here.

I then installed the pigpio library.

Doing this on the Model B rev 2 (not to be confused with the Pi2) was a very slow process. To do everything took over 3 hours. I will be doing the same on a Pi2 in the future just to compare the differences in time to do a complete reinstall.

I installed the SD card into the Pi, it booted up and everything seemed right with the world again. I did  a shutdown of the Pi to make sure not to corrupt the image, unplugged it and went to bed. This morning I powered up the Pi and it wouldn't boot, so I thought I would swap the SD card into a Pi 2 to see if it would boot, and it did - the image was not corrupted. I swapped it back to the B and no boot. So I have a flaky Raspberry Pi B rev 2. I will deal with this later, but will continue work on the Pi 2.

Tone and Tone Off have been implemented. I can't believe how easy it was to do this using pigpio - what a wonderful library. I used some of the "wave" methods. The only confusing part was figuring out how to populate the "pulse" class entries to create audio frequencies.

Here is some commented test code using pigpio waves:

import time  # import the time library

import pigpio  # import the GPIO library

pin = 18

# establish 2 pulse definitions to create a 1k hz tone
# the first entry sets pin 18 high for a duration of 1000 microseconds
# and the second entry set pin 18 low for a duration of 1000 microseconds
tone_1k = [pigpio.pulse(1 << pin, 0, 1000), pigpio.pulse(0, 1 << pin, 1000)]


# remember to execute "sudo pigpiod" on the Pi before executing

#instantiate pigpio
pi = pigpio.pi()

# set the buzzer pin to output
pi.set_mode(pin, pigpio.OUTPUT)

# clear any previous wave descriptions
pi.wave_clear()

# create a wave descriptor
pi.wave_add_generic(tone_1k)  # 100 ms flashes

# create the tone and save the id
tone = pi.wave_create()

# play tone continuously for one second
pi.wave_send_repeat(tone)
time.sleep(1)
pi.wave_tx_stop()  # stop waveform

#clean up
pi.wave_clear()  # clear all waveforms

pi.write(pin, 0)

On to controlling servos next.

Raspberry Pi Diaries

Jan 23 2016

Part 5

I am testing the error paths on some of the blocks (enter a gpio pin number of 99, trying to do a digital write to a pin that was previously setup as an input, etc.). In my previous diary post I mentioned that I will be displaying debugger information as detailed text instead of reference numbers.

I have reconsidered this decision and am going back to reference numbers. The reasoning behind this is that approach is a burden on non-English speakers. If I use reference numbers and provide a cross reference of error number to English text string on the Wiki page, that page could be translated using something like Google translate. 

I am continuing to test error conditions and once I am satisfied with the error processing for the currently functioning blocks, I will go on to block functionality I have not yet addressed.

Here are the items yet to be addressed:

• Tone
• Servos
• Sonar
• Analog Input

For Analog Input, I just purchased an a/d converter module that is already supported by PIGPIO.  The module has a potentiometer and light sensor so it will be fun to play with.

Stay tuned.

The Raspberry Pi Diaries

Jan 22, 2016

Part 4

Some more progress to report. Uploaded the latest Rpi bridge to Github. The bridge is able to detect the board type (B, B+, etc.) and create a pin map of available GPIO pins for that board type.

If an operation is attempted on an illegal GPIO for the board type connected, it is detected, denied.

I am able to set the pin mode for Digital Input and Output from Scratch and the Enable/Disable function is now working.

If Digital Input is set to Disabled, reports are not sent back to Scratch.

If Digital Output is set to Disabled, performing a digital write has no affect on the pin.

The user can toggle back and forth between enabled and disabled.

If a digital or analog (PWM) write is attempted and the GPIO was not set to OUTPUT mode, the write is denied. 

To Do: Come up with a Raspberry Pi set of error messages and verify that they are being reported to Scratch for each error condition.

LATE EVENING UPDATE

Modified debug error reporting to be meaningful strings instead of reference numbers.

To Do: Update Arduino Bridge to do the same.

Control C handling working consistently well now.

The Raspberry Pi Diaries

Jan 20 2016

Part 3

Great progress! I have updated the Raspberry Pi Bridge (code is on Github).

First a word about remote debug on the PI using PyCharm. Turns it out it was trivial. There are 2 methods to do remote debugging, a complicated method and an easy method. Of course I chose the easy way. It is called "Remote debug with a remote interpreter". 

I am able to do all of my edits on my PC, do a code inspection, upload the code to the PI and run a debug session (code running on PI), set breakpoints, etc., all on my PCthrough SSH.

Using the PIBrella as a test vehicle, I successfully:

• Enabled code to connect to xideco
• Connect the RPi to Xideco (all other components are running on my PC)
• Configured LED pins as Input and PWM
• Performed digital and analog(PWM) writes to the LEDs

Still lots to do, but I was able to get some basic functionality up and running in about an hour.

Not bad if I say so myself.

The Raspberry Pi Diaries

Jan 19, 2016

After publishing Xideco and having a good night's sleep, I am about to start on the Xideco Raspberry Pi Bridge.

I am creating this "diary" in the hopes that it may encourage others to create Xideco plug-in modules. I have created a Github branch so that my changes can be tracked by anyone interested.

I will be updating the diary and the branch on an irregular basis, but will try to do so on an almost daily basis until the project is complete.

So let's get started.

GPIO Library

After looking at several readily available and popular Raspberry Pi GPIO libraries I have decided to use PIGPIO. My reasons for choosing this library over the others were:

• A well thought out Python API.
• It worked out of the box.
• Provides callbacks.
• User does not have to be root to affect the GPIO (after starting a daemon as root)
• Seems to support ALL of the features I need.

Development Environment

RPi Board

I am starting off using a Raspberry PI 1 Model B, but have a B+ and a 2 on hand as well. Hopefully the Model B won't run out of steam, but time will tell.

RPi Operating System

I am starting with Raspbian Wheezy, May 2015 release. I will be moving on to the Jessie release sometime in the future.

IDE

I will be using Pycharm 5 Professional running on my main PC for editing, Github support and remote debugging of code residing on the RPi.

Getting Started

I will be using the Arduino Bridge as a template, but there will be major changes. All Arduino specific code will be disabled or removed. So my first goals are:

Try out some of the PIGPIO API calls, starting with something simple, like get_hardware_revision and get_pigpio_version, initializing a pigpio session, configuring a pin for digital input and registering a callback, monitoring the pin for changes and releasing PIGPIO resources upon exit.

I will report back any issues that come up, and will publish the code on the Github branch when I have something worth sharing.

Xi RPi Support Has Been Extended For:

PWM
Standard Servo
Continuous Servo

No changes are necessary to the Xi Clients or Server.

Just update your copy of raspi-io to the latest:

In the xipi directory:

1. sudo npm rm raspi-io
2. sudo npm install raspi-io

Xi4Snap! Is Almost Complete

Just a little more testing, and a quick update of the user guide and the release will be ready.

Once that is complete, servo support is next in the pipeline.

Stay tuned.

Anders Berggren Just Sent Us 

A Video of Xi Controlling a Raspberry Pi with an Arduino

Thank you Anders!!!!

Xi Status Update 2

The first set of block definitions has been finalized (pictured below)  and all client/server code has been completed. Testing for Arduino, and Raspberry Pi is complete on Linux. 

I just need to complete the BeagleBone Black testing, then retest all micro-controllers on Windows. When the documentation is completed, release v.001 will become available.

Additional Features That Will Be Included With v.001

All the features described in this section have been tested in Linux and are ready to be included in the first release.

1. As you probably know, Xi makes use of the Johnny-Five library. This powerful library provides a consistent, hardware independent micro-controller API.  As result, a single server file supports all 3 micro-controllers. Less code, means less maintenance.

2. Speaking of launching, when the XiDuino server is launched, it will automatically launch your default web browser and set the page to http://scratch.mit.edu/. If your browser is already open, it will open a new tab to Scratch. Place the XiDuino launch command in  a .bat file or shell script, create a shortcut,  and you have "One Button Launching".

3. Another feature that was added is automatic Pin/PWM compatibility checking. If a pin is selected for PWM operation, but does not actually support PWM, an error message is displayed. Below, is a screen shot of the alert message generated when pin 7 on a Leonardo was attempted to be set to PWM mode. The feature works for the Raspberry Pi and BeagleBone Black as well.

Future Release Plans

1. Support for additional devices. (Servo, Sonar, Piezo, Steppers, etc.)
2. Support for Snap!
3. A simplified block language translation scheme.
4. A one-click install script.

Stay tuned - there is more to come!

Xi

The Next GenerationScratch 2.0 Hardware Interface For Arduino, Raspberry Pi, and BeagleBone Black

              Click here to see the proof of concept results and video demos.

Mobile Robotics with Scratch: The Whole Truth About the Integration of Scratch, Arduino and Bluetooth

This is a nicely done article by Aldo von Wangenheim

and well worth the read

Learn How To Wirelessly Control an Arduino Using the BeagleBone Black
or
Raspberry Pi

Check out my latest Instructables Article

Please note that some corrections have been made to Step 2. The bluez package is required to be installed into the BBB.

Article has been updated to include Raspberry Pi running the latest Debian Wheezy (2014-06-20) release.