MRS Estimator using LIO-SAM in Real UAV.

[cappizzino]

Hi, there!

I am using "liosam", with "mrs_liosam_core" and "mrs_liosam_estimator_plugin", in order to estimate the UAV's position, following the same ideas applied to LOAM estimator. Thus, some doubts have arisen related to how the estimator manager works. I would like to ask some questions:

1. How does the MRS estimator choose or fuse to have the best state hypotheses?
2. We understand that the main purpose of the MRS estimator is to produce a estimate in the form required by the control pipeline. Nevertheless, if I want to force a choice, how to do that?

@petrlmat , since you had more participation in the lio-sam implementation, could you please help me?

Best regards,
Carlos Pizzino

[petrlmat]

Hi, the estimation manager runs an individual estimator for each localization source and switches between them based on some estimator health metrics. The manager is customizable by the custom_config.yaml located in the tmux session. If you want to see all parameters, you can call rosrun mrs_uav_core get_public_params.py. The most relevant part is:

mrs_uav_managers:

  estimation_manager:

    # loaded state estimator plugins
    # available in mrs_uav_state_estimators: gps_garmin, gps_baro, rtk, ground_truth, dummy
    state_estimators: [
    "gps_garmin",
    "gps_baro",
    "liosam"
    ]

    initial_state_estimator: "liosam" # will be used as the first state estimator
    agl_height_estimator: "" # only slightly filtered height for checking min height (not used in control feedback)

1. The estimation manager publishes the state estimate for the control pipeline from the estimator that is specified as initial: initial_state_estimator: "liosam" # will be used as the first state estimator. If the estimator becomes unhealthy, the estimation manager will automatically switch to the first healthy estimator in the state_estimators list. If there is no healthy estimator available, the UAV will go into failsafe and gradually decrease thrust while keeping zero tilt angles.
2. If you want to force a choice, you can change the initial_state_estimator before running the tmux script. You can also switch into a healthy estimator during a flight by calling the service: rosservice call /$UAV_NAME/estimation_manager/change_estimator "liosam".

I hope this answers your question and if not, please ask for more advice.

Be careful while testing LIO-SAM with a real UAV. So far, we have used it only in simulation and on rosbags but not in feedback of a real UAV.

[cappizzino]

Hi @petrlmat,

I really appreciate your explanation. It was very clear and helpful.

I would like to get a deeper understanding of how the estimation manager automatically switches between estimators. I implemented "gps_garmin" with "liosam", and I expected the estimator manager to switch estimators when the GPS signal was lost, but it did not. The covariances of the "gps_garmin" estimator remained low even when it lost GPS, and the tf "world_origin" was lost. How can I monitor the health of the estimator and how to configure it?

Thank you for the heads up. Later, I can report my experience with liosam estimator in a real UAV.

[petrlmat]

The estimation_manager switches to another estimator when the measurement messages do not arrive for a set amount of time (0.5s default). If the GPS signal is lost but the measurements are still coming to the estimator then it won't switch. Another condition for triggering the estimator switch is the innovation gate. If the innovation (difference of measurement and current state) is above some threshold, it triggers a switch. By default, this innovation-based switch is not enabled though. You can enable it by this parameter:

mrs_uav_managers:
  estimation_manager:
    gps_garmin: # namespace of the state estimator
      lat_gps: # namespace of the lateral estimator
        innovation:
          limit: 1.0 # [m] innovation limit that will trigger action
          action: "switch" # {"eland", "switch", "mitigate"}

However, these health-checking conditions are very basic and if it doesn't work with your setup, I recommend implementing your own estimator arbiter node, which can check other properties of the GPS (e.g. number of satellites, hdop, covariance, etc.) and switch the estimator by calling the change_estimator service.

[cappizzino]

Once again, I appreciate your clarifying message and suggestion. After your response, more questions have arisen.

My first question is related to the package mrs_uav_deployment and the configuration file tmux/just_flying_aloam_octomap/config/custom_config.yaml. In this case, when you set aloam only, and the action of innovation is set to switch, what is the system's behavior? I mean, which estimator will it switch to?

The second question is about transitioning from an external environment to an internal one. If you start to move your UAV using GPS signal, for example using gps_garmin estimator and your UAV flies toward a building, at this moment, the estimator manager might switch to another estimator, so the configuration has to be like that, right?

mrs_uav_managers:
  estimation_manager:
    state_estimators: [
    "gps_garmin",
    "aloam"
    ]

So, if we enable the GPS function using LIO-SAM, it doesn't make sense to simply replace aloam with liosam for me. In this case, do we have to configure like that?

mrs_uav_managers:
  estimation_manager:
    state_estimators: [
    "liosam"
    ]

This scenario is equivalent to the drone has to fly below the treetops, for instance. How should I configure the estimator?

The last question is related to indoor estimator, i.e., location where the GPS signals are not available at all. What would be the starting configuration? Hector Slam (2D?) or A-LOAM or simply px4 estimator (I don't know how to set this estimator) ?

Apologies for the long message, but I truly value your framework and am enthusiastic about expanding my knowledge further.

[petrlmat]

My first question is related to the package mrs_uav_deployment and the configuration file tmux/just_flying_aloam_octomap/config/custom_config.yaml. In this case, when you set aloam only, and the action of innovation is set to switch, what is the system's behavior? I mean, which estimator will it switch to?

If there is no healthy estimator available, the UAV will go into failsafe and gradually decrease thrust while keeping zero tilt angles.

The second question is about transitioning from an external environment to an internal one. If you start to move your UAV using GPS signal, for example using gps_garmin estimator and your UAV flies toward a building, at this moment, the estimator manager might switch to another estimator, so the configuration has to be like that, right?

Yes, that is the correct configuration that allows switching between GPS and ALOAM.

So, if we enable the GPS function using LIO-SAM, it doesn't make sense to simply replace aloam with liosam for me. In this case, do we have to configure like that?

If you fuse the GPS measurements directly in LIOSAM then you can use this configuration. I have no experience with LiDAR + GPS fusion in LIOSAM, so I cannot give you any advice in that regard. Beware, that if LIOSAM estimation breaks, there won't be any other estimator available that the estimation manager could switch to. I think that leaving the gps_garmin or gps_baro estimators as active would be safer in case LIOSAM breaks during outdoor flight.

The last question is related to indoor estimator, i.e., location where the GPS signals are not available at all. What would be the starting configuration? Hector Slam (2D?) or A-LOAM or simply px4 estimator (I don't know how to set this estimator) ?

ALOAM is currently our go-to estimator for indoor flights. Hector SLAM can work reasonably well in structured environments (rooms with straight walls, corridors, forests with tree trunks) but needs an additional sensor for z-axis estimation (garmin, barometer, etc.). SLAMs based on 3D LiDARs are much more robust in all environments, allow more dynamic flights (tilting of the 2D LiDAR increases the chance of SLAM failure), and also allow easier navigation (mapping, planning)) thanks to vertical FoV.

[cappizzino]

Thanks for your help @petrlmat