I am just wondering if the speed of data going through a LAN socket should be relatively instantaneous or is there still a delay even though it is a local network.
From what I have been taught, The speed of the data is based more on your hardware than your software. Depending on if you use ethernet cables (faster) or WiFi waves (slower), the speed will vary. However, despite this, you should still expect nearly instantaneous speeds.
Related
I'm researching and trying to building a RC car that can be controlled by the internet. I've started looking into how communication over the web works, but I seem to be going nowhere. My goal for the project is straight forward:
The RC car has an on-board camera and 4g wifi router that enables communication (driving commands, video streaming) over the internet. A Raspberry Pi will serve as the on-board computer.
I will be able to control the car with my PC even across the globe, as long as I'm connected.
I want to preferably do as much by myself as possible without relying too much on other people's code.
So here are my questions:
How does an application communicate over the internet? What is the interface between the application's logic (e.g pressing "w" to go forward), and transmitting/receiving that command over the internet?
How is video data stream handled?
I've looked into WebRTC and WebSockets for communication, but they are aimed at providing real time communication to web browsers and mobile, not something like a raspberry pi, and I'm still in the blind as for exactly what technology should I use, and in general the overview and architecture of real time communication.
All I've achieved so far was an app that sends text messages between devices through a server on my network, with very primitive reading/writing using java Socket.
In short, what does messenger/skype/zoom do in the background when you send a message or video call?
Any guidance would be greatly appreciated.
First things first. You cannot do real-time control over Internet, period. There is absolutely no way to guarantee the delivery latency. Your control commands can arrive with a delay from milliseconds to seconds, or never. No way around it.
Now, you can still do a number of reasonable steps to absorb that unpredictable latency as much as possible and safe-guard your remote robot from the consequences of the unreliable communication.
For example, instead of sending the drive commands directly - as in, acceleration, deceleration, turn angle, etc., you can send a projected trajectory that is calculated from your drive commands locally on a model. Your RC car must be sufficiently smart to do some form of localisation - at the very least, wheel odometry, and with a good enough time sync between the sender and the RC car you'll be able to control the behaviour remotely without nasty consequences of drive commands executed at an unpredictable delay.
You can add a heart-beat to your protocol, to monitor the quality of the communication line, and if hear-beat is delayed or missing, initiate emergency stop.
Also, don't bother with TCP, use UDP only and maintain your own sequence counter to monitor missing packets. Same applies to the telemetry stream, not just command channel.
What protocol shall i suse for best realtime communication from Raspberry pi to ESP32.
I'm doing some computation on R pi (FFT on signals) and the result shall be sent every 10ms to ESP32.
Esp32 puts the result to LED display and stepper motor.
Raspberry pi is on ethernet and ESP32 on wifi (LAN, home network)
I need to transfer 10 bytes of data every 10ms, but the time delay and frequency response shall be very small. What protocol shall i use? I think MQTT is to slow? Any other idea ?
Anything involves a wireless communication can't be trusted in terms of consistent package delivery with low latency. I don't think you can achieve your 10ms goal for every package with WiFi. There's too many external factors.
Having said that, from your question, I understand you make a measurement/calculation on ESP32 and want to use it somewhere else with low latency. Since an outdated measurement/calculation is redundant, you need to implement a datagram. If your problem definition is suitable to skip a package every now and then, I would use UDP packets. If it arrives in 10ms with no complication, there's no problem with both UDP or TCP. But when it doesn't, UDP will just ignore the fault and send the next data package while TCP will try to deliver it even after 10ms.
Also please be aware that even in TCP, you can have some amount of undelivered packages. (packet loss)
You're pushing the limits of what a WiFi connection can do. Low latency, low jitter data transfers are certainly not guaranteed. If the WiFi channel is even mildly utilized, collisions will introduce delays of several tens or hundreds of milliseconds. The frequency of those delays depends directly on channel utilization. As Bora said, raw UDP datagrams are your best bet. You have to build into the protocol a mechanism to recover from samples which are lost or arrive to late to be useful. All in all, this is not a trivial task, so good luck :)
First and foremost I aware of a "similar" question/answer here: USB: low latency (< 1ms) with interrupt transfer and raw HID
In my case I'm at the start of my project and currently choosing the "right hardware" for the job. I want to transfer raw sensor data from an IMU to a host PC in roughly <1ms. So my Idea was to use a Teensy or Arduino uC to handle the interface between IMU and PC. The current priority is driving the input latency down as best as possible using (ideally) the USB protocol. I'm well aware that once on the PC I have to deal with a non real-time system.
Is there anything "hardware-wise" that I have to pay attention when choosing my Microcontroller?
I need to check whether or not a device can support voip calls at a certain level of quality. My approach (of which I accept there may be a better one) is to conduct an Internet connection speed test on a user's iOS device immediately before the call is placed. The speed test should, as accurately as possible, determine whether the impending voip call will be of good or poor quality.
The voip call includes live video (similar to Skype).
I'm aware of the following techniques to measure connection speed:
Download or upload a file and measure how long it takes.
as outlined here. Will measuring download or upload speed give an accurate picture of what voip call quality will be like for the immediate call? Also, files may be cached or speeds may even be throttled by the ISP.
Use ICMP packets (ie. ping) a reliable server (eg. google.com).
One potential problem with this approach is that (I've heard that) some routers are configured to give ICMP packets a lower priority than others. Therefore they cannot be used as an accurate measure of bandwidth/speed/reachability etc. Is this so?
Is measuring network connection speed an effective way to predict voip call quality? If so, what is an effective and quick (ie. less than 3 seconds) way to measure Internet connection speed for this purpose?
The actual data of a VoIP call is carried over RTP, which really only takes 24-64Kbps (depending upon codec) and requires UDP addresses going each way. Occasional RTCP packets are sent to report status, metrics, etc, but are not really needed.
SIP is used for call setup and teardown.
The RTCP packets carry (minimal) call quality metrics.
Several parameters influence call quality, including choice of codec, available bandwidth, network latency, packet loss (RTP is over UDP so no retransmission), and jitter (inter-packet arrival delay, out of order delivery).
(Cicso) Switches implement RED, a technique to reduce queue depth by randomly discarding network packets. For TCP network connections, that is acceptable, because TCP has retransmission through a sliding window protocol. And many UDP based protocols implement application retransmission. But RTP does not afford that luxury. So random discard of voice packets impairs the connection quality. One solution to RED would be to tunnel VoIP over a TCP connection, but that wasn't the choice made.
Congested networks are a huge source of VoIP call quality problems, and that can be measured during the initial few seconds of a call. Dropped packets due to jitter and delayed packets (high network latency) are two main causes of call quality degredation. I worked on a VoIP quality of service monitor system, and we observed the worst calls had high jitter and high latency (above ~70ms is bad). Avoid high latency, congested networks. Choice of coded can have a huge impact on quality. Higher compression codecs lose more to packet loss than less 'efficient' codecs, so pick a codec that uses higher bandwidth (good luck).
IP networks need QoS guarantees to provide best VoIP quality. And until TCPIP is redefined to include QoS, VoIP will have (potential) problems.
Your approach is close. But you want to measure:
UDP
Packet loss
Congestion
Latency
Packet jitter
You need to timestamp and number your packets, and detect high latency, interarrival jitter, avoid measuring over TCP (packet retransmission will skew your quality numbers, and TCP reorders packets, even though it introduces delay). You also want to know the quality on both. You might find that codec selection would be a huge factor in improving the calls.
The company I worked for building the monitor (Telchemy) licensed their VQMon software as a product to measure quality, so the tool you want already exists.
We are doing research into running a server on a Pi, and communicating with it via a webapp (over a local network) to control 2-3 servos. It appears that the Rpi has only one hardware configured PWM pin, but this can be worked around via servoblaster. However, since Servoblaster utilizes the Rpi's DMA, will it interfere with the Pi's ability to operate a web server? I apologize if this question is unclear i am somewhat unfamiliar with the software/network concepts involved. Additionally, is there a good resource for understanding the DMA function further?
Thanks in advance for any help.
You can control Servos using Software PWM, which will not require any further hardware or using DMA
If you care about performance and want more powerful hardware consider ODROID-X, it has 1.4GHz processor and 1GB RAM and cost $130, it is the best value for the price.
For other alternatives check Small low cost linux pc's