Your SICK ID gives you access to our extensive range of services. This includes direct online orders, price and availability checks, and access to our digital services.
Information regarding Triton diagnostics (errors, warnings, information messages, active modes) and HMI LEDs.
Related Products
Triton Floor-LOC
TLOC100-100 TRITON FLOOR LOCALIZ. SYSTEM
TLOC100-100
Table of Contents
1. Intended use
Triton Diagnostics gives the user information about which modes are active, and if there are warnings or errors. This article explains how to get the Triton Diagnostics message (ROS, ROS2, C++ API), how to read the Diagnostics message and introduces the various warnings and errors,
⚠️
Diagnostics should not be considered a health monitor.
Warnings will not automatically indicate something is wrong with the sensor/setup.
It should be used as a diagnostic. That means; if something is wrong,
you can use these to identify a probable cause.
~/accerionsdk/build/bin$ ./AccerionCLI 192.168.0.173 get diagnostics
GUI
See Diagnostics tab
3. How to read the Diagnostics message
This section provides information on how to interpret the diagnostics messages. The tables with the mapping from integer value to mode/error/warning are derived from the diagnostics.h header file in the API.
3.1. From integer values to modes, warnings, errors and statuses
Although the ROS message and CLI provide strings describing modes, warnings, errors
and statuses, the API and UDP protocol uses single integers to describe them.
We will now explain how to retrieve the information from each specific
mode/warning/error/status from that single integer.
Example 1: Active modes based on integer
As an example we will take the Modes field, but the same approach applies to the
other fields. Suppose we read that the ‘modes’ integer has value 136:
...
modes_code: 136
...
For ROS and C++ users first we go from decimal to binary representation
(UDP users need to translate the hexadecimal value to binary representation):
modes = 136 = 00000000 10001000₂
This means bits at position 7 and 3 are set (read from right to left,
bit starts from 0). Using the table in Section 3.2. Modes,
we can see that the following modes are active:
Bit 7 → "line following"
Bit 3 → "localization"
Example 2: Active warnings based on integer
The same principle holds for warnings and errors. For example, if we read that the
‘warnings’ integer has value 32:
...
warnings_code: 32
...
Which in binary representation is:
warnings = 32 = 00000000 00100000₂
From this we read that bit 5 is set. As we see in
Section 3.3. Warnings, this corresponds to “Low Brightness Cam”.
In the next sections we will learn what these modes, warnings, errors
and statuses mean.
3.2. Modes
Bit
Name
Description
0
idle
Reduces power consumption to <6W.
1
mapping
Triton turns images into signatures and stores them in its database with external reference pose.
2
internal
Let Triton combine corrections and its own odometry. External reference is ignored.
3
localization
Triton actively tries to match the camera images against the floor map.
4
recording raw data
Record a raw video (for debugging purposes)
5
aruco marker detection
Allow to detect Aruco markers.
6
expert
Allows the user to have mode localization and mapping mode enabled.
7
line following
Line following mode provides the closest point to the selected cluster.
8
buffered pose recovery
Buffered recovery mode is searching for a match.
9
continuous signature updating
Signature descriptions are updated if changes are detected.
10
multi code detection
Not supported.
11
clock syncing
Messages contain the Triton system time as timestamp.
(12 t/m 15 not in use)
3.3. Errors
Bit
Name
Description/root cause(s)
Possible Resolution(s)
0
License error
→
Contact SICK.
1
No SD card error
→
Contact SICK.
2
SD card not mounted error
→
Contact SICK.
3
Kernel patch error
→
Contact SICK.
4
Corrupted map error
Map got corrupted during map transfer,
or the map sent to Triton was corrupt.
Reboot the Triton. If problem persists,
contact SICK.
5
Camera error
→
Contact SICK.
(6 to 15 not in use)
3.4. Warnings
Bit
Name
Description / root cause(s)
Possible Resolution(s)
0
Too Fast For Mapping
The sensor is moving too fast to keep up, which may result in gaps in the map.
Drive slower.
1
Low Memory
Thrown when the free/available RAM memory is lower than 10%. This is mostly caused by large maps being loaded, but can have other causes.
This warning does not necessarily indicate something is wrong. One should only contact SICK about this if the actual performance of the sensor is subpar.
2
Low Brightness Cam
Thrown when camera detects a frame where the brightness is too low.
This warning is only a reason of concern if you receive it continuously.
Even then it does not indicate that the system is not working.
Only when the frame that was supposed to detect a match or the few frames in front of that are too low in brightness, this can cause the system to perform worse.
3
High Brightness Cam
Thrown when camera detects a frame where the brightness is too high.
This warning is only a reason of concern if you receive it continuously.
Even then it does not indicate that the system is not working.
Only when the frame that was supposed to detect a match or the few frames in front of that are too high in brightness, this can cause the system to perform worse.
4
Tracking Failed
Thrown when the sensor could not perform relative tracking between two frames.
This warning is no direct reason for concern, unless it is observed frequently.
It can be caused by artifacts on the floor (paint, tape, ..) or too high speeds.
5
Infrequent or no external reference input
User provides no external reference, or at a frequency lower than 5Hz (for Internal Mode disabled only).
Provide an external reference to Triton Floor-LOC with sufficiently high frequency.
6
Large time offset
Offset between ntp server and Triton clock is too large (for clock syncing enabled only).
This warning might appear briefly when enabling clock syncing, but should not persist.
If you receive this warning continuously, it is a sign that the Triton is not syncing to the ntp server properly.
(7 to 15 not in use)
4. Triton’s HMI Status LED’s explained
Triton has human-machine interface (HMI) LED's which provide the status of the sensor:
Color
LED
Description
Solid purple
No mode active
Solid blue
Mapping mode active
Solid green
Localization mode active
White (intermittent)
Triton recognized floor, drift correction sent
Short purple blink
Idle mode active
Solid red
Error
Solid yellow
Triton is booting / no software running
Keywords: Triton, Floor-LOC, diagnostics, HMI LEDs, warnings, errors, active modes
