I'm currently working building and implementing robot control system using cellular system(4G or 5G).I am thinking of using RTOS in order to reduce processing time in server.
The server receive request from the robot and response to it. Through the experiments, I found the following.
- end-to-end delay: 30~50ms(edge)/70~90ms(cloud)
- Processing time: 10~15ms
- data flow:
robot -----> base station -----> edge server
<----- <-----
or
robot -----> base station -----> cloud server
<----- <----
- experimental setup
- CPU Intel Core i9
- OS linux vanilla kernel
Now, I am thinking of installing preempt-rt kernel on cloud/edge servers.
Are the end-to-end delay and the processing time reduced more than 10ms by installing RTOS on the servers?
An RTOS is not about "reducing processing time", it is supports fast and deterministic response to events. That is, response to real-world external events can be effected with well defined minimum and maximum response times. I say "supports" because there are plenty of way the unwary can mess up the scheduling and IPC and make a system behave poorly in this respect.
Reducing processing time is rather a matter of processing speed and processing load. i.e. how fast your processor is and what you are asking it to process. To that extent, selection of efficient algorithms and data structures and compiler optimisation are more effective approaches that using an RTOS.
Ok, now it is not clear to me where you are proposing to use the RTOS. On the Robot or on the server? If on the server, to get deterministic real-time response end-to-end, the communication channel also has to be real-time capable - i.e. guarantee maximum response time. Can it do that?
preempt-rt does not truly make Linux and RTOS, though it may be adequate and appropriate in this application. It has the benefit of providing all the hardware, I/O and networking support for a COTS PC architecture board which most (but by no means all) true RTOS lack, and which you might have to provide by third-party components - that's a big ask of something as complex and PC.
If it works with plain Linux and you need to guarantee specific response times, then it is appropriate. You you are just trying to make the code run faster, this is not the way. A priority based pre-emptive scheduler allows you to ensure specific code runs when it demands it rather then when the kernel gets around to scheduling it. It prevents delay in processing rather then speeds processing.
The software running on the server cannot change the latency of the communication network. As noted above what you achieve is minimum delay in processing, not faster processing. In this case minimising that delay offers little advantage without latency guarantees in the communication which you are unlikely to get - measuring "typical" response times is no guarantee.
Unless every component - robot, communications link, base-station and server - are real-time capable, then system as a whole will not be real-time capable.