Oddly consistent offset

[MoffKalast]

Another thing seen by a client, it seems that in some cases the robot follows goals with a constant offset of sorts. It's likely this is related to lidar position calibration, but it could also be related to not fetching the robot's position often enough, the transform request failing or something similar. Again, perhaps worth a closer look.

[dorkamotorka]

The frequency of fetching robot position is 20Hz. Which is I think also the localization frequency using map? Correct me if I am wrong. What kind of offset are they experiencing? Linear or Lateral offset or is robot driving with a constant orientation error?

[MoffKalast]

Yeah that's my outlook too after checking the code again. I suppose what they're seeing looks very much like the robot would take the goal, transform it into local relative coords or something and then go towards it. It basically ends up at where the goal "was" when the action client first sent it, if that makes sense. It sure doesn't to me but that's what we're seeing somehow.

It's usually a mostly lateral error, but often also linear to some small extent. Another theory is that the robot is missing the goal, doing a stop due via the runaway check and then deciding that's close enough, despite it not being in linear tolerance of the goal. None of it makes any sense.

Just to be clear I've removed all hacky bits from the ezmap side in terms of goal sending aborts and such about a month ago, so it's basically just a straightforward send goal, wait for success kind of deal now which unsurprisingly can even get stuck (waiting close to goals for some reason), but I don't see a workaround for it while giving move_basic full control too.

[dorkamotorka]

Yeah that's my outlook too after checking the code again. I suppose what they're seeing looks very much like the robot would take the goal, transform it into local relative coords or something and then go towards it. It basically ends up at where the goal "was" when the action client first sent it, if that makes sense. It sure doesn't to me but that's what we're seeing somehow.

What branch are they using. Generally this is how things were, before I implemented feature-external-force that updates the goal pose while driving: 1ecb855

It's usually a mostly lateral error, but often also linear to some small extent. Another theory is that the robot is missing the goal, doing a stop due via the runaway check and then deciding that's close enough, despite it not being in linear tolerance of the goal. None of it makes any sense.

Runaway check aborts triggers when the robot is pass the goal and most likely out of tolerance of the goal. Even if the robot misses the goal it marks it as done. We could potentially implement recovery behaviour but I don't think this is necessary since when the robot misses the goal(runaway check triggers) it is still in the range of max. 0.1-0.5m, depending upon the speed he was travelling with.

Just to be clear I've removed all hacky bits from the ezmap side in terms of goal sending aborts and such about a month ago, so it's basically just a straightforward send goal, wait for success kind of deal now which unsurprisingly can even get stuck (waiting close to goals for some reason), but I don't see a workaround for it while giving move_basic full control too.

ok, that's good.

[MoffKalast]

Okay so to restart this discussion now that we've got more data.

What branch are they using. Generally this is how things were, before I implemented feature-external-force that updates the goal pose while driving: 1ecb855

Seen on latest master, but I've done some testing this past week on older versions and it seems to check out at least until 0.4.1 It's probably the external force merge that started this bug in some form.

I don't think it's a thing with move_smooth though, so the question is if it's more worthwhile to fix this here or to fix move_smooth to support turning properly on the spot at 0 m radius. Probably the second one I imagine.

[dorkamotorka]

I agree with the second option.