วีดีโอ

Hello, yes indeed delays are always an issue with any real robotics system. One Idea (more popular with a control community approach) would be to include the delay as you have mentioned in the transfer function x_(i+1)(s)/x_i(s) and ensure that string stability holds . The entity of this delay would need to be measured in the field. In practice delays are never constant and usually not even gaussianly distributed since they may build up when the communication network is more heavily used or some other event-based circumstance. So the idea is to ensure string stability assuming for a "worst case" fixed delay. Another strategy (coming from a robotics perspective) is to include some delay compensation feature, such as reconstructing the actual vehicle state, like the position, based on forward propagating the received state accounting for the communication delay. Something like real_position_now = position_communicated + Velocity*time_delay. Here the time delay could be actually measured in real time by comparing the time stamps of the various messages.