# A Telepresence Wheelchair with 360-Degree Vision Using WebRTC
## 3 Results
### Experiment 1: To evaluate Real-Time Response of Telepresence Wheelchair System  
The main aim of this experiment was to analyze the performance of WebRTC in various network conditions. In this experiment, we conducted the experiments consisting of ten trials. We evaluated the performance of the proposed method by implementing WebRTC to stream videos from the wheelchair to a remote location over the Internet. For each trial, the data transmission was observed during a period from 0 to 500 seconds. The remote user and wheelchair computer were configured with the Intel Core i7 CPU and 8 GB RAM to have sufficient computing power. Window operation system 7 (64 bit), Internet browser (Firefox) was installed. The bandwidth management was taken into account to ensure the consistency of the system performance. To examine the WebRTC performance, we evaluated the objective quality measures. We collected data from the peer connections between the sender and receiver for the cases when both the uplink and downlink bandwidths are unlimited and limited to 1500, 750, 250 kbps. The measurement data were recorded and collected carefully. A diagnostic packet and event recording related to the bandwidth estimation, packets sent, round-trip time and frame rates were measured and logged for analysis and evaluation. **Results:** Figure 6 shows the distributions of average bit rates for the test cases with different bandwidths. The results show that when the bandwidth is limited, the bit rates are slightly lower than the controlled bandwidth for each video stream. As can be seen, it can reach the available bandwidth and maintain a constant bit rate. As expected, the system is designed to be able to use all the available bandwidth of Internet connections for video streaming and sending control signals. It seems that the remaining bandwidth, where test has a lower throughput, might be caused by application performance, for example, the web browser might be too busy to handle data transmission over data channel, other activities of the performance of the computer or the network condition has changed during the connection established between the sender and receiver. In contrast, it is observed that the highest bit rate is 2500 kbps for the case of unlimited bandwidth. This is either limited by bandwidth estimation of the congestion control, or that the session does not need to send at a higher bit rate. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**MOS** & **PSNR** & **SSIM** & **Quality** \\ \hline
5 & \(\geq\)37 & \(\geq\)0.99 & Excellent \\
4 & 32–37 & 0.95–0.99 & Good \\
3 & 25–32 & 0.88–0.95 & Fair \\
2 & 20–25 & 0.55–0.88 & Poor \\
1 & \(<\)20 & \(<\)0.55 & Bad \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Mapping the peak signal to noise ratio (PSNR), structural similarity index (SSIM) to the MOS. In addition to measuring the bit rate, we also observed connections where the signal loss was significant. By continuously lowering the available bandwidth in additional experiments, we observed that a minimum of 250 kbps is necessary to establish video calls between participants. However, at least 250 kbps of available bandwidth is necessary to obtain a somewhat acceptable frame rate at the lowest possible video resolution (\(320\times 240\) pixels). It takes a longer time to reach the maximum streaming rate, especially when the available speed is at the 250 kbps. Apart from being limited by a constant bandwidth, a more common scenario for real-time video streaming applications over wireless networks is that the network speed varies during the connection due to the nature of the fluctuation of the wireless signals and wireless channel conditions. In this experiment, we monitored the performance of how fast WebRTC adapts to new conditions in the real-world network condition. We observed this behavior by setting the maximum network available bandwidth up to 1 Mbps. It is notable that WebRTC's congestion algorithm does not respond directly to different latencies but changes its data rate based on latency variation.