Users Manual

The pose estimate of the SLAM component will be initialized with the current estimate of the stereo INS - and
thus the origin will be where the stereo INS was started.
Since the SLAM component builds on the motion estimates of the stereo INS component, the latter will automat-
ically be started up if it is not yet running when SLAM is started.
When the SLAM component is running, the corrected pose estimates will be available via the datastreams pose,
pose_rt, and dynamics of the rc_dynamics component.
The full trajectory is available through the service get
_
trajectory, see Services (Section 7.1.4) below for details.
To store the feature map on the rc_visard, the SLAM component provides the service save
_
map, which can be
used only during runtime (state “RUNNING”) or after stopping (state “HALTED”). A stored map can be loaded
before startup using the service load
_
map, which is only applicable in state “IDLE” (use the reset service to go
back to “IDLE” when SLAM is in state “HALTED”).
Note that mistaken localization at (visually) similar places may happen more easily when initially localizing in
a loaded map than when localizing during continuous operation. Choosing a starting point with a unique visual
appearance avoids this problem.
The SLAM component will therefore assume that the rc_visard is started in the rough vincinity (a few meters)
of the origin of the map. The origin of the map is where the Stereo INS module was started when the map was
recorded.
7.1.2 Memory limitations
In contrast to the other software components running on the rc_visard, the SLAM component needs to accumulate
data over time, e.g., motion measurements and image features. Further, the optimization of the trajectory requires
substantial amounts of memory, particularly when closing large loops. Therefore the memory requirements of the
SLAM component increase over time.
Given the memory limitations of the hardware, the SLAM component needs to reduce its own memory footprint
when running continuously. When the available memory runs low, the SLAM component will fix parts of the
trajectory, i.e. no further optimization will be done on these parts. A minimum of 10 minutes of the trajectory will
be kept unfixed at all times.
When the available memory runs low despite the above measures, two options are available. The first option is
that the SLAM component automatically goes to the HALTED state, where it stops processing, but the trajectory
(up to the stopping time) is still available. This is the default behavior.
The second option is to keep running until the memory is exhausted. In that case, the SLAM component will be
restarted. If the autorecovery parameter is set to true, the SLAM component will recover its previous position
and resume mapping. Otherwise it will go to FATAL state, requiring to be restarted via the rc_dynamics interface
(see Services, Section 6.3.3).
The operation time until the memory limit is reached is strongly dependent on the trajectory of the sensor.
Warning: Because of the memory limitations, it is not recommended to run SLAM at the same time as Stereo
matching in full resolution, because the memory available to SLAM will be greatly reduced. In the worst case,
a long running SLAM process may even be forcefully reset, when full-resolution stereo matching is turned on.
7.1.3 Parameters
The SLAM component is called rc
_
slam in the REST-API. The user can change the SLAM parameters using the
REST-API interface.
Parameter overview
This component offers the following run-time parameters.
7.1. SLAM 68