Connecting with roboRIO over TCP

[Thardro]

This year we are attempting to do vision processing on an Android phone. We are creating a TCP connection over ADB, and then creating a ServerSocket on the roboRIO and a Socket on the phone, with each having a port 3042 and the hostname on the phone is roborio-3042-frc.local. When we try to accept the ServerSocket on the roboRIO, the program becomes stuck, indicating there is no connection. Has anyone else encountered this, and what can we do to fix the connection?

[Jaci]

If it hangs, it generally means that the client socket isn't finding (or isn't trying to connect to) the host socket. Double check that your client phone is trying to connect to the host (i.e. it reaches the code that creates the connection), and that you're on the same network.

As a rule of thumb, for things like vision tracking that update on a periodic basis, UDP might be a better idea.

[Andrew Lobos]

If you're using adb for network forwarding, it binds the port on localhost

So if you run "adb reverse tcp:3042 tcp:3042" to setup your port forward on the RIO, then the phone connecting to 127.0.0.1 port 3042 will be forwarded to port 3042 on the RIO - use this instead of the RIO's mDNS name.

[Thardro]

Originally Posted by Jaci

If it hangs, it generally means that the client socket isn't finding (or isn't trying to connect to) the host socket. Double check that your client phone is trying to connect to the host (i.e. it reaches the code that creates the connection), and that you're on the same network.

As a rule of thumb, for things like vision tracking that update on a periodic basis, UDP might be a better idea.

We have confirmed that the phone is attempting the connection, and they should be on the same network as adb on the roboRIO is detecting the phone. Why would you recommend using UDP over TCP in this case?

Originally Posted by Andrew Lobos

If you're using adb for network forwarding, it binds the port on localhost

So if you run "adb reverse tcp:3042 tcp:3042" to setup your port forward on the RIO, then the phone connecting to 127.0.0.1 port 3042 will be forwarded to port 3042 on the RIO - use this instead of the RIO's mDNS name.

Thanks for pointing that out, I could not find which host to use so I assumed it was the mDNS name. I will try this as soon as I can get access to a robot again.

[Andrew Lobos]

Originally Posted by Thardro

We have confirmed that the phone is attempting the connection, and they should be on the same network as adb on the roboRIO is detecting the phone. Why would you recommend using UDP over TCP in this case?

UDP is nicer for an application like this because you don't really care about the advantages TCP provides. In a nutshell, TCP will guarantee delivery of packets as long as the socket is connected. UDP is just simply sending data without any guarantee or verification it will arrive intact.

This is great in the case of vision - you're likely going to be sending updates at a fairly fast rate, so if one packet gets lost you don't really want to care about retransmitting it.

Unfortunately, adb only supports bridging TCP and unix sockets as far as I've found



My team's implementation is similar to yours, except we're running the server on the phone side and the client on the RIO - but I can verify adb reverse works in the same way (binding to localhost).

[euhlmann]

So instead of going through the pain of getting adb working on the rio, we went for a simpler route: USB tethering. With root, the vision app auto-enables it as soon as USB is connected. We've tested, and USB tethering works on the rio with no additional configuration required. It's very simple, and it also supports UDP.