[Greg McKaskle]

I think we are all getting on the same page. If you were to use WireShark, and please do if you have the time to expose the kids to it, you will see that the heartbeat of the system are UDP packets flowing from DS to robot and back every 20ms. If they glitch for more that 100ms, the robot gets disabled because the NETCOMM library doesn't feed the FPGA with the next encoded cookie.

I can't say how much UDP buffering there is, but there is definitely some. I'm sure it can be adjusted, but I'd think of that as being helpful in making the OS smaller, not more realtime. The key to having all the other loops doing UDP is to allow all of the readers to be clocked by arriving packets. Nothing else throttles them -- most have a timeout of one second in order to set some defaults. The writer loops are the ones that have the delay, and for that, I use a timed loop which is critical priority. It only takes one timed loop for the whole system and everything else responds to the sent packet. Other writing loops such as for the Kinect use regular loops.

If you want to see the packet statistics, the Charts tab on the DS now displays the lost packets per second and the trip time. Approximately 50 are sent, and the scale for total trip time to and from the robot is 100ms.

Please let me know if you see other odd behaviors or have questions.

Greg McKaskle