PyMata communication problem

[cchd]

I have a problem with PyMata on a system purchased on June 28th (pi2, co-op and DR 8GB SD).

All works perfectly from the Arduino desktop IDE (system currently has KB/mouse/screen), not only blink but also reading analogue ports.

Running pymata_blink.py started well (it compiled and installed the Firmata code) and the LED blinked correctly, but there were error messages:

Code: Select all

pi@cchd ~/scripts $ ./blink.py
Opening Arduino Serial port /dev/ttyS0
Please wait while Arduino is being detected. This can take up to 5 seconds ...
Error: No dispatch entry for sysex_command 0
Error: No dispatch error for data F7
Error: Caught exception in command handler - pop from an empty deque
Error: No dispatch error for data F7
Board initialized in 1 seconds
Total Number of Pins Detected = 20
Total Number of Analog Pins Detected = 6


and the load average climbed to 1.1 (a puzzle: the time.sleep should take no CPU).

Tried reading A0 and writing it

Code: Select all

LDR = 0
firmata.set_pin_mode( LDR, firmata.INPUT, firmata.ANALOG)

then in try loop

LDR_value=firmata.analog_read( LDR )
print "LDR" , LDR_value


and the output was (there were time.sleep delays)

Code: Select all

....
Error: Caught exception in command handler - pop from an empty deque
Error: No dispatch error for data F7
Error: Caught exception in command handler - pop from an empty deque
LDR 687
Error: Caught exception in command handler - pop from an empty deque
Error: Caught exception in command handler - pop from an empty deque
....


with an LDR output roughly every ten exceptions (and that value 687 stayed around there despite altering the light to levels that changed it down to 100 and up to 890 when using the Arduino IDE and its serial console).

The blink script generated no exceptions once it was going, while the script that sent LDR values back generated exceptions all the time (five to ten per value).

I note that I have not set a serial baud rate - not sure at this point how to do it in PyMata. I did so in the IDE and found it worked fine both at 9600 and at 57600 baud, so long, of course, as the program and the serial console were the same.

No difference with ttyAMA0 (which anyway is softlinked from ttyS0), nor with other variations of blink.py, except that one I found including ttyACM0 and a parameter 'firmata_type=PyMata.STANDARD_FIRMATA' gave multiple errors.

CTRL/C halts either program OK with a nice 'Hope to see you soon!' message.

Button on co-op triggers flashes on the green light.

No hanging channels on lsof.

Effects vary between runs (of blink or LDR read). Sometimes Board Auto Discovery fails and avrdude-original: comes in to load flash data, verifying OK: sometimes this involves a complete Firmata recompilation. Often there is a long batch of these errors:

Code: Select all

Error: Caught exception in command handler - pop from an empty deque
Error: No dispatch error for data F7
Error: Caught exception in command handler - pop from an empty deque
Error: No dispatch error for data F7


which I presume means simply that the command is corrupted so not recognised.

It makes no difference powering the system from a stable TeckNet battery pack instead of a mains USB adaptor.

All software recent. The only additions I have made are to install LAMP, a fixed external IP (so you can access the pi on cchd.eu) and CUPS.


Christopher Dawkins, cchd@pjcd.org

[Alan]

Hi Christopher,

Welcome to the forums.

Sorry to hear you're having problems with the Pi Co-op, but thank you for the detailed bug report.

I've just tried to recreate your bug and everything seems fine on an original Model B, but I get similar problems to yours on a Pi 2. Apologies, I guess I must have tested the basic functionality of the Pi Co-op on the new Pi 2, but not the PyMata fork we created.

I think that what we're seeing is the serial communication of PyMata getting itself in a bit of a muddle. Essentially data being misinterpreted, although I've got no idea why this should happen on the Pi 2 and not the original Pi. With regards to the CPU load climbing despite using time.sleep, I think that's because PyMata runs a thread for serial communications which may perhaps be blocking, either on reads or writes.

Now it looks as if, in the time since we forked PyMata, Alan Yorinks the original author has made a lot of changes, a number of which are around the communication code.

I am midway through trying to merge his changes into our fork, and will hopefully have an experimental merge to share sometime tomorrow. In the meantime, you might have some joy syncing directly to Alan Yorinks mainline of PyMata. This version lacks the auto uploading of the PyMata firmware which we've implemented, so you'll need to manually upload a Firmata sketch using the Arduino IDE.

With regards to baud rate, it looks like Firmata is hardcoded to work at 57600bps, which the hardware should be able to handle comfortably.

Regards

Alan

[cchd]

Many thanks for your helpful reply. I agree, it looks like a serial I/O mismatch, and I am exceedingly relieved that you have managed to replicate it! Rather naughty of the pi2 to be different in this regard.

I have other sensors to organise so, if I know this in en route to a fix, I'd prefer to wait until you have done the work. And more so because I am not as clever as you might think and it could take me a day of googling to work out how to 'sync' with the other Alan's code - it may be only only a matter of things I am accustomed to such as downloading and installing, but I'd be afraid of bricking something if I go off piste. And do relax, a week or two (or more) is OK by me.

It is really exciting, this tiny device. Takes me back to the days of the BBC analogue port.

Christopher Dawkins, cchd@pjcd.org and http://cchd.eu/

[Alan]

Hi Christopher,

I have now completed the merge, made a few extra changes for stability, and checked the changes into a branch called 'experimental' in the PyMata github repository. I think that I should be ok to update the mainline of PyMata to this new code, but before I do that, could you please spare some time to help me test it, to see if it solves your problem?

Starting with a copy of the Dawn Robotics SD card the steps to take are

• Delete the PyMata directory if it already exists
• Run the following commands on the command line

Code: Select all

git clone https://github.com/DawnRobotics/PyMata.git
cd PyMata
git checkout experimental
sudo python setup.py install


Now, if you cd into the pi_co-op directory. You should be able to run examples/pymata_blink.py and examples/pymata_analog_read.py without any problems.

The new version of PyMata seems to make the serial communications more stable, but I found that the main problem (especially with the analog sample) is that the threads that PyMata was spawning, to read serial data and to process messages from Firmata were simply taking up too much CPU time. This is because they never slept, and so were effectively busy waiting a lot of the time. Not sure why this caused more of a problem on the Pi 2 than the original Pi, but on the Pi 2 CPU usage was going up to about 130%!

The fix involved putting a small sleep inside the thread run functions which you can see here.

On the same note, you may get improved performance i.e. reduced CPU usage by putting a small sleep (something like time.sleep( 0.01 )) at the end of the loop in the analog read sample.

Anyway, let me know how you get on.

Regards

Alan

[cchd]

Many thanks. Done, and all fixed. No exceptions raised, and load average good too. Many thanks for such a fast response. I can now proceed with the 'Project'.

There's only one problem; the PyMata/examples/pymata_blink.py script gives multiple errors owing to the non-existent ttyACM0 device. It works fine when that's converted to ttyS0).

Christopher Dawkins

[Alan]

Yes, this confused me yesterday as well. I realised enventually though that ttyACM0 is the serial port that will be created when you plug a standard Arduino Uno into a USB port on the Pi. The PyMata examples use this serial port by default because the PyMata library is mainly intended to work with standard Arduinos connected over the USB port, not our custom Arduino board connected to GPIO UART. The samples in the pi_co-op examples directory should all make use of ttyS0 however.

Regards

Alan