More pymata_aio changes!

Version 1.2 Now Available

Another bug fix release.

The data returned as a result of an i2c_read_request was incorrectly formatted as "internal Firmata 2 Byte format".

The code now returns data in its normalized and expected format.

pymata_aio

Version 1.1 Released

This release:

• Fixes a bug that was experienced while performing a multi-byte i2c read request.
• Updates FirmataPlus to be StandardFirmata 2.4.3 compatible.
• Exposes many more examples on the Wiki page.

Download the latest version of pymata-aio on pypi, or download form Github.

Just Released!

So, what Is pymata_aio?

It's the second generation of the PyMata easy-to-use, application programming interface for Arduino Firmata. It uses the Python asyncio library at its core, for maximum concurrency performance.

Three Independent APIs Are Included.

Choose the one that is best suited to your job:

pymata3

The pymata3 API is modeled after the original PyMata API and will seem most familiar to current PyMata users. This API acts as a proxy for the pymata_core API, providing all of the advantages of asyncio, but without having to directly program in asyncio.

Click here to see sample code illustrating pymata3 in use.

pymata_core

This API is a pure asyncio method call API intended for those who wish to use asyncio directly. It exposes its underlying asyncio task/coroutine/futures model to the developer.

Click here to see sample code illustrating pymata_core in use..

pymata_iot

Would you like to connect and control your Arduino over the Internet? PyMata_IOT is a ready to run, Autobahn WebSocket server application, included with this package. Its API is a set of JSON messages exchanged between your application and the server. Because it uses JSON messages, it is totally language independent. You can write your WebSocket client using Python, JavaScript or any other language of your choosing.

Click here to see a simple HTML/JavaScript web page example that communicates with pymata_iot.

It provides the exact the same functionality as the other two examples above, but it provides a web page with two buttons to turn the LED on and off.

Download it here.

Asyncio is Coming to PyMata!

The next version of PyMata, scheduled for release later this summer, incorporates the Python 3 asyncio library. "Why?", you might. ask. Let's compare results of running two similar projects that control a servo motor

Both tests were run using Python 3.4.3 on Linux. The CPU used in the tests is an Intel® Core™ i5-2500K CPU running at 3.30GHz.

First, here is the PyMata 2.08 project code:

And now the system monitor results:

Application code for the new release:

Its system monitor results:

CPU utilization went down from 28% to 6% !

Comparing the code, you might be wondering why there is no import of the asyncio library. There are 3 APIs  included with the new release.

• pymata_core
• This is a pure asyncio API for those that wish to code directly in asyncio. It is a method based API.
• pymata3
• This is a "pymata plug-in api" that acts as a proxy for pymata_core. It shields the user from having to deal with asyncio. This is the API used for the sample code above. It is method based.
• pymata_iot
• This API provides an Autobahn based Websocket interface. It too is a "pymata plug-in" API that uses JSON messaging between client and server.
• Here is a screen shot of a web application taking advantage of this API:

• This rather busy screen shot shows a page that allows control of the digital inputs and the PyMata data latching feature. Pin 12 and 13 are enabled for reporting. Pin 12 is currently low and pin 13 is high. A latch was set for pin 12 that was triggered on 27 June 2015 at 13:27:24. Pin 13 also has a pending latch to fire when it goes low and then high again.
• Here is a sample of the JavaScript code used in this screen shot for setting pin mode:

• This code uses the browser's built-in Websocket client and therefore JavaScript was used. You can easily communicate using a Python Websocket client as well. First here is the JSON message template

• And the Python code to set the pin mode via Websocket:

Here is a summary of the features of the new release, its current status and a "to-do" list.

Major Release Features

• Utilizes the Python asyncio library for concurrency implementation.
• Full implementation of the StandardFirmata version 2.4.3 protocol.
• Continued support for FirmataPlus protocol(Sonar, Stepper Motor, Tone, and Encoder support).
• 3 APIs provided for application flexibility.
• Auto-detection of the Arduino COM port.
• Built-in Control-C detection.

Current Status

• pymata_core API is code complete and tested.
• pymata3 API is code complete and tested.
• pymata_iot is 70% complete and tested.

To Be Done

• Finish pymata_iot.
• Code cleanup.
• Documentation.

PyMata Version 2.07 

(Bug Fix Release)

Now Available on Github and Pypi

Tim Slator identified a bug that manifested itself in an exception being thrown when certain analog pins were being used as digital pins. Tim's fix is incorporated into version 2.07, and tested on an Uno, Leonardo and Mega 2650.

You can obtain the latest changes using pypi or download them here.

Thanks Tim!

Xi Is Now Available on ScratchX

The Scratch team has released an experimental web site that supports hardware extensions for Scratch and a Xi client is available at:

http://scratchx.org/?url=http://MrYsLab.github.io/xi4s.js

A French translation is available at:

http://scratchx.org/?url=http://MrYsLab.github.io/xi4s_fr4.js

Xi allows Scratch to simultaneously control mulitple Arduino, Raspberry PI and Beagle Bone Black microcontrollers and allow them to share sensor data.

To use these clients, you will need to install the Xi servers that can be found at:

https://github.com/MrYsLab/xi

Futures and Coroutines and Loops! Oh my!

I have just published an updated version of esp4s, the project that uses Scratch to interface to an Arduino Esplora microcontroller board. This latest version uses Python 3.4.3 and its associated asyncio library. The new program is called esp4s-aio and is available on Github.

Going from proof of concept to a finished project was not as simple as I had originally thought. The Python documentation for asyncio is really great for reference once you understand how to use the library, but at least for me, was not very instructive for a first time user.

But once I figured out how to convert Pyserial's readline() and write() to "futures", and was able to instantiate and communicate with an aiohttp HTTP server, I was well on my way to finishing the task at hand.

But those weren't my only educational challenges. I also needed to learn how to unit test the code and came upon pytest-asyncio. After asking the package authors several rookie questions, and receiving quick and accurate answers (without any snark I might add) the last pieces of the educational puzzle were in place.

Now on to the code. I started with the same architectural design I used for the original esp4s. However, working through the code, I quickly realized that I could take a simpler, more sequential code flow approach than I used for the original multi-threaded esp4s project. This not only simplified the design, but the testing and debugging, as well.

One very major design departure from the original project, was to go from having the Esplora pushing out all sensor data every 25 ms. to a polled approach.I was concerned that performance would suffer but that turned out not to be the case. 

Now on to the results. I used a common Scratch script called test.sb2, ( which is provided in the esp4s-aio distribution) to compare esp4s and esp4s-aio. The Scratch script toggles an LED on the Esplora while concurrently displaying status for all 16 Esplora sensors. Scratch polls for status data at a rate of approximately 30 times per second.

It was interesting to find that the esp4s-aio version shows no display lag as sensor data varies, but the original version does (which means that the design of the original was sub-optimal). 

However, more dramatic was the difference in CPU utilization. First, here is  CPU utilization for the original:

And now the CPU utilization for esp4s-aio:

In this graph, the first 20 seconds are before Scratch was started and esp4s-aio is running idle. The increase begins when the Scratch script starts polling for data.

So overall, I am very pleased with the results, and plan to use asyncio coroutines for several future projects.  Since my projects tend to be more I/O intensive than CPU intensive, asyncio and coroutines are definitely in my future.