Quote:
Originally Posted by yash101
You'll easily get the framerate. That is based off connection speed. However, even if you get a lower processing framerate onboard the robot, 3 fps is good enough to outmatch the driver station at times. Then, the computer will need to process those images and then send data back to the cRIO. You can use UDP if you are trying for speed, but there is no error correction so there is a chance your robot could do something stupid.
If the robot was having vision tracking making sure it doesn't bump into anything, the robot is speeding at top speed and you walk in front of the robot (accidentally), running on the driver station with a .5s delay with everything, the robot will have a minimum of 5 meters to start reacting, not including the braking distance and other factors. However, having the processing on the robot speeds things up a lot. Plus, you have the lag increase when you go farther from the AP/Laptop in the first example.
|
Where are you getting this 0.5 seconds from?
At competition, the our total delay for the transfer of both the image and the processing was ALWAYS less than 100 ms, usually less than 50ms.
You don't have evidence that shows the total response time from either of the setups, and you also don't have any evidence of how response times actually effect the robot's ability to function. Before making your decision, I strongly suggest you test both methods!
(Also, if your robot can travel 5 meters in 0.5 seconds, you're going 32 feet per second, more than triple what you normally see in FRC).