Arduino outside communication multichannel

Hello,

I am writing a drone pilot and I would like to use my own networking protocol, rather than a RF remote. I am using a raspberry pi zero to connect to internet and I am using the arduino nano to balance the drone (because it gives me constant processing time)

Could someone point me to books/article/documentation on different communication protocols between two chips? I intend to send data from the internet-connected device(rasp) to arduino and not affect the balancing algorithm.

What is the difference between i2c, UART and spi in terms of speed/reliability and which one wold be the best for my scenario?

Thank you very much

How often do messages need to pass from the RPI to the nano, and how long is each message?

Does data need to pass from the nano to the RPI? - if so, how often and how much?

I assume the distance between the RPi and the nano is only a few centimetres?

...R

If you don't want your balancing algorithm to be affected then you need to use hardware (or software) flow control to tell the raspberry pi when it's OK to send data and when it isn't.

Presumably the nano has a cycle that involves gathering sensor data, doing some calculations and setting the PWM signals to the drone ESC. At the end of that cycle you could signal to the pi to send data for some window of time, (4ms or whatever) before restarting the cycle.

Thank you both for your inputs and questions.

The raspberry pi has to send a lot of short data and receive telemetry data from the nano. I want to receive and send data to/from arduino as quickly as possible (it's a realtime application - a drone which has to be controlled in real-time so latency is an issue). The pi will be attached to the custom arduino board (millimetres away, but consider centimeters for testing purposes).

How often? The question should be "how quick?". I am sending data to the raspberry via 4G, therefore some latency is lost there. I want that data, as soon as it is processed to zap into the arduino.

The data coming to the raspberry is in the format YAW/PITCH/ROLL/THROTTLE/RUBBLE.

The data going back to the raspberry should return at 1/10 the rate of the incoming data (it's just for telemetry, pitch, yaw, roll + magnitude)

Is this achievable?

Calculate the number of bits you'll be sending or receiving per second.
Pick a baud rate and calculate how many milliseconds per second you'll need to allocate for sending and receiving data.
Does that leave enough time for your balancing algorithm to do its job?

mylast:
How often? The question should be “how quick?”.

No it should not.

As far as your interface between the RPi and the Arduino is concerned the questions are how often and how many bytes per message.

The time taken to deal with a single message depends on the number of bytes. And whether the process interferes with the nano’s job of keeping the drone level also depends on how often.

as quickly as possible

This is meaningless without numbers.

…R

Hello,

I came back with an update. I looked up what kind of data throughput normal receivers do and they advertise between 1 and 500kb/s

I think I want to have the same capacity.

mylast:
I came back with an update. I looked up what kind of data throughput normal receivers do and they advertise between 1 and 500kb/s

I think I want to have the same capacity.

IMHO this is no help.

YOU want to send data from an RPI to a nano and you want to send data from a nano to the RPI. YOU need to decide exactly what will be in each message that is transmitted. YOU need to decide how often each message should be transmitted.

Design must come before implementation.

What someone else does is their business.

...R

I'm a bit stuck in this matter. Could you give me a handle to understanding how I can determine the number of instructions needed for angle calculation? (i.e how much processor is needed by my IMU to read, calculate and write data to ESC's)?

At the moment I only know it is possible to do all of these and have a receiver attached.

Sorry if I am asking noob questions.

mylast:
Sorry if I am asking noob questions.

That's not a problem.

The trick with all computer problems is to break them down into small parts and tackle them piece by piece.

You said earlier "The data coming to the raspberry is in the format YAW/PITCH/ROLL/THROTTLE/RUBBLE."

Which of these items need to be passed on to the nano?
And please post an example of an actual message that the RPI will receive.

...R

Hi,

I have been thinking about the protocol today.

I want to have a simple and lightweight protocol for both writing and reading from the arduino.

I need to encode 4 channels with values ranging from 0 to 1000

For YAW/PITCH/ROLL, the default value will be 500 (for balance/no rotation)

For Throttle, the default value will be 0

Okay. Thinking about numbers, the value 1000 can be stored in 10 bits (1024)

Let's assume I want 8 channels, that results in 8 x 2^10 bits

Le'ts also assume I need this number of bites every 20ms

This will result in 50 * 8 * 2^10 bits per second, which is equivalent to 409600 bits / second or ~410kbps

I would like to send these as bites and compute the values on the drone

Example with 2 channels ROLL & THROTTLE

0b0111110100 0b0000000000

Can you suggest a more efficient protocol?

Your calculation should be
50 x 8 x 10 = 4000 bps
To clarify, 50 times per second you send 8 fields each of which consists of 10 bits.

For a baud rate of 100000 bps, this means 4% of the time is spent transferring data, leaving 96% for data gathering and balancing calculations.

Or, to put it another way, for each 20 ms cycle, 0.8 ms will be spent doing communication.

SPI, I2C and UARTs are all capable of doing what you want.

mylast:
Okay. Thinking about numbers, the value 1000 can be stored in 10 bits (1024)

Working with 10 bits rather than 16 (2 bytes) is just making extra work for yourself for (I suspect) very little benefit. And if you can persuade yourself that 8 bits (which allows for 256 variations) would be sufficient then life will be considerably easier. I can't imagine the need to vary the attitude in steps smaller than 1/256 - I doubt if you could see the difference.

I am also very sceptical about the need to update the data 50 times per second. The nano is what needs to do things quickly to maintain stability. The commands to it to change direction or attitude don't need to happen very frequently. I suspect 5 times per second would be perfectly adequate. It would be pointless telling it to change direction (or attitude) more frequently than its ability to implement the change.

...R

Thank you very much for your input. I agree with your idea.

I believe 5 times per second (updates) is very irresponsive. Have you ever played a game with 200ms? I think anything under 50ms is good.

What do you reckon, coming back to my initial question. What kind of protocol should I go for?

mylast:
I believe 5 times per second (updates) is very irresponsive. Have you ever played a game with 200ms? I think anything under 50ms is good.

Maybe I have completely misunderstood this. I thought you are trying to control a physical flying machine rather than play a game on a PC. Of course 5 per second was just a suggestion.

...R

mylast:
I believe 5 times per second (updates) is very irresponsive. Have you ever played a game with 200ms? I think anything under 50ms is good.

I fly an Arduino RC plane with a response time of ~100ms and it controls quite smooth. I use UART radios (915MHz 3DR modules) at a baud of 115200 via an automated packaging/transfer algorithm: SerialTransfer.h

Hope it helps

No, you haven't misunderstood. I was just making a comparison between the response time of a game and controlling the physical device. 200ms is unplayable.

Power_Broker:
I fly an Arduino RC plane with a response time of ~100ms and it controls quite smooth. I use UART radios (915MHz 3DR modules) at a baud of 115200 via an automated packaging/transfer algorithm: SerialTransfer.h

Hope it helps

This is very cool. This is exactly what I was looking for. I assume I should use pins 30 and 31 on Nano. I need to study how to write/read from raspberry now. Thank you so much for putting this up. It's very useful.

mylast:
200ms is unplayable.

So what if that is too slow for a game?

...R

The sense of control over the device is diminished. If you want to steer quicky or do acrobatics, it's not going to work because you will see the drone performing the action you requested 1/5 seconds later (at 200ms latency) and that is slow.