Sending data to cRIO

[shuhao]

Just wrote the client code for both python and J2ME

J2ME code:
https://github.com/FRCTeam4069/Robot...ils/networking

Python code and improved server is the same link as above if anyone wants those

[Hjelstrom]

Originally Posted by shuhao

Just wrote the client code for both python and J2ME

J2ME code:
https://github.com/FRCTeam4069/Robot...ils/networking

Python code and improved server is the same link as above if anyone wants those

In your scheme, where is the web server running that you're talking to? Is "flask" a python based web server that you're running on the cRio? Or is the web server running on your driver station?

This year is full of opportunities for ambitious programming!

[shuhao]

Best case scenario is an onboard, ethernet connected, laptop.

Worst case scenario is the DS laptop. Then certain ports need to be changed.

This thing has the potential to control the robot without the DS station (You would still need to "Enable" the robot via the DS station, though.)

My main goal is to do image processing on the laptop.. Gotta have an efficient way to communicate.

[Lalaland1125]

After seeing all those posts suggesting UDP, I still think using UDP for the robot is a very bad idea.

UDP is fundamentally unreliable, you don't know the order or if a package will get to its destination.

While it is possible to code around that unreliability, you are going to end up duplicating much of TCP's utilities and probably end up being both slower and buggier than TCP.

TCP(and stuff based on TCP such as http, json, xml, etc) would be a much better choice as a base for robot communications.

And, if you really need the extra space and speed savings that you would get from UDP, encode in a binary format(such as google protobufs). I am sure the speed and space savings from a binary format outweigh the savings from switching from TCP to UDP.

[Alan Anderson]

Originally Posted by Lalaland1125

UDP is fundamentally unreliable, you don't know the order or if a package will get to its destination.

For a real-time application such as robot control, the lack of a guaranteed delivery is usually a worthwhile tradeoff against the potentially long delivery day of a TCP packet. The kind of data we're talking about is basically "current status" information. If you lose a packet or two, it shouldn't be that big a deal; you'll get updated when the next one comes in.

Using TCP adds error detection and retransmission, but it has to use buffering in order to do it. If the CPU gets busy and can't react quickly, you can end up with significant lag in getting the data where it needs to go.

If you care more about getting every last bit of data, TCP is obviously the way to go. If you care more about getting data with minimum delay, choose UDP.

[Greg McKaskle]

TCP is much preferred if your data will not fit in a datagram. But small amounts of periodically retransmitted data are why UDP was included in the ISO networking model.

As an example, the joystick data from the DS is sent to the robot using ... UDP. The voltage and other robot data are sent back to the DS using ... UDP.
The field sends state data to the DS using ... UDP.

The only field control data not using UDP is the cameras, where the data is 6KB up to 40KB, and would require many datagrams, all arriving, and all reordered before it would be possible to rebuild the JPG image. But that is a perfect example of when to switch to TCP. There are other considerations, but UDP is a great protocol, and so is TCP.

By the way, the Charts tab on the DS now shows how many packets were lost each second and the latency from the DS to the robot and back. The lost packet indicates that either the control or status didn't make it, therefore the round trip failed.

Greg McKaskle

[Joe Ross]

Another note is that a LAN is not typically a high latency or lossy network, so many of the things TCP works around do not apply to the robot network.

[shuhao]

Originally Posted by Hjelstrom

In your scheme, where is the web server running that you're talking to? Is "flask" a python based web server that you're running on the cRio? Or is the web server running on your driver station?

This year is full of opportunities for ambitious programming!

Here's my new dashboard, purely webbased

[IMG=624x300]http://i.imgur.com/oe8qP.png[/IMG]