Java and C++ integration, UDP/TCP

Technical Programming
1

I have written the skeleton of my vision code in C++ now. That runs on the Driver station computer parallel to all the FMS tasks. Our robot is coded in Java. To bring these together, C++ => Java, DS => cRIO, I am thinking about using network sockets.

I would prefer to use UDP because it is faster, but as I’ve heard, the UDP implementation is either non-existent or doesn’t function well in Java, so TCP can work.

I’m persuading the rest of the programming team to work on a small socket client, but they probably either don’t understand network sockets or they aren’t showing GP.

How is the socket networking done with Java on the cRIO? I could use that as a starting point for getting the rest of the programmers to understand what I’m trying to do!

2

I only have a basic understanding of all of this myself, but this idea is very interesting. A quick google search revealed this website on java networking. It talks about the basic ideas of networking as well as how to implement it in java.

I also found the open ports on the field here. It looks like you could be TCP 1180 or HTTP 80/443 depending on your camera configuration.

If you wanted to use java on both ends, I have had great success with Netty.

3

What about UDP/TCP 1234, etc. Does it mean that that port is blocked?

4

I read it as only the ports listed are available for use.

5

Yes; Section 2.2.8 of the manual specifies the open ports on the field:

Once plugged in to the Field Management System (FMS) via the Ethernet cable provided, the only open ports in the ARENA network are as follows:

TCP 1180: This port is typically used for camera data from the cRIO to the Driver Station (DS) when the camera is connected to port 2 on the 8-slot cRIO (P/N: cRIO-FRC). This port is bidirectional.
TCP 1735: SmartDashboard, bidirectional
UDP 1130: Dashboard-to-ROBOT control data, directional
UDP 1140: ROBOT-to-Dashboard status data, directional
HTTP 80: Camera connected via switch on the ROBOT, bidirectional
HTTP 443: Camera connected via switch on the ROBOT, bidirectional

Teams may use these ports as they wish if they do not employ them as outlined above (i.e. TCP 1180 can be used to pass data back and forth between the ROBOT and the DS if the team chooses not to use the camera on port 2).

It looks like Java ME sockets work a bit differently than Java SE sockets. You use the Connector class to open a StreamConnection or SocketConnection object. The Javadocs give an example:


SocketConnection sc = (SocketConnection) Connector.open("socket://10.xx.yy.5:1180");
sc.setSocketOption(SocketConnection.LINGER, 5);

InputStream is = sc.openInputStream();
OutputStream os = sc.openOutputStream();

os.write("
".getBytes());
int ch = 0;
while(ch != -1) {
    ch = is.read();
}

is.close();
os.close();
sc.close();

Note that I have not used these classes, so YMMV.

6

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 :smiley:

7

I would recommend you also take a look at NetworkTables. Integrating C++ into NetworkTables on the drive station will take some use of magic Java stuff called JNI - Java Native Interface. Search here in ChiefDelphi to get some hints.
Best,
Martin Haeberli
(one of many)
Mentor(s) to FRC Team 3045 - SWAT - San Mateo, CA

8

I recommend not just to use UDP, but to use UDP only and nothing more. Do not use TCP and UDP together - better learn how to implement those TCP features based on UDP you may require instead.

9

I just asked our programming mentor and he told me he knew how to implement it! Now, I need to learn the C++ side! Can I use winsock.h/winsock2.h? I don’t know how Java uses the network (the packets it sends) and how to use that with C++. If it can run in Linux too, that would be greatly appreciated! :wink: