RU2751143C1 - Method for automation of sensor calibration of strapdown inertial system of unmanned aerial vehicle - Google Patents

Abstract

FIELD: regulating.SUBSTANCE: invention relates to methods for automatic calibration of strapdown inertial systems (SINS) including acceleration sensors (accelerometers) and angular rate sensors (ARS) in form of gyroscopes. The substance of the invention consists in the fact that interaction of the SINS sensors and the calibration table with the service applications located on workstations is executed by the RS-232/RS-485 protocol; in the web controller, based on the data received from the SINS sensors and stored in the database, the calibration matrices of accelerometers and gyroscopes, as well as the matrices of temperature compensation polynomials, are calculated, the calculated matrices are recorded in the database and the SINS calculator. To provide secure remote access to information resources in a secure segment of the local network, an enhanced authentication technology based on a cryptographic token generated by the web controller is used. To provide a possibility of adapting the method to an expanded number of simultaneously calibrated apparatuses (SINS), WebSockets messages are broadcast; message brokers generated by a WebSockets broadcast support module are used therefor.EFFECT: increased productivity of the procedure of calibration of SINS sensors due to ensured automation thereof and the expanded number of simultaneously calibrated apparatuses (SINS); increased protection against unauthorised access to the information resources in the secure segment of the local network between the web controller and the service applications due to the applied enhanced authentication technology.2 cl, 15 dwg

Description

Technology area

The present invention relates to methods for calibrating inertial sensors and to inertial measuring devices. In particular, the invention relates to methods for automatic calibration of strapdown inertial navigation systems (SINS), which include accelerometers and gyroscopes.

State of the art

The accuracy of the SINS used in robotic unmanned aerial vehicles (UAVs) depends on the accuracy characteristics and the quality of the calibration of its sensors: accelerometers and gyroscopes. This is due to the fact that in small-sized UAVs, sensors are used based on the technology of microelectromechanical systems (MEMS), the disadvantage of which is the presence of systematic and random errors. To eliminate this drawback, the sensors are calibrated, the purpose of which is to determine their systematic errors, which are then taken into account in the algorithms of the SINS on-board computer.

Calibration is performed on special tilt-rotary (calibration) stands, which are oriented relative to the horizon and meridian planes, rotate and rotate at constant angles. In this case, the orientation of the stand, the measurement of the angular velocities of rotation and the angles of orientation of the SINS are carried out with high accuracy. The measured systematic errors of the sensors, called calibration coefficients, after the end of the calibration are written into the SINS on-board computer to compensate for the systematic errors.

Significant disadvantages of the known methods of calibration of SINS sensors are low manufacturability, high labor intensity and duration of the calibration procedure. This can introduce human error during the calibration process.

As a result of the analysis of the prior art, it was found that there is an inventive (non-obvious) problem, which consists in developing a method for automating the calibration of SINS RBVA sensors. This method, due to the automation of the calibration procedure, will significantly increase its productivity, as well as eliminate systematic errors caused by the human factor.

Characteristics of analogs of the technical solution

A known method of calibrating the angular velocity sensors of the strapdown inertial measuring module (BIIM) [see. description of the invention to the patent of the Russian Federation No. 2447404 C2 from 16.06.2010, IPC G01C 21/00, publ. 10.04.2012, bul. No. 10]. The method consists in the fact that the reference value of the angular velocity vector during the rotation of the IRM around an approximately horizontal axis is determined according to the readings of the linear acceleration sensors (DLU), the identification of mathematical models of the angular velocity sensors (ADS) is carried out, while the zero signals of the ADS are determined, the matrix describing the scale coefficients, cross-links, orientation of the sensitivity axes of the ADS in the BIIM, a matrix describing the effect of linear acceleration on the readings of the ADS, and then take into account the identified coefficients in the algorithms for the operation of the BIIM, and do not impose restrictions on the number and location of the ADS to be calibrated as part of the BIIM.

Also known is a method and device for calibrating inertial measuring modules (IMM) [see. description of the invention to the patent of the Russian Federation No. 2602736 C1 from 03.08.2015, IPC G01P 21/00, publ. 20.11.2016, bul. No. 32]. In the specified method of IMM calibration, including the installation of the IMU on the platform of the device for calibration in such a way as to ensure the setting of the angular velocity by the motor around three approximately orthogonal IMU axes, the IMU is rotated around an approximately horizontal axis with variable angular velocities and the components of the mathematical models of the CRS are identified, in particular errors of the scale factor, the constant component of the drift velocity and the g-sensitivity coefficients, while rotation around three orthogonal axes of the coordinate system associated with the IMM is carried out by single fixing the IMM on the device platform, and the evaluation of the components of both error models for the ADS and for the models errors of accelerometers, including errors of the scale factor and zero signals, are carried out on the basis of calculating the residuals of the estimates of the angles of rotation of the IMM sensitivity axes according to the readings of the DUS and accelerometers as a result of a single cycle of calibration movements, while m, an additional interface for wireless data transmission is placed on the platform.

The disadvantage of these methods is the lack of explicit instructions for the automation of the calibration process, which can lead to a significant increase in the time spent on calibrating the RCS and accelerometers before acceptable results are obtained. This can introduce human error during the calibration process.

The known method of calibration of transducers (Calibration of transducers) [see. description of the invention to the patent GB 25404630 A from 18.01.2017, cl. G01G 23/01; G01D 18/00]. It consists in installing a load measurement sensor on the aircraft (aircraft), in which the loads are to be measured using a calibrated sensor, while the remote database is interrogated using an additional code to retrieve the calibration data, which is transmitted to the control unit, after which the set is controlled transducers, and each set of transducers is calibrated, followed by recording the calibration data in the database.

The disadvantage of this method is its limited functionality, as a result of which it cannot be applied to RBVs.

Elimination of the disadvantages of the above calibration methods is possible by building a distributed information system that provides automation of the calibration process. In this regard, a patent search was carried out in related fields of technology to identify known technical solutions that have features that coincide with the features of the claimed invention.

Known communication system (a system for graphical web communication in real time using HTML 5 WebSockets), operating in real time using the HTML 5 WebSockets protocol [see. patent US2015 / 0341472 A1 from 26.11.2015, cl. H04L 29/06; H04L 12/58; H04L 29/08]. The method implemented in this system allows multiple users to interact in a web environment, tracking and displaying in real time each other's messages, location, status, graphics and other communication gestures.

The disadvantages of this system can be attributed to the fact that it is aimed primarily at the work of users among themselves and cannot be used without significant processing to solve specific problems related to the calibration of SINS sensors.

A known system and method for automatic shunt calibration of the sensor [see. patent US 2014/245808 A1 dated 09/04/2014], and in which the sensor assembly may include a Wheatstone bridge with one or more sensing elements, an amplifier connected to the Wheatstone bridge to provide an output signal of the sensor, a resistor and a switch for connecting a resistor between the sensor and adjustable power supply output for induction bias sensor output. In some cases, the controller can perform an automatic shunt calibration routine by activating a switch to connect a resistor between the transmitter and the regulated power supply output to cause a bias in the transmitter output. The controller can read the output value and compare the output value with a predetermined value. The controller can adjust the output of the power supply to a value that moves the output of the sensor to a predetermined value. The controller can repeat the reading.

The disadvantage of this system is its narrow functional limitation, since it is used for automatic calibration of strain gauges.

A system and method for integrating microservices is also known in related technical fields [cf. US patent 2017/0160880 A1 dated 06/08/2017, cl. G06F 3/0482; G06F 3/04842; G06F 17/30554; G06F 17/30867]. This method displays a graphical environment and identifies the next proposed microservice according to the usage data. At least one of the microservices can access a hardware sensor that generates measurement data for at least one microservice.

The disadvantages of this system and method include limited functionality, since the operation of the system with sensors is carried out only in the information reading mode, as a result of which there is no possibility of recording calibration information into the SINS calculator. In addition, there is no information about the possibility of storing calibration data in the system database.

Characteristics of the selected prototype

The closest to the claimed invention in terms of its technical essence and the achieved result is a universal device testing system [see. description of the invention to the patent World Intellectual Property Organization WO 2017/053961 Al dated 09/26/2016, publ. 03/30/2017]. The method implementing the system is intended for independent testing of several dissimilar or similar devices. Devices under test (DUT) can include set-top boxes, wireless routers, and modem / eMTA devices. The system includes real-time, bi-directional / asynchronous communication and interaction between system components. In addition, the system has an operator panel (user interface) used to organize the testing process itself. The system also has a core test runner / processor for testing multiple devices, simultaneously using virtualization containers to interact through the interfaces of the corresponding tested devices. The test framework described provides a separate set of virtualization containers for each of the subsets of the device under test that can perform WiFiLayer 2 and WiFiLayer 3 tests in a way that minimizes or avoids wireless interference.

This system is taken as a prototype for the claimed invention.

The advantage of this system is that it allows you to automate the procedure for testing many dissimilar or similar testing devices, providing the operator with a user interface with which he controls the testing of many of these devices simultaneously, but asynchronously and independently of each other, using a universal tester (testing tool ). At the same time, the system allows testing the interfaces of the following types of devices: set-top boxes, wireless routers, cable modems of subscriber equipment (eMTA).

However, this system, which is the closest analogue (prototype), has the following disadvantages. The system does not allow testing SINS sensors (accelerometers and gyroscopes) and calculating the matrix of calibration coefficients and matrices of temperature compensation polynomials with their subsequent writing to the SINS calculator. The testing system does not provide for the possibility of its use in a protected circuit of a local area network. The use of virtualization containers in the system to interact with the tested devices complicates their configuration and reduces the stability of the testing tools. In addition, the system lacks the ability to broadcast Web Sockets messages, which makes it impossible to simultaneously calibrate the sensors of several SINS.

Consequently, the prototype invention has limited functionality, not allowing the implementation of special tasks arising from the calibration of SINS accelerometers and gyroscopes in RBLA.

The task and the technical result of the invention

The objective of the invention is to expand the functionality of a distributed information system by implementing the procedure for automated calibration of SINS sensors, providing the ability to adapt to the expansion of the number of simultaneously calibrated devices (SINS), providing secure remote access to information resources in a protected segment of the local network.

The technical result of the invention consists in:

- in increasing the productivity of the procedure for calibrating SINS sensors (accelerometers and gyroscopes) by ensuring its automation and expanding the number of simultaneously calibrated devices (SINS);

- in increasing the protection against unauthorized access to information resources in the protected segment of the local network between the web controller and service applications through the use of enhanced authentication technology.

The specified technical result is achieved by the fact that in the method of automating the calibration of the sensors of the strapdown inertial system of a robotic unmanned aerial vehicle (RBVA), which consists in the fact that the strapdown inertial system (SINS), containing accelerometers and gyroscopes (SINS sensors), is placed and fixed on the calibration table with a temperature chamber, SINS sensors and a calibration table are connected to workstations located in the local network segment, on which service applications are launched to interact with equipment (SINS sensors and a calibration table), for data exchange between service applications and an automated workstation (AWP ) operators use a web controller to handle HTTP requests and handle / send WebSockets messages, while two-way and asynchronous real-time communication between the UI and service applications provide multiple WebSockets messages, receiving The initial (raw) data and logs of the calibration procedure obtained during the calibration process are recorded in the database, a set of distinctive features has been introduced , with the help of which the interaction of the SINS sensors and the calibration table with the service applications located on the workstations is carried out using the RS-232 / RS protocol -485; in the web controller, based on the data received from the SINS sensors and stored in the database, the calibration matrices of accelerometers and gyroscopes, as well as the matrices of temperature compensation polynomials, are calculated, the calculated matrices are written into the database and the SINS calculator, while ensuring secure remote access to information resources in the protected segment of the local network, they perform the authentication procedure for the token generated by the web controller, then save the token at the local service station, additionally use the web controller to verify the token to check the validity of the saved token at the local service station, use the token for authentication service without re-entering the credentials of the user on whose behalf the information exchange is carried out using the WebSockets protocol.

In the proposed method, to ensure the possibility of its adaptation to the expansion of the number of simultaneously calibrated devices (SINS), broadcasting of WebSockets messages is carried out, for this purpose, message brokers generated by the WebSockets broadcast support module are used.

The achievement of the technical result is ensured by applying new actions (operations):

- on data exchange in a distributed information system between service applications and devices (SINS sensors and a calibration table), including in broadcast mode using message brokers;

- on the calculation and recording in the database and the SINS calculator of calibration matrices of accelerometers and gyroscopes, matrices of temperature compensation polynomials;

- on the implementation of the technology of enhanced authentication using a cryptographic token generated by the web controller.

Thus, the introduction of a set of new essential features is a non-obvious inventive solution of a technical nature.

The analysis of technical solutions made it possible to establish that analogs characterized by a set of features that are identical to all features of the claimed technical solution are absent in known storage media, which indicates the compliance of the claimed method with the "novelty" condition of patentability.

The search results for known solutions in this field of technology, as well as in related areas, in order to identify features that match the distinctive features of the prototype features, have shown that they do not follow explicitly from the prior art. The prior art also did not reveal the influence of the transformations envisaged by the essential features of the claimed invention on the achievement of the specified technical result. Therefore, the claimed invention meets the “inventive step” requirement of patentability.

Disclosure of invention

The essence of the invention and distinctive (from the prototype) features

A method for automating the calibration of sensors of a strapdown inertial system of a robotic unmanned aerial vehicle (RBVA), which consists in the fact that a strapdown inertial system (SINS) containing accelerometers and gyroscopes (SINS sensors) is placed and fixed on a calibration table with a temperature chamber, SINS sensors and a calibration the table is connected to workstations located in the local network segment, on which service applications are launched to interact with equipment (SINS sensors and a calibration table), a web controller is used to exchange data between service applications and the operator's automated workstation (AWS), with which handles HTTP request processing and WebSockets message handling / dispatch, while two-way and asynchronous real-time communication between the user interface and service applications provide multiple WebSockets messages obtained during the calibration process, the original (unprocessed) the data and logs of the calibration procedure are recorded in the database, characterized in that the interaction of the SINS sensors and the calibration table with the service applications located on the workstations is carried out via the RS-232 / RS-485 protocol; in the web controller, based on the data received from the SINS sensors and stored in the database, the calibration matrices of accelerometers and gyroscopes, as well as the matrices of temperature compensation polynomials, are calculated, the calculated matrices are written into the database and the SINS calculator, while ensuring secure remote access to information resources in the protected segment of the local network, they perform the authentication procedure for the token generated by the web controller, then save the token at the local service station, additionally use the web controller to verify the token to check the validity of the saved token at the local service station, use the token for authentication service without re-entering the credentials of the user on whose behalf the information exchange is carried out using the WebSockets protocol.

The proposed method, characterized in that, to ensure its adaptation to the expansion of the number of simultaneously calibrated devices (SINS), broadcasting WebSockets messages is carried out; for this, message brokers are used, generated by the WebSockets broadcast support module.

Comparative analysis of the claimed invention with the closest analogue (prototype) shows that in the proposed invention, significant distinguishing features are the presence of new actions (operations), as well as new logical connections between new (introduced) actions (operations) and known actions related to restrictive features.

These essential distinctive features lead to the emergence of the claimed invention new properties that allow for the automation of the sensor calibration procedure, carried out simultaneously with several SINS, based on a distributed information system built on the basis of a secure local network.

Brief Description of Drawings

The alleged invention is illustrated by the drawings shown in Figures 1-15.

Figure 1 shows a typical block diagram of a distributed information system, on the basis of which a method for automated calibration of SINS RBLA sensors is implemented. This distributed information system consists of the following main blocks:

1 - database;

2 - subsystem for processing messages of the WebSockets protocol;

3 - a subsystem for processing custom HTTP requests and requests to the REST API;

4 - message broker to support broadcast sending of data using the WebSockets protocol;

5 - Web-server of the system;

6 - operator's web browser on the operator's workstation;

7 - system service for interacting with SINS;

8 - service of the system for interaction with the rotary-tilt test bench (calibration table);

9 - strapdown inertial navigation system RBVA;

10 - calibration table (swivel-tilt test bench).

Figure 2 shows an entity-relationship model of a domain in an information database of a distributed information system.

Figure 3 shows a generalized algorithm for processing a request by a web controller.

Figures 4 and 5 show the algorithms of the distributed information system service in the authentication and token verification modes, respectively.

Figure 6 shows a block diagram of the automated calibration procedure for SINS sensors.

Figure 7 shows the screen form of the start page of the web controller.

Figure 8 shows the screen form of a page with a list of tests before the start of the proof test.

Figure 9 shows the screen form of the page for switching the stand to the control mode of the angular position.

Figure 10 shows the screen form of the page for transferring the stand to the angular velocity control mode.

Figure 11 shows the screen form of the page with the results of the calibration of the accelerometers.

Figure 12 shows the screen form of the page with the elements of the accelerometer calibration matrix.

Figure 13 shows the screen form of the page with the results of the calibration of the gyroscopes.

On Fig shows the screen form of the page with the elements of the calibration matrix of gyroscopes.

Fig. 15 is a screen form of a test list page after completion of the proof test.

Description of the implementation of the method

The system based on the method includes two components: a cross-platform web application for interacting with the user and the database (DB) of the system (hereinafter the web controller), as well as a service application for interacting with the equipment (hereinafter the service). The block diagram of the system is shown in figure 1.

The system contains SINS 9 and a calibration table (single-axis rotary test bench Acutronic AC1120Si) 10, connected via the RS-232 / RS-435 protocol to workstations located in the protected segment of the local network, on which instances of the service application of the system 7 and 8 are running, respectively, whose main task is to interact with equipment. Each of the service applications interacts with the server, also located in the secure network segment, on which the system's web controller is installed, using the TCP protocol. Web server 5, through which information is exchanged between the services of the system 7 and 8, as well as the automatic workstation (AWS) of the system operator, dispatches requests for web application 8, which consists of two independent subsystems: processing HTTP requests 3 and to process / send WebSockets 2 messages. To broadcast WebSockets messages, Subsystem 2 interacts with the WebSockets 4 translator helper, which uses a message broker. Each of the subsystems reads and writes from / to the PostgreSQL database of system 1.

The input data of the system are:

- the magnitude of the projections of the acceleration of gravity on the axis of sensitivity of the accelerometers a _x , a _y , a _z ;

- the magnitude of the projections of the angular velocity vector on the axis of sensitivity of gyroscopes (angular velocity sensors) ω _x , ω _y , ω _z ;

- the temperature value of the accelerometers t _ax , t _ay , t _az , the temperature value of the gyroscopes (angular velocity sensors) t _gx , t _gy , t _gz ;

- angles of orientation of SINS sensors relative to the calibration stand.

The output data are matrices of calibration coefficients for accelerometers and gyroscopes, as well as matrices of temperature compensation polynomials, which are stored in the system database and, if necessary, can be written into the SINS non-volatile memory.

The web controller program resides in the Docker container image. The launch process consists in creating an appropriate container from an image, and then launching the web controller in this container, along with launching the database management system (DBMS) and message broker in separate containers.

When designing the information database of the program, the entities of the subject area were identified and relationships were built between these entities. Figure 2 shows the entity-relationship model of these objects.

The main entity responsible for the separation of user rights is the "User", which belongs to a certain group of permissions, described by the entity "Group". The main attributes of the User entity are:

- id - user ID in the system;

- username - username;

- password - SHA-hash of the user's password;

- last_login - date and time of the last user login to the program;

- is_active - a sign that the system can be logged in on behalf of the user;

- first_name - username;

- second_name - second name or patronymic of the user;

- last_name - user's last name;

- is_staff — sign that the user has access to the administrative panel login authority;

- date_joined - user creation date;

- is_superuser - a sign that the user has superuser rights;

- groups - groups of permissions to which the user belongs;

- user_permission - individual permissions available to the user;

- organization - the organization in which the user works;

- department - the department in which the user works;

- position - the position in which the user works.

Each User entity has a many-to-one relationship with an Organization entity that has the following attributes:

- id - organization identifier in the system;

- name - full name of the organization;

- short_name - short name of the organization.

Since the User user, in addition to the organization, also works in a department, each User entity has a many-to-one relationship with the Department entity, which has the following attributes:

- id - department identifier in the system;

- name - department name.

Also user User is in some position. This is expressed by a many-to-one relationship between the User and Position entities. The Position entity has the following attributes:

- id - position identifier;

- name - the name of the position.

The additional entity "Token" (Token) is intended for authorization by the service, while being linked to the User entity by a "one-to-one" relationship and has the following attributes:

- id - token identifier in the system;

- key - the user's token itself;

- user - the user for whom the token was generated;

- created - the date and time when the token was created.

The calibration algorithm provides for many steps with the need to record the results of each step. Each run of the calibration algorithm is viewed as a separate Experiment entity, with associated entities storing measurement results, as well as sensor calibration matrices and temperature coefficient matrices. The Experiment entity contains the following attributes:

- id - test identifier in the system;

- started - date and time of the start of the test (running the algorithm);

- finished - date and time of the end of the test (running the algorithm);

- user - the user running the algorithm;

- state - the state in which the corresponding test is located.

Within one run of the algorithm (test), several measurements of the sensor readings are made. The Measurement entity is responsible for storing measurement values, which has a many-to-one relationship with the Experiment entity. The attributes of the Measurement entity correspond to the inputs to the calibration algorithm:

- id - measurement identifier in the system;

- experiment - the test for which the measurement is performed;

- temperature - temperature of the heat chamber;

- faceplate_angle - angle of rotation of the faceplate of the stand (takes on the NULL value, if not provided by the operating mode of the stand in which the measurement is made);

- angular_velocity - the angular velocity of the test bench (takes on the NULL value, if not provided by the operating mode of the test bench in which the measurement is made);

- a_x, a_y, a_z - the magnitude of the projections of the gravitational acceleration on the axis of sensitivity of the accelerometers;

- omega_x, omega_y, omega_z - the magnitude of the projections of the angular velocity vector on the axis of sensitivity of the gyroscopes;

- t_ax, t_ay, t_ax - accelerometer temperature value;

- t_gx, t_gy, t_gz - gyro temperature value.

Calibration matrices are calculated for various temperatures and sensors. The CalibrationMatrix entity is used to store the calculation results of the calibration matrices, which is many-to-one related to the Experiment entity. The calibration matrix entity has the following attributes:

- id - identifier of the calibration matrix in the system;

- experiment - test for which the calibration matrix was defined;

- temperature - temperature of the heat chamber;

- sensor - sensor for which the calibration matrix is defined;

- rows, columns - the number of rows and columns of the adjustment matrix (for the calibration algorithm, these values are 4 and 3, respectively);

- items - elements of the calibration matrix in the form of an array.

The temperature coefficient matrix is formed from calibration matrices obtained for various temperatures. The TemperatureMatrix entity is used to store the calculation results for the temperature coefficient matrix, which is many-to-one related to the Experiment entity. The temperature coefficient matrix entity has the following attributes:

- id - identifier of the matrix of temperature coefficients in the system;

- experiment - test for which the matrix of temperature coefficients was determined;

- rows, columns - the number of rows and columns of the temperature coefficient matrix (for the calibration algorithm, these values are 12 and 4, respectively);

- items elements of the matrix of temperature coefficients in the form of an array.

The Device entity is used to interact with devices using the WebSockets protocol. The Device entity attributes are:

- id - device identifier in the system;

- name - the name of the device in the system;

- created - date and time when the device record was created;

- settings - device settings in JSON format.

Device state changes are logged using the DeviceLog entity. The DeviceLog entity attributes are:

- id - identifier of the journal entry in the system;

- user - the user on whose behalf the interaction with the device is carried out;

- device - the device for which the logging is carried out;

- type — type of log entry;

- time - date and time of the log entry;

- info - additional information stored in the log.

Fixation of messages transmitted from the device to the web controller is performed using the "Message" entity (Notification). The attributes of the Notification entity are:

- id - message identifier in the system;

- from — device from which the message is sent;

- to - device to which the message is sent;

- user - the user on whose behalf the message is being sent;

- experiment - a test within which the message is transmitted;

- time - date and time of message transmission;

- data - message data in JSON format.

The Group, Permission, and ContentType entities are service entities; therefore, the description of the attributes for them is not provided.

The block diagram of the request processing algorithm is shown in Figure 3. At startup, the web server configuration files and the web application file containing the web controller settings are read. Then the web controller is initialized in accordance with the specified settings. Then the main loop of the application begins.

After being processed by the application server, the user's request is dispatched by the router, which determines which controller of the web application using the MVC (Model-View-Controller) concept should be applied for this request. The decision is made based on a list of rules consisting of a regular expression and the name of the web application controller.

In every request from the web controller, the database is accessed. The received data can be substituted into the template and sent after rendering to the user in the form of an HTML page.

For secure interaction between the web controller and the service, it is necessary to authorize the service so that in the future the service can interact with the web controller on behalf of some user present in the system database. However, the credentials of the user on whose behalf the information exchange is to be conducted must be located on the workstation on which the service is installed. Therefore, in order to prevent the storage of the user's password outside the system database, authorization using a token is used.

To receive and work with a token, the web controller provides a specialized REST API.

When operating in this mode, the service initially reads the configuration file, which contains the settings for connecting to the server on which the web controller is installed. Then the username and password are entered from the keyboard. It is necessary that the user of interest has the necessary permissions to control the devices with which the service will interact. The block diagram of the system operation algorithm in the verification mode is shown in Figure 4. Next, the structure is filled with information about the username and password to form a REST request. The data is marshaled to JSON format, and then a REST request is made to the / api / v1 / login / endpoint.

On the web controller side, the REST request data is deserialized, the username and password are extracted. After that, a search is performed for a user with the obtained name in the database.

If the user is not found, then an error message is generated and sent to the service as a response. Otherwise, an attempt is made to authenticate the found user using the password obtained in the REST request. If the user is not authenticated (the password is not correct), then an error message is generated and sent to the service as a response. Otherwise, the token is searched for the given user in the database. If the token is found, then a response is generated with the found token, the response is serialized into JSON format and it is sent to the service. Otherwise, a token is generated for this user and written to the database, after which a response with the generated token is generated, the response is serialized into JSON format, and it is sent to the service.

On the service side, reading and unmarshalling of the received data from the JSON format is performed. The HTTP response status code is also analyzed. If the status code is 200, in other words, the REST request was successful and the token was either found or generated, then a structure is formed containing the username entered from the keyboard and the token received from the request. After that, this structure is marshaled to JSON format and then the string is written in JSON format to the credentials.json file. Otherwise, if the HTTP response status code is not 200, which indicates that errors occurred during the execution of the REST request, the transmitted error message is displayed and the credentials.json file is not generated.

When working with the service in other modes, you do not need to enter user credentials, since the required user credentials will be taken from the credentials.json file.

When working in the token verification mode, the service initially reads the configuration file config.yml, which contains the settings for connecting to the server on which the web controller is installed. After that, the credentials.json file is read, in which the username and his token are already written.

Next, a structure is filled with information about the username and his token to form a REST request. The data is marshaled to JSON and then a REST request is made to the / api / v1 / verify / endpoint. A block diagram of the system's operation in the token verification mode is shown in Figure 5.

On the web controller side, the REST request data is deserialized, the username and token are allocated. After that, a search is performed for a user with the obtained name in the database. If the user is not found, then an error message is generated and sent to the service as a response. Otherwise, the token is searched in the database for the found user. If the token is not found, then an error message is generated and sent to the service as a response. Otherwise, the comparison of the found and transferred tokens is performed and the result of this comparison is passed to the service as a response after serialization to JSON format.

On the service side, reading and unmarshalling of the received data from the JSON format is performed. The HTTP response status code is also analyzed. If the status code is 200, in other words, the REST request was successful and the token was found, then the result of the token comparison is displayed. Otherwise, an error message is displayed.

Description of the implementation of the method with examples of specific implementation

The block diagram (algorithm) of the procedure for the automated calibration of SINS sensors using the example of using a calibration table in the form of a single-axis stand of the AC1120Si series (ACUTRONIC) is shown in Fig. 6. The operation of the flowchart is described as follows:

1) A check is carried out in the manual mode of the initial settings of the stand, namely:

- using a level, with an accuracy of not less than 0.05 mm per 1 m, the vertical plane of the rotating faceplate of the stand is checked;

- the reliability of fastening the device for positioning the IMU to the stand faceplate is checked.

2) An experiment record is created and written to the database.

3) The connection of the required devices is checked, such as a calibration table (test bench) and SINS sensors.

4) According to the list of temperature cycle values T (-30, -10, 20, 40, 80), the temperature value in the heat chamber is set equal to T degrees Celsius.

5) A message is generated to switch the calibration table (stand) to the angular position control mode, this message is serialized into JSON format, and then the data is transferred to the service using the WebSockets protocol.

6) On the service side, the transmitted message is unmarshaled from the JSON format and, then, a command for switching the stand to the stand angular position control mode is formed and transmitted by writing to the serial port.

7) The state of the stand is read and its state is marshaled to the JSON format, and then, using the WebSockets protocol, this state is transferred to the web controller.

8) On the web controller, the received message is deserialized from the JSON format and the specified state of the stand is checked. If the test bench is not in the specified state, then an error message is displayed on the web interface and the created record is deleted from the database.

9) Otherwise, a cycle begins in which the angle of rotation of the faceplate A changes from 45 to 315 degrees.

10) A record is made in the database for a given rotation angle A degrees.

11) A message is formed to rotate the faceplate of the stand to the position A degrees, the message is serialized into JSON format, and then the data is transferred to the service using the WebSockets protocol.

12) On the service side, the message is unmarshaled from the JSON format, a command is formed to rotate the stand faceplate at an angle of 45 degrees of arc, and the command is sent to the stand by writing to the serial port.

13) The 9dof_main_raw_request_cmd_s command is formed to request the "raw" data of the SINS sensors and transfer them by writing to the serial port.

14) The "raw" data of the SINS sensors are read from the serial port and messages are formed with the received data from the accelerometers and gyroscopes of the SINS IMM.

15) The message is marshaled to JSON format, using the WebSockets protocol, this message is transmitted to the web controller.

16) On the side of the web controller, the message is deserialized from the JSON format, the sensor data is written to the database and displayed on the web interface.

17) The angle of rotation A is increased by 45 degrees and the transition to the next iteration of the cycle is carried out (point 9).

18) A message is formed to switch the stand to the angular velocity control mode, this message is serialized into JSON format, and then the data is transferred to the service using the WebSockets protocol.

19) On the service side, the transmitted message is unmarshaled from the JSON format and, then, a command for switching the stand to the stand angular velocity control mode is formed and transmitted by writing to the serial port.

20) The state of the stand is read and its state is marshaled to the JSON format, and then, using the WebSockets protocol, this state is transferred to the web controller.

21) On the side of the web controller, the received message is deserialized from the JSON format and the specified state of the stand is checked. If the test bench is not in the specified state, then an error message is displayed on the web interface and the created record is deleted from the database.

22) Otherwise, a cycle begins in which the angular velocity V changes according to the specified values from the list (50, -50, 100, -100, 200, -200, 300, -300).

23) Recording is carried out in the database for a given value of the angular velocity V degrees per second.

24) A message is formed to set the angular velocity V degrees per second, the message is serialized into JSON format, and then the data is transferred to the service using the WebSockets protocol.

25) On the service side, the message is unmarshaled from the JSON format, a command is formed to set the angular velocity equal to V degrees per second, and the command is sent to the stand by writing to the serial port.

26) The 9dof_main_raw_request_cmd_s command is formed to request the "raw" data of the LSI sensors and transfer them by writing to the serial port.

27) The "raw" data of the SINS sensors are read from the serial port and messages are formed with the received data from the SINS accelerometers and gyroscopes.

28) The message is marshaled to JSON format and, using the WebSockets protocol, this message is transmitted to the web controller.

29) On the side of the web controller, the message is deserialized from the JSON format, the sensor data is written to the database and displayed on the web interface.

30) Select the next value of the angular velocity V from the list and go to the next iteration of the cycle (point 22).

31) The components a_x, a_y, a_z of the projection of the gravitational acceleration vector are selected from the database and a two-dimensional array NumPyAm is formed, each row of which has the form a_x, a_y, a_z, 1.

32) Calibration coefficient matrix Ka is calculated according to formula (1), while the reference matrix As is set when the program starts

K _a = ( A _m ^T A _m ) ^–1 A _m ^T A _s . (one)

33) The calibration matrix Ka is recorded in the database for a given temperature value T.

34) The components o_x, o_y, o_z of the projection of the angular velocity vector are selected from the database and a two-dimensional array NumPyOm is formed, each row of which has the form o_x, o_y, o_z, 1.

35) The matrix of calibration coefficients is calculated according to the formula (2), while the reference matrix Os is set at the start of the program

K _o = ( O _m ^T O _m ) ^–1 O _m ^T O _s . (2)

36) The calibration matrix Ko is written to the database for a given temperature value T.

37) Select a new value T from the list and go to the next iteration of the loop (point 4).

38) Obtaining the matrix Ka for all values of the temperature T. Initialize the array Kp with zero values to store the coefficients of the polynomials.

39) Start a cycle in which the elements of the matrices Ka are selected line by line for different values of the temperature T.

40) The choice of the values of the elements of the matrices Ka and the formation of the vector Va for different temperatures T.

41) Calculation of the coefficients of the polynomial and adding the coefficients to the end of the array Kp.

42) Select the next element of the matrices Ka and go to the next iteration of the loop (step 39).

43) Obtaining the matrix Ko for all temperatures T.

44) Start a cycle in which the elements of the matrices Ko are selected line by line for different values of the temperature T.

45) The choice of the values of the elements of the matrices Ko and the formation of the vector Vo for different temperatures T.

46) Calculation of the coefficients of the polynomial and adding the coefficients to the end of the array Kp.

47) Select the next element of the matrices Ko and go to the next iteration of the loop (item 44).

48) Writing the Kp matrix to the database and displaying the completion message on the web interface.

To calibrate the sensors, it is necessary to open the web browser application on the user's working machine and enter the URL string of the web controller in the address bar, then the initial page shown in Fig. 7 will be displayed.

After that, if the user is present in the database, it is necessary to enter the program by pressing the "Login" button, as a result, a transition will be made to the page for entering credentials. If the user is not in the system, he needs to click on the "Registration" button, as a result of which a page will be opened, in which it is necessary to enter the user's registration data.

In case of successful login, as well as in case of successful registration, a list of the tests performed by the user will be displayed, as shown in Fig. 8.

To start the test, you must press the "Start test" button, as a result of which the page about the transfer of the Acutronic AC1120Si stand to the angular position control mode will be displayed (Fig. 9), after which it is necessary to press the "Start the calibration stage" button.

After the completion of receiving the readings of the SINS sensors, the page about the transfer of the Acutronic AC1120Si stand to the angular velocity control mode (Fig. 10) will be automatically displayed, on which it is also necessary to press the button "Start the calibration stage". As a result, the process of obtaining readings from SINS sensors will be launched again.

In the course of the program, if necessary, the pages for transferring the Acutronic AC1120Si stand to various operating modes can be re-displayed until all the necessary sensor readings are obtained.

After all the necessary measurements, a page will be displayed with the results of the calibration of accelerometers for various positions of the stand (Fig. 11), by clicking on the "Next" button, the matrix of calibration coefficients for the accelerometer (Fig. 12) will also be shown.

To display the page with the results of the DUS calibration, you must also click the "Next" button. As a result, a page with the results of the DUS calibration at various stand positions will be displayed (Fig. 13).

After that it is necessary to press the button "Next" and as a result the elements of the calibration matrix of the SDS will be displayed (Fig. 14). To complete the test, it is necessary to press the "Finish" button, as a result of which the calibration matrices will be written to the database and the transition to the page with the list of tests will be made (Fig. 15). Then you can start a new test.

Technical effect

Comparative analysis of the prototype method (closest analogue) and the proposed method showed the following. In the claimed method, there are new essential features, which are a set of new actions (operations). The presence in the claimed method of these new essential features, introduced in a non-obvious way by a new technical solution, allows you to achieve the objective of the invention, namely: expanding the functionality of a distributed information system.

Indeed, a set of new actions (operations) that ensure the exchange of data in a distributed information system between service applications and devices (SINS sensors and a calibration table), including in broadcast mode using message brokers, as well as performing calculations and writing to the database and the SINS calculator of calibration matrices of accelerometers and gyroscopes, matrices of temperature compensation polynomials, makes it possible to implement the procedure for automated calibration of SINS sensors, to provide the possibility of expanding the number of simultaneously calibrated devices (SINS).

Automation of the SINS sensor calibration procedure, in turn, leads to such a technical effect as it increases the productivity of the calibration procedure. The greatest increase in productivity will be carried out in the case of simultaneous calibration of several SINS. In this case, the operator is left with only the actions (operations) associated with the placement and fastening of the SINS sensors on the rotary-inclined test bench (calibration table), as well as with the launch and control of the calibration procedure from the automated workstation. Whereas the calibration algorithm itself, which provides for many routine steps with the need to record the results of each step, is performed automatically.

In addition, a set of new actions (operations) that ensure the implementation of the enhanced authentication technology using a cryptographic token generated by the web controller makes it possible to increase the level of protection against unauthorized access to information resources in the secure segment of the local network between the web controller and service applications.

The achievement of such a technical effect as increased protection against unauthorized access to information resources is carried out due to the following. First, not every service that interacts with the equipment will gain access to the web controller and interact with it. Secondly, this technology will protect the system from unauthorized actions of the operator, in the event that he wants to simulate information exchange between the equipment service and the web controller.

Thus, the claimed method for automating the calibration of SINS sensors RBLA increases the productivity of the SINS sensor calibration procedure by ensuring its automation and expanding the number of simultaneously calibrated devices (SINS) and increases protection against unauthorized access to information resources in the secure segment of the local network between the web controller and applications -services through the use of enhanced authentication technology. In addition, the application of this method in practice will eliminate or reduce systematic errors and unauthorized actions caused by the human factor during the calibration procedure and thereby increase its quality and efficiency.

Claims (2)

1. A method for automating the calibration of sensors of a strapdown inertial system of a robotic unmanned aerial vehicle (RBVA), which consists in the fact that a strapdown inertial system (SINS) containing accelerometers and gyroscopes (SINS sensors) is placed and fixed on a calibration table with a temperature chamber, SINS sensors and the calibration table is connected to workstations located in the local network segment, on which service applications are launched to interact with equipment (SINS sensors and a calibration table), a web controller is used to exchange data between service applications and the operator's automated workstation (AWS) that handles HTTP request processing and WebSockets message handling / dispatch, while real-time bi-directional and asynchronous communication between the UI and service applications provide multiple WebSockets messages from the original (raw ) data and logs of the calibration procedure are recorded in the database, characterized in that the interaction of the SINS sensors and the calibration table with the service applications located on the workstations is carried out via the RS-232 / RS-485 protocol; in the web controller, based on the data received from the SINS sensors and stored in the database, the calibration matrices of accelerometers and gyroscopes, as well as the matrices of temperature compensation polynomials, are calculated, the calculated matrices are written into the database and the SINS calculator, while ensuring secure remote access to information resources in the protected segment of the local network, they perform the authentication procedure for the token generated by the web controller, then save the token at the local service station, additionally use the web controller to verify the token to check the validity of the saved token at the local service station, use the token for authentication service without re-entering the credentials of the user, on whose behalf the information exchange is carried out using the WebSockets protocol. 2. The method according to claim 1, characterized in that, to ensure its adaptation to the expansion of the number of simultaneously calibrated devices (SINS), WebSockets messages are broadcast, for this, message brokers generated by the WebSockets broadcast support module are used.

Images