Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Specialized Message Parsers #80

Open
ChuiVanfleet opened this issue Feb 2, 2024 · 4 comments
Open

Support for Specialized Message Parsers #80

ChuiVanfleet opened this issue Feb 2, 2024 · 4 comments
Labels
Consider Sponsorship wontfix This will not be worked on

Comments

@ChuiVanfleet
Copy link

The built-in ros2 message parser works well for most types, but there are cases where the built-in parser does not produce usable time-series. For example, If I have a ros2 JointState message, the meaning of each element in the position array depends entirely on the order of joint names. If I have a node that does not publish those joint names in a consistent order, then I cannot plot meaningful data.

Another example may be Transform messages, where the time-series I want to plot does not correlate to the [0]th index in the array of tfs. In this case I would want a time-series based on frame_id/child_frame_id pairs.

It would be very useful to provide some sort of interface that would allow us to provide our own parser per message type. If no specific parser exists, then use the built-in one.

@facontidavide
Copy link
Contributor

If I have a node that does not publish those joint names in a consistent order, then I cannot plot meaningful data.

This is not true (as far as I know), PlotJuggler should handle that just fine. See here:

https://github.com/facontidavide/PlotJuggler/blob/main/plotjuggler_plugins/ParserROS/ros_parser.cpp#L386-L454

and

https://github.com/facontidavide/PlotJuggler/blob/main/plotjuggler_plugins/ParserROS/ros_parser.cpp#L456-L482

Everything you mentioned was solved already. Did you even try?

@facontidavide
Copy link
Contributor

It would be very useful to provide some sort of interface that would allow us to provide our own parser per message type. If no specific parser exists, then use the built-in one.

Possible but complicated. If your company wants to sponsor this development. Let me know.

@ChuiVanfleet
Copy link
Author

Everything you mentioned was solved already.

Indeed, I'm merely using existing public messages as an example to illustrate the need. You've already solved the problem by building in those special parsers into the library. I'd like to provide my own special parsers without having to modify your code and recompile. If I could implement an interface and have the pj-ros-plugins load in my library, I think that would be ideal.

I'm fine doing this work myself on my own time, I'd just appreciate some direction from you on how you'd like to see it done. My first thought is leveraging plugin-lib, and using the message type string as the plugin type, but I don't know how/if it would work with ros1 messages.

Thanks!

@facontidavide facontidavide added the wontfix This will not be worked on label Feb 2, 2024
@facontidavide
Copy link
Contributor

My suggestion is to look at older version of this repo (before version 2.0) or to the current version of ParseROS plugins in PlotJuggler.

Closing this as "wontfix"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Consider Sponsorship wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants