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.
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:
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:
- Data is continuously being streamed by the accelerometer, 3 line followers and 2 wheel encoders.
- 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.
- There are currently 12 separate processes running to monitor and control the Raspberry RedBot.
Some Important Facts About The Framework Used to Create razmq
- Everything is written using Python 3.4.2, the version that comes with the Raspberry Pi image.
- All processes are activated using the lunch process launcher - simplifies the start up process.
- Processes may be started, stopped, added and removed at will, with no system crashes. Effectively providing a software backplane with hot swapping capabilities.
- 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.
- 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.
- Without any coding changes, any process may be run on any computer residing on a single LAN.
- 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.
- The system is totally non-blocking without the need of mechanisms like the Python asyncio or threading or multiprocessing modules.
- 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).
- 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!
