Quote:
Originally Posted by Alan Anderson
Good information. I'll only make two comments:
UDP is usually preferable to TCP for the kind of data you're sending from the offboard computer to the robot. You're really only interested in the latest information, not in guaranteeing delivery of every single packet in order. TCP's retransmission of unacknowledged packets can introduce significant delays if there is network congestion (e.g. video streams).
Your custom MetaTCPVariables package is no longer necessary. NetworkTables provides exactly the same thing and is included with robot software development environments this year.
|
UDP is absolutely preferable,
sadly the Squawk VM doesn't support it. We tried that at first, and gave it a shot again this year in hopes the Squawk VM would be updated in the newer cRIO firmwares but it hasn't been.
As far as NetworkTables goes, I'm sure it works but I'm personally not a big fan of it. It's big, confusing, poorly documented, and there are few if any good examples on how to use it. That said, I have been considering trying it this year just to give it a shot, I just need to block out some time to sit down with it and figure it out. It'd definitely be nice to have something everyone can use more easily without having to deal with writing in their own TCP code, I'll keep this updated as we deal with that.
Warehouse: Funny you'd mention that, we're actually thinking of using a Raspberry Pi on the robot this year. The packet priority should not matter as the bandwidth isn't nearly saturated enough for that to be an issue, though. Our plan with the Raspberry Pi is to run pretty much all the same Labview VIs, but to separate them out from the Dashboard (which would actually be even easier.)