Quote:
|
The cRio connects via Ethernet to its camera, downloads a new image, processes it, and drives to the target, while causing the swerve drive controls to freak out from the non-constant loop time (even though vision is running in a separate virtual thread). I have seen vision processing mess up PID calculations. That's exactly why we didn't use the camera in 2009 with our swerve drive.
|
I hadn't heard many complaints about this. The framework for 2009 was kept simple and not designed specifically for a swerve robot. The "virtual threads" are real vxWorks threads BTW, and by default everything runs at the same priority. My suggestion to try and improve this would be to up the priority on the PID or lower it on the vision. VxWorks and LV RT are certainly used in realtime applications just as demanding as keeping wheels pointed in a particular direction. Also, learning to use the tools to learn where the processing is going, what latencies are being seen, and where memory is going, is IMO a good problem.
The thing about vision is that it produces so much data that it can bring almost any processor to its knees. Some simple things can be done with little code, but people have very high expectation -- "My two year old sees it, why doesn't the computer?"
If you want to post a good description of your lag, perhaps I can help you find the issue and solve it for real rather than talk about fictional ones. PM me if you want to try and do this interactively or want to provide code.
Greg McKaskle