search

ubi-agni / tactile_toolbox

software to handle tactile sensors in ROS
9 stars 5 forks source link

[rviz_tactile_plugin] No taxel displayed but status OK due to wrong channel #36

Closed guihomework closed 1 year ago

guihomework commented 1 year ago

I finally found why I had a TactileState plugin not display any taxels while the status told everything was OK. Problem was that the robot_description had the wrong tactile_channel. 

<tactile channel="tactile glove">

Default is tactile glove (for backward compatibility) while our latest driver does not advertise the channel tactile glove in the msg, but only tactile . We use upload.launch and set the tactile_channel correctly. However display.launch does not offer to pass that info so it was hard to see this was the problem while testing human_hand PR #14

Do you think it is possible to show a warning message if there is no message at all matching the current channel (all messages discarded). The warning should obviously not be there if all messages had matching channels, but also no warning if some messages produced a valid taxel (partially matching channel) during the timeout period.

That would help a lot to debug and find the reason of no display. Maybe status message such as, "None of the mgs with tactile channel X match any sensor description"

rhaschke commented 1 year ago

Do you think it is possible to show a warning message if there is no message

Sure. I'm not yet exactly sure about the conditions when you want to display a warning and where (it could be global to the TactileState display or local to each channel). I don't remember the details of messages and the display now. Let's have a look at it tomorrow.

rhaschke commented 1 year ago

I think #37 is pointing into the direction of this feature request. Please have a look.

guihomework commented 1 year ago

After spending several minutes trying to understand how std::equal_range was functionning at all (never seen this function in my basic programming life yet) I was still not sure I understand how the comparison works on strings to create the 2 range boundaries, but I think I can see that when the span of the range is zero (both boundaries equal), this is equivalent to "none of the input message found a matching channel in the sensor list" and hence produces a one warning on the terminal. This looks like the improvement I was looking for. I would need to test it to confirm. Please stay tuned (in theory only monday, but I will try sooner).

rhaschke commented 1 year ago

Of course, I tested the claimed behavior that a warning is issued once the channel cannot be found. My main questions is: are you satisfied with the ros console warning or do insist in a status warning in rviz (which would be much more costly).

guihomework commented 1 year ago

In general, I am satisfied with a ROS console warning, because I would look at the console, but I known some users won't necessarily even start rviz from console. We had an icon starting a launch file (maybe a terminal, I forgot now) that nobody then looked again in my team, so in such cases, this won't be seen as well, but I believe that the warning message is more required when debugging/preparing a pipeline, rather than users anyway. Once the pipeline is started as a one click app/launch, the problems of matching channels should already have been solved by a developer. Conclusion, warning is sufficient.

rhaschke commented 1 year ago

Ok. Will merge then.