MAPS 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 connection 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.
- 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 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 frame rate 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 frame rate 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, due to network latency this method is less accurate, than sending an electric pulse. When triggering by pulse, timing accuracy is sub-millisecond.
