generative modeling for Rhino
We're having problems trying to set up a Galapagos/Arduino feedback loop.
Here's the simpified case:
The problem is that Galapagos reads the light intensity value (fitness factor) too early - before the servo arm rotates to it's position.
We've tried adding a script component to delay just the fitness value, but it resulted in slowing up the whole definition, up & downstream...
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.
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 ;-)
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?
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.
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.
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.
Is that a 1 second delay? Or 1 millisecond? If it's 1 second, how responsive is it (your light optimizer)?
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.