MAPS interface
The Anemos MAPS position sesnsor device is equipped with multiple controll 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 controll webpage. Depending on custommer 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 controll application and sensor controll modes. Controll modes effect the way the device communicates with connected infrastructer and the way the sensor is triggered.
A brief summary of currently awailable controll modes is available below. For further details of the controll modes, please refer to the product manual supplied with the product.
The details of the controll mode is set by the internal configuration fin the device, that is supplied by Anemos.
Custom controll modes can be implemented on custommer 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 controll 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 controll mode can only be used with a limited types of sensor controlls 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 controll 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.
- 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.
- 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 controll 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 controll.
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 controll command on the open connection. The controll 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 typmestamp the message was generated to the microsecond.
