Quote:
Originally Posted by sthreet
Is it alright if I ask how one language can communicate with another directly? I mean, I could make a file of some sort (txt?) and get the data from it, if both languages supported that, but something that would work better in realtime?
|
A byte is a byte is a byte, regardless of language.
Say you have an array of 14 Floats (have no idea why you'd have 14 of them in FRC). C++ has a way to cast/interpret all 14 floats into an array of bytes. Java has a way to cast/interpret the bytes to Floats. You can do this all yourself (faster to implement from scratch, doesn't depend on 'flavor of the month' frameworks, often easier to increase performance) or use something like Google protobufs (easier to understand and add new features, once you understand the framework).
Some frameworks even support sending a method call with parameters across the socket between multiple languages - such as CORBA and Java RMI. However in FRC this usually isn't necessary. Our messages are is a byte array of (1)An integer which identifies how to decode the byte array (message id that, when converted to hex, usually states what the message is - 0x60B0760 = 'Go Bot Go', i.e. the HOT message) (2) An integer which is the Message length - useful for custom generic messages where the id changes based upon bit flags so that bandwidth can be saved when necessary and (3) the rest of the message. The rest of the message is an array of bytes, and each 'float' or 'int' in the array is always a 4-byte value (i.e. no doubles or longs).
Our team tried the SmartDashboard & NetworkTables in 2012 for a few things, but it wasn't working out for what we wanted. That year and every year since, we have implemented our own network code. From what I hear, it's wonky and was somewhat unreliable (we still don't reliably get a message from the D/S to the robot without killing the robot...) so we won't open-source it. Next year, we have plan to evaluate alternative approaches.