|
Flashing light detection
Charles Tomkins from United Kingdom [13 posts] |
17 year
|
Hi, I am using the movement filter to pick up a flashing light (~1Hz) which works quite nicely at 7 fps, however when I start the RR Lego RCX control the frame rate drops to around 2 fps. I presume that the pipeline has to wait for the RCX and tower to complete their chatter, every time.
Its not a big deal, but it means that my bot (which is only a panning cam as yet) cannot consider moving until everything has settled ; which is taking about 10 seconds at the 2fps rate.
Are better ways to do this? (Ive attached my RR file)
-Maybe its simply that flashing lights are not the easy to distinguish navigational reference points, that I hoped they might be!
 program.robo
|
|
|
|
Lego Slowdown
Anonymous |
17 year
|
Chas,
Yes, that is correct that the Lego IR communication is not the fastest. One quick thought .. is there any way to know when things have settled down? If so you could but a conditional statement (if statement) around the Lego module and only execute it when needed. This will allow the frame rate to be preserved and still have the Lego module run when needed.
Also be sure to turn off as much of the Lego module as possible ... this will decrease communication requirements and speed up the frame rate.
We will also investigate making the control system independent of the frame rate.
Let us know how it goes ... and thanks for the robo-file.
STeven.
|
|
|
|
Charles Tomkins from United Kingdom [13 posts] |
17 year
|
STeven,
Thanks; only executing the Lego control module once the movement detection has settled down (IF there is a low COG_AREA) has made a big difference, in fact it has just about tripled the speed (5.7fps)
- my camera can now move again after only 3 seconds :-)
Out of interest, the COG_X variable seems to be one tenth of its RR value when it is inside the RIS program (I dont think this is happening inside BricX ) -This isnt a problem at all, just something I thought I should mention in case there are any fellow RIS newbies!
Thank you again
program.robo
|
|
|
|
RIS Variables
Anonymous |
17 year
|
Chas,
Glad the conditional helped increase the speed.
Question about the RR variable being 1/10 when in the RIS program ... we had a similiar problem to that about 2 weeks ago or so. Can you try downloading RoboRealm again and let us know if you see the same issue? We thought we had corrected that problem ... but perhaps that was for the Lego NXT??
STeven.
|
|
|
|
Charles Tomkins from United Kingdom [13 posts] |
17 year
|
Hi STeven,
I'm using the version with circle detection. It's peculiar as a NQC program put into the RCX picks up the COG_X values correctly.
Only a program created by the Lego RIS software divides the COG_X values by ten. I am saying 'COG_X' because I havent really tested other RR variables.
-Maybe a warning note on the RR lego control module, just to remind people would be enough, if the problem lies within RIS?
BTW I notice that when using the translate module the only way to alter the COG X&Y (of a white filled circle on a black background) is to decrease the X-offset below zero , translating the image in the other 3 directions has no effect. Im not sure quite how translating should effect the COG coordinates, so I am not sure if this is a glitch or not.
-Little glitches or not this is a wonderfull program.
Chas
program.robo
|
|
|
|
Translate Fixed
Anonymous |
17 year
|
Chas,
Agreed. We added a little note in the Lego docs to let people know about the scaling issue. We think it is due to how the RIS handles decimal variables ... but we could be wrong.
The translate module was created a while back and was definitely not correctly respecting how the current theme of RoboRealm is. We've fixed that issue and it should behave more as would be expected. Thanks for the bug tip!
And also thanks for the compliments!
STeven.
|
|
This Thread