M01415

(1)

International Conference on Computer System 2014

161

Abstract— The real time video streaming implemented on an embedded system which has limited in hardware resource must have minimum delay time of transmission and high quality video in order to avoid a mistake on controlling a Carrier Robot from a central control. This paper presents an implementation of a real time video streaming using an open source of GStreamer tool installed on embedded system of Raspberry Pi. The video data which is transmitted to the control system of Carrier Robot has resolution of VGA 640 x 480. The average time delay of video data transmission is between 180 and 350 millisecond. The strength of signal condition is between -70 dBm up to -50 dBm at 30 frames per second.

Keywords— Carrier Robot, Embedded System, Raspberry Pi, Video Streaming, GStreamer.

I. INTRODUCTION

HE embedded real time video streaming installed on Carrier Robot helps a user to see the paths and obstacle in front of Carrier Robot and navigate Carrier Robot to reach a destination. In this paper we proposed a design of a robot vision system using real time video streaming implemented in an embedded system for remotely controlled Carrier Robot. There are many designs used to perform video streaming, such as a video streaming capture and transmission system based on Servfox [1], the design of video streaming implemented on Python [2]. Greco et all proposed a protocol for delivering a video stream in a mobile ad-hoc environment [3]. The performance comparisons of video data formats were conducted. Rao et all compare the computational speed performance of Dirac Video Codec to the computational speed performance of H – 264 / MPEG – 4 AVC [4]. Seeling et all compare the quality performance of VP8 to the quality performance of H - 264 SVC [5]. Mok, R.K.P et all measure the quality of HTTP video streaming [6]. The frequency of rebuffering affects the variations in the quality. Swaminathan et all described the live latency can be reduced using the

Kevin Ananta Kurniawan1 , is with Satya Wacana Christian University,

Jl.Diponegoro 52 – 60 Salatiga 50711, Jawa Tengah, Indonesia (e-mail: [email protected]).

Darmawan Utomo2_{, is with Satya Wacana Christian University,}

Saptadi Nugroho3 _{is with Satya Wacana Christian University,}

Hartanto Kusuma Wardana4 is with Satya Wacana Christian University,

Jl.Diponegoro 52 – 60 Salatiga 50711, Jawa Tengah, Indonesia (e-mail: <[email protected]).

chunked encoding approach [7]. The video streaming used for remotely controlled vehicle must have a minimum delay time of transmission and high quality video which is received in a central control of Carrier Robot. The user in a central control of Carrier Robot needs an accurate video streaming so the Carrier Robot can be controlled properly.

The system of remotely controlled Carrier Robot and the central control of Carrier Robot which are implemented in the labs are shown in Fig. 1. The embedded system of Raspberry Pi and camera installed in the remotely controlled control are used to perform video streaming via wireless local area network.

Fig. 1 The Carrier Robot and the central control of Carrier Robot

II.THE EMBEDDED REAL TIME VIDEO STREAMING

Fig. 2 shows the video streaming architecture. The data captured from the camera is transmitted directly to a media player installed on the client device [8, pp.140-145]. The raw video data captured from camera is processed using Motion Picture Experts Group – 4 Advanced Video Coding (MPEG – 4 AVC). The video data is compressed by reducing the unchanged data that repeat from frame to frame [8, pp. 167-168]. The video data is sent from a streaming server to a client computer which has a media player. The media player is used to receive and decompress the video streaming

Fig. 2 The Video Streaming Architecture

The Embedded Real Time Video Streaming

for Controlling Carrier Robot

Kevin Ananta Kurniawan

1

, Darmawan Utomo

2

, Saptadi Nugroho

3

and Hartanto Kusuma Wardana

4

(2)

162 The GStreamer based on Glib Object System is a framework which is used to process the audio and video data and perform video streaming, record video streaming, play and edit the audio and the video file. This framework is developed using C by the community of GNOME Project.

The GStreamer SDK version 1.0 is installed on the embedded system of Raspberry Pi to control the Carrier Robot. There are tools such as MJPG-Streamer, Netcat, VLC and Motion which can be used to perform the video streaming. Compared to the other tools, the GStreamer SDK tool has minimum delay to perform the video streaming. Fig 3 shows the Carrier Robot that was implemented.

The video streaming application using the GStreamer tool that is implemented on embedded system of Raspberry Pi can transmit the video data using H–264 format which has resolution of VGA 640 x 480. This application is run on Linux operating system. The H–264 formatted video data is transmitted from Raspberry Pi located in Carrier Robot to the computer at the central control of Carrier Robot using User Datagram Protocol (UDP).

Fig. 3 shows Carrier Robot which has implemented. This Carrier Robot consists of an embedded system which is used to perform video streaming.

Fig. 3 Carrier Robot

Fig. 4 shows the application program of video streaming. When the user presses the ‘Stream’ button the video streaming process will start.

Fig. 4 The application program of video streaming

III. EXPERIMENT AND RESULT

One empirical testing factor that need to be tested is time delay between the factual and stream as seen on the screen. Testing is done by directly comparing the captured image between digital stopwatches that instantly seen by camera and the image that displayed on the monitor. There is a factual time delay as shown in Fig. 5. Fig. 5 displays a 180 ms delay between the factual image 4:14.82 and 4:14.64 as seen on the monitor.

Fig. 5 a 180 ms delays between the factual and from the receiver on the monitor.

Twenty times experiments have been conducted in the labs to find the relation between signal strength and the time delay. The signal strength was arranged from -50 dBm, -60 dBm, -70 dBm, and -80 dBm. The relationship between signal strength and the time delay is shown in the Table 1.

TABLEI

THE EXPERIMENTAL RESULTS OF TIME-DELAY TO THE SIGNAL STRENGTH

Signal Power (dBm)

Frame per Second

(fps)

Delay (ms)

1 2 3 4 5 Avg.

-50 30 160 180 180 180 200 180

-60 30 180 220 200 190 180 194

-70 30 390 320 200 230 220 312

-80 30 6,290 8,150 10,158 200 200 4,999

From the experiments, the good results are obtained at the average time delay between 180-350 ms and signal strength between -70dBm up to -50dBm at 30 fps. The good results are defined as the ongoing stream video shows video that looks similar to the factual. At the testing number-4 the time delay was 5 seconds in average. This result is not relevant if implemented in the real time robotics. Besides the delay, the quality of the image is degraded sharply.

(3)

163 location of power strength are shown in the Fig. 6. The driver need to be careful when through an area with a signal strength less than -70 dBm since the noise is very annoying the streaming video.

Fig. 6The signal strength at some points in the C Builing.

From the measurement results, points that in the position line of sight with the antenna have a relative better signal strength (-70 dBm up to -50 dBm) than points that hindered by fence or wall ( < -70 dBm). In this experiment, the better signal will be rewarded with less delay (< 350 ms). On the other hand, when the signal strength below than -80 dBm, controlling robot wirelessly got so much noise thus some commands may be missed, increasing the delay, and broken the running images. Fig. 6 shows a capture image from video streaming that was obtained when the robot out of line of sight. The image was fall apart because not all data packets arrive at the receiver (UDP stream) at a period of time. When the less data constructed again by the decoder, decoder will yield a fractured images.

Fig. 6The weak signal strength produces the fracture video.

IV. CONCLUSION

In this paper, the embedded real time video streaming for controlling Carrier Robot has been implemented and tested to the time delay and the signal strength. The video streaming is used to be a feedback in the control system for Carrier Robot. The real time video is implemented using open source software GStreamer as a module in the Embedded Raspberry Pi.

Two results have been obtained from the experiments. First of all, the streaming video needs signal strength between -70 dBm up to -50 dBm to get a good quality of video at 30 fps and delay time below than 350 ms. Secondly, the signal strength less than -70 dBm would significantly reduce the quality of the video and hardship in controlling the Carrier Robot.

ACKNOWLEDGMENT

The reported work was funded with support from Satya Wacana Christian University, Salatiga, Indonesia.

REFERENCES

[1] Geng, Xingyu, et al. "A New Design of Video Streaming Capture and Transmission System." Journal of Multimedia 9.10 (2014): 1160-1165. [2] Zhang, Hai Feng, and Xu Chang Fang. "Design of Embedded Streaming

Media Server Based on Python." Applied Mechanics and Materials 418 (2013): 261-264.

[3] Greco, Claudio, Marco Cagnazzo, and Béatrice Pesquet-Popescu. "Low-latency video streaming with congestion control in mobile ad-hoc networks." Multimedia, IEEE Transactions on 14.4 (2012): 1337-1350. [4] Rao, K. R., Do Nyeon Kim, and Jae Jeong Hwang. "Performance

Analysis and Comparison of the Dirac Video Codec with H. 264/MPEG-4, Part 10." Video coding standards. Springer Netherlands, 2014. 199-219.

[5] Seeling, Patrick, et al. "Video network traffic and quality comparison of vp8 and h. 264 svc." Proceedings of the 3rd workshop on Mobile video delivery. ACM, 2010.

[6] Mok, Ricky KP, Edmond WW Chan, and Rocky KC Chang. "Measuring the quality of experience of HTTP video streaming." Integrated Network Management (IM), 2011 IFIP/IEEE International Symposium on. IEEE, 2011.

[7] Swaminathan, Viswanathan, and Sheng Wei. "Low latency live video streaming using HTTP chunked encoding." Multimedia Signal Processing (MMSP), 2011 IEEE 13th International Workshop on. IEEE, 2011.