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 3 Next »

  • Interfaces that are available for customers to use with RapidSense

  • External cameras currently supported

  • Functionality available

  • Limitations

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.

Concept of Operation

Users create volumes in RapidSense by drawing cuboids via the control panel. The volumes can be dragged around, resized, named, and deleted. Figure 1 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, then modify the filter parameters to suit their application. Multiple filters can be assigned to a single volume, however, a filter instantiation can only be associated to a single volume.

Figure 2 - RapidSense Volumes

Architecture

RapidSense is designed and implemented around the actor-design pattern. The actor pattern 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 2 is a breakdown of the actors comprising RapidSense.

Figure 3 - Internal Bird’s-Eye-VIew

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 either manually by hand or 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) 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 Filter or Height Check

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. More details for change detection can be found here.

Attached Parts Configuration

Attached parts are

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