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 ....