Use ALOAM and Octomap in simulation

[lidiaxp]

I am trying to use ALOAM as the estimator and octomap for mapping the environment.

In session.yml, I added:

- slam:
      layout: tiled
      panes:
        - waitForRos; roslaunch mrs_aloam_core slam_pipeline.launch OUSTER_TYPE:=OS0-128
  - mapplan:
      layout: tiled
      panes:
        - waitForRos; roslaunch mrs_octomap_mapping_planning mapplan.launch
          config_octomap_server:=./config/octomap_server.yaml
          config_octomap_planner:=./config/octomap_planner.yaml
          config_pcl_filter_ouster:=./config/ouster_filter_mapping.yaml
          config_pcl_filter_rs_front:=./config/rs_front_filter.yaml
          config_pcl_filter_rs_down:=./config/rs_down_filter.yaml

It works perfectly with gps_baro as the estimator; I can see the map from slam and octomap. However, when I change the custom configuration to use ALOAM as the estimator:

custom_config:=rospack find mrs_aloam_estimator_plugin/custom_configs/mrs_uav_managers.yaml

I cannot see the map generated from octomap anymore.

This is my default custom_config where ALOAM and octomap seem to be working:

mrs_uav_managers:

  constraint_manager:
    default_constraints:
        gps_garmin: "fast"
        gps_baro: "fast"

  estimation_manager:

    # loaded state estimator plugins
    state_estimators: [
      "gps_garmin",
      "gps_baro",
    ]

    initial_state_estimator: "gps_baro" 
    agl_height_estimator: "garmin_agl"

  uav_manager:

    takeoff:
      during_takeoff:
        controller: "MpcController"
        tracker: "LandoffTracker"

      after_takeoff:
        controller: "MpcController"
        tracker: "MpcTracker"

II could not identify what could be wrong since only the estimator is being modified. Do you know what could be wrong? I am trying to do it in the simulation.

I am using these sensors in the simulation:
waitForGazebo; rosservice call /mrs_drone_spawner/spawn "1 $UAV_TYPE --enable-realsense-front --enable-rangefinder --use-gpu-ray --enable-ground-truth --enable-ouster model:=OS0-128 horizontal_samples:=1024 use_gpu:=True --pos -5 0 0 0"

The topic I am checking for the octomap is /uav1/octomap_global_vis/occupied_cells_vis_array.

[lidiaxp]

Sorry, I forgot to check the TF tree. The Octomap launch was using world_origin as the world_frame, but ALOAM uses local_origin by default. I changed the world_frame to local_origin in the mapplan.launch file, and now it is working perfectly. Thank you very much.

[lidiaxp]

We’re actually using the OS0-128 both in simulation and in real world. I haven’t encountered any timeout issues so far, so maybe it could be related to computational limitations on your setup? Just a guess, as I haven’t seen that behavior myself.

We’re not using ALOAM anymore, but that’s mainly because our environment lacks features, and ALOAM was struggling to handle it well. Right now, we’re testing EKF SLAM and integrating it into the MRS stack via the passthrough localization.

I haven’t explored it in depth yet, but for environments rich in features, I still believe ALOAM is one of the best lightweight options available.

Regarding re-localization: I’m not sure if ALOAM itself supports it natively (or MRS). From my experience, in the MRS system if ALOAM loses odometry, the MRS system triggers emergency landing. But you can set up your own re-localization pipeline by integrating additional estimators (Garmin, GPS-Baro, etc.) and feeding them as the main localization source (estimation_manager/odom_main) via the passthrough.

As for ALOAM's documentation, they mainly refer to their paper, but you can find everything they made public in this repo.

[migsdigs]

Thanks so much @lidiaxp! This is all very helpful for my development. Out of curiosity, is there a reason why you're integrating EKF-SLAM into the MRS stack via the passthrough localization instead of creating a plugin for it?

[lidiaxp]

No special reason, only because (for me) it is easier to implement and quicker to make modifications.

[migsdigs]

Hi again @lidiaxp

Apologies for coming back to this thread and bugging you again. I was wondering if you had attempted using any VIO algorithms for state estimation on your drone, or using any RGB-D cameras (something like OAK-D), rather than using LIO algorithms?

Again, thank you very much

[lidiaxp]

Hi, unfortunately no. I’ve only used RealSense for object identification, not specifically for state estimation