Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

RapidSense Overview:

RapidSense is a software platform that enables operation of robots within dynamic, unstructured environments. Users select what parts of the platform they wish to leverage to address their needs. RapidSense offers several sensors a user can select from or a generic sensor, if they prefer to use their own vision source. Users define volumes within which RapidSense operates and have the option of specifying additional functionality to perform within those volumes such as object detection or change detection. A volume’s default behavior is to provide dynamic collision avoidance through the scan scene command. The following diagram illustrates RapidSense’s platform architecture.

image-20240308-164757.png

Concept of Operation

Users create volumes in RapidSense by drawing cuboids via the RTR control panel. The volumes can be resized, named, and deleted. Figure 2 illustrates the concept. Users can create filters and assign them to a volume. After assigning a filter to a volume, users can then query the filter in real-time, and modify the filter parameters to suit your application. Multiple filters can be assigned to a single volume, however, a filter instantiation can only be associated to a single volume.

image-20240308-171457.png

Architecture

RapidSense is built on a reactive, high performance architecture, called the actor-design pattern. This architecture is a message passing pattern for distributed, event-based systems. Most filters are implemented as independent actors. The interface to RapidSense is REST-based. As users configure RapidSense the configuration is persisted by RapidSense allowing users to configure a system once and then reuse that same configuration until a change is desired. Figure 3 is a breakdown of the actors comprising RapidSense.

image-20240308-171735.png

Configuration

RapidSense is configured through a pair of configuration files (rapidsense.json and cal.json) both located at /home/user/.config/rapidsense . Users can configure the system through the Control Panel by way of the volumes endpoint. A user of the system creates volumes within which operations take place. As volumes are created in the control panel the configuration files update persisting configuration between invocations of RapidSense. An example of a configuration file and details of the file format follow.

{
  "volumes": [
    {
      "id": integer,
      "bounds": {
        "lower_bound": [xlower, ylower, zlower], // all values represented as doubles, units in meters
        "upper_bound": [xupper, yupper, zupper]  //      "                                   " 
      }
    },
    ...
    "height_filters": [ ... ], // format details found in height filter documentation
    "change_detection_filters": [ ... ] // format details found in change detection filter documentation
  ]
}

Volumes

Volumes are specified as a JSON list. The list contains a description of every volume. The following fields are required:

  • ID - The volume ID as an integer.

  • Bounds - Lower and upper bounds of the volume as (x, y, z) coordinates in the project’s reference frame. All values are in meters as doubles.

Optional Configuration Fields

Users can override the default behavior of the system in a number of ways. The following are the currently supported ways to override behavior.

  • Simulation - To connect to the Unity simulation and use its sensors over hardware devices, users can specify a sensors section in the configuration file. An example of the simulation service running on address localhost at port 6698 follows.

{
  "volumes" : [ ... ],
  "sensors": {
    "external": {
      "discovery": {
        "hostname": "localhost",
        "port": 6698
      }
    }
  }
}

Filters

Filters are created and associated to volumes. Each filter has its own set of configurable parameters that are exposed to users allowing adjustments for specific applications. Every volume can contain multiple filters, however, a filter instantiation may only be tied with a single volume or sensor (in the case of model-based filters). Whenever a filter is created, updated, or deleted, the RapidSense configuration file is updated accordingly saving the user’s progress. This allows users to restart RapidSense and pick back up from where they last left off.

RapidSense currently supports the following set of filters: Height Check and Change Detection.

Height Check Filter

The height filter returns the maximum height within a specified area within a specific volume. The units are all in meters. More details for height filter can be found here.

Change Detection Filter

The change detection filter finds differences between an expected template that the user builds through the filter’s object interface and the actual scene. The change detection filter is not yet a release feature and will be delivered later in '24.

Proxy Connection to RapidPlan

RapidSense provides users a TCP/IP socket interface for command and data exchange. Each category of data is transported over a dedicated connection. The connections and the information are illustrated and detailed below. Work is underway to transition the interface to a REST interface using JSON payloads. These new interfaces are defined in the section REST Interface below the existing interfaces.

  • No labels