Brian,
If you insert the Watch_Variables module you will see additional variables that mention the capture time of the image. I think that's probably what you want .. that will, however, be very close to the actual machine time as the USB delays will be very short. The issue is probably in the network transmission of the data from the Winbook to your dashboard. I'm not sure if you are also transmitting the image but doing so will really slow things down (due to network issues). If you read the bottom of
http://www.roborealm.com/FRC2016/Computing.php
under system configurations you can learn more about why you are getting oscillations. That's very common in bandwidth limited environments when the round trip time is too slow in comparison to reaction time.
A still image will always be more accurate than a moving image ... but I don't think in your case that will make too much of a difference. As long as the camera has enough light it will not blur the image too much to make that an issue. Unless you really so see the images being very blurred or slurry I'd not worry about that too much.
You may find, however, that the robot vibrates a lot when moving ... which WOULD cause the images to be blurry since the vibrations will be very high frequency. Snap a couple screenshots (using Ptr Sc button on your keyboard) when moving quickly and see what the image looks like.
While the image distortion does play a role in accuracy you would also see this issue when the robot is stationary since the lens will distort regardless of if moving or not. If you find that shots performed when the target is only visible in the the extreme left or right of the image then you have a distortion issue. Firing from slightly off-center will still work since the distortion will be greater on the sides of the image and not in the center.
The issue could be on the polling of the API. The network tables will do a better job on sending changed data ... or if you use the WaitImage in the API command that will ensure that only new data is polled. It is possible to poll faster than 30fps which you will not really need to since only new information is created on a new frame.
what I would check is to see what and how much information is flowing over the network. If you are transmitting the image, try reducing the image size (thats 1/4 the amount of data) which may suddenly run much faster. Keep in mind that any part of the system can have delays (including the Labview calculation) which should be reviewed again.
In terms of RR, keep an eye on the gray numbers to the right of the pipeline. They should all be quite low and the fps should be around 10-20 fps (ideally higher). If the gray numbers are larger than 00:100ms then that module may be slowing things down too. Its how we profile to see what modules might need to be reviewed or upgraded to increase performance.
Cheers,
STeven.
|
|