BACKGROUND

Real-time computing systems such as robotic systems (e.g., autonomous vehicles) need to be responsive. Such systems have a set of deadlines, and missing a deadline is considered either a system failure and/or degrades the quality of service. In such systems, a delay of less than a millisecond in the system can, in some situations, cause a failure. Many applications of real-time computing are also low-latency applications (e.g., autonomous vehicles must be reactive to sudden changes in the environment). Moreover, a robotic system such as an autonomous vehicle performs several successive operations on sensor data with the output of one operation used as the input of another operation (e.g., pipeline stages). As such, real-time computer systems and applications often require low latency. Therefore, for a system design to meet the needs of such robotic systems, the core software and hardware components must not interfere with the requirements of real-time computing.

The design and organization of such complex robotic systems traditionally requires laborious trial-and-error processes to ensure both hardware and software components are correctly connected with the resources necessary for computation. Optimizing system properties such as latency often becomes intractable due to the number of components involved (compute hardware, communication networks, communication protocols, software allocation, etc.). Current approaches for optimizing system performance primarily address resource allocation issues (e.g. memory usage, bandwidth utilization), but not latency. However, as discussed above, latency is a critical factor in optimizing system performance for real time systems for improving system performance and hitting important safety goals such as ensuring system reaction times are sufficient.

This document describes methods and systems that are directed to addressing the problems described above, and/or other issues.

SUMMARY

In various scenarios, systems and methods for designing a robotic system architecture are disclosed. The systems may include a processor and non-transitory computer readable medium including programming instructions that can be executed by the processor to perform the methods of this disclosure. The system may define a software graph and a hardware graph. The software graph may include a first plurality of nodes representing discrete computational tasks, and a first plurality of edges representative of data flow between the first plurality of tasks. The hardware graph may include a second plurality of nodes representing hardware components of a robotic device, and a second plurality of edges representative of communication links between the second plurality of nodes. The system may map the software graph to the hardware graph by assigning each of the first plurality of nodes to one of the second plurality of nodes and each of the first plurality of edges to one or more of the second plurality of edges. For the mapping, the system may then model a latency associated with a computational path included in the software graph, and allocate (based on the latency) a plurality of computational tasks in the computational path to a plurality of the hardware components to yield a robotic system architecture. The system may use the robotic system architecture to configure the robotic device to be capable of performing functions corresponding to the software graph. Optionally, the software graph may be a multigraph and the hardware graph may be a pseudograph.

In various implementations, the system may also update the mapping of the software graph to the hardware graph by defining an objective function comprising a first cost of assigning a discrete computational task to a hardware component and a second cost of assigning a data flow to a communication link. Optionally, the system may minimize the objective function using a plurality of constraints, the plurality of constraints comprising at least one of the following: an atomicity constraint, a bandwidth constraint, a resource constraint, or a flow constraint. Additionally and/or alternatively, the system may minimize the objective function using the latency associated with the computational path included in the software multigraph.

In certain implementations, the system may model a system latency across all computational paths included in the robotic system, and then generate the robotic system architecture by allocating a plurality of computational tasks across all computations paths included in the robotic system to a plurality of hardware components for improving the performance of the robotic system architecture using the system latency.

In some implementations, the latency may be modeled as a function of a first latency introduced by the hardware components and a second latency introduced by the communication links. The second latency for a communication link may be modeled as a function of, for example, a number of messages currently assigned to that communication link, a average size of the currently assigned messages, a standard deviation of sizes of the currently assigned messages, a number of messages an additional communications link will add, and/or a size of the currently assigned messages. The first latency for a hardware component may be modeled as a function of input and output message timings from that hardware component. Optionally, one or more parameters for modeling the first latency may be determined based on checkpoint data corresponding to the robotic device.

The system may, in certain implementations, in the software graph: associate a type and an amount of resources required to execute a task associated with that node with each of the first plurality of nodes, and associate an amount of required bandwidth with each of the first plurality of edges. Additionally and/or alternatively, the system may in the hardware graph associate a type and an amount of resources provided by that node with each of the second plurality of nodes, and associating an amount of available bandwidth with each of the second plurality of edges.

