Quote:
Originally Posted by Joe Ross
You didn't mention what programming language you use or what resolution you had issues with in the past.
For C++ and Java, the WPILib CameraServer class has been completely rewritten to significantly optimize it. We get lower latency and much lower CPU usage compared to last year. It also sends the data as a standard mjpeg stream, so you can open it in a web browser. This is helpful because it can help determine if it's your dashboard, or something else that is causing the latency. You should give it a try this year before trying to implement your own.
In general, you want to use the smallest resolution that gets you the results you need. For a driver camera, we've been able to get away with 160x120 in the past. That requires pushing 16x less pixels then 640x480.
|
Just wanted to echo Joe's sentiment here. An issue I've seen at competitions is that the bandwidth (between driver station and robot) is sometimes limited due to various environmental issues that arise during a real-world competition. FIRST has done a lot of work to improve things here, but the wireless link between the robot is susceptible to disruption from other signals (e.g., cell phones). Again this is usually not a problem but in addition to keeping your video bandwidth on the low side I'd encourage you to think through what happens if this doesn't work due to some sort of temporary disruption. I think it will likely be fine 99% of the time, but there are (likely rare) times when it may not, so think carefully before making this a feature that your robot has to have to play the game. Be sure to have a workaround in case it doesn't work during a particular match.