MAPS interface

The Anemos MAPS position sensor device is equipped with multiple control modes and output interfaces.

Interfaces

There are multiple interfaces, some for convenience functionality and some for production usage.

Currently all the interfaces include connecting to the device over LAN using one of two standard ways.

Reaching the device over ethernet connection.

Each MAPS device is supplied with an ethernet connector. If you connect your device to your local subnet, it will attempt to obtain an IPv4 address as a DHCP client. After a successfull connection and setup you can reach the device using it's ip address via it's MAPS interface:Graphical Interface

Graphical interface

All the MAPS devices are equipped by a web-based interface. The interface can be reached by typing the ip address of the device into a browser, and opening the control webpage. Depending on customer requests and the version of the MAPS device, the dive might require login information that is supplied with the device.

The main purpose of the web-based interface is setting up the device and tracking it's status.

On activation, the interface shows information about the sensor including:

• Position output,
• A surface for browsing previous output logs of the device,
• Configuration parameters of the device,
• Tools for fine-tuning the mechanical setup of the device,
• Debug information.

In a typical use case, the graphical interface is used in short periods of time, setting up, and checking the device.

Websocket interface

For long term usage and integration with the system of the customer, one can use the network interface.

The network interface is using the websocket protocol for communication. Depending on the control mode, each device opens listens websocket connection open on one or more ports set in the settings of the file.

Control modes

The MAPS device is equipped with multiple control application and sensor control modes. control modes effect the way the device communicates with connected infrastructure and the way the sensor is triggered.

A brief summary of currently available control modes is available below. For further details of the control modes, please refer to the product manual supplied with the product.

The details of the control mode is set by the internal configuration fin the device, that is supplied by Anemos.

Custom control modes can be implemented on customer request for additional fees. Our support and sales teams can help with the details.

Connection modes

The conection modes determine the communication with the device while it is active and running. The device has two basic communication modes: standalone, and websocket. Note, that the web-based graphical interface is still active in both modes enabling the user to monitor the device.

Standalone mode

In standalone mode the device is starting to gather data on startup, and continues producing position data until power off. In this control mode the output of the device is an internal or external storage (e.g.: usb drive), that can store data for later use.

Standalone mode is suitable for off site, offline data gathering, where the data is produced without management, and evaluated later.

Note, that this control mode can only be used with a limited types of sensor controls as some of the sensor modes require active management of the device.

Websocket mode

In websocket mode, the device opens one or more websocket ports that enables connections from the network. The websocket communication then can be used for two purposes. Sending control commands to the device, and receiving position data from the device.

The standard format of communication is sending and receiving strings containing Json messages. This way, the communication is structured, and versatile.

Sensor trigger modes

Sensor trigger modes determine how producing a position data is triggered in the device.

When triggered, the device has to perform two tasks before it can produce output.

1. Capture phase: The position determination is based on processing the image of a camera sensor looking at a grid pattern .Therefore, the device first has to capture an image frame.
2. Data processing phase: After the image is captured, the device processes the data using our patented algorithms to produce the projection data.

The capturing phase usually takes between 33 milliseconds and 10 seconds to complete, based on the device settings. Higher accuracy usually needs a longer capture phase (for details on accuracy and performance see MAPS performance). After capture, the frames arrive into a buffer where they are stored until they are processed.

Data processing takes place in our MAPS compute device, and takes between 0.1 to 1 second to compute. The speed of processing strongly relies on the captured data, therefore there is again a trade-off between speed and accuracy (for more details see, again, MAPS performance).

Based on the definition above, the sensor trigger modes are as follows.

Free-run mode

In "free-run mode" the capture phase of the device is in a infinite loop endlessly producing new data filling the buffers. Furthermore, the data processing phase is also in a loop processing a frame and taking the next one whenever it's ready. The data processing is always using the latest complete frame in the captures output queue, therefore the latency is always less then the time of capturing one frame. In this mode, the overall framerate of the system is equals to the slower one of the capture and data processing phases. As usually the data processing phase has a lower rate than the capturing therefore, the final framerate is usually corresponds to the time of processing one frame, but timing considerations can be included by configuring the device.

In this mode accurate timing of frames is not possible, as we do not have control over the device during run-time.

Free-run is the only mode of the MAPS sensor in Standalone mode, since this mode does not need any outside control. In Websocket + free-run mode the device is continuously broadcasting position data from the connected clients.

Software trigger mode

Software trigger mode corresponds to the mode of the device, when triggering a measurement is done on the websocket connection. In this mode, the frame capture is initiated by a control command on the open connection. The control command is a JSON string of the form:

{command: "trigger"}

The result is usually a set of position data also in JSON format like:

{
    pre: "trigger",
    msg: "ack",
    type: "data",
    data: "[00001234], 0.01880000721, 0.064851435995, 0.002141690211, -0.000887731, 0.000075537, -0.000707648, 0, 0, 0, 0, 0, Output Good"
    time: "2022-11-25 16:30:14.056392"
}

Where:

• pre: is the command the respond corresponds to
• msg: is an overall message informing about the result (can be general information or error message)
• type: is the type of the payload
• data: is the "payload", i.e., position data.
• time: is the timestamp the message was generated to the microsecond.

In software trigger mode the result of the message is usually a position data, therefore the answer has to wait for the capture and the processing it as well. Starting parallel queries by sending multiple "trigger" commands is depreclated as it may lead to errors in the resulted data.

The timing accuracy of the capture in this case is roughly 33 milliseconds or the latency of the network communication.

Hardware trigger mode

Hardware trigger mode is for highly accurate timing of the capture. In this mode the camera sensor is set up in an idle state waiting for a hardware driven trigger. The trigger is an electric pulse sent on a physical connection, connected to the device (details can be found attached to the manual attached to the device).

Hardware trigger mode can be regarded as a combination of software trigger and standalone modes. The trigger is coming from an outside source, and after processing data, the device broadcasts the results to each of the subscribers connected to the websocket connection.

In this case the capture phase is always 33 milliseconds, therefore triggering again within that time is not possible. Also, if the device is triggered faster, then it can process the captures, then a buffer is filled queue-ing the captured data. If the buffer is full (for size of the buffer consult manual of the device), and a new capture is triggered, then the latest frame in the queue will be thrown away (i.e., data loss can occur).

The hardware trigger mode is also equipped with a software trigger feature triggering the capture internally by sending a command on the websocket connection. Although, du to network latency this method is less accurate, than sending an electric pulse. When triggering by pulse, timing accuracy is sub-milisecond.