CN116389520A - Multi-sensor state management method and system applied to automatic driving - Google Patents

Abstract

The invention provides a multi-sensor state management method and a system applied to automatic driving, wherein the method comprises the following steps: registering a monitor communication thread, and registering a CAN monitor thread and a GPS monitor thread based on the monitor communication process; a registration module/hardware monitor thread and a status monitor thread; periodically cycling the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, and counting the current system state and the safe mode state; and sending the current system state and the safe mode state to a user through a visual interface by the automatic driving platform middleware. The invention can be operated on monitors of different automatic driving platforms, has strong compatibility, can uniformly manage the states of various sensors, and is compatible with various visual interfaces according to requirements.

Description

Multi-sensor state management method and system applied to automatic driving

Technical Field

The invention belongs to the technical field of automatic driving, and particularly relates to a multi-sensor state management method and system applied to automatic driving.

Background

In the field of automatic driving, the types and the number of sensors carried by vehicles are various, and brands and drives of the same type of sensors can be different; the messages transmitted among the modules in the automatic driving platform are different, and the middleware for transmitting the messages on different platforms is different; the states of the hardware and the modules are needed to be displayed through visual interfaces, interfaces given by different visual interfaces are different, compatibility of the multiple sensors in the prior art is poor, unified management of the states of the multiple sensors cannot be achieved, and automatic driving of an automobile is affected.

Disclosure of Invention

In order to solve the technical problems, the invention provides a multi-sensor state management method and a system applied to automatic driving, which are used for solving the technical problems existing in the prior art, can simultaneously manage a plurality of different sensor hardware states, monitor the automatic driving platform module state, analyze and count the state and output the state to a visual interface, simultaneously create different monitoring threads to monitor corresponding hardware and software states according to user configuration, monitor different data according to monitored contents, finally analyze and count different data, and output the data to the corresponding visual interface for viewing and operation of a user.

In a first aspect, the present invention provides the following technical solutions, and a multi-sensor state management method applied to automatic driving, where the method includes:

reading user vehicle configuration to acquire user configuration information, and mobilizing corresponding automatic driving platform middleware based on user requirements;

registering a monitor communication thread on the autopilot platform middleware, and registering a CAN monitor thread and a GPS monitor thread based on the monitor communication process;

registering a module/hardware monitor thread and a status monitor thread according to the user configuration information;

periodically cycling the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, and counting the current system state and the safe mode state;

and sending the current system state and the safety mode state to a user through a visual interface by the automatic driving platform middleware.

Compared with the prior art, the beneficial effects of this application are: according to the method, firstly, user configuration information is acquired by reading user vehicle configuration, corresponding autopilot platform middleware is mobilized based on user requirements, registration, message communication and data storage among subsequent hardware and modules are met, then monitor communication threads are registered on the autopilot platform middleware, CAN monitor threads and GPS monitor threads are registered based on the monitor communication processes, a plurality of different sensor hardware states CAN be managed simultaneously through registering different monitors, the autopilot platform module state is monitored simultaneously, and then the current system state and the safe mode state are sent to a user through a visual interface through the autopilot platform middleware.

Preferably, the step of registering the CAN monitor thread and the GPS monitor thread based on the monitor communication thread includes:

reading CAN configuration information, acquiring CAN card signals according to the CAN configuration information, selecting corresponding functions, reading CAN information, and setting the surarray state and msg information of the CAN;

acquiring a GPS communication message, and judging whether the automatic driving platform middleware receives the GPS communication message or not;

if the automatic driving platform middleware receives the GPS communication message, analyzing and configuring the surcharge state of the GPS, and if the automatic driving platform middleware does not receive the GPS communication message, configuring the surcharge state of the GPS as UNKNOMN.

Preferably, the step of registering a module/hardware monitor thread according to the user configuration information includes:

reading module software module classification in user configuration information, declaring module_state class of a first module to be monitored corresponding to a module/hardware monitor, and judging whether the configuration information of the first module to be monitored contains a first communication thread id;

if the configuration information of the module to be monitored contains a first communication thread id, a first Topic monitor thread and a Process monitor thread are sequentially registered;

If the configuration information of the module to be monitored does not contain the first communication thread id, registering a Process monitor thread;

judging whether the user configuration information has module classification or not, if the user configuration information has no module classification, reading hardware classification in the user configuration information, declaring the hw_state class of a second module to be monitored corresponding to a module/hardware monitor, and judging whether the configuration information of the second module to be monitored contains a second communication thread id or not;

if the configuration information of the second module to be monitored contains a second communication thread id, registering a second Topic monitor thread, judging whether the configuration information of the second module to be monitored contains a hardware mounting Path, and if the configuration information of the second module to be monitored contains the hardware mounting Path, registering a Path monitor thread;

if the configuration information of the second module to be monitored does not contain the second communication thread id, judging whether the configuration information of the second module to be monitored contains a hardware mounting Path, and if the configuration information of the second module to be monitored contains the hardware mounting Path, registering a Path monitor thread.

Preferably, the step of registering the first Topic monitor thread includes:

obtaining a Topic message and judging whether the autopilot platform middleware receives the Topic message or not;

if the autopilot platform middleware receives the Topic message, acquiring Topic message delay and judging whether the Topic message delay is larger than a preset configuration delay or not;

and if the Topic message delay is not greater than the preset configuration delay, clearing the delay data of the message_delay of the Topic_status.

Preferably, the step of registering the Process monitor thread includes:

acquiring a user thread id under a system directory, acquiring a process name from a cmdline in a directory corresponding to the user thread id, and storing the process name as a process list;

judging whether a name corresponding to the module_state exists in the process list;

if the Process list has a name corresponding to the module_state, configuring a running value in the process_state as true;

if the Process list does not have a name corresponding to the module_state, judging whether the running value in the process_state is true, if the running value in the process_state is true, judging whether the vehicle state is an automatic driving state, if the vehicle state is the automatic driving state, printing an ERROR log, configuring an msg message, and configuring the running value in the process_state to be false.

Preferably, the step of registering a Path monitor thread includes:

reading the hardware configuration of the second module to be monitored and acquiring a hardware mounting path;

judging whether the hardware mounting path exists in the system or not;

if the hardware mounting path exists in the system, configuring the summary state as OK, and if the hardware mounting path does not exist in the system, configuring the summary state as UNKNOWN.

Preferably, the step of registering a status monitor thread according to the user configuration information includes:

obtaining module_state information and judging whether a running value in a process_state is true or not;

if the running value in the process_state is true, counting the surname state of the corresponding module, judging whether the module_state information contains first Topic_state information, and if the module_state information contains the first Topic_state information, judging whether the message_delay in the first Topic_state information is smaller than a preset value;

if the message_delay in the first Topic_state information is not smaller than a preset value, counting the message_delay delay of the corresponding module, and judging whether the user configuration information has module_state information or not;

if the user configuration information does not contain module_state information, acquiring hw_state information and judging whether the user configuration information contains surarray state information, if the user configuration information contains surarray state information, counting surarray states of corresponding modules and judging that the hw_state information contains second Topic_state information, and if the hw_state information contains second Topic_state information, judging whether the message_delay in the second Topic_state information is smaller than a preset value;

If the message_delay in the second topic_state information is not smaller than the preset value, counting the message_delay delay of the corresponding hardware, and judging whether the user configuration information has hw_state information or not;

if the user configuration information does not contain hw_state information, checking a state monitor, acquiring a current time stamp and issuing a system state message, a summary state message of a module and hardware and a message_delay delay message.

Preferably, after the step of sending the current system state and the safe mode state to the user through the visual interface by the autopilot platform middleware, the method further includes:

performing system self-checking on the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread according to a preset time interval;

the step of performing system self-checking on the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread according to a preset time interval comprises the following steps:

checking the running state of each monitor, and judging whether the visual interface receives a stop instruction issued by a user or not;

if the visual interface does not receive a stopping instruction issued by a user, acquiring a current program time stamp and initializing a module_state and an hw_state;

Reading the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, executing a periodic function of a corresponding monitor, and judging whether a registered monitor thread exists or not;

if there are monitor threads registered, the step of checking the running state of each monitor is executed back at preset time intervals.

In a second aspect, the present invention provides a multi-sensor state management system for automatic driving, the system comprising:

the configuration reading module is used for reading the vehicle configuration of the user to acquire user configuration information, and mobilizing the corresponding automatic driving platform middleware based on the user requirements;

the first registration module is used for registering a monitor communication thread on the automatic driving platform middleware and registering a CAN monitor thread and a GPS monitor thread based on the monitor communication process;

the second registration module is used for registering a module/hardware monitor thread and a state monitor thread according to the user configuration information;

the state statistics module is used for periodically cycling the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread and counting the current system state and the safe mode state;

And the user operation module is used for sending the current system state and the safety mode state to a user through the visual interface through the automatic driving platform middleware.

Preferably, the system further comprises:

the self-checking module is used for carrying out system self-checking on the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread according to a preset time interval;

the self-checking module includes:

the state detection sub-module is used for checking the running state of each monitor and judging whether the visual interface receives a stop instruction issued by a user or not;

the instruction receiving sub-module is used for acquiring a current program time stamp and initializing a module_state and an hw_state if the visual interface does not receive a stop instruction issued by a user;

the reading submodule is used for reading the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, executing a periodic function of a corresponding monitor and judging whether a registered monitor thread exists or not;

and the circulation submodule is used for controlling the state detection submodule to check the running state of each monitor according to a preset time interval if the registered monitor threads exist.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a flowchart of a multi-sensor state management method applied to automatic driving according to a first embodiment of the present invention;

fig. 2 is a detailed flowchart of step S2 in a multi-sensor status management method for automatic driving according to a first embodiment of the present invention;

fig. 3 is a detailed flowchart of step S31 in the multi-sensor status management method for automatic driving according to the first embodiment of the present invention;

FIG. 4 is a detailed flowchart of step S312 in a multi-sensor status management method for automatic driving according to a first embodiment of the present invention;

FIG. 5 is a detailed flowchart II of step S312 in a multi-sensor status management method for automatic driving according to a first embodiment of the present invention;

fig. 6 is a detailed flowchart of step S315 in the multi-sensor status management method for autopilot according to the first embodiment of the present invention;

FIG. 7 is a detailed flowchart of step S32 in a multi-sensor status management method for automatic driving according to a first embodiment of the present invention;

FIG. 8 is a flow chart of a multi-sensor status management method for autopilot according to a second embodiment of the present invention;

fig. 9 is a detailed flowchart of step S60 in a multi-sensor status management method for automatic driving according to a second embodiment of the present invention;

FIG. 10 is a block diagram of a multi-sensor status management system for automatic driving according to a third embodiment of the present invention;

FIG. 11 is a block diagram II of a multi-sensor status management system for automatic driving according to a third embodiment of the present invention;

fig. 12 is a block diagram of a hardware structure of a computer according to another embodiment of the present invention.

Embodiments of the present invention will be further described below with reference to the accompanying drawings.

Detailed Description

In order that the invention may be readily understood, a more complete description of the invention will be rendered by reference to the appended drawings. Several embodiments of the invention are presented in the figures. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and/or" as used herein includes any and all combinations of one or more of the associated listed items.

Example 1

As shown in fig. 1, in a first embodiment of the present invention, the present invention provides a multi-sensor state management method applied to automatic driving, the method comprising:

s1, reading user vehicle configuration to acquire user configuration information, and mobilizing corresponding automatic driving platform middleware based on user requirements;

specifically, the user vehicle is configured as the configuration of each hardware and each module in the autopilot vehicle driven by the user, meanwhile, the user vehicle configuration also comprises a period, a software and hardware configuration path and the like, and based on the configuration information of the user, the corresponding autopilot platform middleware can be called, wherein the autopilot platform middleware refers to software or service programs which provide connection between system software and application software in an autopilot platform framework and are responsible for functions such as module registration, message communication, data storage and the like.

S2, registering a monitor communication thread on the automatic driving platform middleware, and registering a CAN monitor thread and a GPS monitor thread based on the monitor communication process;

specifically, since the vehicle state information needs to be read through the CAN bus, a CAN monitor needs to be registered, and the GPS information contains various states, so that one GPS monitor needs to be registered separately;

meanwhile, before registering the CAN monitor thread and the GPS monitor thread, the vehicle state information is acquired through a plurality of monitors, and the corresponding vehicle state information is sent to the automatic driving platform part through the monitors, and the process of sending the vehicle state information needs to be through establishing a monitor communication thread, so that the monitors CAN send the acquired vehicle state information to the automatic driving platform middleware, and information transmission and reception among the sensors in the process of uniformly managing the multiple sensors are realized.

As shown in fig. 2, the step S2 includes:

s21, reading CAN configuration information, acquiring CAN card signals according to the CAN configuration information, selecting corresponding functions, reading CAN information, and setting the summation state and msg information of the CAN;

s22, acquiring a GPS communication message, and judging whether the automatic driving platform middleware receives the GPS communication message or not;

S23, if the automatic driving platform middleware receives the GPS communication message, analyzing and configuring a surarray state of the GPS, and if the automatic driving platform middleware does not receive the GPS communication message, configuring the surarray state of the GPS as UNKNOMN;

among these, the GPS may have a sur status, NOT_ READY, GOOD, INVALID, and the like. S3, registering a module/hardware monitor thread and a state monitor thread according to the user configuration information;

specifically, the user configuration information comprises a module name/hardware name, a configuration path, a communication thread id and a communication message type, and meanwhile, the corresponding monitor can be additionally configured and added according to actual requirements, and the configuration path, the communication thread id and the communication message type in the user configuration information are all selectable configuration information;

it should be noted that the module/hardware monitor thread includes a first Topic monitor thread, a Process monitor thread, a second Topic monitor thread, and a Path monitor thread, where the first Topic monitor thread and the second Topic monitor thread are communication message type monitor threads, the Process monitor thread is a thread name monitor thread, and the Path monitor thread is a mounting Path monitor thread of the module/hardware in the autopilot platform;

The status monitor thread is specifically a summary monitor thread, which specifically includes 4. A registration system status monitor thread, a vehicle status monitor thread, a security mode thread, and the like.

The step S3 includes a step S31 and a step S32, wherein the step S31 is a step of registering a module/hardware monitor thread, and the step S32 is a step of registering a status monitor thread;

as shown in fig. 3, the step S31 includes:

s311, reading module software module classification in user configuration information, declaring module_state class of a first module to be monitored corresponding to a module/hardware monitor, and judging whether the configuration information of the first module to be monitored contains a first communication thread id;

the module_state class comprises a summary state, an msg message, a process_status thread state, a topic_status communication state and the like, and can be adjusted according to actual needs;

s312, if the configuration information of the module to be monitored contains a first communication thread id, a first Topic monitor thread and a Process monitor thread are sequentially registered;

as shown in fig. 4, the step of registering a first Topic monitor thread includes:

S312A, acquiring a Topic message and judging whether the automatic driving platform middleware receives the Topic message or not;

S312B, if the autopilot platform middleware receives the Topic message, acquiring Topic message delay, and judging whether the Topic message delay is larger than a preset configuration delay or not;

specifically, if the autopilot platform middleware does not receive the Topic message, configuring a message_delay delay of topic_status to be-1;

S312C, if the Topic message delay is larger than the preset configuration delay, configuring the message_delay of the Topic_status as delay data, and if the Topic message delay is not larger than the preset configuration delay, clearing the delay data of the message_delay of the Topic_status;

the preset configuration delay is the maximum delay allowed to be accepted by the middleware of the automatic driving platform.

As shown in fig. 5, the step of registering a Process monitor thread includes:

s312a, acquiring a user thread id under a system directory, acquiring a process name from a cmdline in a directory corresponding to the user thread id, and storing the process name as a process list;

wherein, the system catalog is a proc catalog;

s312b, judging whether a name corresponding to the module_state exists in the process list;

s312c, if the Process list has a name corresponding to the module_state, configuring a running value in the process_state as true;

S312d, if the name corresponding to the module_state does not exist in the Process list, judging whether the running value in the process_state is true, if the running value in the process_state is true, judging whether the vehicle state is an automatic driving state, if the vehicle state is the automatic driving state, printing an ERROR log, configuring an msg message, and configuring the running value in the process_state to be false.

Specifically, if the running value in the process_state is not true, the running value in the process_state is configured as false, and if the vehicle state is not an automatic driving state, an ERROR log is correspondingly printed, an msg message is configured, and the running value in the process_state is configured as false.

S313, if the configuration information of the module to be monitored does not contain the first communication thread id, registering a Process monitor thread;

s314, judging whether the user configuration information has module classification, if the user configuration information has no module classification, reading hardware classification in the user configuration information, declaring the hw_state class of a second module to be monitored corresponding to a module/hardware monitor, and judging whether the configuration information of the second module to be monitored contains a second communication thread id;

Specifically, if the module classification is still included in the user configuration information, returning to execute the step of reading the module software module classification in the user configuration information, declaring the module_state class of the first module to be monitored corresponding to the module/hardware monitor, and determining whether the configuration information of the first module to be monitored includes the first communication thread id, that is, returning to execute step S311;

the hw_state class comprises a summary state, an msg message, a topic_state communication state and the like, and can be adjusted according to actual requirements;

s315, if the configuration information of the second module to be monitored contains a second communication thread id, registering a second Topic monitor thread, judging whether the configuration information of the second module to be monitored contains a hardware mounting Path, and if the configuration information of the second module to be monitored contains the hardware mounting Path, registering a Path monitor thread;

specifically, in step S315, the step of registering the second Topic monitor thread is identical to the step of registering the first Topic monitor thread;

as shown in fig. 6, the step S315 includes:

S315A, reading the hardware configuration of the second module to be monitored and acquiring a hardware mounting path;

S315B, judging whether the hardware mounting path exists in the system or not;

S315C, if the hardware mounting path exists in the system, configuring the summary state as OK, and if the hardware mounting path does not exist in the system, configuring the summary state as UNKNOWN.

S316, if the configuration information of the second module to be monitored does not contain the second communication thread id, judging whether the configuration information of the second module to be monitored contains a hardware mounting Path, and if the configuration information of the second module to be monitored contains the hardware mounting Path, registering a Path monitor thread.

As shown in fig. 7, the step S32 includes:

s321, acquiring module_state information, and judging whether a running value in a process_state is true or not;

s322, if the running value in the process_state is true, counting the surmerry state of the corresponding module, judging whether the module_state information contains first Topic_state information, and if the module_state information contains the first Topic_state information, judging whether the message_delay in the first Topic_state information is smaller than a preset value;

specifically, if the running value in the process_state is not true, the ERR log is issued correspondingly, and if the module_state information does not include the first topic_state information, the step of judging whether the user configuration information includes the module_state information is executed.

S323, if the message_delay in the first Topic_state information is not smaller than a preset value, counting the message_delay delay of the corresponding module, and judging whether the module_state information is still in the user configuration information;

s324, if no module_state information exists in the user configuration information, acquiring hw_state information and judging whether the user configuration information has the surarray state information, if so, counting the surarray state of the corresponding module and judging that the hw_state information contains second Topic_state information, and if so, judging whether the message_delay in the second Topic_state information is smaller than a preset value;

s325, if the message_delay in the second Topic_state information is not smaller than a preset value, counting the message_delay delay of the corresponding hardware, and judging whether the user configuration information has hw_state information or not;

specifically, if the preset value is 0 and the message_delay in the second topic_state information is smaller than the preset value, the ERR log is issued correspondingly.

S326, if the user configuration information does not have hw_state information, checking a state monitor, acquiring a current time stamp and issuing a system state message, a summary state message of a module and hardware and a message_delay delay message;

Specifically, if the user configuration information includes module_state information, the step S321 is executed again.

S4, periodically cycling the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, and counting the current system state and the safe mode state;

s5, the current system state and the safe mode state are sent to a user through a visual interface through the automatic driving platform middleware;

specifically, the system state is obtained by calling a state interface of a computing platform where the monitoring program operates, for example, linux is obtained by calling shell commands, windows is obtained by calling dos commands and the like, then the processed information is transmitted to a visual interface, and the information such as the safety mode state, the vehicle state and the like is obtained by screening and monitoring information transmitted by a CAN module.

The first advantage of this embodiment is: firstly, user configuration information is acquired by reading user vehicle configuration, corresponding autopilot platform middleware is mobilized based on user requirements, registration, message communication and data storage among subsequent hardware and modules are met, then monitor communication threads are registered on the autopilot platform middleware, CAN monitor threads and GPS monitor threads are registered based on the monitor communication processes, a plurality of different sensor hardware states CAN be managed simultaneously by registering different monitors according to the user configuration information registration module/hardware monitor threads and the state monitor threads, the state of the autopilot platform module is monitored simultaneously, and then the current system state and the safe mode state are sent to a user through a visual interface through the autopilot platform middleware.

Example two

As shown in fig. 8, in a second embodiment of the present invention, there is provided a multi-sensor state management method applied to automatic driving, the system including:

s10, reading user vehicle configuration to acquire user configuration information, and mobilizing corresponding automatic driving platform middleware based on user requirements;

s20, registering a monitor communication thread on the automatic driving platform middleware, and registering a CAN monitor thread and a GPS monitor thread based on the monitor communication process;

s30, registering a module/hardware monitor thread and a state monitor thread according to the user configuration information;

s40, periodically cycling the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, and counting the current system state and the safe mode state;

s50, the current system state and the safe mode state are sent to a user through a visual interface through the automatic driving platform middleware

S60, performing system self-checking on the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread according to a preset time interval;

Steps S10, S20, S30, S40, and S50 are the same as steps S1, S2, S3, S4, and S5 in the first embodiment.

As shown in fig. 9, the step S60 includes:

s61, checking the running state of each monitor, and judging whether the visual interface receives a stop instruction issued by a user;

s62, if the visual interface does not receive a stop instruction issued by a user, acquiring a current program time stamp and initializing a module_state and an hw_state;

s63, reading the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, executing a periodic function of a corresponding monitor, and judging whether a registered monitor thread exists or not;

s64, if the registered monitor threads exist, returning to execute the step of checking the running state of each monitor according to the preset time interval;

specifically, the user may operate on the visual interface, if the user does not issue a stop instruction on the visual interface, the step S61 starts to be executed, by acquiring the current program timestamp and initializing the module_state and the hw_state, then reading each registered monitor thread to execute the periodic function of the corresponding monitor, judging whether there is any registered monitor, sequentially implementing the process of self-checking the system, and if the stop instruction issued by the user is received, canceling the monitor threads and ending.

Compared with the first embodiment, the second embodiment has the following advantages: the embodiment can sequentially judge the registration state of the monitor thread, the motion state of the sensors on the vehicle and the state of the vehicle by adding the process of self-checking the system, and simultaneously control the end and the motion of the self-checking process of the system by judging whether a stop instruction issued by a user is received or not, so that the user can control and manage the multiple sensors.

Example III

As shown in fig. 10, in a third embodiment of the present invention, there is provided a multi-sensor state management system applied to automatic driving, the system including:

the configuration reading module 1 is used for reading the vehicle configuration of a user to acquire user configuration information, and mobilizing the corresponding automatic driving platform middleware based on the user requirements;

the first registration module 2 is used for registering a monitor communication thread on the automatic driving platform middleware and registering a CAN monitor thread and a GPS monitor thread based on the monitor communication process;

a second registration module 3 for registering a module/hardware monitor thread and a status monitor thread according to the user configuration information;

a state statistics module 4, configured to periodically cycle the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread, and the state monitor thread, and count a current system state and a security mode state;

The user operation module 5 is used for sending the current system state and the safe mode state to a user through a visual interface through the automatic driving platform middleware;

and the self-checking module 6 is used for performing system self-checking on the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread according to preset time intervals.

Specifically, the multi-sensor state management system applied to automatic driving specifically comprises a vehicle platform, an automatic driving platform, a monitor and an HMI display;

as shown in fig. 11, a plurality of sensors are mounted in the vehicle platform for acquiring the vehicle state, a monitor is used for monitoring the vehicle and the sensor state, an autopilot platform is used for controlling the vehicle to autopilot and sending the vehicle and the sensor state to an HMI display, and the HMI display is specifically a visual interface for displaying information of the vehicle, a monitoring switch, a monitoring state and the like.

The first registration module 2 includes:

the CAN configuration sub-module is used for reading CAN configuration information, acquiring CAN card signals according to the CAN configuration information, selecting corresponding functions, reading CAN information and setting the summation state and msg information of the CAN;

The GPS communication module is used for acquiring the GPS communication message and judging whether the automatic driving platform middleware receives the GPS communication message or not;

and the state configuration sub-module is used for analyzing and configuring the surcharge state of the GPS if the automatic driving platform middleware receives the GPS communication message, and configuring the surcharge state of the GPS as UNKNOMN if the automatic driving platform middleware does not receive the GPS communication message.

The second registration module 3 includes:

the reading sub-module is used for reading module software module classification in the user configuration information, declaring module_state class of a first module to be monitored corresponding to the module/hardware monitor, and judging whether the configuration information of the first module to be monitored contains a first communication thread id;

the first booklet filling module is used for registering a first Topic monitor thread and a Process monitor thread in sequence if the configuration information of the module to be monitored contains a first communication thread id;

the second booklet injection module is used for registering a Process monitor thread if the configuration information of the module to be monitored does not contain the first communication thread id;

the module classification sub-module is used for judging whether the user configuration information has module classification, if the user configuration information has no module classification, reading hardware classification in the user configuration information, declaring the hw_state class of a second module to be monitored corresponding to the module/hardware monitor, and judging whether the configuration information of the second module to be monitored contains a second communication thread id;

The third booklet injection module is configured to register a second Topic monitor thread if the configuration information of the second module to be monitored includes a second communication thread id, determine whether the configuration information of the second module to be monitored includes a hardware mount Path, and register a Path monitor thread if the configuration information of the second module to be monitored includes the hardware mount Path;

and the fourth booklet filling module is used for judging whether the configuration information of the second module to be monitored contains a hardware mounting Path or not if the configuration information of the second module to be monitored does not contain a second communication thread id, and registering a Path monitor thread if the configuration information of the second module to be monitored contains the hardware mounting Path.

The first registration submodule includes:

the Topic message unit is used for acquiring the Topic message and judging whether the autopilot platform middleware receives the Topic message or not;

the message receiving unit is used for acquiring the Topic message delay if the Topic message is received by the automatic driving platform middleware and judging whether the Topic message delay is larger than a preset configuration delay or not;

and the delay unit is used for configuring the message_delay of the Topic_status as delay data if the Topic message delay is larger than the preset configuration delay, and clearing the delay data of the message_delay of the Topic_status if the Topic message delay is not larger than the preset configuration delay.

The first booklet module further includes:

the user thread id acquisition unit is used for acquiring the user thread id under the system directory, acquiring the process name from the cmdline in the directory corresponding to the user thread id and storing the process name as a process list;

the name judging unit is used for judging whether the process list has a name corresponding to the module_state or not;

the first configuration unit is used for configuring a running value in the process_state as true if the name corresponding to the module_state exists in the Process list;

and the second configuration unit is used for judging whether the running value in the process_state is true if the name corresponding to the module_state does not exist in the Process list, judging whether the vehicle state is an automatic driving state if the running value in the process_state is true, printing an ERROR log and configuring an msg message if the vehicle state is the automatic driving state, and configuring the running value in the process_state to be false.

The third registration submodule includes:

the path reading unit is used for reading the hardware configuration of the second module to be monitored and acquiring a hardware mounting path;

the path judging unit is used for judging whether the hardware mounting path exists in the system or not;

And the third configuration unit is used for configuring the surly state as OK if the hardware mounting path exists in the system, and configuring the surly state as UNKNOWN if the hardware mounting path does not exist in the system.

The second registration module 3 includes:

the module_state information sub-module is used for acquiring module_state information and judging whether a running value in the process_state is true or not;

the state statistics sub-module is used for counting the summary state of the corresponding module if the running value in the process_state is true, judging whether the module_state information contains first Topic_state information or not, and judging whether the message_delay in the first Topic_state information is smaller than a preset value if the module_state information contains the first Topic_state information or not;

the delay statistics sub-module is used for counting the message_delay delay of the corresponding module if the message_delay in the first Topic_state information is not smaller than a preset value, and judging whether the module_state information is still in the user configuration information;

the hw_state information acquisition sub-module is used for acquiring the hw_state information and judging whether the user configuration information contains the surlyn state information if the user configuration information does not contain the module_state information, counting the surlyn state of the corresponding module if the user configuration information contains the surlyn state information, judging whether the hw_state information contains second Topic_state information or not, and judging whether the message_delay in the second Topic_state information is smaller than a preset value if the hw_state information contains the second Topic_state information;

The hardware delay statistics sub-module is used for counting the message_delay delay of the corresponding hardware and judging whether the user configuration information has hw_state information or not if the message_delay in the second topic_state information is not smaller than a preset value;

and the state checking sub-module is used for checking the state monitor if the user configuration information does not contain hw_state information, acquiring the current time stamp and issuing a system state message, a summary state message of the module and hardware and a message_delay delay message.

The self-test module 6 comprises:

the state detection sub-module is used for checking the running state of each monitor and judging whether the visual interface receives a stop instruction issued by a user or not;

the instruction receiving sub-module is used for acquiring a current program time stamp and initializing a module_state and an hw_state if the visual interface does not receive a stop instruction issued by a user;

the reading submodule is used for reading the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, executing a periodic function of a corresponding monitor and judging whether a registered monitor thread exists or not;

and the circulation submodule is used for controlling the state detection submodule to check the running state of each monitor according to a preset time interval if the registered monitor threads exist.

In other embodiments of the present invention, a computer device is provided, including a memory 102, a processor 101, and a computer program stored in the memory 102 and executable on the processor 101, where the processor 101 implements the multi-sensor state management method for autopilot described above when executing the computer program.

In particular, the processor 101 may include a Central Processing Unit (CPU), or an application specific integrated circuit (Application Specific Integrated Circuit, abbreviated as ASIC), or may be configured to implement one or more integrated circuits of embodiments of the present application.

Memory 102 may include, among other things, mass storage for data or instructions. By way of example, and not limitation, memory 102 may comprise a Hard Disk Drive (HDD), floppy Disk Drive, solid state Drive (Solid State Drive, SSD), flash memory, optical Disk, magneto-optical Disk, tape, or universal serial bus (Universal Serial Bus, USB) Drive, or a combination of two or more of the foregoing. Memory 102 may include removable or non-removable (or fixed) media, where appropriate. The memory 102 may be internal or external to the data processing apparatus, where appropriate. In a particular embodiment, the memory 102 is a Non-Volatile (Non-Volatile) memory. In a particular embodiment, the Memory 102 includes Read-Only Memory (ROM) and random access Memory (Random Access Memory, RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (Programmable Read-Only Memory, abbreviated PROM), an erasable PROM (Erasable Programmable Read-Only Memory, abbreviated EPROM), an electrically erasable PROM (Electrically Erasable Programmable Read-Only Memory, abbreviated EEPROM), an electrically rewritable ROM (Electrically Alterable Read-Only Memory, abbreviated EAROM), or a FLASH Memory (FLASH), or a combination of two or more of these. The RAM may be Static Random-Access Memory (SRAM) or dynamic Random-Access Memory (Dynamic Random Access Memory DRAM), where the DRAM may be a fast page mode dynamic Random-Access Memory (Fast Page Mode Dynamic Random Access Memory FPMDRAM), extended data output dynamic Random-Access Memory (Extended Date Out Dynamic Random Access Memory EDODRAM), synchronous dynamic Random-Access Memory (Synchronous Dynamic Random-Access Memory SDRAM), or the like, as appropriate.

Memory 102 may be used to store or cache various data files that need to be processed and/or communicated, as well as possible computer program instructions for execution by processor 101.

The processor 101 reads and executes the computer program instructions stored in the memory 102 to implement the multi-sensor state management method applied to autopilot as described above.

In some of these embodiments, the computer device may also include a communication interface 103 and a bus 100. As shown in fig. 12, the processor 101, the memory 102, and the communication interface 103 are connected to each other via the bus 100 and perform communication with each other.

The communication interface 103 is used to implement communication between modules, devices, units, and/or units in the embodiments of the present application. The communication interface 103 may also enable communication with other components such as: and the external equipment, the image/data acquisition equipment, the database, the external storage, the image/data processing workstation and the like are used for data communication.

Bus 100 includes hardware, software, or both, coupling components of a computer device to each other. Bus 100 includes, but is not limited to, at least one of: data Bus (Data Bus), address Bus (Address Bus), control Bus (Control Bus), expansion Bus (Expansion Bus), local Bus (Local Bus). By way of example, and not limitation, bus 100 may include a graphics acceleration interface (Accelerated Graphics Port), abbreviated AGP, or other graphics Bus, an enhanced industry standard architecture (Extended Industry Standard Architecture, abbreviated EISA) Bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an industry standard architecture (Industry Standard Architecture, ISA) Bus, a wireless bandwidth (InfiniBand) interconnect, a Low Pin Count (LPC) Bus, a memory Bus, a micro channel architecture (Micro Channel Architecture, abbreviated MCa) Bus, a peripheral component interconnect (Peripheral Component Interconnect, abbreviated PCI) Bus, a PCI-Express (PCI-X) Bus, a serial advanced technology attachment (Serial Advanced Technology Attachment, abbreviated SATA) Bus, a video electronics standards association local (Video Electronics Standards Association Local Bus, abbreviated VLB) Bus, or other suitable Bus, or a combination of two or more of the foregoing. Bus 100 may include one or more buses, where appropriate. Although embodiments of the present application describe and illustrate a particular bus, the present application contemplates any suitable bus or interconnect.

The computer can execute the multi-sensor state management method applied to automatic driving based on the acquired multi-sensor state management system applied to automatic driving, so that the management of the multi-sensor state is realized.

In still other embodiments of the present invention, in combination with the above-described multi-sensor state management method for automatic driving, embodiments of the present invention provide a technical solution, a readable storage medium having a computer program stored thereon, where the computer program when executed by a processor implements the above-described multi-sensor state management method for automatic driving.

Those of skill in the art will appreciate that the logic and/or steps represented in the flow diagrams or otherwise described herein, e.g., a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

More specific examples (a non-exhaustive list) of the readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). In addition, the computer readable medium may even be paper or other suitable medium on which the program is printed, as the program may be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

It is to be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the various steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, may be implemented using any one or combination of the following techniques, as is well known in the art: discrete logic circuits having logic gates for implementing logic functions on data signals, application specific integrated circuits having suitable combinational logic gates, programmable Gate Arrays (PGAs), field Programmable Gate Arrays (FPGAs), and the like.

The technical features of the above-described embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above-described embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The above examples merely represent a few embodiments of the present application, which are described in more detail and are not to be construed as limiting the scope of the invention. It should be noted that it would be apparent to those skilled in the art that various modifications and improvements could be made without departing from the spirit of the present application, which would be within the scope of the present application. Accordingly, the scope of protection of the present application is to be determined by the claims appended hereto.

Claims (10)

1. A multi-sensor state management method for use in autopilot, the method comprising:

reading user vehicle configuration to acquire user configuration information, and mobilizing corresponding automatic driving platform middleware based on user requirements;

registering a monitor communication thread on the autopilot platform middleware, and registering a CAN monitor thread and a GPS monitor thread based on the monitor communication process;

Registering a module/hardware monitor thread and a status monitor thread according to the user configuration information;

periodically cycling the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, and counting the current system state and the safe mode state;

and sending the current system state and the safety mode state to a user through a visual interface by the automatic driving platform middleware.

2. The method for managing a multi-sensor state applied to automatic driving according to claim 1, wherein the step of registering a CAN monitor thread and a GPS monitor thread based on the monitor communication thread comprises:

reading CAN configuration information, acquiring CAN card signals according to the CAN configuration information, selecting corresponding functions, reading CAN information, and setting the surarray state and msg information of the CAN;

acquiring a GPS communication message, and judging whether the automatic driving platform middleware receives the GPS communication message or not;

if the automatic driving platform middleware receives the GPS communication message, analyzing and configuring the surcharge state of the GPS, and if the automatic driving platform middleware does not receive the GPS communication message, configuring the surcharge state of the GPS as UNKNOMN.

3. The method for managing multi-sensor status for autopilot of claim 1 wherein the step of registering module/hardware monitor threads based on the user configuration information comprises:

reading module software module classification in user configuration information, declaring module_state class of a first module to be monitored corresponding to a module/hardware monitor, and judging whether the configuration information of the first module to be monitored contains a first communication thread id;

if the configuration information of the module to be monitored contains a first communication thread id, a first Topic monitor thread and a Process monitor thread are sequentially registered;

if the configuration information of the module to be monitored does not contain the first communication thread id, registering a Process monitor thread;

judging whether the user configuration information has module classification or not, if the user configuration information has no module classification, reading hardware classification in the user configuration information, declaring the hw_state class of a second module to be monitored corresponding to a module/hardware monitor, and judging whether the configuration information of the second module to be monitored contains a second communication thread id or not;

if the configuration information of the second module to be monitored contains a second communication thread id, registering a second Topic monitor thread, judging whether the configuration information of the second module to be monitored contains a hardware mounting Path, and if the configuration information of the second module to be monitored contains the hardware mounting Path, registering a Path monitor thread;

If the configuration information of the second module to be monitored does not contain the second communication thread id, judging whether the configuration information of the second module to be monitored contains a hardware mounting Path, and if the configuration information of the second module to be monitored contains the hardware mounting Path, registering a Path monitor thread.

4. The method for managing multi-sensor status for autopilot of claim 3 wherein the step of registering a first Topic monitor thread comprises:

obtaining a Topic message and judging whether the autopilot platform middleware receives the Topic message or not;

if the autopilot platform middleware receives the Topic message, acquiring Topic message delay and judging whether the Topic message delay is larger than a preset configuration delay or not;

and if the Topic message delay is not greater than the preset configuration delay, clearing the delay data of the message_delay of the Topic_status.

5. The method for managing multi-sensor status for autopilot of claim 3 wherein the step of registering a Process monitor thread comprises:

Acquiring a user thread id under a system directory, acquiring a process name from a cmdline in a directory corresponding to the user thread id, and storing the process name as a process list;

judging whether a name corresponding to the module_state exists in the process list;

if the Process list has a name corresponding to the module_state, configuring a running value in the process_state as true;

if the Process list does not have a name corresponding to the module_state, judging whether the running value in the process_state is true, if the running value in the process_state is true, judging whether the vehicle state is an automatic driving state, if the vehicle state is the automatic driving state, printing an ERROR log, configuring an msg message, and configuring the running value in the process_state to be false.

6. The multi-sensor state management method for use in autopilot of claim 3 wherein the step of registering a Path monitor thread comprises:

reading the hardware configuration of the second module to be monitored and acquiring a hardware mounting path;

judging whether the hardware mounting path exists in the system or not;

if the hardware mounting path exists in the system, configuring the summary state as OK, and if the hardware mounting path does not exist in the system, configuring the summary state as UNKNOWN.

7. The method for managing a state of multiple sensors for use in autopilot of claim 1 wherein the step of registering a state monitor thread based on the user configuration information comprises:

obtaining module_state information and judging whether a running value in a process_state is true or not;

if the running value in the process_state is true, counting the surname state of the corresponding module, judging whether the module_state information contains first Topic_state information, and if the module_state information contains the first Topic_state information, judging whether the message_delay in the first Topic_state information is smaller than a preset value;

if the message_delay in the first Topic_state information is not smaller than a preset value, counting the message_delay delay of the corresponding module, and judging whether the user configuration information has module_state information or not;

if the user configuration information does not contain module_state information, acquiring hw_state information and judging whether the user configuration information contains surarray state information, if the user configuration information contains surarray state information, counting surarray states of corresponding modules and judging that the hw_state information contains second Topic_state information, and if the hw_state information contains second Topic_state information, judging whether the message_delay in the second Topic_state information is smaller than a preset value;

If the message_delay in the second topic_state information is not smaller than the preset value, counting the message_delay delay of the corresponding hardware, and judging whether the user configuration information has hw_state information or not;

if the user configuration information does not contain hw_state information, checking a state monitor, acquiring a current time stamp and issuing a system state message, a summary state message of a module and hardware and a message_delay delay message.

8. The method for managing a state of multiple sensors for use in autopilot of claim 1 wherein after the step of sending the current system state and the safe mode state to a user via a visual interface through the autopilot platform middleware, the method further comprises:

performing system self-checking on the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread according to a preset time interval;

the step of performing system self-checking on the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread according to a preset time interval comprises the following steps:

checking the running state of each monitor, and judging whether the visual interface receives a stop instruction issued by a user or not;

If the visual interface does not receive a stopping instruction issued by a user, acquiring a current program time stamp and initializing a module_state and an hw_state;

reading the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, executing a periodic function of a corresponding monitor, and judging whether a registered monitor thread exists or not;

if there are monitor threads registered, the step of checking the running state of each monitor is executed back at preset time intervals.

9. A multi-sensor state management system for use in autopilot, the system comprising:

the configuration reading module is used for reading the vehicle configuration of the user to acquire user configuration information, and mobilizing the corresponding automatic driving platform middleware based on the user requirements;

the first registration module is used for registering a monitor communication thread on the automatic driving platform middleware and registering a CAN monitor thread and a GPS monitor thread based on the monitor communication process;

the second registration module is used for registering a module/hardware monitor thread and a state monitor thread according to the user configuration information;

the state statistics module is used for periodically cycling the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread and counting the current system state and the safe mode state;

And the user operation module is used for sending the current system state and the safety mode state to a user through the visual interface through the automatic driving platform middleware.

10. The multi-sensor state management system for use in autopilot of claim 1 wherein the system further comprises:

the self-checking module is used for carrying out system self-checking on the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread according to a preset time interval;

the self-checking module includes:

the state detection sub-module is used for checking the running state of each monitor and judging whether the visual interface receives a stop instruction issued by a user or not;

the instruction receiving sub-module is used for acquiring a current program time stamp and initializing a module_state and an hw_state if the visual interface does not receive a stop instruction issued by a user;

the reading submodule is used for reading the CAN monitor thread, the GPS monitor thread, the module/hardware monitor thread and the state monitor thread, executing a periodic function of a corresponding monitor and judging whether a registered monitor thread exists or not;

And the circulation submodule is used for controlling the state detection submodule to check the running state of each monitor according to a preset time interval if the registered monitor threads exist.

Images