ofArduino based on StandardFirmata in cppGlue

Hey,

I’ve put some more work into the arduino support in cppGlue and it’s now at the point where I’d like to have had it at the OF Lab.

For some reason it’s not working properly at 115200 bps but If you run it at 57600 it seems to work fine. I’ve tested it against the latest Firmata and StandardFirmata (v2b3).

If you check it out at cppglue.googlecode.com you’ll also find some updated example code as well.

The basic idea is that there’s a StandardFimata class that complies with StandardFirmata sketch on the Arduino. It should be plug and play, except that you might have to turn down the baud rate to 57600.

Then there’s a Arduino class that currently extends standard firmata with servo, wire (I2C), and sht sensor support. However to get this working you need to use GlueFirmata on the arduino, and install all of the arduino libraries it depends on.

I will try to keep StandardFirmata up to date with the latest release of the StandardFirmata sketch. Once the final StandardFirmata 2.0 on the Arduino is released I’ll tag everything, but it’s pretty set now so I don’t expect there to be much changes on the OF side.

Arduino and GlueFirmata might see more changes though since I put in stuff that I need for specific project but can’t achieve through StandardFirmata, like wire, blinkM and SHT sensor support for example… some of this could prove useful for others and might eventually trickle down to StandardFirmata, but until it does I think it’s wise to keep it separated.

So, for OF i think a good idea could be to make an ofArduino class that simply extends StandardFirmata. It should be plug and play and easy to use for beginners, except that they unfortunately might have to change the baud rate in the StandardFirmata sketch on the arduino.

If you release it for OF without poco you’ll have to comment out the events, but that should be it since it now uses ofSerial…

hope you find it as useful as I do,

btw, I’ve also updated the DmxPro class to use ofSerial and it works fine (at least up to 509 channels)…

hey erik,

thanks! It’s perfect timing, because poco is part of the core now and it should be no problem to get everything with event included. I think we might work it a bit to fit within the current model, but it looks not so complicated…

having tried a recent version of the firmata code out for the interactivos workshop in mexico, I have to say that we are super happy to include this and it should greatly simplify cpp -> arduino communication. I was really shocked at how simple and elegant it is to use. I’m not used to hardware / software communication being easy :slight_smile:

in addition to integrating this code to the OF core, I’ve been discussing with Hans to develop a small set of hardware based tutorials (ie, analog input, analog output - pwm, digital input, digital output) so that we can release OF example code that you can follow by building with set parts and instructions. I think of this as a kind of firmata hello world… jenny choudry helped me with this alot in mexico. if you have any ideas about what would be dirt simple to hook up and document (ie, push button, potentiometer, led on pin 13, etc) let me know – also, a small parts list might be good to develop. that way, folks can get up an running with firmata with known systems…

thanks again for this push, we are really looking forward to working with it…

take care!
zach

That’s strange about 115kbps not working correctly…

What if, instead of making an ofArduino class that was instantiated and dealt with, you extended ofSimpleApp with something like your arduinoExample/testApp.cpp? Then when someone wants to interface to the Arduino, they just extend “ofArduinoApp” instead of ofSimpleApp. This isn’t really the standard way of using libraries, but it could simplify things like setting up the event handlers. Then you just have to override methods like onInitialized, onAnalogPinChanged, etc. when you need them.

Again, it’s not normally how libraries are used… but it works in some cases (like in Processing, where everything extends PApplet, the class that implements all the standard functions – making them local so that when you write code everything easy to write and read).

If you extend StandardFirmata with ofArduino, I would want to be able to say something like

  
ofArduino* arduino = new ofArduino(this, ""/dev/cu.usbserial-FTDXPMW6", 57600);  

And have it assume the methods for the event handlers, so that you just have to add them to your testApp to actually get the data.

Essentially: it looks great already, the only thing I can imagine is finding a way to collapse the event handler attaching and connect() into a single call (either by extending testApp, or like the code snippet above).

I believe OF is going the Poco event way in v 0.6 so maybe sticking with Poco events might not be such a bad idea.

http://forum.openframeworks.cc/t/of-events/1020/0

Zach: I think you’re right on with the simple hardware tutorials.

Led on pin 13 for digital output
Button on digital pin for digital input
Pot on analog pin for analog input
Led on pwm pin for analog out…

It’s not the most exiting of sensors and actuators, but the components should be easily available to most people and simple to hook up… I wouldn’t mind putting together these tutorials w/ photos + code when 0.06 comes out…

Kyle: I see your point, poco events could definitely be simplified a bit for OF. I’ll keep the poco events as they are for now, and look over them when 0.06 with poco is released, I think they’ve wrapped the events a bit for that release… Anyway, for beginners it’s still possible to do input and output by polling the class…

What if, instead of making an ofArduino class that was instantiated and dealt with, you extended ofSimpleApp with something like your arduinoExample/testApp.cpp?

That’s more or less what we use in 0.06 events, but instead of creating a whole new testApp, you just need to create a listener, and inherit that listener in your applications: we have multiple inheritance here, so no need to touch the testapp :wink:

I’ve been using the tween class in cpp.glue, and have adapted it to use an events structure more similar to that in oF 0.06

There’s only the tween, no animator, but if you want to take a look, perhaps it can be useful as an example. I also got rid of the namespaces and have used some delegates to make the syntax of the call easier, now to create a tween you use something like:

  
backTween.setParameters(BACK_TWEEN,backEaseOut,leftPos,rightPos,duration,0);  

You can download from:

http://65.111.166.199/openframeworks/ofxTween.zip

Also was thinking, that perhaps you should create several addons instead of cpp.glue If they were more interelated… but having arduino in the same package as some easing equations doesn’t make very much sense to me.

[quote author=“arturo”]we have multiple inheritance here, so no need to touch the testapp :slight_smile: A much cleaner solution, and the syntax would be exactly what I had in mind.

Yeah, the ofxTween class looks nice… I need to sit down with this and of 0.06 some time soon…

I agree that cppGlue would be more useful if it was split up in several addons. I didn’t have the intention of making an addon at all at first, basically because I didn’t want to maintain versions with and without poco dependencies and because there are some (and were more) dependencies between the classes. So the reason it’s all in one library is just out of convenience, for me it’s easier to work with all of it at once…

You could see glue as a small and alpha-ish general purpose library, you check it all out but only include the stuff you use (as with poco)… Or you can do like you’ve done with ofxTween and I think Zach is doing with the Arduino class, move more useful and stable parts of into oF or addons… But, yeah, I guess it looks a bit silly now that there’s so little stuff in there…

Now that poco goes into oF it will be easier to rework the more “final” code, like the animator/tweens/callers/dmx/arduino into proper addons. I just have to figure out how to best manage it all… I like to be able to move fast and do major refactorings of the code at the same time as I like to share code that others could find useful. It’s more or less a matter of time, unfortunately there’s always too little of it…