Reducing Latency in UDP Communications

I am working on a project where we are flying a quadcopter with an onboard Raspberry Pi which communicates with a host PC. I am currently developing the communications between the two systems using UDP protocols. I am using two Simulink models, one on the PC and one built onto the Pi, that both use the Raspberry Pi UDP Send and Receive blocks. There is very little else in the models - just a clock to generate a signal to send back and forth, and byte pack and unpack blocks. While I have been able to successfully send information back and forth, the latency has been extremely high, ranging anywhere from 2-7 seconds. Obviously, this is not practical for real-time applications. This latency is approximately the same, independent of whether both computers are communicating over WiFi or connected to a router via Ethernet. In addition, ping times between the two systems are low (<5 ms), so I don't believe the hardware configuration to be a problem.

Would anyone be able to provide a few tips or pointers towards helping to reduce the messaging latency?

Thanks.

[Walter Roberson]

Is the packet size variable? Did you specify the exact number of values expected for the packet?

If you were using the MATLAB routines directly I would have you check your DatagramTerminateMode

Unfortunately I am having difficulty finding specific documentation on the Raspberry Pi UDP Receive block; I see it exists but the documentation basically says "Open the library and take a look"

[Michael]

The package size is fixed. As of right now, I am just sending one double value back and forth. Both receive blocks are expecting a packet of that size, and receive it correctly, just with high latency.

Answer 1

[Uladzimir]

Dear Michael, You should run your models in external mode. According to mathworks manual for real-time windows target, it provides efficiency up to 20 kHz. For this you need to set discrete fixed step solver, set up rtwin.tlc file in code generation options, then build model and run it in external mode. You could use Packet Input and Packet Output blocks, tuned as standard udp device. Our model worked with 1..3 ms delay.

[Michael]

Unfortunately, we cannot use External Mode as we are using some functions for Third Party hardware support that does not support code generation.

[Uladzimir]

Actually, that's strange, because I used normal mode too with UDP Send and UDP Receive blocks and it worked, maybe just a little bit more time variable than in external. 2-7 secs is too many. I can recommend you to do a such test: switch off all the control and signal processing features both on the embedded side and in simulink, then use fixed-step ramp block as signal source, embedded system gets and instantly sends the value back. By comparison the sent and got value you could see the latency. And find out, the problem is in the too heavy algo or in the connection. Good Luck!

[Michael]

My models were fairly simple to begin with, but I went ahead and simplified them down to just the UDP Send and Receive blocks, a ramp source, and a scope to see the results. I am still observing this absurdly large delay.

[Uladzimir]

I got your point. There is a lot to think about. What solver do you use? I used discrete, fixed-step. Also, you could try real-tyme sync block, it shows amount of missed ticks.

[Uladzimir]

P.S. I've just looked through my normal-mode model and noticed that here UDP SEND Binary and Receive Binary blocks were used. It have a size of the packet option. Also I remember, that there were troubles with byte alignment on the embedded side.