[Ginto8]

This is actually a big reason I'm glad my team decided to ignore my early advice and go with IterativeRobot again instead of command-based. The command scheduler is... well, just that, a scheduler. It does a, then b, then c, then d. If any of these things takes too long, everything slows down. When a, b, c, and d are fairly small operations (like most operations on a robot), you don't have an issue. Camera tracking means processing at least 1 640x480 image, probably multiple times and with algorithms that are usually a bit more complex than O(n). When doing all of these operations, your cRio's 400 MHz processor isn't exactly a shining star. If you don't have the luxury of being able to change the processing over to the driver station end, your best bet will be to scrap the command structure (at least partially) and put the processing into a separate thread.