rostopic: Make all numeric fields fixed width for easier reading

[ayrton04]

When viewing, for example, covariances within a nav_msgs/Odometry message, or any message with an array of floating-point values, it can be hard to see the values if the messages are updating frequently. In general, it might be easier to make all numeric fields have fixed width and precision so that each message has a constant character size.

[dirk-thomas]

This would be a great feature. It would probably be best to add a command line option to apply this kind of fixed width output. Please consider providing a PR to add this functionality.

Since it is not likely that the maintainers will have time to work on this feature request I will mark the ticket with the milestone "untargeted".

[ayrton04]

I'll take this on, sure.

[ayrton04]

Any preference as to functionality? Should this apply only to floating point numbers, or to integers and Boolean values as well?

[dirk-thomas]

On the one hand you could print all values of the array fixed length (based on their type). For types where the potential value range is huge compared to the actually used one that might waste a lot of space (e.g. int64). Calculating the necessary max width based on all the values would result in less space but would also jump when the range of the values changes (e.g. from 99 to 100).

On the other hand you could print the array entries in separate line to avoid the dynamic length problem. But then the number of lines per message might be a lot for big arrays.

Depending on the use case either or might make more sense...

[ayrton04]

My original plan was to add a fixed width flag that would simply apply to all numerical values in the message, regardless of whether or not they're part of an array. However, you then start to get ugly output like header sequence numbers with nine spaces before them. For now, I'll make it only for arrays of ints and floats, and will hold off on the line breaks (though I agree that could also work). Thanks for the input!

[dirk-thomas]

This should be addressed with the recently merged PRs in genpy and ros_comm referenced above.