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.

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 multiple informations about the sensor including:

• Position output,
• A surface for browsing previous ouptut 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 protocoll 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 eqquipped with multiple control application and sensor control modes. control modes effect the way the device communicates with connected infrastructer and the way the sensor is triggered.

A brief summary of currently awailable 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 temas 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 graphival 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 stratup, 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 dta 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 sensorm 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 natwork. 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 string embeding 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 taks 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 dta using our Paternted algorithms to produce the projection data.

The capturing phase usually takes between 33 miliseconds 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 porcessing strongrly relies on the captured data, therefore there is again a tradeoff between speed and accuracy (for more details see, again, MAPS performance).

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

Freerun mode

In "freerun mode" the capture phase of the device is in a infinate 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 famerate of tr system is equals to the slower one of the capture and data processing phases. As usually the data proseccing phase has a lower rate than the capturing therefore, the finall frameta is usually corresponds to the time of processing one frame, but timing consideratins can be included by configuring the device.

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

Freerun is the only mode of the MAPS sensor in Standalone mode, since this mode does not need any outside control. In Websocket+freerun 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 ths 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 captura and the pricessing it as well. Starting paralell queries by sending multiple "trigger" commands is depleclated as it may lead to errors in the resulted data.

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

Hardware trigger mode

Hardware trigger mode is for higly 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 phisical connection, connected to the device (details can be found atached 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 miliseconds, 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 occure).

The hardware trigger mode is also equiped with a software strigger 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, timign accuracy is sub-milisecond.