FRC Java TCP client

[yash101]

I need help. I need to make a TCP socket client to read and write data to a socket server in the back end. The Java ME in the cRIO seems quite limited (I don't have enough experience to back myself though), and I can't figure out the default socket library. Java.net is absent so I cannot use the Java native functions.

The socket server is written in C++. It is meant to communicate data between the cRIO and my coprocessor, mostly, but to also allow me to tap into the datastream from a remote computer!

I have been searching in Google and CD for a while and I am only coming across solutions for Java SE and above!
Have a good day

[Jon Stratis]

Well, it doesn't help right now... but in our Alpha and Beta testing of the new control system, the RoboRio uses full Java 8 SE. So, if you're looking to create something that could possibly be used in the future, you can work with the full SE and get it working on the RoboRio when your team gets one.

[yash101]

That really doesn't help too much, though. There is a chance that the Java SE might not be released in time. While that unfortunate chance is quite slim, I want to get started now. I want to get myself in a position in which I can calculate all the info I want on a separate computer with a lot of power, and send back the data to the cRIO. I guess that if I cannot get a network interface started, I might need to use a Raspberry Pi to convert these requests into a serial interface so I can use the serial I/O in the cRIO.

I would rather tend to avoid that method because it means that I will need to add another step in the data transfer, which will make the system prone to lag. With the level of AI I have planned, I need to do whatever I can to reduce lag! . Thanks for your answer, and I hope I can get this sorted out sometime soon!

[Arhowk]

Originally Posted by yash101

With the level of AI I have planned, I need to do whatever I can to reduce lag! .

Keep in mind that sending packets is a <sarcasm>bit</sarcasm> easier than writing AI scripts...

Also, remember the golden rule of efficiency, write the code first then determine if you have an issue. A thought-based AI will have no problem from the added delay by having a hardwired pie.

Also, I hope this is a stupid question but have you looked into NetworkTables?

[yash101]

Originally Posted by Arhowk

Keep in mind that sending packets is a <sarcasm>bit</sarcasm> easier than writing AI scripts...

Also, remember the golden rule of efficiency, write the code first then determine if you have an issue. A thought-based AI will have no problem from the added delay by having a hardwired pie.

As far as the actual question is concerned, do you have to use TCP? The only class I know of in Java 5 would be DatagramSocket which sends UDP.

I am using a library to make socket programming extremely easy. However, the easiest to implement protocol that it supports is TCP. Also, I want a constant bi-directional data transfer. I basically want to have some request system, where the cRIO can request some data from the coprocessor, and vice-versa. This would also allow me to use the same socket server to send data to a UI, etc.

UDP is my last choice. For some basic path-planning, I will need to ensure that all the requests complete in a structured order!

I guess that if I can implement NetworkTables on the coprocessor, that would make things extremely simple! However, I don't think NetTables were built to be as portable as I want them to be!

[Arhowk]

Originally Posted by yash101

I am using a library to make socket programming extremely easy. However, the easiest to implement protocol that it supports is TCP. Also, I want a constant bi-directional data transfer. I basically want to have some request system, where the cRIO can request some data from the coprocessor, and vice-versa. This would also allow me to use the same socket server to send data to a UI, etc.

UDP is my last choice. For some basic path-planning, I will need to ensure that all the requests complete in a structured order!

I guess that if I can implement NetworkTables on the coprocessor, that would make things extremely simple! However, I don't think NetTables were built to be as portable as I want them to be!

What dont you understand about the Packet class?

write data to the PacketOutputStream and send it to the server..

found this in the SocketConnection class (which seems to be the well documented class around packets and sockets)

 SocketConnection sc = (SocketConnection)
 Connector.open("socket://host.com:79");
 sc.setSocketOption(SocketConnection.LINGER, 5);

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

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

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

[yash101]

Yes, but I can't use that in FRC Java. It is in java.net, which is not present on the cRIO Java!
My main purpose of this thread is to find solutions that work in the current Java ME environment that the cRIOs run!

[Arhowk]

Originally Posted by yash101

Yes, but I can't use that in FRC Java. It is in java.net, which is not present on the cRIO Java!
My main purpose of this thread is to find solutions that work in the current Java ME environment that the cRIOs run!

According to the javadocs it's in javax.microedition.io.

E/ please fact check >.> just pasted that into my 2013 bot code and it worked fine (except for an uncaught exception)

[yash101]

That was exactly what I was looking for. Now, I need to figure out how to implement it!

[SteveGarward]

One of the best places to start is still the Java Tutorial. Here's the page on socket programming:
http://docs.oracle.com/javase/tutori...rking/sockets/

[Jon Stratis]

Originally Posted by yash101

That really doesn't help too much, though. There is a chance that the Java SE might not be released in time. While that unfortunate chance is quite slim, I want to get started now. I want to get myself in a position in which I can calculate all the info I want on a separate computer with a lot of power, and send back the data to the cRIO. I guess that if I cannot get a network interface started, I might need to use a Raspberry Pi to convert these requests into a serial interface so I can use the serial I/O in the cRIO.

I would rather tend to avoid that method because it means that I will need to add another step in the data transfer, which will make the system prone to lag. With the level of AI I have planned, I need to do whatever I can to reduce lag! . Thanks for your answer, and I hope I can get this sorted out sometime soon!

In time for what? While nothing is official until the season starts, Alpha teams have been using Java SE on the RoboRio successfully since last fall, and they didn't make any changes when they moved into Beta... I'd say you'd be pretty safe moving forward with that path - just mock out the RoboRio part on another computer for now.

When I'm working on a project at work, I seldom have a production-equivalent environment I can do my development on. We set things up so we can do development where we need to do development, then deploy to system environments (scaled down production hardware), and eventually to something that is actually production equivalent and then production. Is it possible to adopt a similar approach here? It'll save you a lot of headaches in the long run, as you can do development and some amount of testing without needing to monopolize time on the robot (or last years bot or practice bot or whatever). That time with the robot can probably be better spent with driver practice or build improvements.

[orangelight]

I am making one for my team here
https://github.com/orangelight/Robos...ation-Protocol

[NotInControl]

You can definitely use streams on the Java cRIO. We have been using TCP for years on our robot.

Here is some code to help you get started

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import javax.microedition.io.Connector;
import javax.microedition.io.ServerSocketConnection;
import javax.microedition.io.StreamConnection;
import org.team2168.utils.Util;


private int port;
private String messageOut;


private volatile boolean clientConnected;


// A TCP Socket Connection
private ServerSocketConnection conn = null;

// TCP Socket Stream
private StreamConnection sc = null;


// Address Variable
private String addressIn = "socket://:" + port;


// Opens a socket to listen for incoming connections
try{
	try {
		conn = (ServerSocketConnection) Connector
				.open(addressIn);

	} catch (IOException e) {
		e.printStackTrace();
	}

	// wait for a client to connect, this blocks until a connect
	// is made
	System.out.println("Listening on: "
			+ conn.getLocalAddress() + " on port: "
			+ conn.getLocalPort());
	sc = conn.acceptAndOpen();
	System.out.println("Client Connected");

} catch (IOException e) {

}

//To get the input stream
try {
	InputStream is = null;
	is = sc.openInputStream();
}catch (IOException x) {
	x.printStackTrace();
}


//Example to get the output stream
OutputStream os = null;
try {
	os = sc.openOutputStream();

	while (true) {
		//keep sending some message
		messageOut = "Some Message";

		buf = messageOut.getBytes("US_ASCII");

		try {
			os.write(buf);
		} catch (IOException e) {
			// e.printStackTrace();
			System.out.println("Appears Client Closed "
					+ "the Connection");

			// close streams
			os.close();
			sc.close();
			conn.close();

		}
	}
} catch (IOException e) {
	e.printStackTrace();
}

For 2015: Instead of using ServerSocketConnection and SocketConnection, just use ServerSocket and Socket classes to create TCP streams. It is much simpler to create a server in JavaSE

Here is an example for 2015 roboRio:

	// A TCP Socket Connection for RoboRio
	private ServerSocket listener = null;

	// TCP Socket Stream connection
	private Socket client = null;

        private int port;


        try {
		listener = new ServerSocket(port);
	} catch (IOException e) {
		e.printStackTrace();
	}

	// wait for a client to connect, this blocks the current thread until a connect
	// is made
	System.out.println("Listening on port: " + listener.getLocalPort());
	client = listener.accept();
        System.out.println("Client Connected");

//For the input stream, try the following:

try {
	DataInputStream is = new DataInputStream(client.getInputStream());
      } catch (IOException e) {
	 e.printStackTrace();
      }


//And for the outputstream try the following

try {
        DataOutputStream os = new DataOutputStream(client.getOutputStream());
     } catch (IOException e) {
         e.printStackTrace();
     }

[JesseK]

I would say I could help, but our team has used a C++ server on the robot for as long as I can remember - the client on the display was in Java. There are some 'tricks' to getting performance enhancements, but if you're going for full AI then you should focus on that specifically since that is by far the longest lead time to your goal.

I'd also recommend your robot be the server so you can control how often a client attempts re-connects at game time. You get 2-way comms if it's a TCP socket.

[gblake]

OBTW,

UDP's is unreliablity only results in lost messages when resource contention exists. I doubt there will be much of that in a well-designed version of a specialized appliance like a co-processor communicating with a robot controller.

To remove the possibility of lost or out-of-order messages, if the other solutions (already posted) hadn't been available, you could implement a simple user-code handshake to ensure reliable, ordered delivery of UDP messages between the two processors.

I know that an efficient off-the-shelf TCP implementation is almost always the proper way to avoid reinventing the wheel; but one shouldn't be scared of reinventing parts of it, if (and only if) necessary.

Ensuring reliable (in the connection-oriented communication sense) and ordered delivery isn't all that hard, and wouldn't add much overhead to an intra-robot comm link.