Just solved a really sneaky race condition last night, so I thought I would do something so other people don’t fall in that trap and blame their vision slowness on “LabVIEW is slow.”
In Robot Main.vi, there is a bit of code shown in the attached image that applies what is effectively a constant (an unwired control) to the global variable Enable Vision. You need to remove this bit of code if you are going to at all use this variable, say, to turn a ring LED on or off. If you do not, you can easily miss this, since you’re “not supposed to edit Robot Main.vi.” I certainly missed it.
This race condition is characterized by your vision code taking almost exactly 50 ms to loop every time, while it appears to take about 300 ms to update the result variables. As a result, it pretty much just looks like it’s running slow.
If you do that while using the variable to simultaneously enable vision code and turn on a ring light, the ring light will be always on, which is not allowed.
Wouldn’t it make more sense to create a variable to control your ring light rather than alter the way it’s already functioning to control the vision system as a whole?
R07-M really depends on which light source you’re using. If you’re using something with a 300 lumen output, you’re probably going to have a bad time, but if you’re simply just using the LED ring in FC or a smaller LED that was mentioned in another thread, I doubt anyone will rule that illegal.
Please note: I am not an inspector. Please at least run it though a spike just in case. The ability to be able to turn it off will not be a bad choice at all.
I’d imagine you’re planning on your team operating in the portions of the field clouded by one, or both, airships. Is your vision code not streaming a feed to your drivers to help them drive the robot in these cases?
The streaming code is a self-looping VI that starts when Vision Processing.vi initializes. It is separate from the actual vision loop that you write. It lies far outside the Enable Vision case structure.
