Firefly 1.006 Now Available

I am excited to announce the release of Firefly 1.006! This is a major release and includes many new components and bug fixes, along with a number of new tutorials and example files. Here are a few notable features:

Firefly 1.006 unveils a new Arduino Code Generator component which attempts to convert any Grasshopper definition into Arduino compatible code (C++) on the fly. It works by detecting components that are 'upstream' from the Uno/Mega Write component. The Code Generator checks the component ID against a library of custom C++ functions which then get added to the code if there is a match. The code can be simultaneously saved as a .pde (Arduino Sketch) file to be opened in the Arduino IDE.

In addition, there is also a new Upload to I/O Board component which allows you to upload any sketch (see above) directly to your Arduino board from within the Grasshopper environment. A lot of stuff happens behind the scenes with this component. Essentially it creates a dynamic MakeFile and calls a shell application to convert the .pde file into a .cpp (C++) file and then into .hex code (machine readable code) to be uploaded to the microcontroller. Now, you can automatically convert your Grasshopper definition into Arduino code and upload it directly to your board! Note: WinAVR is required to be installed on your machine in order to properly upload sketches to your board. You can download the latest version here.

We didn't stop there. The communication process has between Grasshopper and your Arduino board has been overhauled. Thanks to the newly rewritten GH_Timer (by David Rutten), the Uno/Mega Read components are now roughly 10x faster than previous versions. The Firefly Firmata has been re-written to be more flexible and efficient. The Uno/Mega Write component have changed how it sends data out to the board as well. Simply right-click on any input and set the data type to Digital, PWM, or Servo... That's right, you can dynamically attach a Servo to any pin now!

If that weren't enough, I've also added several components to handle network communication, namely UDP (User Datagram Protocol) and OSC (Open Sound Control). The UDP Listener and Sender components allow you to send/receive messages over a wireless or LAN network using asynchonous transmission. OSC messages are essentially specially formatted UDP messages and the OSC Listener and Sender components add functionality in handling this type of information.

There is much much more too (I didn't even mention the new XML Search or State Detection components)! For a full list of modifications and feature enhancements, check out the change log included in the download link.

To download the latest version of Firefly, please visit: http://www.fireflyexperiments.com/download/

If you are using Firefly and would like to share your projects, comments or ideas please e-mail us (info@fireflyexperiments.com) or post to the discussion forum. Updates will be posted to the Firefly website.

Firefly Developers:
Andy Payne [LIFT Architects; Harvard GSD - Cambridge, MA]
Jason Kelly Johnson [Future-Cities-Lab; CCA - San Francisco, CA]

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Firefly is a set of comprehensive software tools dedicated to bridging the gap between Grasshopper (a free plug-in for Rhino), the Arduino micro-controller, the internet and beyond. It allows near real-time data flow between the digital and physical worlds, and will read/write data to/from Pachube / internet feeds, remote sensors and more.

Firefly was founded by Andy Payne and Jason Kelly Johnson in 2010. Andy has been primarily responsible for writing the code underlying Firefly’s various core components. He has also been involved (along with Jason) with the development of the Firefly Firmata, a critical piece of open source software which enables a direct connection between the Arduino hardware and the Grasshopper environment. As of 2011, Andy is the lead researcher and developer of Firefly’s new X control tools. He is currently pursuing this research independently as a part of his PhD dissertation at Harvard GSD in Boston, MA. Jason continues to develop and support the core Firefly tools and educational primer. Jason has been active in helping to establish the connection between Firefly and the Arduino software and hardware environment. He is currently an Assistant Professor of Architecture and Interaction at CCA in San Francisco, California.

Acknowledgements:
Firefly is built upon the Grasshopper plug-in for Rhino, both developed by Robert McNeel and Associates. We would like to thank Prof. Panagiotis Michalatos for his generous support and guidance in the development of the Firefly_X toolset. Robert Lee also made critical contributions to early versions of the original Firefly build file. The Arduino language syntax is based on Wiring by Hernando Barragan. The Arduino environment is based on Processing byBen Fry and Casey Reas, and is now supported by an amazing team of software and hardware developers that continue to refine and expand its capabilities. Pachube was created by Usman Haque and his amazing team at pachube.com. The reacTIVision framework is being developed by the Music Technology Groupat the Universitat Pompeu Fabra in Barcelona, Spain. Ronnie Parsons and Gil Akos of StudioMode in New York City have also contributed to the development of some amazing example files that were released with version 1.004. We would also like to acknowledge the input of various colleagues, students and workshop participants for their support and questions which help the evolution of Firefly.

Comment

You need to be a member of Grasshopper to add comments!

Comment by thebaldearchitecture on October 21, 2011 at 11:57am: Super! :)

Thank you Andy!

Comment by Andy Payne on October 21, 2011 at 10:06am: @thebaldarchitecture,

After watching your video, I think I understand your question (but correct me if I'm wrong). Are you asking that when you removed one of the fiducial markers, why did the point stay on the screen (instead of being removed like the marker was)? If so, this behavior is intentional. You see, the reactivision engine will stop keeping track (if even for a moment) if the marker disappears from the screen). You may have noticed that there were several instances when you're hand actually covered up the marker from the camera, and yet the point didn't disappear. I didn't want the points to automatically to disappear if it was just dropped momentarily. Instead, it remembers whatever the last position of the recorded point was. I didn't want the issue coming up, where you may be dependent on the point for some solution, but it's constantly popping in and out of the viewport because the engine keeps losing track of the marker momentarily. This way, it keeps the last known location and never drops it, unless you intentionally want to remove it from the scene.
However, there's still the issue of wanting to remove a point (if this is indeed your intention). When you drop the Reactivision component onto the canvas, you may have noticed that there are black tick marks and a thin grey line in the Rhino viewport. The black tick marks indicate the boundary of the engine's camera view (the extents). The thin grey line is slightly offset from this boundary. To remove a marker from your scene, all you need to do is to slowly move the marker outside the grey boundary line (and this will remove the marker from the list).
Hopefully, this helps clarify what the Reactivision component behaves the way that it does. Feel free to send any other comments or suggestions on how to make it better.
Cheers,
Andy Payne

Comment by thebaldearchitecture on October 21, 2011 at 10:03am: Hi Boys!

Does anyone know why is there a point?

http://www.youtube.com/user/thebaldearchitecture?feature=mhee#p/a/u...

Comment by David Merlin on July 5, 2011 at 10:34am: Andy-

Firefly.gha file is unblocked and I tried installing the full version of .NET 4.0 Framework, but the Firefly.gha components still don't load in Rhino 5. Are there any log files I could send you?

I'm just starting to get into the release with Rhino 4 and will let you know if I run into any problems.

david

Comment by Andy Payne on July 5, 2011 at 8:05am

Instead of a list of non-supported components (which would likely be a lot)... I should probably create a list of supported components. I could do that fairly easily. See below:

List of supported components for Code Generator (ver 1.006):

Remap_Numbers
Addition
Subtraction
Integer_Division
Division
Multiplication
Absolute Value
Negative
Modulus
Square
Square_Root
Cube
Cube_Root
Logarithm
One_Over_X
Degrees
Radians
Natural_logarithm
Power
Power_of_10
Power_of_2
Power_of_E
Factorial
Sine
Cosine
Tangent
Sinc
ArcCosine
ArcSine
ArcTangent
Domain
Minimum
Maximum
Pi
Golden_Ratio
Gate_And
Gate_Not
Gate_Or
Gate_Xor
Gate_And_Ternary
Gate_Majority
Gate_Nand
Gate_Nor
Gate_Or_Ternary
Gate_Xnor
Constrain
Smoothing
Fader_One_Way
Fader_Two_Way
Binary_Blink
State_Detection

Comment by Gia Djahaia on July 5, 2011 at 7:55am: Thank you, for your explanations. My expectations unfortunately proved. But no need to translate this example to arduino ide, actually i was just curious about possibilities of new FF build, so that's why my question appeared when i faced this problem. Is there any list of non-supported components for codeGen? Just to be aware of those in addition to the C# and VB.NET components.

Comment by Andy Payne on July 5, 2011 at 7:47am: Ah... ok. I see now. You've stumbled on one of the current limitations of the Code Generator component :) I haven't created functions for every GH component... and certain ones wont need to be translated (an Arduino doesn't really need to know what a Line or Mesh Intersection is). Most of the Math tab has function definitions in place... One thing I could see a problem are the Script components (C# or VB.NET). It's not impossible... but I have to think about how to implement this. The Code Gen and Upload to Board components are still very much in their infancy and I have more that I ultimately want to do for both of these... but at the moment, it could be difficult to directly translate the tri-color switch definition for that reason.

Now, that said... this example would not be that difficult to code directly in the Arduino IDE. I could try to work up something for your (if needed)... but you should be able to run it with the Firefly firmata at least for testing purposes. Do you need this to run off an external power supply (ie. autonomous)?

Comment by Gia Djahaia on July 5, 2011 at 7:41am: Not definition is failing, but my attempt to plug this definition to the CodeGen component. I mean when im pluggin it, the CodeGen turns orange and i see warnings: function not found: C#_component, and function not found: stream gate.

So the question was have u succeed in translating this definition to the arduino code, and then uploading it to the board to work autonomous?

Comment by Andy Payne on July 5, 2011 at 7:33am: Hi Gi,

I'm a little confused on your last comment. I did test the tri-color switch example and everything worked as expected. Of course, it depends on your circuit setup (ie. which legs of the tri-color LED have to be connected to certain Digital pins). But, yes... it should work. You have to upload the Firefly Firmata to your board. Then, open the port. Then double-click the toggle connected to the Start input of the Uno Write component to begin sending data out to the board. Then go back up and double-click on the GH_Timer component to start the fader values. This should work if your circuit looks like the image included in the tutorial. How is your definition failing?

-Andy

Comment by Gia Djahaia on July 5, 2011 at 6:59am: Andy, did u try to generate and upload to board the example files of your own? For some reason I failed with 3color switch definition. (although I didn't try the rest)