I’m not exactly sure where that comment comes from. Can you clarify? From the quoted REP 105, I think the wording is not ideal, its a little verbose for just trying to say:
The transform from map to odom is provided by a localization (or SLAM, mapping) component. The rest of the words about how that transform is computed are unnecessary. Also the fact it doesn’t mention SLAM, only localization, is interesting. I’m not sure if that was an intentional exclusion or just wasn’t on the mind at time of writing.
AMCL also produces a
PoseWithCovarianceStamped, doesn’t mean it is required to be REP-105 compliant. You can be compliant and also then provide additional information.
Those are indeed 2 valid options of things for robot localization to fuse. In the situation you present where you’re using RL as a localizer, then RL itself is now the “localization component”, and not the inputs to RL. Its then on RL to produce the transformation to be REP 105 compliant. Regardless, the additional publication of other messages (ie
PoseWithCovarianceStamped) are not necessary and shouldn’t be explicitly required for the minimum REP standard in my opinion.
To address your last 3 paragraphs respectively, and to summarize my opinion:
- They should only publish transforms to be minimally compliant
- If you’re fusing multiple sources of data together, using RL or otherwise, then that fused output is now the localization transformation source and that should be complient with REP-105, not the components that came into it.
- Like in publishing addition information (like
PoseWithCovarianceStamped), you’re welcome to also publish intermediate calculations for other frame transformations. However at the end of the day, a source should be providing the
map -> odom transformation. The intermediate steps or additional things you do are application specific and with in the blackbox of a localizer as far as the rest of your system is concerned.
Separately, if you’re asking what I think a localizer should produce, I think that includes a
PoseWithCovarianceStamped. But REP-105 is concerned with frame convention, not localizer conventions. If you wanted to add the requirement to publish a pose, that should be a separate REP since REP-105 is dealing exclusively with frames, usually in TF, which doesn’t take in covariance information. If you’re working with multiple localization components, fusing them, and outputting a composite localization component, I agree each of them should be compliant so they are independently valid as localization components themselves (to have reusability). However, as far as the block diagram of your system is concerned, the “localization component” is the entire entity of the individual elements going into the fusion method and then served to the system. So REP-105 applies to the entirety of it, which is really then just on RL, and the individual localization components do not need to strictly follow the existing REP (but should, if you don’t want to make trouble for yourself).
Summary of this opinion:
- Probably, yeah we should make a new REP for localization / mappers to provide not only REP-105 frames, but also the pose with covariance on update for a potential upstream use.
- Technically as far as REP-105 is concerned, if you use AMCL and a few other methods to fuse together, AMCL nor the other methods are localization components. Only the fusion of them is the localization component requiring to publish the frames.
- I see no drawbacks for this but I’m not sure it should be strictly required. I think it should be an option called out with an explanation for why you might want to include the
PoseWithCovarianceStamped. If you’re using a single algorithm, what you propose doesn’t matter to a user.