User interaction with chat interface

Previously I showed how to communicate between Python and the Arduino. Next we need a way for the user to interact with the Arduino, via the Python interface. The user might be a person, typing commands into a terminal, or it might be another script. Ultimately we will want to control the entire behavioral shaping process from another script, which for example will observe the subject's performance and adjust future trials accordingly.

For reading: Let's write out everything the arduino says to a text file. This way we'll have an exact record of what happened. Other programs can parse this file for the results so far.

For writing: This was a little more difficult. I wanted a general interface that could be used by a human or another script to communicate with the Python chatting script. I decided to use a named pipe, which is similar to a file. Anything that is written to this file-like object will be picked up by the chatting script and communicated to the Arduino, line by line.

Here's the old code as well as the new code:

The syntax for reading from the pipe is a little clunky. I wanted it to be non-blocking, because otherwise the program halts if there is nothing to read. But the non-blocking read will raise an error whenever no data is found. So we catch that exception and ignore it.

To create the pipe named TO_DEV, we just need to run:
    os.mkfifo('TO_DEV')

Now you can write to the pipe, either from another terminal like so:
    echo "MESSAGE" > TO_DEV
This automatically appends a newline.

Or from another Python script:
    pipeout = os.open('TO_DEV', os.O_WRONLY)
    os.write(pipeout, 'MESSAGE\n')
Here you have to add your own newline.


Next time I'll package this up into a complete script and demonstrate it.

First step -- a chat interface

The first thing we need is a way to communicate between python and the arduino over the serial port.

Python side

The `pyserial` library makes things easy here.

The `timeout` keyword is a key element here. That defines how long `readlines` will wait for input before returning. If you set it to 0, it will return whatever it finds immediately. The problem with that approach is that we're going to be calling this function over and over again in an infinite loop. I suspect a smaller number of calls with a small delay will end up being more efficient than a much larger number of calls with a near-zero delay. That's something to test layer.

The `write` function actually writes immediately and returns ("non-blocking").

The Arduino side

The arduino needs something to say. Let's have it report the time every second. Also, let's have it acknowledge any chat it receives, simply by echoing back whatever it hears.

The actual `receive_chat` function resides in a library.

Things are more complicated here than in Python because we have only low-level functions available. Whenever there are new characters available, we add them to a global variable `receive_buffer`. It has to be global because it needs to persist over many calls to this function.

Once the buffer gets to a newline, it stops taking characters and returns the line it received. It also echoes it on the serial port so that Python knows its message was received.

What if multiple lines are waiting to be received? This will only return the first one. This is easier than coding up a linked list of multiple commands. It also means that other things have a chance to run on the rest of the update cycle.



Now the arduino can communicate with Python. But how does Python interact with the user? The user might be a real person, or it might be another Python script, for instance one controlling the state machine. The next post will cover the methods by which the user can read what the arduino is saying, and type in responses.