Thanks all for the suggestions. I think the final verdict is going to be replacing the white LED's out of a small LED flashlight with green ones, just for the sake of having a built housing, unless we can find one local, and then putting in the appropriate power regulation and connections.
Quote:
Originally Posted by apalrd
1. The vision code is very very slow
|
Very true, which is why you shouldn't design your program to use the vision processing algorithm you design continuously. Instead, use it to give you a rough angle (whatever parameter you are going with), decrease the error of that parameter, and continue. We are planning on going through no more than 3 stages of this any time we enter our auto-score mode, and use PID control for our robot/manipulator movements, i.e. Rough, Middle, Fine correction.
Quote:
Originally Posted by apalrd
and can cause great control lag to other systems. Think about this while manipulating your images.
|
Can you explain why it would cause lag in your other systems? I know why it should cause lag (because you are trying to move your robot/manipulator with to obsolete commands) but it should not cause lag due to communications or from the vision processing resources being used. If they are, you should make sure that all your vision processing is done (if you're using LabView, I have no experience with WindRiver) in the Vision Processing.vi and you are passing that data to global variables. If you don't do it this way you are much more likely to have lag issues.
When not in auto-scoring mode, the vision processing algorithm will be completely disabled. I haven't been able to do much testing yet but I assume this will reduce lag. Now we are getting around 4-6 frames per second I believe, and are shooting for around 12 without the vision processing, which is about what we were getting about last year if I'm not mistaken.