How we launched robots in small Chernobyl

The birth of the concept of Remote Reality

The story of our “crazy” project began three years ago, when reflecting on the future prospects of the gaming industry, my friend Alex said: “Imagine a future in which people, in the form of entertainment, from any part of the world manage real robots on the playing ground like“ avatars »».

The idea initially seemed to us quite interesting and not difficult to implement. We immediately "sat down" for the search for similar projects and were surprised to find that no one did anything like that. It seemed strange, because the idea was literally "on the surface." We found many traces of amateur prototyping projects in the form of an Arduino-based chassis with a camera, but no one brought any project to its logical conclusion. Later, overcoming seemingly endless difficulties and problems, we understood the reason for the lack of analogs, but initially the idea seemed to us extremely simple and quickly realized.

Next week we devoted a concept study. We imagined dozens of varieties of robots with different capabilities and hundreds of game grounds between which players can instantly move through the "teleport". Anyone, on the basis of our "solution", had the opportunity to build their own playing ground of various scales.

We immediately decided that these thoughts fit more into the concept of an entertainment attraction, rather than a computer game. People love entertainment and want something new, and we knew what to offer them. As in any business, the question of payback immediately surfaced, because at first glance it seems that our physical model is limited by the number of robots. But having multiplied robots by 24 hours and by the price of an hour of 5-10 dollars, doubts disappeared. The financial model was not a Klondike, but it paid off even at 10% load.

Very quickly, we had a new concept in our head: Remote Reality, similar to Virtual Reality and Augmented Reality.

Like the rest of the "experimenters", first of all, we took the machine on the radio control, put the Chinese Wi-Fi camera on it, installed the Arduino board and our robot "went." We asked our friend from the United States to connect to the machine via the Internet. He was able to drive around our office and we were delighted. The control and video delays in a few seconds did not seem to be a problem.

From now on, we have divided our work in two directions:

• modeling and construction of the playing ground
• development and creation of robots and control systems

Gullivers in the city of Pripyat

I'll start my story from the landfill. We understood that people had to play somewhere. The place should be known all over the world, “mysterious” and simple in technical implementation. Turning over many options, we suddenly had the idea of ​​Chernobyl. The Chernobyl zone met all our requirements, and most importantly, all possible future damage and damage to the playing ground could be attributed to the post apocalypse.

Having found a room of 200 square meters, we set to work, which in the end lasted two years. We painted the streets and textures of houses, created three-dimensional models of buildings, including interior floors. Then they cut out all of the chipboard plates and plywood, collected buildings from hundreds of different parts.

We tried to recreate, as accurately as possible, all the textures of Pripyat, "peeping" at Google maps. Of course, the size of the room did not allow us to create everything exactly, and we didn’t want to miss the details, so, for example, we had to move the Chernobyl NPP closer to Pripyat.

It is difficult to calculate how many hundreds of boards, dozens of sheets of plywood, fiberboard and other "consumables" we spent. For the last three months, we literally crawled on all fours with brushes and paints, decorating houses and floors. We wanted to have maximum detail. The scale of the city turned out to be 1:16 and the houses with a height of 9 floors were approximately at the chest level of an adult. Being in this city, we felt like real giants.

A little about us

Then probably it’s time to talk about our team. Initially, there were only two engineering friends. Thinking over the project, we understood that it would be difficult to find an investor for such an “adventurous” idea and we made the decision to do everything for our money. Many people helped us during the work. Someone for free, we hired someone for help.

A good example of teamwork was the story of 3D printing. We collected our printer and printed the first parts on our own until we came to the conclusion that you cannot be an expert in everything. Printing took us a lot of time, parts of parts were large and an unexpected marriage at the end of printing details spoiled all our plans. As a result, we found a “narrow” specialist in 3D printing, who later became part of our team. Dividing our dreams, he helped us to make the body of robots just at the cost of plastic.

Collecting robots, we could not do without the help of a turner. This was helped by one of our friends. Construction work at the landfill required often non-standard and complex solutions, we were very lucky to meet the guys who also actively helped us in these matters.

The project was very lucky with the artist designer, his talent was invaluable.

To save as much as possible on the construction of the gaming arena, we had to do almost everything ourselves. But besides a large polygon there was also a technical part ...

The victory over the delayed video signal

Certainly the issues of engineering project implementation will be more interesting to you than the description of our “urban planning”.

Let's return to the moment when, as you remember, we put the camera on the “cart” and managed to control it. Following this, it is time to choose the iron and technology to create our robots. The first surprise was waiting for us here: sorting through a dozen cameras, we could not achieve a signal delay at which controlling the robot via the Internet would be comfortable. Everything was complicated by the time it took to order samples of cameras in China and test them.

We wanted to make the robot management system completely in the browser without any “download our wonderful client” and outdated Flash players. This greatly narrowed the list of technologies and cameras that support them. We have been experimenting for a long time with the transfer of the video stream in the MJPEG format, but in the end we abandoned this idea. These experiments cost us half a year to waste. We even fully assembled the first five robots and launched open testing for everyone, but ...

Live tests showed the inability of the router to process a huge video stream over the air from several robots in the MJPEG format, as soon as we tried to optimize the image resolution. The video stream from one robot failed to make less than 20-30 Mbit, which made it impossible for stable simultaneous operation of the 20 robots we planned. We also could not find a ready-made sound transmission solution without delay. This led to the fact that we had to look again for the appropriate technology for our tasks.

As a result, our choice stopped at WebRTC. This provided us with the transfer of video image and sound with a delay of only 0.2 seconds.

Then it was time to model and assemble robots. To be less dependent on external suppliers, we printed all the details of our bots on a 3D printer. This allowed us to create the most compact model of the robot, and optimally put inside all the electronics and powerful batteries.

Power supply system

The next question was related to power supply, because we really wanted to change batteries, as rarely as possible. After going through a lot of ready-made options, we stopped on our own battery, assembled from the elements of Panasonic 18650B. A battery with a voltage of 17 volts and a capacity of 6800 mAh made it possible for our robots to actually drive 10-12 hours on a single charge.

In the process of experiments, we successfully “ditched” hundreds of elements, because we wanted to use the capacity of the elements as much as possible, and the voltage at the end of the discharge fell very quickly and our simple voltage indicator assembled on the divider did not always give accurate readings. But in the end, we raised the threshold of the minimum allowable voltage from 2.5 volts to 3.2, plus put a chip for precise voltage control and cases of “death” of Panasonic stopped.

We chose iMax B6 devices that are popular among modellers as a charger with the option of charging in the element balancing mode. We “ruined” some of the batteries because of the incorrect calibration of Chinese copies of iMax B6. We connected five cans and charged them in balancing mode. At the end of the charge, the total battery voltage was tested without a breakdown into cells, and in fact one bank was not fully charged and "died" first.

Engines for robots

Surely many of you have asked yourself the question: why 17 volts? The answer is hiding in the engines. Motors are the second part of our “Chinese torment” after selecting cameras. We went over a lot of different engines. To our horror, almost all of them had a small resource and quickly failed. After 3-4 months, during the experiments, we managed to find the manufacturer of “normal” motors in terms of reliability, but there was still no final solution.

In a conventional car, the transmission of power plays a key role in the transmission of power from the engine to the wheels. We did not have it. By reducing the voltage on the motors, we successfully reduced the speed of the robot, but at the same time its power was lost and our “tanchiki” could not slowly turn around on the spot. Soon we solved this problem.

Oh, I said that word is tanchiki.

Why "tanchiki"?

Why precisely “tanchiki”? The answer is simple. If we add an unknown Internet channel delay to the camera delay, then some Australian resident can comfortably control only something relatively slow. This was the first argument in favor of the choice of tanks, and the second argument, which finally convinced us, was the comfortable control of the robot. The man used to click on the “arrow” to the right to expect the robot to turn to the right, and without the tracks it was impossible to do, because only the tanks are turning “on the spot”. We were also happy about the expected “super cross-country ability”. Having ordered in China a box of rubber tracks, we began to print "wheel-rollers" under the tracks.

The very first tests broke our dreams into “fluff and dust”, the caterpillars often flew off the tank when driving into low obstacles. Having studied the basics of tank mechanics and tried various tensioners and auxiliary wheels, we still did not solve this problem. We had to part with the tracks. So, as the robots were already printed and assembled, we had to look for some quick and simple solution, but it was one thing - good wheels with a rubber tread. And how do you turn on the spot you ask? We "got out", tying the two axes together with a thin strap from a 3D printer. In general, it turned out wheeled robot with all-wheel drive and turning in place.

Heart of the robot

We have already told about most of the elements of our robot and did not say anything about the most important component.

Our bot is based on the Raspberry Pi mini computer on Linux and specially developed software that allows the robot to communicate with the server. Raspberry Pi works in conjunction with our control and management board. The board includes a microcontroller, a driver for motors, chips for processing signals from various sensors, and an accurate battery voltage control module. For ease of assembly, we implemented absolutely all peripheral connections on separate connectors.

As I mentioned earlier, we often had to change components when we encountered unforeseen problems. It happened this time. Initially, we collected the first robots on the Orange Pi, to save. Later we had to replace them with the Raspberry Pi 2 B. But this was not the end either. We soon again had to replace this mini computer with the version of Raspberry Pi 3 B + that had a 5 GHz module onboard the WiFi. But more on that later.

Wi-Fi setup

The next problem that awaited us was the Wi-Fi radio channel. We learned about it only by starting tests at once 10 robots in motion. Our landfill was located in a closed basement and the “overlap” from the reinforced concrete walls was simply terrible. The control teams passed normally, but the video stream “wildly slowed down” when one of the robots left for a far corner of the room.

The transition from 2.4 GHz to 5 GHz helped us cope with the channel loading. But the difficulties did not end there. If the robot drove around the corner, the signal fell below -80 dBm and the brakes started. Finally, we solved the problem by installing a sector antenna with remote reception and raising the transmitter power to half a watt. Of course, the router had to be “picked up” from the segment of business solutions with a powerful processor.

It is worth mentioning that we tried for a long time instead of increasing the power to adjust the seamless roaming mode based on the Ubiquity solution, but alas, the Wi-Fi module we needed “refused” to support it, but the iPhone worked perfectly, moving between several access points.

Having collected a dozen of robots and running the control and management server, in November 2018 we entered Kickstarter with the Isotopium Chernobyl project. We had no idea that tens of thousands of people would soon try our game.

About what was waiting for us further and why we almost closed the project, read our next article (soon): The world's first online game with RC models controlled via the Internet