Case PoC latency

Elaut Group has been in the entertainment business since 1959. Most of the devices you find at the fairgrounds and in arcade halls were probably invented and produced by them. Elaut is therefore an innovative world player in electromechanical games. They continuously embrace new techniques to take the quality of their games to the next level.

Their innovative nature led them to Refleqt. At Elaut, they were taking plenty of first steps in their digitization story. They wanted a platform where you could live stream games and thus play arcade games from your smartphone. Read: control a grappling claw machine from your couch to win a prize.

Customer need

To make this story true, it came to light fairly quickly that video latency was a huge challenge. Latency is the time it takes data to go from point A to B and back. When you sent a command to the gripper, the first internal tests took more than five seconds to see the gripper arm move on the screen. This was far too slow for this type of game.

As a result, Elaut turned to Xplore Group. Specifically, to Refleqt, Cloudway, AppFoundry and Gluo. Their question was so complex that we had to combine the expertise of these four competence centers within our group to create a Proof-of-Concept (PoC). Before we made any statements about the feasibility of the project, we had to test it on small scale.

Proof-of-concept

The project started as a close collaboration between Refleqt and Cloudway, our partner specializing in cloud-native development. After many brainstorming sessions, we came up with a five-step plan to test latency.

From a specially developed Web application, we were able to send MQTT messages to a Raspberry Pi, a hardware component also used in controlling real-world grab machines. Instead of connecting a grip machine to the other side of the Raspberry Pi, we connected it with a screen. This screen continuously changed from red to green depending on the message we had sent via MQTT.

Finally, we filmed the screen continuously with a camera. We also sent the signal from the stream to the hardware component, which in turn sent it back to the web application. Via image recognition, we then registered here when the screen changed color.

This setup was ideal for our PoC. We registered when we sent a signal to switch the color. Via image recognition, we received a signal when the color had actually changed. By juxtaposing those two measurement moments, we were able to measure latency end-to-end.

Execution PoC

After we determined our setup, it was time to perform measurements. We performed 100,000s of measurements to determine latency. We fully automated this process. We felt it was important to be as thorough as possible, so we tested different network speeds: wifi, 3G and 4G.

Elaut is a global player, so we felt it was important to test latency on a global scale. We performed measurements in Oregon and Virginia in the U.S., in Ireland, Mumbai in India and Sydney in Australia. We had to take into account that both the Raspberry Pi and the software were operating from Belgium. This potentially meant additional delays.

Still, the results exceeded our expectations. When we sent a command from Sidney to Belgium – the furthest point – the video stream returned at an average of 600 milliseconds. This is (insanely) fast.

Because this process was so fast, we contacted AWS: our leading provider of cloud computing services. We wanted to know if our measurements were correct. To answer our question, AWS itself set up a small setup to verify this quick measurement. What turned out: our measurement result was correct.

Finally, AppFoundry also created a mobile application, which was similarly connected to a real physical gripper. With completely the same technical setup, we were able to control it via MQTT commands and had a real-time video stream available within our app. This allowed us, in addition to a technical validation, to feel for ourselves how the latency in real life scenarios.

Wim Vervust

Result

Collaboration with many different disciplines

Looking back on this PoC, the first thing that strikes us is that we could not have done this alone. We worked intensely with our partners in this story:

• Cloudway: they set up the entire cloud structure. For example, think about handling the video stream in the application.
• AppFoundry: they built the front-end of the application that lets you control the grab arm and score a plush bear.
• Gluo: they were in charge of DevOps and automating the cloud infrastructure.
• Elaut: they were responsible for setting up and configuring the cameras.

If we had not brought together these experts from different disciplines, it would have been practically impossible to set up this PoC. Or then the process would probably have had a much longer lead time. Now we set it up and executed it at a very fast pace: in just three weeks!

Latency gave green light to start the Livecadia project

So the common thread in this story was getting the latency as fast as possible. During our PoC, we encountered a lot of bottlenecks that impacted latency, including the camera itself.

If we configured the cameras to transmit maximum image quality, they had a delaying factor because it also had to transmit larger amounts of data. To eliminate this stumbling block, we played around with a number of settings, for example lowering the number of frames per second. The final result was still very clear images, without affecting performance.

It was a technical feat to realize this PoC. We are therefore very proud that we managed to do this. The PoC merely served to see if Elaut’s request was technically possible.

With this project we proved the technical feasibility of this project. Namely: to play arcade games remotely via a video stream in near real-time. The result gave us the green light to start the actual implementation of the project. Stay tuned, soon we will tell you more about the development story of Livecadia!

Curious about what performance testing services we still offer?