Robot must calculate close RFID tags

[etsardou]

Roadmap:

• [x] Add rfid tags in space
• [x] Add / remove tags from stdr_gui
• [x] Add RFID reader sensor in stdr_robot
• [x] Support RFID Reader sensors in stdr_parser
• [x] RFID readers to receive the rfid tags and post the measurements
• [ ] rfid tags to post their tf (?)
• [x] Add rfid reader support in robot creator in stdr_gui

[czalidis]

I believe this issue is also closed by PR #149. Rfid tags are static and hence posting both a transformation (using tf) and a RfidTagVector.msg to list all active tags would be an overkill. In case of posting a tf transform, GUI has to listen from tf the pose of the tag and from stdr_server/rfid_list topic the rest info which is kind of complicated. I believe it should stay as it is.

@etsardou your thoughts on that, should we leave it as is and close this issue?

[etsardou]

I stated the tf transform not for functionality reasons, but for inspection reasons (see the RFID tags in rviz) and completion (as everything else has tfs).

I think the tag's tf should be added in a later version, in order to cope with any map's origin alterations. So we can close this one and create another enhancement issue. Am i missing anything?

[czalidis]

I think the tag's tf should be added in a later version, in order to cope with any map's origin alterations.

That sounds like a functionality to me. But it is exactly the same thing to read the pose from a message, or from the tf. Thats why we introduced a static frame called map_static, so static things could refer to it.

Think of the following use case: A user has to provide the pose where he likes his tags, either the pose should be measured from the lower left corner of the map (aka. map_static) or from the map's origin (which is also provided by the user). In either way, the user himself has to calculate the transform and provide the correct coordinates, there is nothing to be done by tf. When the user uses the GUI to add a new tag, it is explicitly defining the pose of the tag, so the only thing to decide is the reference frame, which has to be consistent between all tags. Therefore I can not see where a tf transform of a tag would be helpful.

I stated the tf transform not for functionality reasons, but for inspection reasons (see the RFID tags in rviz) and completion (as everything else has tfs).

This is something to talk about. I agree that we should provide some kind of ros friendly visualisation for rfid tags, thermal sources, etc. I am just not sure, if tf is the right thing to do. Imagine having all tf frames enabled in rviz, it would be nearly impossible to understand what is what. In my opinion it would be better for server to provide an rviz Marker on a MarkerArray for visualizing such things. We could also provide an rviz plugin for even easier visualization, based on Marker Array.

My point here is that we do not need tf. If we can find a use case where tf is needed I would happy to discuss it. My other point is, that if we want tf only for visualization we should use visualization stuff instead, like Marker and MarkerArrays.

[etsardou]

I agree with you for both points. So i) we close this issue ii) any tag coordinates refer to the map_static frame (nothing more to be done here) iii) we must implement a visualization method, prefferably based on Markers (new issue under the enhancement tag)

[czalidis]

Ok, I am closing this issue. Preferably, we should implement a visualization method when all kinds of sources (thermals, co2, etc) would be available on stdr_server and when the upcoming reengineering has finished.