Arduino + Firmata + Pyduino (Python)

Has anyone had luck using Firmata + Pyduino, the Python library?

The Firmata sketch is located here: Arduino Playground - Firmata but the download link is broken so I had to copy/paste from the CVS site. Only later did I find that Firmata is already located in a folder in the Arduino IDE (I'm on WinXP).

I've had no luck getting the Pyduino library and example to work. PySerial can connect to the Arduino's serial port without errors, but any attempt at one- or two-way communication (for example, getting the firmata version number stored in the sketch on the arduino) produces nothing. Other serial communication to my board using other sketches works fine.

Hi, I wrote pyduino, so this is almost certainly my fault :slight_smile:
Can you post the python you were using (if it isn't just the example), and any errors you're getting. I've not got my arduino with me for a few days, but last time I used it I had it working fine. One possibility is that firmata is now working at the 115200 bitrate - I need to check properly, but it's either happened or happening soon. I'm so behind with my arduino news :slight_smile:
If thats the problem you could try changing line 51 of pyduino.py from

self.sp = serial.Serial(port, 57600, timeout=0.02)

to

self.sp = serial.Serial(port, 115200, timeout=0.02)

I'll be able to have a proper look in a few days time, but any more info would be much appreciated.
Joe

Thanks for the response, sounds like you're the person to talk to.

I'm not trying to do anything fancy, just turn on the LED at pin 13 of my Diecimila. This is the code I was using after changing the serial rate in pyduino.py like you suggested:

import pyduino
a = pyduino.Arduino("com5")
a.digital[13].set_active(1)
a.digital[13].set_mode(pyduino.DIGITAL_OUTPUT)
a.digital[13].write(1)

The firmata sketch uploads fine, the rx/tx lights blink while it runs, and I don't get any errors in Python, but nothing else happens. I know it's not a communication issue; I have sent and received serial data from my Arduino in several other instances. PySerial and the FTDI drivers are installed (I'm on Python 2.5). Any idea as to what's going wrong? Thanks again for your help.

dylpkls91: are you using a Diecimila? orphans: have you tested pyduino on a Diecimila?

The auto-reset feature of the Diecimila means that you might need to pause 2 seconds or so after opening the serial port but before sending any data over it. That gives the bootloader on the Diecimila a chance to time out and start the firmata sketch. Otherwise, the first few bytes sent by pyduino will go to the bootloader, not firmata.

Ohhh... yep, I've got a Diecimila. I'll try putting a time.sleep(2) in pyduino.py and see if that works. I'll let you know how it goes. Thanks for the tip! :slight_smile:

Well, I just added a sleep of two seconds right after pyduino initializes the serial connection, but nothing changed in the behavior of my arduino. I even fixed the mistake in my test code where I forgot to call board.iterate() before writing to the pin, but that didn't change anything either. :cry:

Mellis: No I hadn't tested with a Diecimila - there was a post on the mailing list saying that Firmata worked better with the automatic reset, but I think that sending a couple of bytes to get the version straight after initializing the connection could be a problem. But not this problem evidently - I think it might be a bug on top of a bug :smiley: I'll stick a sleep in a new version once I know what's causing this.

dylpkls91: Ok, could you try running this - it's about as basic as it can get.

import pyduino
a = pyduino.Arduino("com5")
print a.get_firmata_version()

You should see the status LED strobe a pattern at the start (giving the major and minor version of firmata). Then there should be another quick blip or two from the status pin, and you should get a version number back. If this works then then serial communication with firmata is OK, and it's probably something in my digital code which is a little sketchy :slight_smile: If you could try this at both bitrates it'd be much appreciated too.

Also if none of that works could you give it a go using rev 1.3 of firmata. I think there's a chance that the serial initiation code has gone amiss in the change to using firmata as a library (I can't find it in the 0.10 arduino code anyway...)

Sorry I can't debug this myself at the moment, and cheers for looking into it.
Joe

Yea, the firmata that comes with Arduino 0010 doesn't work - I'm not sure it even compiles. You might also try increasing the delay from 2 seconds to 3 or 4 (or more).

Thank you both again for your help, but I regret to say that pyduino still isn't working.

Here's what I was able to find out:

  • The firmata included in Arduino 0010 does compile for me, whereas revision 1.3 doesn't.
  • Changing the baudrate in pyduino.py doesn't affect my results (I'm using the included firmata, which uploads w/o errors). I tried rates of 9600, 57600, and 115200.
  • I was finally able to get a two-value tuple from the get_firmata_version() function, by appending "self.iterate()" to init in pyduino.py's Arduino class.
  • The above fix only works when pyduino.py sleeps for 6 or more seconds after beginning the serial connection. ("import time; time.sleep(6)")
  • The code I posted in an earlier post, to just turn on the LED at digital pin 13, still doesn't work, although "a.digital[13].get_active()" returns 1 (which must mean that the pin was successfully set active).

Right, I think that I almost know what's going on now...maybe
The iterate and sleep should definitely be in init - that's my fault. The iterate after get_firmata_version() grabs the bytes sending the version, everything I've done before has been looping over iterate so I didn't notice.
I think that the problem setting the digital pin is in the 0010 version of firmata, although it does compile. I'm going to take a guess that the compile errors in rev 1.3 are to do with port_to_input_PGM not being found. If so try putting
#include <pins_arduino.h> after the EEPROM include in firmata. I think it should compile then and (hopefully) work with 57600 bitrate. If it compiles and doesn't work then we're back to it being my fault. If it doesn't compile then can you post up the errors - I remember I had to do a little tweaking to get 1.30 to compile with 0010 (probably just the include), but I thought it was my fault botching the new versions of everything.
Cheers
Joe

You might want to try the version of Firmata in the processing-arduino library from the Interfacing w/ Processing page on the playground. That's the one I've been using (I created the Processing library), and I believe it's the most recent stable version.

BTW, dylpkls91: when you upload a sketch (e.g. led blink), do you have to wait about 6 seconds or so after uploading it before it starts running? You may have gotten a Diecimila that was accidently burned with the NG bootloader, which works fine, but has a longer initial delay (so requires a longer sleep in the pyduino code).

Here's where I'm at right now.

I just tried Firmata 1.30, applying orphans' suggestion of including pins_arduino.h. At first, it didn't compile and I got the same error, but it worked after I poked around and changed the method calls in lines 164 and 165 of Firmata from "port_to_input" to "port_to_input_PGM".

I'm using pyduino.py modified in the following ways: I added a six-second sleep and self.iterate() to init, and set the baudrate to 57600, which matches the speed set in Firmata's setup() function.

But I'm still at the same point: Python can connect to the board via serial, pin 13 verifies being set active, I can get the version number, but any attempt to write a 1 to the pin does nothing. The rx light flickers, but that's it. :cry:

Mellis: Thanks, I'll try using that Firmata and let you know how it goes. No, when I upload a regular sketch (like the hello world led test) the board starts the program only a couple seconds after the transfer is complete. I put a six-second sleep in pyduino.py so that no data would be sent until after Firmata does its initial pin13-version-blink thing. Thank goodness my Arduino doesn't suffer from bootloader issues!

Thank you both again for all your help. It just goes to show that open-source communities have more than one advantage over the big guys. ;D

Breaking:

I am now using Firmata 1.29 and Pyduino (with sleep and iterate in init and a baudrate of 57600).

The Processing examples work (input, output, and pwm).

Better yet, as far as I can tell, Pyduino is now working just fine!!!

Thank you, thank you, thank you, both!

;D ;D ;D

Brilliant! Over the next couple of days I'll put up a new version of Pyduino which has your changes in, and contains the working firmware so we don't have this problem again. Thanks for all of your help dylpkls91 and mellis.
Joe

Great! Why don't I just e-mail you the two files or something?

Through trial and error, I found that the shortest possible sleep time without data/command loss is 1.5 seconds for Diecimilas.

Yeah, that'd be great if you could. My email's in the linky thing at the bottom of the posts.

Hmmm...

I've been playing around some more, and it seems like reading analog and digital inputs only works in a "while True" loop like the one in the pyduino example. I can't just grab an input's value once, it returns a 0.

Yeah, I get this too - I've got a fix for analog, just need to get a free hour to look at digital. What happens is that there is a delay between activating a pin and getting values out, so it just returns zero (a default value). I think I should be able to have a look this afternoon.
Joe

Great, once that's fixed, it'll be set! ;D

Right - half success...
Analog works fine afaik, and is not too bad code wise. Digital is however pretty sketchy I'm afraid. Anyway, here's a new version of pyduino: http://rafb.net/p/u9u2QP86.html
...and a rough idea of how it should work: http://rafb.net/p/FjOkxU38.html

As you can see, the analog iterates until it does not return -1 (i.e. a value has been assigned to the analog pin). This would be OK to do with digital, but there is no way of knowing whether the digital pin has been activated or not, as it only signals on a change. This is in the TODO for firmata, so will hopefully be in the next version. For now you can work around it by iterating for a while after the pin is activated so it has time to get a value.

On the plus side this has helped me find a big old bug in the digital handling, so it's all been good and worthwhile :slight_smile:
Let me know how this one goes
Joe