AMCL: Assertion 'cidx >= 0' failed

[mfe7]

I'm using AMCL on Ubuntu 16.04 with Kinetic. The error that often comes up is:
amcl: .../amcl/src/amcl/pf/pf.c:525: pf_cluster_stats: Assertion cidx >= 0' failed.`

This sometimes occurs after I send a new initialpose estimate after driving for a few seconds, but I haven't yet found a consistent procedure that causes it to happen.

I have tried building from source and downloading the package with apt, and see the same behavior both ways. I didn't see this error on my robot with Ubuntu 14.04 with Indigo, but I also have changed the type of laserscanner.

Looking at the source code, this error seems to mean there are no particles - any suggestions of where to look for the cause?

[mfe7]

I built from source with the indigo-devel branch and haven't seen the error (still on 16.04)

[mikeferguson]

Given that new info, there are only two possibly relevant commits in Kinetic that were not in indigo:

• 65261a8#diff-f9c8b2ff23a212af56d0b3de46fcf48b
• 232cfd2#diff-f9c8b2ff23a212af56d0b3de46fcf48b

If I had to guess, I'd think it was the latter? Perhaps try reverting that commit on the kinetic-devel branch and see if your problem goes away? If so, we can look deeper into why / how to fix it.

[tutorgaming]

I also have this issue. (ros-kinetic) when trying to set the initial pose from rviz, amcl always crashed.

[SteveMacenski]

I have also experienced this issue. I see it happen when using robot_localization frequently but for some reason doesn't rear its head using robot_pose_ekf or not that I'm able to notice in terms of a crash.

[DLu]

@tutorgaming @SteveMacenski If you can provide replicable steps, it will be easier to debug.

[SteveMacenski]

I'm generally unable to trigger it on demand. We don't recall seeing this issue in Indigo either.

I agree the second commit is probably the issue. I would test to see if reverting that resolves the issue but the behavior is sporadic for me. I'll have to wait until next time it comes up to test. If @tutorgaming could test if it happens more consistently in your application, that would be awesome.

[JinglinZhang]

This issue happens more frequently when set a new pose in the kinetic version. Maybe there's no need to assert cidx >= 0 in line 525 in pf.c.

[SteveMacenski]

I'm not sure that's the most robust answer. From diff 232cfd2#diff-f9c8b2ff23a212af56d0b3de46fcf48b I don't think that situation needs pf_cluster_stats. Can someone explain why that was needed or if we can revert that?

I have been running a fork of AMCL with that commit commented out for about 2 weeks now and I haven't seen the issue in that time. I think it would be good @DLu @mikeferguson to revert this if you agree.

[chungying]

Hi @SteveMacenski, pf_kdtree_cluster clusters all samples into several groups to represent multiple hypotheses of robot poses, where a cluster of samples is a hypothesis of a robot pose. pf_cluster_stats is needed to calculate sum of weights, mean and covariance of each hypothesis. The cluster with the highest sum of sample weights is the most likely robot pose, and the mean and covariance is published as the robot pose in AmclNode::laserReceived(). This is the reason why pf_cluster_stats is needed.

Speaking to the assertion error cidx>=0, the error means a sample in a set is not found in the set's kdtree. However, the sample pose should be found in the kdtree. I think this error occurs after the Gaussian-distributed samples of the initial pose couldn't be inserted correctly into the set's kdtree or after pf_kdtree_cluster doesn't work well.

[SteveMacenski]

I'm not questioning the need for it in general, it is called elsewhere in the program, my mistake for being non-specific. This was added in the condition when force_publication = true and resampled = false. If we haven't resampled, why would we need to cluster again?

I've been working fine for 2 weeks removing that recent commit. Before, I hardly went a couple days without seeing it.

[chungying]

Sorry for misunderstanding. However, I think we still need to cluster again because there is a possibility that two moving clusters of hypotheses overlap after odom_->UpdateAction.

[SteveMacenski]

Hope everyone had a good holiday-
I've run with this for now 3 weeks. I don't disagree that it could be good but I believe that I have isolated it to this commit.

Can we revert it?

[DLu]

I think so. Please open a PR.

[SteveMacenski]

PR #666 resolves (I hear that number is good luck in some... particular circles)

[boilerbots]

Great to see this got resolved, when will we see it built and pushed out to kinetic, I updated 2/22/2018 and it is still bad.

[SteveMacenski]

That's a question for @DLu and @mikeferguson

For now, you can use my branch for a solution

[mikeferguson]

I'll have to check with @DLu on if we need to get anything else merged (I do know we need to update a few maintainer emails before release), but I can do a release in the next few days.

[SteveMacenski]

Awesome.

[SteveMacenski]

Any movement here?

[mikeferguson]

Apologies on that -- when I commented on this issue, I thought it was already reviewed & merged. That was not the case.

I have a thumbs-up to do a release. I had spent a few minutes to see if there was a more elegant fix than just removing those lines (since the original PR fixes one edge condition error). I had not found a better fix and ended up running out of time that day.

I'm currently in the middle of moving, if there's no other comments on that PR by Monday, I'll merge and release then.

[mikeferguson]

merged into kinetic, ported to lunar (still to be merged). releases shortly.

[SteveMacenski]

Thanks Fergs

Apparently I can't close this issue, do you mind?

[mikeferguson]

Now released to Kinetic: ros/rosdistro#17159

[SteveMacenski]

Thanks everyone!