We go TCP all the way. We have our own specific reasons, most stemming from the mentors' careers in critical applications where reliability trumps speed.
UDP is only faster because doesn't have QoS built in. This means you may only get part of the message back to the robot, which may not handle a bad message and crash. It also doesn't natively enforce FIFO messaging, so the messages may collide or come out of order. This is fine if your robot is trying to tweet something - but maybe not so much for that critical vision target message.
First 4-bytes are the 'magic number'; second 4-bytes are the message length; the third 4-bytes are the robot time stamp; then finally the message itself. The 12-byte custom header is well-worth the overhead when considering how easy it is to implement a new message. The message encode/decode order is hard-coded to reduce dependencies on external 'flavor of the month' libraries, but is generally easier to do than it seems on the surface. The design approach also teaches students the basics of network programming. We have different messages: one is the data, one is debug messaging, others are more custom. The debug messages have the same format but are arrays of 2-byte chars, making it very easy to dump to and yank off of the socket.
The robot is C++, our custom driver's display & vision system is Java. It wasn't trivial to setup and integrate (threading on the robot mainly), but now it works flawlessly.
I plan to release a more generic library over the summer for use with next year's control system. Can't wait for a Linux-based flavor of robot
