Galapagos - Firefly - Arduino: feedback loop

Replies to This Discussion

Permalink Reply by Andy Payne on November 20, 2011 at 7:24pm

Hi Jacek,

I've also tried this experiment... but without much success.  I had the same setup as yours, but at the time I was using an older version of Galapagos (and Firefly).  As you pointed out, the fitness factor in Galapagos is evaluated before registering the servo moment.  I'm sure you've tried different timer intervals too... which I don't think will necessarily help in this case.  I think the problem is synchronicity between GA input and FF output.  I've tried to optimize Firefly to run as fast as possible, and with the threaded GH_Timer, I can usually get a solution interval on my laptop of around 31ms.  Part of the lag is just because of the UI threading model of Grasshopper, and the timer doesn't fire until all things have been processed in that thread (so drawing everything on the canvas, etc.)  I have found that I can get higher framerates (and thus the solution will be calculated faster) if you minimize the Rhino and Grasshopper windows (literally make them as small as possible).  There is a Frame Rate component in Firefly that will tell you how many frames per second the data is updating.  Because the Timer has to wait on the UI threading to finish, the less it has to draw the faster your solution will fire.  I've found that if I lower my screen resolution to 1024x768) and then minimize the Rhino and Grasshopper windows then I can sometimes get a frame rate as high as 60fps.  This might be fast enough to get the Read component to update the solution fast enough for Galapagos (although I'm not positive).  Perhaps David could implement a event-trigger mechanism in Galapagos to decide when to update the solution.  Have you tried posting this on the Galapagos forum?

On a side note, I have tried other methods for light tracking (without using GA).  It's usually a more simplified process, and I only really tried it briefly during a workshop where a participant was after this same sort of thing.  Basically, I just helped write a short script that would take the current sensor value and then try to determine if it should try to move to the right or left in order to reach the desired light level (also an input of the C# component).  Basically, the psuedo code goes like this: Create a counter variable and initialize it to zero.  Each time the solution is recomputed, check if the current light level matches the desired light level.  If the light level is below the desired level, increment the counter by one, and recompute the solution again.  The counter variable gets assigned to the servo position. If the light level is above desired level, then decrement the counter.  This way, it auto-adjusts to find a position that matches the desired light level.  It isn't really perfect, and I would imagine some temporal smoothing or other approaches would be needed to refine it a bit.  I think the Galapagos way would be much more interesting, but for lack of a better approach, this might serve as a starting point.   

HTH,

Andy

Permalink Reply by Jacek Jaskólski on November 21, 2011 at 3:07pm

Hi Andy,

Thanks for the quick response.
I'll try experimenting the way you suggested. But in general I'm interrested in a more generic solution, I mean we could imagine that the "real life" process triggered by any external device, could take a couple of seconds to produce a result, which then should be read back into GH.

 

One of our ideas was to have an additional sensor which would only serve to tell GH whether the process has ended or not and then use it's input as a toggle/switch to the measured output.

In this particular case we could ie. attach a potentiometer axially to the servo in a fixed manner so it could track the servo's current rotation. Then I would compare the slider value to the result from the potentiometer sensor and use the result (true/false) as a filter gate for the photoresistor output. In other words - I would make sure the fitness value is empty as long as the servo is moving an not in it's designated position.

 

I am not sure though if that would actually work - will GA wait for the paramater to produce any value or will it just generate an error?

(well, I guess I'll have to try that out, won't I ;-)

 

 

Permalink Reply by Melvin Salas on May 30, 2012 at 7:21pm

Hi Jacek,

I just wanted to know if you were able to fix the issue. I'm trying to achieve the same type of feedback loop. Did you find a way to delay galapagos?

Thanks!,

Melvin

Permalink Reply by Jacek Jaskólski on June 1, 2012 at 3:20am

Hi Melvin,

Unfortunately no... as far as I know Galapagos still doesn't have a "evaluate on trigger" option or anything like that.

Good luck anyway, maybe you'll find some kind of a workaround.

J.

Permalink Reply by Melvin Salas on June 1, 2012 at 4:48pm

Thanks for your response, I'll keep trying then.  I've been thinking on creating a genetic algorithm in python on grasshopper (a very simplified version). I know it's complicated, but I think I will give it a try. 

I will let you know if I find some other way.

Permalink Reply by Melvin Salas on June 7, 2012 at 10:16pm

Hi Jacek!

I think I found a way to make it work. I've been trying it for the past few days, its not perfect but its working. I connected a python script that just said: time.sleep(1) to the slider connected to Galapagos. It doesn't matter that the python block is not connected to the Galapagos solver, it will slow down the slider and Galapagos will not be able to move it fast enough. It works fine with a 1 second delay for me, but I'm trying to find the perfect fit.

Let me know if you try it.

Permalink Reply by Andy Payne on June 8, 2012 at 5:51am

Is that a 1 second delay?  Or 1 millisecond?  If it's 1 second, how responsive is it (your light optimizer)?

-Andy

Permalink Reply by Melvin Salas on June 8, 2012 at 12:13pm

Hi Andy

yes, time.sleep(1) is 1 second, it takes a float number for milliseconds. (time has to be imported)

I think less than 1 second will work. I just want to be sure that the information gets back to Galapagos for now. I've made the simplest test possible. The idea is that the servo will move the disc over the light and it should identify that position #2 is the one that lets the most amount of light in. I also encountered another problem, the information from the light sensor jumps alot.  I could't use a firefly smooth definition because it slowed the information back to galapagos, so I had to create another definition in python that reads: if x > = 25 and x <= 75: a = 1 ...etc. I might have to think of a better way for future tests.

But, the last 10 tests were positive, so I'm building a more complex one.

I will let you know how it goes.

Permalink Reply by konrad k sobon on July 21, 2013 at 1:26pm

Can you please post the image of the exact code that goes into the Python object? I am trying to slow down Galapagos so that it let's Kangaroo form finding settle on a form before it advances to the next genome. Also, how does one connect Python component to a Slider in GH?

Thanks all help is much appreciated!

Thanks!