Security robot: requirements for our MSS

Table of contents:

So, let’s get down to the story of how we started to make our security robot and what we have come to at the moment. Our team is working on an IoT platform, and the security robot has become one of its own smart device projects. This post will tell you how the existing mobile security systems (MSS) were researched and what requirements were eventually set for the Proof of concept prototype.

Mobile security systems: everything is just beginning

We do not undertake to give exact forecasts, but it is pretty evident that the guards’ time is running out. Sooner or later, most organizations will give up unnecessary employees, entrusting the routine to robots. Protecting buildings and territories is an actual routine. And robots will cope with it better. For example, they do not distract by watching football at night. And the costs for them are much less than for the guards’ salaries.

Meanwhile, in the market of mobile security systems, everything is just beginning. When we conducted the research, there were not so many ready-made solutions. So far, they offer routine video surveillance and alarm systems. This is the last century.

A few examples of when security robots are used helped to formulate a minimal list of what we want to achieve in the end to be no worse:

• autonomous patrolling of the territory by a robot, moreover, based on artificial intelligence;
• remote control of the robot – like a car in childhood, only from a smartphone;
• automatic sending of the robot to the base station for charging – like a vacuum cleaner that a cat took from us;
• video surveillance functionality (can’t do without it);
• person recognition and face detection;
• the ability to install a laser radar and other sensors, up to fire safety control;
• automatic sending of notifications if the robot does not like something and found suspicious;
• group interaction of several robots.

We will implement most of this functionality later. In the meantime, after the stage of theoretical research, we faced the first practical task. We are talking about developing the Proof of concept prototype. Let us explain for those new to the topic – this is the first stage of any new device development, often assembled from improvised means. The main thing is to confirm that the device can function in the desired way and that the task is practically solvable by the chosen methods.

Two challenges for the Proof of concept prototype

During the PoC phase, we needed to make sure of two main things:

• that we will be able to design the platform for remote control of the robot and fit it into the framework of our IoT platform;
• that we can find a solution that will ensure the minimum delay in the transmission of the video signal.

Why is the second nuance important? We will not receive video from static cameras, and the robot does not move randomly or along a pre-arranged route. Yes, we plan to teach him to move autonomously using AI. But the idea is to be able to navigate the robot through space remotely, with the mobile app and in-built camera, even being on the other side of the planet. If the signal delay is too long, it will at least be annoying.

We struggled with the video a lot. Non-obvious problems arose in this part, which we will discuss in detail in the future.

But the key for this stage was ensuring compatibility with our platform. We needed the robot to become another IoT device for 2Smart Cloud without special crutches on the platform side. And to do this, we need to create a compatible firmware for controlling the mechanical parts of the robot. And in the future – to support the functionality that we want to implement.

We started looking for existing solutions that can be quickly adapted to our needs and test the concept of a security robot. As a result, we realized that there is nothing better than children’s kits for robotics!

We ordered the Lego Mindstorm constructor to assemble the Proof of concept prototype on its basis. What came of it – read in the following posts!