MDP in a Nutshell 5 — Communication

Actually, we are setting up an error control mechanism on the top of UDP…

Subheading has no offense XD

Key Words:

#efficiency #dataflow #TCP #UDP #String #Json

  • Communication structure — data flow
  • Communication protocol — let’s call it protocol
  • Communication channel — TCP or UDP

First you need to discuss well with your teammates. What will be the data flow among your system? Will android tablet directly send command to Rpi/Arduino? Who will decode the sensor readings? Who’s going to control robot movements?

This is really important. It’s better to solve this problem during the first half of recess week. (other basic work should be finished before this. Like rpi multi-threaded programming and arduino serial monitoring)


Please be noticed that, our team decided to put Bluetooth module on PC. So the rpi will never face power comsuption problem. Your whole system will be more robust. However, i will not be that elegant. LOL

Second half will be focus on communication protocol.

Usually, Rpi will communicate with PC and tablet in a Json format.

http://stackoverflow.com/questions/383692/what-is-json-and-why-would-i-use-it

It’s good for communication.

And usually, arduino team will talk with rpi team to decide their own format:

Maybe like:

  • W|A|S|D
  • R12L1R1L3

Arduino can only receive string.. byte by byte. So it’s easy to just KISS.


But Arduino can send Json oh~

https://github.com/bblanchon/ArduinoJson

It’s very easy to just import the library. Just try Serial.println(JsonObj);


Try do debug separately: arduino to Rpi, Rpi to PC, Rpi to tablet, … so and so on. This is more efficient than whole team come together and wait for one or two debugging for whole day.

Settle your protocol and follow it. Pay attention to it! Your team will be more efficient.

Next topic actually should not be a topic.

TCP or UDP?

This should never be a problem…

Definitely, you should choose TCP.

Why cannot use UDP?

Even though the robot movement should be fast and efficient, you cannot afford it if you lost one single packet. Let’s say, you lose one packet, which is a command, turn left.

If you don’t have any “error control”, your pc will assume robot made that movement, which your robot didn't.

#GG

Use TCP

And reduce rpi’s work load to make less latency.

For example, don’t send to much rubbish to tablet. (arduino delete all debug info before integrate). Don’t delay, just send every command to pc immediately. Your application is on application layer. You don’t need to worry about out-of-order packages. =_=

Yay, do maintain a queue to store everything. When there is any disconnection happens, Rpi is supposed to send everything to pc again.

Settle everything before it’s too late.

Make wise changes before it’s not too late~

Communication part should be relatively easy throughout the whole project.