Sending data to cRIO

[mikegrundvig]

For my own understanding then would you run a web server on the computer and make HTTP calls from the cRIO? And if so, what is the code on the cRIO to do that? I see minimal WPI documentation on socket and nothing on HTTP. Even a link to the right documentation would be enough to get me started. Thanks!

-Mike

[shuhao]

Originally Posted by mikegrundvig

For my own understanding then would you run a web server on the computer and make HTTP calls from the cRIO? And if so, what is the code on the cRIO to do that? I see minimal WPI documentation on socket and nothing on HTTP. Even a link to the right documentation would be enough to get me started. Thanks!

-Mike

Java Doc: http://k.thekks.net/frcdoc/javax/mic...onnection.html

Yeah, you're right. I initially planned to use a purely standard compliant restful server. However, I think I might just go with flask as it will be super easy to program for and I already have a LOT of experience with it.

On top of flask, I'll probably have code to pull off the camera image from its HTTP stream, and use OpenCV to process them. Those results returned by the processor will be added to a queue (by POSTing to the flask server), which then the cRIO could pull off from a GET request to a specific address. Since flask's dev server is not the ideal choice for high traffic concurrent application (not exactly it, but it'll be more than 20 req per second.. for sure), I'll probably setup a gevent wsgi server to wrap that around the flask app, which I already have code for that I've written for other applications.

The only non-problem I have with this is the overhead of message delivery.. but those are really nothing since everything is either local or over an ethernet cable.. transferring some simple JSON data, and gevent is fully equipped to handle those.

I feel like someone is going to call this setup too complicated.. but it's fool proof, there will be little to no errors in the server/client code as the only ones that has a chance of occurring is some sort of connection error (or a bug in the library.. but i doubt that).. which will occur with socket anyway.

If someone is going for the same approach, I'll be happy to share my client and server code.

[mikegrundvig]

Gah, I totally lost track of the fact you are using Java. We are using C++ and I have no idea how the students are going to get C++ to talk to anything effectively. Serial was a crap shoot and still is. I REALLY wish we were using something else.

-Mike

[apalrd]

If you're sending data between the cRio and a laptop on the robot (connected to the bridge or 2nd cRio ethernet port), it would seem that UDP datagrams are the simplest solution, as they are easy to implement (a UDP listener does not require more than one thread, and a UDP sender is a synchronous call requiring no state at all)

[mikegrundvig]

The problem is getting students that barely know C++ far enough along to actually put that together. With Java at least I could point to hundreds of cut-and-pastable examples. I think we will probably stick with the original serial idea just for it's general simplicity.

-Mike

[shuhao]

Originally Posted by mikegrundvig

The problem is getting students that barely know C++ far enough along to actually put that together. With Java at least I could point to hundreds of cut-and-pastable examples. I think we will probably stick with the original serial idea just for it's general simplicity.

-Mike

Is there no member of the team that could just pick up another language by reading references? C++ is a terrible language to learn how to program, as it has way too many concepts enrolled into 1 (really 2 languages into 1, if you think about it). On top of that, the C++ already code is not portable to the cRIO.. so you're getting even less support with that...

For me though, I don't think Copy-Pasta is the best idea in terms of programming the robot.. the students will neither learn, nor will the robot be well programmed...


Edit: Just took a look at the C++ references (stupid chm files.. gotta find a viewer lol) and it seems your options is fairly limited.. existing C++ code probably won't work for you either.

Also, are you a mentor on the team?

[mikegrundvig]

C++ was the language the students wanted as they picked it last year and it worked for em. There are two differences to last year though - they had one student on the team who was OK at C++ and the robot code was vastly simpler. They have no C++ mentors that have shown up regularly and while I'm actually a good programmer, I don't know C++ goop well enough to help significantly.

Is there no member of the team that could just pick up another language by reading references? C++ is a terrible language to learn how to program, as it has way too many concepts enrolled into 1 (really 2 languages into 1, if you think about it). On top of that, the C++ already code is not portable to the cRIO.. so you're getting even less support with that...

I agree, I think learning C++ by the seat of their pants is a nasty problem. I'm going to appear one last time to get things working in Java. Porting the robot code they've done thus far to Java would be a trivial exercise we could complete in under an hour. Add to it how many advantages we'd get with all the built-in libraries and available online examples, it seems like a no-brainer solution.

Just took a look at the C++ references (stupid chm files.. gotta find a viewer lol) and it seems your options is fairly limited.. existing C++ code probably won't work for you either.

Yeah, not too much is there? All of that appears readily available in Java as well. Then we also get micro-edition abilities to boot. I've had a lot of trouble getting details on what the OS itself of the cRIO gives us for c/c++ options. This makes porting code from say an Apache library over to the cRIO very scary.

Also, are you a mentor on the team?

Yup, so beyond suggestions and some guidance, it's their decision. Thanks!

-Mike

[Greg McKaskle]

Learning to use UDP can be an opportunity to look at Java or LV examples and let the kids translate it to C++, or at least try to. I agree that C++ copy and pasting code is not a great learning environment, especially if there isn't a mentor there to help debug and help fix things.

Greg McKaskle

[shuhao]

For those people who are interested, I just took about 30 minutes to write up the server code for messaging:

https://github.com/FRCTeam4069/Mediator

[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